Привет всем.
Хотел бы представить задумку моего проекта. На данный момент прорабатывается концепция и идет сбор идей. Поэтому все ваши соображения и пожелания будут очень кстати. Вот документ в гуглодоках, описывающий концепцию:
//docs.google.com/View?docid=df75jvv4_0g57q6wgs…
Он будет обновляться и дополняться по мере сбора идей по функционалу и реализации.
Оставляйте ваши соображения здесь в коментах или в аську 130787.
Спасибо всем, кто откликнется.
24 февраля 2009 в 21:00
Да, и еще. Идет ли речь о разработке полностью нового протокола или о работе на основе существующего (например, XMPP)?
21 февраля 2009 в 23:03
В этом, собственно, и заключается вопрос.
Возможно, стоит все-таки реализовывать модуль как класс Python с заданным интерфейсом? Как вариант, модули можно разделить по типам: native (на Python) и alias (вызовы модуля в соответствии с настройками xml-конфига передаются другим модулям). Как вариант, можно для модулей на других языках автоматически создавать класс-wrapper.
20 февраля 2009 в 20:05
изначально задумывалось, что агент будет просто запускать бинарник модуля, передавая в качестве параметра команду или конфигурацию.
Учитывая возросшие задачи, надо будет придумать что-то другое. Особенно для модулей мониторинга.
20 февраля 2009 в 19:05
А каким должен быть интерфейс между агентом и модулем? Чтобы модули было удобно писать на языках от C до bash, через что они должны взаимодействовать с агентом?
20 февраля 2009 в 8:01
скорей всего будет некий интерфейс между агентом и модулями. так будет логичней, как мне кажется. и можно будет писать модули на чем угодно
20 февраля 2009 в 1:02
Держать онлайн или подключаться? Мне кажется, это может зависеть от набора используемых модулей. Вариант "всегда онлайн" обязателен, но возможно и иное решение.
Предполагается ли, что модули написаны на Python (хотя бы wrapper)? Или создается также протокол общения агента с запущенным модулем?
19 февраля 2009 в 22:00
На данный момент пользую питон 2.5.
DBUS хорош локально и в линуксе. Насколько мне известно, в виндовсе его нет. Да и реализовать XML внутри потоков TCP не такая проблема. засунуть это в SSL думаю тоже не составит труда.
Кстати еще не знаю как лучше сделать – деражть подключения всех клиентов постоянно онлайн, либо подключаться п необходимости.
Пока склоняюсь к варианту "всегда онлайн", т.к. в случае с мониторингом загрузки процессора, частота генерации событий может быть большой и мы получим большой оверхед в сетевых коммуникациях.
Насчет автозапуска модулей есть соображение: у каждого модуля сделать метод Init, который уже будет либо просто завершать свою работу, если модуль не для мониторинга, либо запускать собственно мониторинг.
Насчет установки самого агента через менеджер пакетов- тут согласен. было бы полезно.
19 февраля 2009 в 14:01
Сертификат сервера нужен обязательно; что же до клиентов, то клиент может как использовать предустановленный сертификат, так и сгенерировать сертификат при первом подключении. При этом сервер может при подключении нового клиента автоматически в соответствии с настройками присвоить ему уже существующую конфигурацию (к примеру, при использовании известного сертификата или нахождении его в локальной сети компании), присвоить ему некоторую настройку "по умолчанию" (появился в отделе, занимающемся настройкой перед продажей компьютеров, новый компьютер – внести в соответствующие группы и передать указанные команды) или вообще отказать в подключении (посторонний компьютер из Интернета).
Что касается установки средствами менеджера пакетов. Использование другого подхода приведет к тому, что агент будет устанавливать файлы, о которых не будет проинформирован менеджер пакетов. Это в принципе допустимо, но при этом сам агент должен (это весьма желательно) быть установлен через менеджер пакетов, а при удалении удалять вместе с собой и все модули.
Типы модулей. На мой взгляд, такое понятие, как "тип модуля" просто лишено смысла. По крайней мере, нет нужды полагать его обязательной характеристикой модуля. Вполне достаточно флага "автозапуск", определяющего, следует ли активировать модуль в момент запуска агента. Так, модуль мониторинга активируется при запуске, а модули смены настройки DNS или удаленного доступа – только по запросу от сервера.
Да, возможно стоит посмотреть в сторону существующих средств связи и вместо собственного протокола, основанного на xml, использовать взаимодействие, скажем, через dbus? Я не знаю, возможно ли использование dbus по сети и что для этого требуется.
P. S. Python 2.* или 3.0?
19 февраля 2009 в 11:03
На данный момент разработан демон-заглушка на питоне.
насчет шифрования канала идея хороша. Насчет сертификатов – требуется строгая идентификация как каждого конкретного клиента, так и сервера. Чтобы злоумышленник не мог притвориться ни клиентом ни сервером. Сделать это на базе сертификатов + шифрованный канал – думаю хорошая идея.
Насчет подписывания модулей, тоже согласен.
установка модулей средствами менеджера пакетов – не самая лучшая идея. Объясню почему. Представим что нужен модуль для конфигурирования какогото софта на сервере. С вероятностью 99% этот будет написано либо на sh, либо на perl. Теперь представим что это модуль придется делать для всех возможных дистрибутивов, навскидку rpm, deb. mdk плюс гентушный портеж. И это только самые популярные линукс – дистрибутивы. А ведь есть и другие юниксы где скрипты будут выглядеть так же.
Я вижу этот момент так: с каждым модулем прилагается его описание в XML, где описывается, для каких ОС он предназначен, каие параметры умеет конфигурировать и т.д.
Разграничение доступа админам разного уровня – безусловно полезная функция, о которой я. честно даже не задумался. Включу в концепт.
Кроме того, думаю стоит сделать механизм, не знаю как назвать, подхвата чтоли. Когда с машины тупо снесли виндовс, она появляется с чистой конфигурацией. А для нее уже есть в системе настроенный профиль.
Кроме того, сейчас пришла в голову мысль. Есть два типа модулей – собственно модули, занимающиеся конфигурацией, и модули для мгновенного удаленного управления. Можно добавить сюда модули для мониторинга различных параметров системы и генерирования на серверной стороне событий, которые можно было бы как-то обработать.
19 февраля 2009 в 11:00
Несколько дополнительных идей.
Разумеется, клиент-серверное взаимодействие осуществляется по зашифрованному каналу, причем каждый клиент при начальной настройке привязывается к конкретному сертификату сервера (позднее список доверенных сертификатов может быть изменен).
При передаче команды на установку модуля также следует передавать цифровую подпись файла модуля.
Желательно, чтобы по возможности установка модулей производилась средствами установленного в системе менеджера пакетов.
Желательно, чтобы сервер имел возможность автоматически конфигурировать подключаемый к нему компьютер. К примеру, в зависимости от его IP и ближайшего сервера вносить его в ту или иную региональную группу.
Желательна возможность выдачи агенту команды на удаление себя с клиентской станции.
Желательна возможность введения администраторов с ограниченной областью полномочий – к примеру, работающих только с машинами одной из групп. К примеру, администратор группы filial_spb имеет возможность присваивать машинам некоторые группы, специфические для его филиала, но не для других.
Желательно, чтобы управление производилось стандартными средствами используемого дистрибутива (к примеру, настройки firewall должны вноситься в соответствующий конфигурационный файл, а не применяться средствами IPTables).
А какой язык программирования планируется использовать в системе?