Кто-либо замеченный программа помощника для создания журнала изменений для сервера?
Я был в этом сражении также. Мой ответ - то, что то, кто бы ни ответственен в течение времени работы сервера, является тем, который должен быть ответственен за все обновления, изменения, и т.д., и т.д. Nobodoy еще должен иметь способность выполнить эти типы функций на сервере. Если это - Ваше задание, чтобы удостовериться, что сервер в порядке и если босс держит Вас ответственный и ответственный за сервер затем, это - Ваша обязанность поддержать и защитить его.
Большинство разработчиков собирается сказать Вам, что им нужен администраторский доступ уровня к серверу, и большинство из них собирается не согласиться со мной, но я - тот, который должен перезагрузить его в 2:00, когда он зависает, должен восстановить его после того, как неудавшееся обновление, время простоя заряжено против моего отдела, и т.д., и т.д. Я должен ответить директору по информационным технологиям для чего-либо, что влияет на наш SLA, поэтому я - единственный, кто получает администраторский доступ уровня к серверу, и я ответственен за все компоненты, обновления, изменения, и т.д.
Две простых идеи приходят на ум:
Используйте команду "регистратора", чтобы позволить администраторам отправить остроты в системный журнал. Так как имя пользователя включено, оно делает для легкого создания отчетов в виде сценария. Если Вы регистрируетесь к центральному хосту, Вы зарегистрировали эти изменения централизованно также.
Просто добавленный все изменения в/etc/motd, не только документируя изменения, но также и отображая их всем, когда они входят в систему.
Оба метода предоставляют себя хорошо тому, чтобы быть сделанным вручную верными администраторами или путем сценариев.
-
1я думаю регистратор, является корректным ответом здесь. Добавленная премия - то, что Вы, вероятно, архивируете системный журнал где-нибудь так или иначе, таким образом, у Вас уже есть инфраструктура для сбора данных журнала изменений. – duffbeer703 15 November 2010 в 16:09
Никогда не слышал о таком инструменте.
Но я предполагаю, что следующее может быть сделано
Администратор запишет названия файлов, измененных в некотором текстовом файле наряду с соответствующим описанием.
Те файлы затем rsynced с некоторым удаленным сервером или могут быть в некоторой папке в той же системе с меткой времени, присоединенной к нему. Это резервное копирование будет также содержать администраторское использование файла для записи о модификациях.
Текстовый файл, в котором администратор пишет изменения, будет иметь некоторый стандартный формат для записи имен файлов и соответствующего описания, которое будет прочитано некоторым ударом / Python / сценарий жемчуга прежде, чем выполнить rsync.
Другие резервные инструменты как rdiff или rsnapshot могут использоваться вместо rsync.
Если "безотносительно редактора они используют", оказывается, Emacs, то Вы могли использовать его команды редактирования журнала изменений. В самом простом это могло что-то столь же простое как выполнение следующей команды
emacs -f add-change-log-entry
который запросит расположение файла журнала изменений и автоматически создаст новую запись с именем, адресом электронной почты и датой, готовой к редактированию.
Я не эксперт Linux, но это кажется мне, необходимо было бы сцепить систему для получения любого способа, которым администратор мог бы выйти из системы. например, Если кто-то ввел exit в консоли, чтобы выйти из системы, было бы необходимо иметь оболочку, выполняют совершенно другое действие к, он - нормальный ответ на exit, иначе пользователь просто выйдется из системы.
Это возможно? Возможно, но это означало бы настраивать оболочку (оболочки). Конечно, я мог бы быть неправым и уже существует удобный способ сцепиться, встроенные команды укусили, если существует, я не знаю об этом.
Конечно, ни одно из вышеупомянутого не помогло бы вообще, если бы рассматриваемый пользователь получил доступ к системе удаленно, такой как через SSH.
Я конкретно ничего не документирую на серверах. Мы используем марионетку, которая является каноническим ресурсом конфигурации для серверов. Конфигурация для марионетки находится в управлении версиями. Если сервер должен быть восстановлен, мы используем марионетку, чтобы сделать это. Любая конфигурация, которая не была в марионетке, потеряна. Поэтому большая часть конфигурации находится в марионетке, и журнал изменений находится в марионеточных фиксациях.