ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [inet-admins] tac+ia



On Wed, 12 Apr 2000, Sergey Sorokin wrote:

SS>> Мне кажется, что проблем с блокировками будет гораздо меньше (или не будет
SS>> вовсе), если пользовать нечто более заточенное под взаимодействие
SS>> точка-многоточка, чем пайпы.
SS>> 
SS>>  Это:
SS>>    - sockets
SS>>    - system V IPC (очереди сообщений)
SS>> 
SS>
SS>А никому не кажется что тут начинают изобретать масло масленное? Tacacs
SS>он и прдуман как система передачи аккаунтинга/авторизации через
SS>сокеты... Тогда уже действительно разумнее придумать модули типа
SS>плугинов для работы с разными базами.

  Он-то так и придуман. Но вопрос в том, что необходимо к нему подключать
разные способы авторизации. Можно их включать непосредственно в код такакса,
что не очень хорошо (сложно управлять всем проектом, каждый модуль захочет
пользовать что-то не[до]документированное), а можно организовать эти модули в 
виде отдельных процессов. Да, такакс это протокол для авторизации
через сокеты. И мы можем каждый модуль сделать такакс сервером и на запрос к
основному серверу порождать запросы к ведомым. Правда, в данном случае ведомые
будут сидеть физически на том же сервере, им надо давать разные номера
портов, отдельно запускать. Короче, зоопарк.

  И вариант другой: модули организуются в виде отдельных процессов,
запросы принимают через универсальную функцию get_next_request(rq_struct
*rs), отправляют ответы через send_reply_to_main_server(ans_struct *as);
  Обе функции (а так же init_tacacs_module()) загоняем в библиотечку,
которую в достаточной степени документируем.

 В самом такаксе (в конфиге) описываем модуль путем указания имени екзешника,
в котором он лежит. При старте такакса форкаем по процессу на модуль, из него 
делаем exec с параметром, указывающим способ связи с основным процессом (SysV 
IPC key, назначенный этому процессу идентификатор сообщения). Параметры
командной строки разбираются функцией init_tacacs_module из нашей библиотеки.

  В принципе, функция приема - передачи может быть реализована любым из
обсуждавшихся способов (через sockets, SysV IPC, через пайпы). Хоть в виде еще 
одного, очень примитивного, tacacs-server :)

 Модуль будет иметь следующую структуру: из main() зовем init_tacacs_module,
потом в цикле получаем запросы и обрабатываем их, как нам удобнее: можем в
том же процессе, можем по процессу на запрос форкать. Это уже дело каждого
конкретного модулеписателя. После обработки запроса посылаем ответ, ссылаясь
на id запроса, указанный в rs.

    С уважением, Даньков Михаил, г. Белгород.

                 ОАО "Деловая Телерадиокоммуникация" - партнер Глобал Один
                 тел./факс +7-(0722)-27-48-45     http://www.btrc.ru
                 2:5037/9@fidonet                 HAM CALLSIGN: RK3ZWO


=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.