Компьютерное управління виробництвом

КОМПЬЮТЕРНОЕ УПРАВЛІННЯ ПРОИЗВОДСТВОМ

Проект обліку користувальних рахунків для інтернет-провайдерів з урахуванням OS FreeBSD із застосуванням програми «Billing ISP».

Курсовой проект виконав студент Іванов М.Н.

САНКТ-ПЕТЕРБУРГСКИЙ ДЕРЖАВНИЙ МОРСЬКИЙ ТЕХНІЧНИЙ УНИВЕРСИТЕТ

САНКТ-ПЕТЕРБУРГ

1999 г.

Предпроектное обстеження об'єкта автоматизации.

Опис предметної області розв’язуваної задачи.

В справжні час багато (ISP) інтернет сервіс провайдерів вирішують проблеми обліку користувальних рахунків, й проблеми контролю над трафіком шляхом написання нових додатків, що часто призводить до частим збоїв даного ПО, і відповідно не відпрацьовує вкладені до нього кошти. З іншого боку, такі продукти неспроможні обслуговувати велика кількість користувальних рахунку також представляти всю оброблену інформацію в компактній, зручною до роботи і аналізу формі. Більшість запропонованих у час систем білінгу, тобто. систем обліку відпрацьованого «он-лайнового «часу користувачами Інтернет-провайдера (ISP) грунтується, зазвичай, на аналізі стандартних лог-файлов таких опирационных систем, як SCO Unix, SunOS, HpOS, AIX, IRIX разів у добу, на тиждень, на місяць та т.д. У той час як запропонована система білінгу основаная принципово інший ідеї, що полягає у контролю над кожної сесією користувача окремо в реальному масштабі часу. Що дає значно знизити час на обробку биллинг-инженером статистики роботи кожного користувача чи групи, знизити трудомісткість занесення платежів користувачів на лицьові рахунки (базі даних програмних засобів) і дозволяє провайдерам зменшити кількість обслуговуючого персоонала, що безпосередньо віддзеркалюється в собівартості наданих послуг.

Функции предметної області, реалізованої задачи.

Основные функціональні переваги такий підхід залежить від тому, що відстежуються і коректно відпрацьовуються, фіксуються і генеруються в звіти такі дані как:

Регистрирование сполуки будь-який тривалості з точністю, рівної одному кванту часу (наприклад, 5 секунд). Квант часу задається системним адміністратором;

Исчерпывание коштів у особовому рахунку користувача, якщо він перебуває в момент як «он-лайн », і примусове його відключення (ця ситуація дуже актуальна, коли ISP надає новому клієнту «тестовий годину »);

Возможность завдання кожному за користувача або заради груп користувачів гнучких прайс-листов із зазначенням ціни на у.о. протягом години «он-лайнового «часу у залежність від часу діб, і дня тижня. Наприклад, є ISP, яка має вартість «денного «(з 9 ранку до 6 вечора) Інтернету — $ 1, а «вечірнього «(з 6-ї вечора до 9 ранку) — $ 0,6. Користувач телефонує без чверті 6-ть вечора навчався і працює 15 хвилин за тарифом $ 1 протягом години і 30 хвилин за тарифом $ 0,6 протягом години (всього 45 хвилин), і з його особового рахунку, відповідно, знімається сума $ 0,25+$ 0,3, тобто. $ 0,55;

Переход користувача з однієї прайс-листа на другий, при исчерпывании коштів у особовому рахунку У першій схемою і за авансовому платежі з іншого прайс-листу без відключення користувача. Реально це ситуацію, коли користувач за одним прайс-листу, і коли його стали закінчуватися вартість особовому рахунку, він зробив новий внесок, але вже іншому (наприклад, «пільговому ») прайс-листу. Потім він допрацював свої годинник по «старому «прайс-листу і спокійно почав працювати по «новому «прайсу-листу;

Удаленным користувачам надається зручний www-интерфейс з якого можуть повністю контролювати працювати Інтернеті до кожного модемного дзвінка на вузол ISP, зокрема, зрозуміло, вони у час подивитися розмір свого особового рахунку на момент (момент генерування web звіту з даних програми «Billing ISP».

Cистемному адміністратору (биллинг-инженеру) надається досить простий лідера в освоєнні стандартного Unix систем режим командної рядки, відкритість, простота і можливість «заточування «системи під свої конкретні особенности.

Основные якості й особливо запропонованої системи биллинга

Высокая точність підрахунку «он-лайнового часу «відпрацьованого користувачами;

Простая інтеграція запропонованої системи в існуючу систему їм аутентифікації DialUp-пользователей провайдера (забігаючи вперед, хочеться відзначити, що у сьогодні наша система підтримує лише схеми TACACS+ і pppd);

Возможность розгортання запропонованої системи паралельно із вже існуючою системою білінгу провайдера для тестування і налагодження з єдиною метою остаточного запуску в експлуатацію;

Автоматическое отримання щоденних (щотижневих, щомісячних) звітів відпрацьованих годинників та їх вартості за групами клієнтів (наприклад, «основний тариф », «пільговий тариф », «бартер », «халява »);

Возможность підключення SQL-сервера для генерації гнучкішою системи статистик з допомогою SQL-запросов;

Минимальные вимоги до апаратним ресурсів серверу білінгу (запропонована система може функціонувати навіть без SQL-сервера). Проте, www-сервер (Apache) все-таки слід встановити здобуття права віддалені користувачі мали доступом до своєї статистики через звичний www-интерфейс;

Своевременное оповіщення користувача і системного адміністратора через e-mail у тому, що розмір особового рахунку користувача наближається до кінця;

Гибкое ведення прайс-листов по групам користувачів, їх швидка і нескладна модифікація (наприклад, установка «святкового тарифу «коли «народну гулянку «випадає на середину тижня);

Возможность віддаленого адміністрування користувачів

P. S. У вище описане тексті застосовуються деякі фахові терміни які стосуються різним клонам Unix систем, і навіть до общесистемному професійному ПО такі як:(демон, Apache, pppd, домашній каталог користувача, ядро, сервер білінгу, лог-файл, користувач, www-интерфейс, SQL тощо.), які потребують додаткових коментарях. Описание даних термінів можна порівняти з повноцінним книжковим виданням, унаслідок чого воно не присутній. Короткі пояснення можна було одержати у упорядника даної курсової работы.

Организационно-экономическая сутність задачи.

Использование цього комплексу програмного забезпечення дозволить невеличкому интерне-провайдеру значно знизити собівартість послуг за коммутационному підключенню своїх абонентів, а також відкрити їм зручну систему тарифних планів, тестових підключень, систему аналізу та моніторингу власних рахунку також статистики підключень, що природно сприяє зростанню клієнтів і збільшення прибутку нашого ISP.

Также слід зазначити, що основна економія коштів відбувається поза рахунок використання абсолютно безплатного програмного забезпечення, саме ОС FreeBSD і системи обліку «Billing ISP», які поширюються з відкритою вихідному кодом по ліцензії GNU не мають обмежень на число копій тощо. Наявність вихідного коду даних продуктів дає можливість адаптації їх під вже існуючі бухгалтерські програми розвитку й системи обліку. Також значна економія відбувається поза рахунок небагатьох технічного персоналу обслуговуючого цю систему. По персоналу можна назвати, що управляти даної системою можуть фахівці низьку кваліфікацію, тобто. саме система «BillinISP» не вимагає поглибленого знання Unix подібних опирационных систем, мережевих технологій і найскладнішого мережного устаткування такого як CISCO, отож, що зарплатню такого робітника щодо невелика. У водночас середня зарплатню сертифікованого фахівця коштує від 500 $-1500 $. Природно, що з підтримки системи в актуальному стані такі працівники необхідні, але з допомогою застосування цієї схеми їх кількість можна значно зменшити без втрати якості обслуговування клієнтів.

Для довідки деякі комерційні операційні системи можуть досягати вартості 5000 $, при це з обмеженою кількістю установок і з обмеженою числом користувачів плюс до цьому близько 2000;3000 $ може коштувати яка був посередня биллинговая система.

Из всього вище сказаного видно, що з застосуванні даного програмного забезпечення інтернет-провайдери отримують істотну выгоду.

Разработка інформаційного забезпечення задачи.

Описание вхідний информации.

Основным вхідним документом, з яким взаємодіє розглянута биллинговая система це копія платіжного доручення користувача ISP. При реєстрації клієнта провайдер пропонує йому вибрати встановлений тариф (прайс-лист) на послуги комутованого підключення на певне (тарифом) час, яким клієнт перераховувати встановлену гроші. Після реєстрацію ЗМІ й передоплати послуг нашого ISP з цього приводу (в домашній каталог користувача копіюються певний набір файлів див. нижче) користувача надходить певна прайс-листом сума, що у процесі роботи користувача в інтернеті зменшується через певний тарифом (прайс-листом) квант на певну суму. Відповідно, всі, що робить друга програми білінгу інша значна її частина фіксує всі у базі даних, і у тому особистому каталозі користувача в окремий лог-файл виходячи з, якого і генеруються звіти користувачеві й адміністратору. Також до вхідний інформації можна віднести: відрахування з користувальницького рахунки, проведене час у інтернеті, час підключення (реєстрації у системі). З викладеної вище інформації допоміжний модуль програми билинга може надавати докладну статистикуего рахунки користувача, як адміністратору і самому клієнту ISP.

Файл завдання прайс-листа (тарифної схеми) — account. conf

#.

#.

# Приклад файла account. conf (.account.conf). # Лідируючі прогалини, порожні строки,.

# рядки, які з символу «# «игнорируются.

# Обробляються лише рядки, які з ключевого.

# слова «price: ». Кількість рядків «price «неограченно.

# Формат прайс-листа (тарифної схеми) ;

# price: День_недели, час_начала-час_окончания $стоимость_в_у.е.

# що він відповідає проміжку времени.

# час_начала:00-час_окончания:59.

# Якщо за вказуванні тимчасові діапазони перетинаються, то стоимость.

# години приймається последняя.

# Основна тарифна схема. # Ціна: в будні дні з 10:00—18:00 — $ 1.

# в проміжку — $ 0,6.

#.

#.

comment: Поле_comment_будет_автоматически_выводиться_при_запуске.

comment: демома_в_режиме_получения_сведений_о_размере_лицевого.

comment: счета_пользователя._Удобно_использовать_для_задания_комментарий.

comment: к_прайс_листу.

commenth:

commenth: Поле_commenth_выводится,_если_размер_лицевого_счета.

commenth: выдается_в_html_формате._Пробелы_должны.

commenth: заменяться_на_подчеркивания._Количество_строк_comment_и.

commenth: commenth_не_ограничено,_однако_суммарная_длина_каждой_не.

commenth: не_должна_превышать_1000_символов.

price: Monday, 0−9 $ 0.6.

price: Monday, 10−17 $ 1.

price: Monday, 18−23 $ 0,6.

price: Tuesday, 0−9 $ 0.6.

price: Tuesday, 10−17 $ 1.

price: Tuesday, 18−23 $ 0,6.

price: Wednesday, 0−9 $ 0.6.

price: Wednesday, 10−17 $ 1.

price: Wednesday, 18−23 $ 0,6.

price: Thursday, 0−9 $ 0.6.

price: Thursday, 10−17 $ 1.

price: Thursday, 18−23 $ 0,6.

price: Friday, 0−9 $ 0.6.

price: Friday, 10−17 $ 1.

price: Friday, 18−23 $ 0,6.

price: Saturday, 0−23 $ 0.6.

price: Sunday, 0−23 $ 0.6.

Описание файлів в домашньому каталозі користувача з «біллінгової інформацією «.

.pay — інформацію про нарахуваннях (історія нарахувань) на лицьової рахунок користувача доларів чи $. Файл має формат виду:

#.

#.

# Платежі клієнта ivan.

#.

#.

1999/02/27 13:00:01 Add pay | 10.5.

1999/03/15 15:12:00 Add pay | 23.

1999/05/05 12:30:40 Add pay | 6.5.

Как видно, даний файл має дві поля довільній довжини розділені символом «| «. Перше (ліве) полі містить коментар чи, інакше кажучи, обгрунтування другого (правого) поля, де міститься число з плаваючою точкою, що б вартість транзакції, тобто. вартість біллінгової інформації. Основна єдина одиниця виміру біллінгової інформації - умовна одиниця чи $. Якщо наведений раніше файл міститься у домашньому каталозі користувача ivan, то, підсумувавши друге (праве) полі, бачимо, що «загальний розмір нарахувань на лицьової рахунок (чи платежів) клієнта ivan дорівнює 40 умовним одиницям. Відкривши цей файл, системний адміністратор чи користувач ivan може лише дізнатися скільки взагалі було нараховано даний лицьової рахунок, але те, коли (ким) це було зроблено (забігаючи вперед, хочеться відзначити, що такий спосіб зберігання біллінгової інформацією звичайних текстових файлах, тобто. «дата, обгрунтування операції | розмір », є основним для запропонованої системи). Додавати чи змінювати інформацію в файлах .pay має лише системний адміністратор. Робити це можна зробити що з командної рядки, і через веб-інтерфейс;

.weekly — інформація про відрахуваннях (історія відрахувань) з особового рахунку користувача в умовних одиницях за фактичну роботу за минулий тиждень в кожному з'єднанню (по кожної наданої послузі). Формат файла аналогічний формату файла .pay.

#.

#.

# Робота клієнта ivan за поточну неделю.

#.

#.

1999/05/18 13:00:01 Time elapsed=40 sec., cost | 0.052.

1999/05/19 15:12:00 Time elapsed=1200 sec., cost | 0.156.

1999/05/19 16:30:40 Time elapsed=75 sec., cost | 0.101.

Запись в файл. weekly робить демон по закінченні сполуки. У наведеному вище фрагменті файла. weekly в першому полі міститься наступна інформація: дата закінчення сполуки (YYYY/MM/DD), вреня закінчення сполуки (HH:MM:SS), тривалість з'єднання перетворені на секундах (Time elapsed). У другому полі файла. weekly, від'єднаного символом «| «міститься вартість транзакції (вартість сполуки, вартість фактично наданої послуг у умовних одиницях);

.work — інформація про відрахуваннях (історія відрахувань) з особового рахунку користувача по за цілі тижні на сумі. Наприкінці кожної тижня друге полі файла. weekly підсумовується і підсумкова сума заноситься в файл .work.

1999/05/18 1999/05/25 cost | 5.011.

1999/05/26 1999/06/01 cost | 2.133.

Файлы .weekly у домашніх каталогах користувачів «розбухають «через те, що в ній протоколюється кожне з'єднання. З іншого боку, як свідчить практика, більшості користувачів цікавий лише докладний звіт використання машинного часу за поточну і тиждень, тому інформація, нагромаджена в файлах. weekly повинна «компрессироваться ». Якщо ж користувачеві потрібно надати докладний звіт до праці двох- (трьох-, чотирьохтощо.) минулого тижня (що відбувається нечасто), то цю інформацію системний адміністратор може «витягти «з SQL-базы. Оновленням файлів .work, .weekly і .weekly.last має займатися спеціальна програма w_update.pl, запускаемая по крону щотижня;

.weekly.last — копія файла. weekly за тиждень;

.current — поточний розмір особового рахунку користувача в умовних одиницях, файл оновлюється після завершення сесії даного користувача, служить для «швидкого «обчислення розміру особового рахунку користувача, наприклад, при старті нового соединения;

.time — наявність такого файла (під наявністю файла мається на увазі файл з цим ім'ям будь-який довжини, у цьому однині і нульової, доступним читання в момент) сигналізує у тому, що баланс особового рахунку користувача завжди позитивний. У російській мові зазвичай під цим розуміють солодке слово «халява ». Зрозуміло, цей файл передусім повинен мати, наприклад, співробітники ISP та найближчі родичі ;-).

.refused — наявність такого файла сигналізує у тому, що баланс особового рахунку користувача завжди негативний, тобто. доступ то систему тимчасово призупинений;

.type — тип користувача (наприклад, «свій », «халява », «бартер », «гроші «). Служить для розподілу користувачів на групи, з яких подальшому генерується статистична інформація;

.account — тип (чи індекс) прайс-листа для даного користувача. Цей файл зручне використовуватиме завдання прайс-листа окремим групам користувачів. Ви створюєте бажаний прайс-лист і поміщаєте їх у каталог /var/statserv/etc, а користувачам у домашніх каталогах вказуєте лише посилання нього. Якщо ви хочете поміняти прайс-лист для деякою групи користувачів, то, Ви редагуєте прайс-лист лише у одному місці ми (див. нижче «Алгоритм вибору тарифної схеми для користувача при старті демона »);

.account.conf — власний прайс-лист для даного користувача. Див. структуру файла.account.conf. Цей файл треба використовувати у разі, коли ви хочете поставити для користувача індивідуальний прайс-лист;

.pay.next — авансовий платіж, чи таке нарахування на лицьової рахунок користувача після скасування поточного особового рахунку. Можливо використано у разі, коли користувач не вичерпав поточний лицьової рахунок, проте оплатив таку послугу як раніше чи новому прайс-листу;

.account.next — те, як і .account (див. вище), але для авансового платежа.

Опис вихідних документов.

В результаті роботи біллінгової програми всю інформацію на роботу користувач, як уже зазначалося вище, фіксується в лог-файлах і базі даних. Це є основним базисом для генерації звітів і статистики. Вилучувані дані можуть бути в ролі структурованих таблиць, або у формі звітів по запрашиваемым даним. Ця інформація, є також підтвердженням те, що користувач працював у мережі у разі претензій последнего.

Список інформації - даних, які пропонують користувачеві й системному адміністратору (биллинг-инженеру):

Время реєстрації користувача в конкретний день Оставшаяся сума справа рук у пользователя Время, проведене сети Статистика роботи у мережі по дням, тижнів і месяцам Почтовое повідомлення користувача і адміністратора про закінченні грошового взноса.

Общая структурована таблиця статистики за певного періоду времени При генерації вищезазначеної інформації використовуються додаткові модулі програми «Billing ISP» й системніші програми Unix такі як, CGIмодулі (для звернення до баз даних, і генерації HTML коду і форм чи листів), Apache web server (висновку на екран HTML коду згенерованого CGI програмою), MTA Sendmail (для відправки електронного листи користувачеві про закінчення счета).

Описание технологій і алгоритмів виконання завдання та його машинна реализация.

Описание входження у базі даних вхідний информации.

Отличительная риса аналізованої програми з інших варіантів даної курсової роботи, є повністю ароматична генерація і занесення до бази даних інформації крім створення самих рахунків користувачів. Це визначається основному специфікою даного програмного продукту і операційній середовища, де він работает.

Алгоритм нарахування умовних одиниць на лицьової рахунок пользователя Если файл .pay в домашньому каталозі користувача відсутня, то занести розмір платежу в файл .pay, а індекс прайс-листа в файл.account. Перехід до пункту 3;

Вычислить поточний розмір особового рахунку користувача. Якщо він негативний чи нульовий, то черговий платіж заноситься в файл .pay, а обраний індекс прайс-лист в файл.account. Якщо поточний розмір особового рахунку користувача позитивний, то черговий платіж заноситься в файл .pay.next, а обраний індекс прайс-листа в файл.account.next;

Обновить файл. current з поточним розміром особового рахунку;

Занести платіж в таблицю «ПЛАТЕЖІ «бази даних (опционально).

Алгоритм фіксації у базі статистичної информации Введение.

Рассматриваемый програмний продукт безпосередньо залежить від системних викликів операційній середовища, де він працює, в тому числі від деяких додатків, наприклад PPPD (назва цього демона походить від назви протоколу сполуки користувача і провайдера Point to Point Protocol), syslog (системна програма, фіксуючої перебування користувача у системі, і навіть фіксує в лог-файлы повідомлення ядра ОС). У зв’язку з, що описи даних продуктів це тема окремої курсової роботи, даний алгоритм буде описаний поверхностно.

При поєднанні користувача до провайдеру запускається програма Mgetty, яка управляє і инициализирует роботу модему. Запуск даної програмы фіксується в системних лог-файлах системи. Після цього її запуску вона активізує, у нашій випадки демон PPPD, який у часи чергу принемает і реєструє користувальні запити, й після перевірки всього потрібного впускає чи ні в систему. Усі дії даних сервісів після сполуки відстежує програма syslog, що й генерує основну базу дій користувача в системе.

Billing ISP, як зазначалося вище безпосередньо взаємодіє зі PPPD перевіряючи актуальність даного підключення й у випадки вдалого входу змінює (зменшує) за певний квант часу рахунок пользователя.

Также демон білінгу з сполуки користувача починає вести підрахунок час перебування користувача з певним зміною в SQL базі полей.

Обобщенный алгоритм рішення задачи.

Ядром запропонованої системи є спеціально написаний демон «білінгу «(надалі просто демон), здійснює контролю над израсходованнным часом і/або умовними одиницями користувача, що у сьогодні у режимі «он-лайн ». Демон запускається в останній момент входу користувача до системи, після закінчення одного кванта часу (наприклад, 5 секунд) знімає вини з лицьового рахунки користувача вартість одного кванта відповідно до діючу пенсійну систему цей час ціною, яка, до речі, не може змінюватися залежно від часу діб, а після завершення сеансу зв’язку демон припиняє своєї роботи, протоколюючи інформацію про тривалості сеансу зв’язку й відпрацьованою вартістю спеціальний лог-файл в домашньому каталозі користувача і за необхідності, у загальну SQL-базу даних. Інакше кажучи, окрема копія демона є постійною у пам’яті серверу білінгу і «стежить «за користувачем протягом усього сеансу зв’язку. Інформації про нарахуваннях на лицьової рахунок користувача і виведення з особового рахунку за фактично відпрацьоване «он-лайновое «час (так звана «биллинговая інформація ») зберігається у домашніх каталогах користувачів у звичайних текстових файлах. Тобто. кожному за користувача створюється свій набір файлів з біллінгової інформацією. Відповідно, обчислення розміру особового рахунку користувача відбувається виходячи з вмісту цих файлів. Таке розподілене зберігання біллінгової інформації з кожному користувачеві забезпечує простоту побудови системи, отже надійність, і дає можливість організації нескладної системи доступу до лицьовим рахунках через www-интерфейс. У водночас, така сама інформація, але трохи й інші вигляді зберігається в SQL-базе, проте вона використовуються виключно для генерації статистичної інформації наданої системному администратору.

Алгоритм виконання окремих модулей.

Алгоритм обчислення лицьового рахунки перед входом користувача в систему Данный алгоритм повинна реалізовувати програма, виконує аутентификацию користувача (TACACS+ чи pppd) на етапі підключення його до Інтернету. У цілому цей разі основну роль повинен грати файл. current, який містить вже розрахований значення розміру особового рахунку, т.к. в момент розмір особового рахунку повинен бути отриманий практично миттєво.

Если файл. refused присутній в домашньому каталозі користувача, то поточний розмір особового рахунку приймається негативним. Перехід до 5 пункту;

Если файл .time є у домашньому каталозі користувача, то поточний розмір особового рахунку приймається позитивним. Перехід до 5 пункту;

Если файл. current присутній в домашньому каталозі користувача, те з нього береться поточний розмір лицьового рахунки (файл .current оновлюється щоразу після роботи демона). Перехід до 5 пункту;

Текущий розмір особового рахунку обчислюється за такою формулою: «загальна сума нарахувань з файла .pay мінус загальна сума відрахувань з файла .work мінус загальна сума відрахувань з файла. weekly » ;

Если поточний розмір лицьового рахунки позитивний, доступ до системи користувачеві разрешатеся, у протилежному разі - запрещается.

Алгоритм вибору прайс-листа (тарифної схеми) для користувача при старті демона Если в домашньому каталозі користувача перебуває файл.account.conf, то прайс-лист для даного користувача читається від цього файла;

Если в домашньому каталозі користувача присутсвует файл. account, те з нього читається перша рядок, яка додається в слову account, до отриманої рядку додається розширення .conf, отже файл з прайс-листом з отриманим ім'ям читається з каталогу /var/statserv/etc;

Если файли.account.conf і .account відсутні в домашньому каталозі користувача, то прайс-лист для даного користувача читається з файла /var/statserv/etc/account.conf (прайс-лист за умовчанням).

Действия, що їх за демона при старте Анализирует командний рядок. У ролі першого параметра йому передається ім'я користувача, як друге — NAS-порт (чи пристрій, наприклад, /dev/cuaa2), як третього — адресу NAS-сервера (третій параметр потрібен у разі коли в провайдера більш одного NAS «a);

Выбирает прайс-лист (тарифну схему) для користувача (див. «Алгоритм вибору прайс-листа для користувача при старті демона »);

Проверяет присутність у домашньому каталозі файла .time, коли він є - зводить відповідний прапорець в зміну us. unoff=1;

Проверяет присутність у домашньому каталозі файла. refused, коли він є - зводить відповідний прапорець в зміну us. refused=1;

Вычисляет значення лицьового рахунки користувача (див. пункт 4 «Алгоритму обчислення особового рахунку при вході користувача до системи »). Навіть якщо взяти розмір особового рахунку негативний, демон однаково продовжуватиме роботу, оскільки з закінченні першого ж кванта часу він, за необхідності, подасть сигнал відключення цього користувача;

Демонизируется ;-);

Записывает свій PID в файл з ім'ям NAS-порта до каталогу /var/run (якщо в провайдера довше NAS «a — то необхідно модифікувати демон, щоб уникнути конфліктів у каталозі /var/run між NAS «амі);

Программирует власний таймер на поставлене квант часу й входить у нескінченний цикл, вивести ринок із якого може лише SIGHUP.

Действия, що їх за демона при закінченні одного кванта времени Обновить лічильник (в секундах) тривалості поточного сполуки, відповідно до чинним тарифом обчислити вартість одного кванта часу, оновити зміну у якій накопичується вартість поточної сесії;

Проверить, чи користувач досі на системі - переглянути файл /var/run/utmp. Якщо користувача в системі немає, то викликати процедуру, виконувану при завершенні сесії;

Если користувач не вичерпав свій лицьової рахунок, то чекати витікання наступного кванта часу. У протилежному разі описані нижче дії виникають при исчерпывании коштів у особовому рахунку:

Проверить, чи ринковий цей користувати «привелегированным ». І тому оцінити прапорець us.unoff. Якщо us. unoff==1, то чекати витікання наступного кванта часу;

Проверить, була викликана програма /var/statserv/bin/killuser, якщо так — то чекати витікання наступного кванта часу. Річ у тім, що через особливостей побудови деяких систем аутентифікації, при исчерпывании коштів у особовому рахунку, фактично користувач відключається не відразу після виклику програми /var/statserv/bin/killuser, а ще через певний інтервал часу;

Если файл .pay.next відсутня в домашньому каталозі користувача, отже, користувача необхідно примусово відключити. Перехід до пункту 9;

Прочитать суму з файла .pay.next. Переписати їх у файл .pay. Видалити файл .pay.next. Обчислити поточний розмір особового рахунку користувача. Якщо він негативний, то перехід до пункту 9;

Перечитать новий прайс-лист з файла.account.next. Видалити файл.account.conf, коли він присутній. Перейменувати файл.account.next в файл. account й уміє чекати витікання наступного кванта часу.

Вызвать програму /var/statserv/bin/killuser з параметрами имя_пользователя і NAS-порт, яка пошле сигнал відключення користувача;

Действия, що їх за демона при завершенні сессии При завершенні сесії сервер аутентифікації TACACS (чи pppd) читає PID демона з каталогу /var/run/ і посилає йому SIGHUP (може бути, також інший варіант, коли демон постійно сканує файл utmp і виконує нижче описані дії, якщо користувач «изчез «з файла utmp). Демон видаляє файл зі своїми PID-ом з /var/run/, записує інформацію про хіба що завершеною сесії в файл. weekly, оновлює файл. current з поточним розміром особового рахунку користувача і викликає скрипт /var/statserv/bin/close_session. з параметрами имя_пользователя, NAS-port, продолжительность_сессии, стоимость_сессии.

Контрольный пример.

Описание використання демона биллинга

Демон billing є ядром запропонованої системи обліку користувачів для ISP. Він може працювати у двох режимах — в «основному «режимі (тобто. режимі демона) контролю особового рахунку користувача у реальному масштабі часу й в «допоміжному «режимі видачі даних про розмірі особового рахунку користувача чи контролю правильності завдання тарифної схеми. Нижче наведені всіх можливих ключі запуску і параметри командної рядки:

/var/statserv/bin/billing.

Usage error: billing [-vdeashtpPrRwW] [username] [port] [nas].

— v show version and exit.

— d daemonize billing.

— e increase debug level in daemonize mode.

— a show current price.

— з show current account for sysadmin.

— p. s show current account.

— h show current account in HTML format.

— t total user account.

— p show payP show pay history.

— n show pay. nextN show pay. next history.

— r show workR show work history.

— w show weeklyW show weekly history.

Режим демона — запуск з ключемd. Далі йдуть обов’язкові параметри — ім'я користувача, NAS-порт (порт модему) й ім'я NAS-сервера (якщо NAS-сервер у ISP один, цей параметр вибирається довільно, проте зовсім опускати його не можна). Приклад:

/var/statserv/bin/billingd jackson Async2 access.provider.net.

Режим видачі даних про розмірі особового рахунку користувача — запуск з ключемp. s і єдиним параметром — ім'ям користувача. Приклад:

/var/statserv/bin/billingp.s jackson.

В даному варіанті на стандартний висновок щось виводиться, а «знак «особового рахунку відбивається у коді повернення. Якщо розмір особового рахунку більше або рівний нулю, тобто. доступ користувачеві до системи дозволено, то billing повертає число 0, коли менш ніж нуля, тобто. доступ користувачеві до системи обмежений, то billing повертає число 1.

/var/statserv/bin/billingst jackson.

На стандартний висновок виводиться загальний розмір особового рахунку користувача в plain text. Див. п. 4 алгоритму обчислення розміру особового рахунку користувача.

/var/statserv/bin/billingspt jackson.

На стандартний висновок виводиться загальний розмір нарахувань на лицьової рахунок користувача та її загальний розмір в plain text. Алгоритм обчислення особового рахунку той самий. КлючP задає висновок історії нарахувань.

/var/statserv/bin/billingз jackson.

Соответствует виклику.

/var/statserv/bin/billingstpnrw jackson.

т.е. найбільш «употребительному «використанню billing з погляду системного адміністратора. Виклик billing з ключемh, наприклад.

/var/statserv/bin/billingshtpnrw jackson.

выводит інформацію про особовому рахунку користувача в HTML-формате у тому, щоб їх можна було надавати користувачеві через www-интерфейс;

Режим перевірки алгоритму вибору прайс-листа для користувача. Виклик:

/var/statserv/bin/billinga jackson.

Предназначен лише заради системного адміністратора щоб контролювати правильність завдання тарифної схеми для даного користувача.

Список литературы

Для підготовки даної роботи було використано матеріали із сайту internet.