КОМПЬЮТЕРНОЕ УПРАВЛІННЯ ВИРОБНИЦТВОМ

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

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

Санкт-Петербурзький ДЕРЖАВНИЙ МОРСЬКИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

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

1999

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

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

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

Опції предметної області, що реалізується завдання.

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

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

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

Можливість завдання для кожного користувача або для груп користувачів гнучких прайс-листів з зазначенням ціни в у.о. за 1 годину "он-лайнового" часу в залежності від часу доби і дня тижня. Наприклад, є 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, і, таким чином файл c прайс-листом з отриманим ім'ям читається з каталозі/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

-c show current account for sysadmin

-s show current account

-h show current account in HTML format

-t total user account

-p show pay-P show pay history

-n show pay.next-N show pay.next history

-r show work-R show work history

-w show weekly-W show weekly history

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

/var/statserv/bin/billing-d jackson Async2 access.provider.net

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

/var/statserv/bin/billing-s jackson

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

/var/statserv/bin/billing-st jackson

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

/var/statserv/bin/billing-spt jackson

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

/var/statserv/bin/billing-c jackson

Відповідає викликом

/var/statserv/bin/billing-stpnrw jackson

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

/var/statserv/bin/billing-shtpnrw jackson

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

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

/var/statserv/bin/billing-a jackson

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

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

Для підготовки даної роботи були використані матеріали з сайту http://www.ed.vseved.ru/