Реферат: Проект учета пользовательских счетов для интернет-провайдеров на базе OS FreeBSD с применением программы "Billing ISP"

САНКТ-ПЕТЕРБУРГСКИЙГОСУДАРСТВЕННЫЙ

МОРСКОЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

КУРСОВАЯ РАБОТА

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

                                                                    

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

                                                                                           

                      

ВЫПОЛНИЛ:

СТУДЕНТГРУППЫ 6420

Иванов М.Н.

ПРОВЕРИЛ:

НАУМОВА .

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

1999г.

Разделыкурсового проекта:

1.     Предпроектное обследование объектаавтоматизации.

           

           

           

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

           

           

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

           

           

           

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

1.     Предпроектное обследование объектаавтоматизации.

 

1.1.                    Описание предметной областирешаемой задачи.

В настоящие время многие (ISP) интернет сервис провайдеров  решают проблему учета пользовательскихсчетов, и проблему контроля трафика путем написания новых приложений, чтозачастую приводит к частым сбоям данного ПО, и соответственно не оправдывает вложенные в него средства. Кроме того,такие продукты не способны обслуживать большое число пользовательских счетов ипредставлять всю обработанную информацию в компактной, удобной для работы ианализа форме. Большинство предлагаемых в настоящее время систем биллинга, т.е.  систем учета отработанного«он-лайнового» времени пользователями Интернет-провайдера(ISP)  основано, как правило, на анализе стандартных лог-файловтаких опирационных систем, как SCO Unix, SunOS, HpOS, AIX, IRIX  раз в сутки, в неделю, в месяц и т.д. В товремя как предлагаемая система биллинга основаная принципиально другой идее, заключающейся вконтроле за каждой сессией пользователя в отдельности в реальном масштабевремени. Что позволяет значительно снизить время на обработку биллинг-инженером статистики работы каждого пользователяили группы, снизить трудоемкость занесения платежей пользователей на лицевыесчета (базу данных этой программы) и соответственно позволяет провайдерам уменьшить количество обслуживающего персоонала, что непосредственно отражается на себестоимостипредоставляемых услуг.

1.2.                   

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

Регистрирование соединения любой продолжительности с точностью, равной одному кванту времени (например, 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 и т.д.), которыенуждаются в дополнительных комментариях. Описания данных терминов можносравнить с полноценным книжным изданием, вследствие чего оно здесь неприсутствует. Короткие пояснения можно получить у составителя данной курсовойработы.

1.3.                   

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

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

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

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

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

2.1.                   

Основным входным документом, с которым взаимодействуетрассматриваемая биллинговая система это копияплатежного поручения пользователя 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), продолжительность соединения в секундах (Timeelapsed). Во втором поле файла .weekly,отделенного символом "|" содержится стоимость транзакции(стоимость соединения, стоимость фактически предоставленной услуги в условныхединицах);

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

    1999/05/181999/05/25 cost                        | 5.011

    1999/05/261999/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 (см. выше), но только дляавансового платежа.

2.2. Описание выходныхдокументов.

В результате работы биллинговойпрограммы вся информация о работе пользователь, как было сказано выше,фиксируется в лог-файлах и базе данных. Это являетсяосновным базисом для генерации отчетов и статистики. Извлекаемые данные могутбыть представлены в качестве структурированных таблиц, либо в форме отчетов позапрашиваемым данным. Данная информация, также является подтверждением того,что пользователь работал в сети на случай претензий последнего.

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

1.    

2.    

3.    

4.    

5.    

6.    

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

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

 

3.1.                   

Отличительная черта рассматриваемой программы от другихвариантов данной курсовой работы, является полностью ароматическая генерация изанесение  в базу данных информации заисключением создания самих счетов пользователей. Это определяется в основномспецификой данного программного продукта и операционной среды, в которой онработает.

Алгоритм начисления условных единиц на лицевой счетпользователя

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

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

3.     Обновить файл .current с текущим размером лицевого счета;

4.     Занести платеж в таблицу«ПЛАТЕЖИ» базы данных (опционально).

Алгоритм фиксации вбазе статистической информации

Введение.

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

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

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

3.    биллинга смомента соединения пользователя начинает вести подсчет времени пребыванияпользователя с соответствующим изменением в SQL базе полей.

           

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

           

Алгоритм вычисления лицевого счета при входепользователя в систему

Данныйалгоритм должна реализовывать программа, выполняющая аутентификациюпользователя (TACACS+ или pppd) на этапе подключенияего к Интернету. В этот случае основную роль должениграть файл .current, который содержит ужевычисленное значение размера лицевого счета, т.к. в данный момент размер лицевогосчета должен быть получен практически мгновенно.

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

2.     Если файл .time присутствует в домашнем каталоге пользователя, тотекущий размер лицевого счета принимается положительным. Переход к пункту 5;

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

4.     Текущий размер лицевогосчета вычисляется по формуле: «общая сумма начислений из файла .pay минус общая сумма отчислений из файла .work минус общая сумма отчислений из файла .weekly»;

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

Алгоритм выбора прайс-листа(тарифной схемы) для пользователя при старте демона

Если в домашнем каталоге пользователя находится файл .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. Действия, выполняемые демоном при истечении одногокванта времени

1.    Обновить счетчик (в секундах) продолжительности текущего соединения, всоответствии с действующим тарифом вычислить стоимость одного кванта времени,обновить переменную в которой накапливается стоимость текущей сессии;

2.     Проверить, присутствует липользователь все еще в системе — просмотреть файл /var/run/utmp. Еслипользователя в системе нет, то вызвать процедуру,выполняемую при завершении сессии;

3.     Если пользователь неисчерпал свой лицевой счет, то ждать истечение следующего кванта времени. Впротивном случае описанные ниже действия возникают при исчерпывании средств налицевом счете:

4.     Проверить, является ли этотпользовать «привелегированным». Для этого посмотреть на флажок us.unoff. Если us.unoff==1,то ждать истечение следующего кванта времени;

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

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

7.     Прочитать сумму из файла .pay.next. Переписать ее в файл .pay.Удалить файл .pay.next. Вычислить текущийразмер лицевого счета пользователя. Если он отрицателен, то переход к пункту 9;

8.     Перечитать новый прайс-лист из файла .account.next.Удалить файл .account.conf, если онприсутствует. Переименовать файл .account.nextв файл .account и ждать истечение следующегокванта времени.

9.     Вызвать программу /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,продолжительность_сессии, стоимость_сессии.

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

Описание использования демона биллинга

Описаниеиспользования демона биллинга

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

/var/statserv/bin/billing

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

   -v  show version and exit

   -d  daemonizebilling

   -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 HTMLformat

   -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

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

еще рефераты
Еще работы по компьютерным сетям