Если Вы выполняете автоматические обновления

Вы можете использовать Унисон для синхронизации файлов. Унисон использует rsync протокол и может работать на основе ssh. Вы, возможно, должны скопировать исполняемый файл в свой каталог в удаленной системе.

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

Править: Для синхронизации папки на от системы C (с рабочим Drobox), выбранный каталог на B становится концентратором и A и C две спицы. Запланируйте шаги так, чтобы только один работал за один раз.

  • Унисон расписания в системе C для синхронизации к каталогу на B.
  • Унисон расписания в системе для синхронизации к каталогу на B. (Может потребовать NFS, монтирующего каталог.)
  • Периодически, проверьте Унисон на конфликты, если автоматическое разрешение не было настроено.

Существуют другие способы обработать это. Если каталог на B является alway, смонтированным при необходимости в нем то можно пропустить этот шаг. Символьная ссылка на autofs монтирование NFS обработала бы это.

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

15
27.04.2012, 13:51
2 ответа

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

Вот некоторые вещи рассмотреть:

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

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

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

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

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

11
27.01.2020, 19:50

Я согласовываю 100% с тем, что уже сказал Caleb. Некоторые более CentOS-определенные метки от меня:

Распределение основано на Redhat и его патчах. Те патчи тестируются очень хорошие и за прошлые 4 года, где мы использовали CentOS 5 с 50 + серверы, там никогда не был плохой патч.

НО: Хотя мы применяем все патчи ежедневно автоматически к серверам, которые выполняют просто материал распределения, мы загружаем рабочие серверы (после того, как glibc или обновление ядра) только после того, как у нас были наши системы тестирования, работающие в той конфигурации несколько дней.

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

Автоматическое исправление имеет побочный эффект, что исправленные компоненты часто перезапускаются - поэтому при неправильном конфигурировании их после запуска, перезапуск перестанет работать..

7
27.01.2020, 19:50

Теги

Похожие вопросы