Сервер заданий как единая платформа.

1. Откуда и зачем


Вначале все было совсем просто. Потребовалась программа или комплекс программ, позволяющих проводить централизованное администрирование с учетом возможности, что некоторые из администрируемых станций согут быть временно отключены. То есть ушел сегодня человек по-раньше домой, а администратору захотелось добавить по всем машинам новые права доступа на некоторый каталог. Все включенные машины синхронизировались, а эта одна так и осталась неизмененной. И пришлось потом бедному администратору на следующий день все править в ручную. Решение очевидно: задания на изменения должны где-то накопливаться. Включит человек машину на следующий день и она сама заберет накопившиеся изменения и приведет их в силу. Появился сервер-накопитель и программы клиенты. Однако через некоторое время выяснилось, что серверу-накопителю совсем без разницы, что он так бережно хранит, то есть можно сделать обобщенный сервер заданий, а выполняемые на нем действия будут зависеть от клиентской части. То есть клиент может вовсе не заниматься администированием, а например просто работать в виде пейджера на офис - передавать сообщения от машины к машине с возможностью сохранения оных для пользователя отлючившегося временно по делам. Или еще лучше программа тестирования для школы - придумал преподаватель тест, разослал всем студентам. Те пришли когда смогли, выполнили задания и послали ответы преподавателю, а утого в очереди постепенно накапливаются все ответы. Пришел преподаватель через неделю и проверил труды ствоих птенцов. И все это на одном сервере - здорово, правда?

2. Общая схема работы.

2.1 Основной режим.


Схема собственно очень простая. На сервер посылаются задания. Они выстраиваются в очереди и по запросам клиентов передаются последним.


Но чем дальше думалось, тем все больше и больше хотелось получать от этого сервера. Появились команды. Теперь сервер может выполнять определенные задания, например добавлять задание определенному пользователю, очищать список задач, возможно даже подавать звук по заказу

2.2 Режим мониторинга

Благодаря командам сервер можно заставить работать в обратном направлении. Это позволяет осуществлять, например, мониторинг состояния станций. Теперь станции посылают самим себе (в свои очереди) задания-отчеты, а главная консоль забирает их и просматривает.

Не правда-ли все очень просто. И не надо изобретать отдельной программы. Как уже говорилось - поведение всей системы зависит только от клиентов.
 
 

3. Протокол

Все эти радости требуют определенной очередности. Клиенты должны теперь знать как и в каком порядке выполнять чтобы сервер правильно воспринял их пожелание - протокол.

Клиент выполняет следующие действия.

a) Во первых конечно он должен доказать что может работать, то есть некоторая процедура аутентификации
b) Во вторых должен сообщить команду которую желает выполнить
c) Затем послать данные команде, если конечно они необходимы. Для команды очистки всех очередей, например, аргументов не требуется, а для команде добавления задания определенной станции целых два (какой станции и что).
d) Если в ответ должны получить данные, то забираем. Например список заданий накопившихся к данному моменту.

Вот собственно и все. Сервер выполняет теже действия только в симметричном порядке.
 

4. Безопасность.


Ну вот все кажется хорошо, да не совсем. Дали возможностей, теперь требуется ограничить доступ к ним всем желающим. Все что далее написано находится в постоянном развитии и не является окончательным решением проблемы.

Во первых аутентификация. Пароли проверяются со стороны сервера с использованием PAM. Сценарий для порграммы должен находится в /etc/pam.d/r-job. Так что можете накручивать сценарии как угодно, использовать NIS и так далее...
 

Весь траффик шифруется (на данный момент используется алгоритм AES), причем ключи шифрования меняются при каждом новом сеансе. С учетом того что сами сеансы связи очень краткие злоумышленник дольше будет заниматься дешифровкой чем очереди заданий уже опустеют. Тонкий момент - обмен ключами. Сейчас для этого используется довольно надежный алгоритм Диффи-Хеллмана. Благодаря ему стороны получают общий ключ ни разу не передавая его по сети в открытом виде. Обмен происходит в самом начале и в дальнейшем работа идет уже с использования шифра с полученными ключами. Сервер тоже не дремлет. Получив очередное задание от заносит его в очередь (или несколько очередей) закрывая своим локальным ключом шифрования.

Помимо перечисленных механизмов сервер может общаться только с теми станциями IP адреса которых состоят в специальном списке. То есть клиент с неразршенной машины никогда не сможет аутентифицироваться даже зная пароль. Конечно остается опасность подмены IP-адреса, используя несовершенство протокола. Но для решения этой проблемы предусмотрены сертификаты основанные на RSA.

Итак получаем следующую схему аутентификации:

1. Проверка по списку станций
2. Проверка по сертификату
3. Обмен ключами шифрования (алгоритм Диффи-Хелмана)

В дальнейшем все сообщения шифруются полученными ключами

4. Проверка знания пароля

4.1 Протоколирование событий

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

4.2 Сертификаты станций


Как временная замена SSL присутствует следующая схема. Клиент генерирует для себя пару  из открытого и закрытого ключей. Сеанс организуется следующим образом
1. Клиент предлагает серверу свой публичный ключ.
2. Сервер или принимает его (если он не знаком со станцией) или игнорирует (если уже имеет сертификат от станции).
3. Сервер берет произвольное число, шифрует на публичном ключе клиента и посылает этакую задачку клиенту.
4. Клиент расшифровывает число и посылает ответ.
5. Сервер сравнивает ответ о если он правилен принимает соединение.

В качестве алгоритма используется RSA на очень больших числах (50-значные в 36-ричной системе счисления).

5. Возможные команды и уровни доступа


По мере появления все новых команд стало очевидным, что не все станции могут выполнять их все. Например удалением заданий из очередей может заниматься администратор сервера, но не может обычный пользователь. Поскольку различение на данный момент идет на уровне станций, то и разграничение доступа осуществляется на их базе. При добавлении в будущем нового слоя различия "пользователи на станции" возможно установление отдельных разграничений и для них. А пока все команды разделены на несколько уровней доступности. К каждой станции приписывается уровень доступа. С конкректной станции может быть выполнена та или иная команда только если ее уровень доступа не меньше требуемого уровня команды.

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


На данный момент присутствуют следующие команды (разделены по уровням доступности):
 
 
минимальный уровень:
GET_ONLY_COMMAND получить текущие задания для станции
GET_ONLY_WARRANTY_COMMAND режим "доставка с гарантией" предыдущей команды
LIST_STATION_COMMAND получить список доступных станций
первый средний уровень:
ADD_ONLY_COMMAND добавить новое задание для всех станций
ADD_ONLY__MINE_COMMAND добавить новое задание для своей станции
GET_AND_ADD_COMMAND добавить новое задание для всех станций и получить текущие задания для данной
GET_AND_ADD_WARRANTY_COMMAND режим "доставка с гарантией" предыдущей команды
второй средний уровень:
ADD_ONLY_ONE_STATION_COMMAND добавить новое задание для указанной станции
PEEK_ONE_STATION_COMMAND просмотреть список заданий для указанной станции
GET_ONLY_ONE_STATION_COMMAND получить текущие задания для указанной станции
высший уровень:
CLEAN_COMMAND удалить все задания для всех станций
CLEAN_ONE_STATION_COMMAND  удалить все задания для указанной станции
STOP_SERVER_COMMAND остановить сервер
PAUSE_SERVER_COMMAND временно приостановить работу сервера
RESUME_SERVER_COMMAND восстановить работу сервера
ADD_STATION_COMMAND добавить новую станцию в список разрешенных
DEL_STATION_COMMAND  удалить указанную станцию из списка разрешенных

6. Как запустить


Теперь как работать с программой. Очень просто - надо ее откомпилировать. Затем заполнить файл списка станций в формате:

уровень1:IP-адрес1
уровень2:IP-адрес2
...

Следующим будет главный конфигурационный файл сервера. Ниже примеден его пример
 

#
#Пример конфигурационного файла rjobd
#

#Все запросы будут записываться в этот журнал
  activity_log:  /tmp/rjob.log

#Все сообщения об ошибках будут записываться в этот журнал
  error_log: /tmp/rjob.err

#Шаблон названия дла файлов заданий
  job_name: /tmp/rjob~

#Путь к файлу со списком разрешенных станций
  station_list: ./client-list
 

И наконец для аутентификации необходимо создать файл-сценарий по адресу /etc/pam.d/rjob. Можно просто скопировать аналогичный для ppp или заполнить самостоятельно согласно примеру приведенному ниже:

#%PAM-1.0
auth       required     pam_nologin.so
auth       required     pam_pwdb.so shadow nullok
account    required     pam_pwdb.so
session    required     pam_pwdb.so
 

При запуске сервера командной строкой регулируются следующие параметры:

После запуска сервера остается только запустить нужный клиент и приступать к работе.
Перед запуском клиента не забудьте создать сертификаты для него, используйте команду getkeys.

6.1 netadm

Пример консольных утилит позволяющих осуществлять централизованное администрирование:

6.2 rmonitor

Пример консольных утилит позволяющих осуществлять централизованный мониторинг:

7. Ваши мысли


Вот пока и все. Вывод один - сообщайте идеи, сообщайте об ошибках, пишите новые клиенты... интересно
 
 

Stanislav Ievlev
<inger@linux.ru.net>