Я работаю над настройкой нашей системы Linux (и, возможно, Windows, если возможно), чтобы мы могли отслеживать административные изменения и иметь их историю, на которую можно было бы ссылаться. В настоящее время у меня довольно хорошая настройка с etckeeper, logwatch и mercurial.
Я хотел бы сделать это немного более надежным, придираясь к любому администратору, когда он выходит из системы, сообщением, в котором его спрашивают, хотят ли они создать журнал изменений для того, что они только что сделали на сервере. Ответ «Нет» продолжит процесс выхода, а ответ «да» приведет их к любому редактору, который они используют, где они могут ввести все, что они хотят, о том, что они только что изменили в системе. Затем помощник changlog добавлял бы некоторое стандартное форматирование к тому, что они там помещали (добавляли дату / время, имя пользователя, отступ, переносили на 70 символов в строке и т. Д.) И добавляли это к файлу где-нибудь в системе. Затем я бы включил этот журнал изменений в настройку мониторинга, которая у меня уже есть, что приведет к тому, что он будет контролироваться по версиям и отправлен в централизованное место.
Я представляю что-то, что будет выглядеть и работать во многом так же, как функция фиксации / комментария работает с mercurial / git / svn, за исключением того, что комментарий форматируется по-другому и сохраняется в файл локально. Бонусные баллы за наличие хуков до / после фиксации или за возможность их настройки.
Спасибо.
На ум приходят две простые идеи:
Используйте команду logger, чтобы позволить администраторам отправлять однострочные сообщения в системный журнал. Поскольку имя пользователя включено, это упрощает создание отчетов по сценариям. Если вы входите на центральный хост, вы также получаете централизованный журнал этих изменений.
Просто добавлял все изменения в / etc / motd, не только документируя изменения, но и показывая их всем при входе в систему.
Оба метода хорошо поддаются выполнению вручную верными администраторами или с помощью сценариев.
Никогда не слышал о таком инструменте.
Но я думаю, что можно сделать следующее
Администратор запишет имена измененных файлов в текстовый файл вместе с соответствующим описанием.
Затем эти файлы синхронизируются с каким-либо удаленным сервером или могут находиться в какой-либо папке в той же системе с прикрепленной к нему меткой времени. Эта резервная копия также будет содержать файл, который администратор использует для записи изменений.
Текстовый файл, в который администратор записывает изменения, будет иметь некоторый стандартный формат для записи имен файлов и соответствующего описания, которое будет прочитано некоторым сценарием bash / python / perl перед выполнением rsync.
Вместо rsync можно использовать другие инструменты резервного копирования, такие как rdiff или rsnapshot.
Если "какой бы редактор они ни использовали" окажется Emacs, тогда вы можете использовать его изменить команды редактирования журнала. В простейшем случае это может быть что-то простое, например выполнение следующей команды
emacs -f add-change-log-entry
который запросит местоположение файла журнала изменений и автоматически создаст новую запись с именем, адресом электронной почты и датой, готовую для редактирования.
использование чего-то вроде iwatch или tripwire должно показать вам различия в файлах. - затем сохраните где-нибудь эти отчеты с комментариями.
Я не эксперт по Linux, но мне кажется, что вам нужно подключить систему, чтобы фиксировать любой способ выхода администратора из системы. например Если кто-то набрал exit на консоли для выхода из системы необходимо, чтобы оболочка выполняла действие, совершенно отличное от ее обычного ответа на exit, иначе пользователь просто выйдет из системы.
Это возможно? Возможно, но это будет означать настройку оболочки (ей). Конечно, я могу ошибаться и уже есть удобный способ перехватить бит встроенных команд, если он есть, я не знаю об этом.
Конечно, ничто из вышеперечисленного не поможет, если соответствующий пользователь получит доступ к системе удаленно, например, через SSH.
Я специально ничего не документирую на серверах. Мы используем марионетку, которая является каноническим ресурсом конфигурации для серверов. Конфигурация марионетки находится в управлении версиями. Если сервер необходимо перестроить, мы используем для этого марионетку. Любая конфигурация, которой не было в марионетке, теряется. Поэтому большая часть конфигурации находится в марионеточном режиме, а журнал изменений - в марионеточных фиксациях.