Различные локальные значения и основные значения для настроек сеанса PHP
Мы работаем над кодом, который выполняет следующие действия с использованием terraform (на AWS):
- Создает экземпляр core-os (1) с yaml-файлом облачной конфигурации мы предоставили
- Создает AMI из этого экземпляра
Процесс работает отлично до сих пор.
Когда мы запускаем экземпляр (2) из этого AMI через консоль AWS. Вновь запущенный экземпляр не использует файл конфигурации облака.
Он (2) имеет единицы services / systemd, которые были созданы в экземпляре (1) с помощью файла yaml облачной конфигурации. Но эти службы мертвы. Они работают отлично, если мы запускаем их явно с помощью systemctl
Как мы можем убедиться, что ЛЮБОЙ экземпляр, созданный из этого AMI, должен запускать эти модули services / systemd при запуске или должен загружать этот файл облачной конфигурации?
(У нас есть этот yaml с облачной конфигурацией, сохраненный в месте внутри машины, если мы запустим файл облачной конфигурации вручную через coreos-cloudinit --from-file = path / to / file / cloud- config.yaml , все работает отлично. я просто хочу быть уверенным, что ничего не произойдет неожиданно)
Из ADFS PoV ничего делать не надо.
Да - сертификат удален.
Однако, Любые CP и RP, которые не получат автоматически новые метаданные, сломаются, так как подумают, что токен неправильно подписан.
Их нужно обновлять вручную.
.Я не согласен с принятым ответом. По моему опыту, типичная доверяющая сторона:
- Не принимает новые метаданные автоматически.
- Определенно выходит из строя каждый раз, когда происходит обновление сертификата.
- Полностью удивлен, когда я сообщаю о сбое, даже если это произошло 3 года подряд
- Не знает, как использовать метаданные, и требует, чтобы я вместо этого отправил им сертификат по электронной почте
Так что да, волнуйтесь.
Моя самая большая полагающаяся сторона, Google, похоже, не реализует автоматическую обновление метаданных и предоставляет только один слот для загрузки сертификата, что означает, что нет способа выполнить плавный переход. Вы должны загрузить сертификат в Google в тот самый момент, когда он станет основным на сервере ADFS, или у вас будет сбой.
(Я предполагаю, что цель наличия обоих сертификатов в метаданных - позволить проверяющим сторонам фактически принять оба из их во время перекрытия в их диапазонах дат, что сделало бы возможным плавный перенос. В Google такого нет.)
Даже более компетентная доверяющая сторона, использующая на своей стороне ADFS, не смогла выполнить автоматическое обновление и только преуспела при обновлении метаданных xml путем воссоздания доверительных отношений с нуля.
Беспокойство сильно.