Моя проблема: политики cfengine3 создаются / обновляются вручную на сервере (концентраторе политик), и клиенты регулярно (каждые ~ 5 минут) перетаскивают их с сервера: / var / cfengine / masterfiles на свой соответствующий someclient: / var / cfengine / входы (как должны).
Но иногда это ведет себя непоследовательно. Обновленный файл на сервере может появиться на клиентах лишь через некоторое время. Может пройти> 30 минут или больше, пока он внезапно не «увидит» обновление. Это происходит, особенно если то, что я создал / обновил, находится в подкаталоге в ./masterfiles.
Я проверил с помощью tcpdump, что каждый клиент фактически обменивается данными с главным сервером через порт cfengine (5308) каждые 5 минут.
Я не могу понять причину, по которой файлы политик не обновляются.
Кто-нибудь испытал то же самое или есть предложение? Спасибо.
(Только что обновлен до cfengine 3.3.1, смешанная изолированная среда CentOS / Fedora - остальная часть сети успешно работает на cf2).
Дэвид,
Копируются ли обновленные файлы, а локальный cf-agent не реагирует на изменения? Или обновленные файлы копируются гораздо позже?
Единственная причина, по которой я могу придумать, - это то, что часы между системами не синхронизированы. Проверьте / var / cfengine / inputs / cf_promises_validated - в этот файл указывается время последней проверки обещаний на сервере, и клиенты перезагружают свои локальные политики, используя эту временную метку.
Вы также можете разместить свой вопрос в Справочный форум CFEngine, где его обязательно увидит большее количество экспертов CFEngine :)
Дэвид,
Я также подозреваю, что часы смещены, как Диего. Искать cf_promises_validated на http://cfengine.com/blog/cfengine-330-release-notes что может дать вам некоторые ресурсы. Ключ - это обещания копирования в файле failsafe.cf.
Вы упомянули, что только что обновили свой CFEngine до 3.3.1.
В / var / cfengine / masterfiles / cf_promises_validated в 3.3.1 появилась новая метка времени (я догадался, что предыдущая версия представляет собой пустой файл), что означает, что мы можем просто изменить способ копирования файла с «mtime» на «дайджест» в вашем current failsafe.cf, чтобы избежать проблем с системными часами. См. Также /var/cfengine/share/CoreBase/failsafe.cf, тело copy_from u_rcp уже имеет составное тело "дайджеста".
Как и другие, я подозреваю, что часы искажены. Проверьте свое время. Вы также можете удалить файл cf_promises_validated в / var / cfengine / inputs на удаленном агенте. Затем он увидит, что файл cf_promises_validated в / var / cfengine / masterfiles на концентраторе политик отличается, и продолжит полное обновление политики.
Начиная с 3.3.0 cf_promises_validated должен содержать отметку даты и времени, чтобы мы не полагались на правильную синхронизацию времени для обновлений политики.
Проверьте файл failsafe.cf, если вы используете политику начальной загрузки по умолчанию.
Политика 3.3.1 или 3.3.0 (не уверен, что сгенерировала отказоустойчивый, на который я смотрю) имеет обещание с дескриптором check_valid_update, который использует u_rcp для обновления файла cf_promises_validated, если это необходимо. Если он исправляет обещание, он вызывает класс / контекст validated_updates_ready, которым ограничено обещание с дескриптором update_files_inputs_dir, чтобы обновить остальную часть политики. Проверьте в теле copy_from u_rcp, что используется для атрибута сравнения. Если это дайджест, то он должен использовать содержимое файла, а не только его временные метки.