Comments 36
Попробуйте что-ли puppet или chef.
именно
Я где-то год назад это все на puppet поднимал
но кстати есть один косяк — приходилось лепить костыли на dpkg — если были какие-то ошибки, то ему становилось очень плохо, решалось
dpkg --configure -a
apt-get update
apt-get upgrade с кучей ключей по поводу тихо и все
Я где-то год назад это все на puppet поднимал
но кстати есть один косяк — приходилось лепить костыли на dpkg — если были какие-то ошибки, то ему становилось очень плохо, решалось
dpkg --configure -a
apt-get update
apt-get upgrade с кучей ключей по поводу тихо и все
С первых строчек статьи стало понятно, что первый комментарий будет про Chef/puppet
А есть готовый пример на базе puppet или chef?
Можно было бы как статью оформить, думаю многим было бы интересно.
Можно было бы как статью оформить, думаю многим было бы интересно.
expect -re «Password:»
#Отправляем пароль
send «YOU_PASSWORD\r»
ssh ключи? не не слышал?
#Отправляем пароль
send «YOU_PASSWORD\r»
ssh ключи? не не слышал?
Конечно, но учитывая специфику организации, где ОС переустанавливают с периодичностью полной луны, генерировать ключи каждый раз накладно. + если необходимо ключи можно сгенерить изменив файл setup. Реализаций масса, это один из примеров
ключ вообще-то один — на сервере. Вы сервер раз в месяц переустанавливаете?
Я в таком случае просто настроил дистрибутив убунты с автоустановкой и в конец прописал инсталляцию puppet — он в репах, так что проблем не было.
Все сводилось к тому чтобы пройти поставить, пройти ввести имена машин (так было удобнее), потом на сервере подписать все и отправить их в ребут.
Изначально ставится стандартный пароль и при первом заходе копируется ключ и пароль меняется вообще на случайный — он больше не нужен.
Я в таком случае просто настроил дистрибутив убунты с автоустановкой и в конец прописал инсталляцию puppet — он в репах, так что проблем не было.
Все сводилось к тому чтобы пройти поставить, пройти ввести имена машин (так было удобнее), потом на сервере подписать все и отправить их в ребут.
Изначально ставится стандартный пароль и при первом заходе копируется ключ и пароль меняется вообще на случайный — он больше не нужен.
Ок ок, все верно. Касаясь данной реализации, что даст ssh ключ? лишний раз не вводить логин/пароль, я полностью согласен это не секурышно, но и без ключа отлично отрабатывает.
P.s в следующей версии обязательно исправлю, с ключом.
P.s в следующей версии обязательно исправлю, с ключом.
Ну я бы просто забил на вот такой велосипед и просто бы заюзал puppet — там просто сразу идет и готовые скрипты, и разбитие на классы, и отчеты, и уже куча готовых вещей
Кстати nfs шару для складывания логов лучше заменить на rsyslog или что-то из компании syslogеров — он может централизованно собрать все логи с машины — и полезнее будет — об ошибках каких-то сразу узнавать
Кстати nfs шару для складывания логов лучше заменить на rsyslog или что-то из компании syslogеров — он может централизованно собрать все логи с машины — и полезнее будет — об ошибках каких-то сразу узнавать
возможно автоматизировать переустановку рабочих станций. Регламентировать это хоть как-то. А после создания регламента таких работ, можно автоматизировать принудительную установку обновлений со стороны клиентской системы, настроить её на внутренний репозиторий (из той же автоматической установки) и забыть про «отслеживание версий софта»,
Откройте для себя:
FreeIPA v.3 — freeipa.org
SSSD v1.9 — fedorahosted.org/sssd/wiki/Documentation
Упрощает вашу задачу с паролями.
FreeIPA v.3 — freeipa.org
SSSD v1.9 — fedorahosted.org/sssd/wiki/Documentation
Упрощает вашу задачу с паролями.
1. Я очень сомневаюсь в квалификации администраторов, которые переустанавливает ОС с «регулярностью полной луны» — обычно ОС переставляют либо при глобальном апгрейде железа, либо при смерти винчестера, и то, вопрос спорный — наличие бекапов решает и эту проблему, учитывая что юникс не винда, которая уже даже спокойно переносит практически полную смену железа.
2. Та же убунта вообще влёт настраивается на автоматическое обновление прямо в процессе установки прямым вопросом «обновляемся сами, в ручную или через облако?»
3. про ssh ключи, видимо совсем не слышали.
4. про настройку рабочих станций на внутренние прокси сервера для обновлений, видимо тоже.
5. про chef/puppet уже говорили, могу только еще на systemimager намекнуть.
6. про мастер образ ОС и клонирование банальным акронисом, видимо тоже никто не слышал.
7. Банальный полный регулярный бекап, я, пожалу вообще промолчу.
8. Про снапшоты виртуальных машин и виртуализацию, пожалую промолчу тоже. Откат до предварительно сделанного снапшота чистой системе занимает полминуты на не очень современных серверах.
2. Та же убунта вообще влёт настраивается на автоматическое обновление прямо в процессе установки прямым вопросом «обновляемся сами, в ручную или через облако?»
3. про ssh ключи, видимо совсем не слышали.
4. про настройку рабочих станций на внутренние прокси сервера для обновлений, видимо тоже.
5. про chef/puppet уже говорили, могу только еще на systemimager намекнуть.
6. про мастер образ ОС и клонирование банальным акронисом, видимо тоже никто не слышал.
7. Банальный полный регулярный бекап, я, пожалу вообще промолчу.
8. Про снапшоты виртуальных машин и виртуализацию, пожалую промолчу тоже. Откат до предварительно сделанного снапшота чистой системе занимает полминуты на не очень современных серверах.
Еще я бы добавил ко всему этому apt-cacher-ng
Все немного не так, в статье не описано всех нюансов рабочего процесса, да и в принципе это не нужно. Весь смысл в том, чтобы иметь контроль и отчетность, функция автоматического обновления, это скорее бонус, чем главная задача.
Зачем нужен контроль над тем, что и так контролирует куча народу, создавшая дистрибутив?
Единственная вещь, которую стоит контролировать, это сервисы на серверах, к, примеру, привязка конкретной софтины к конкретной версии конкретной библиотеки, взаимодействие с которой протестировано на сто процентов и в случае, если изменение версии библиотеки повлечёт за собой нарушение работы п/о — так делает, например glassfish, zimbra, которые разворачиваются целиком и полностью в /opt и почти от основной системы не зависят
Единственная вещь, которую стоит контролировать, это сервисы на серверах, к, примеру, привязка конкретной софтины к конкретной версии конкретной библиотеки, взаимодействие с которой протестировано на сто процентов и в случае, если изменение версии библиотеки повлечёт за собой нарушение работы п/о — так делает, например glassfish, zimbra, которые разворачиваются целиком и полностью в /opt и почти от основной системы не зависят
В полку велосипедистов на костылях прибыло :)
Про ssh ключи уже сказали, вводить пароль sudo через expect это жесть какая-то. На то он и sudo, чтобы настроить какие команды и кому можно выполнять от суперпользователя без запроса пароля.
Режим работы программы всё же лучше задавать ключами, а не вводить с клавиатуры. А то если захочется потом это автоматизировать, то так просто в скрипт это уже не обернешь.
Перестанавливать можно или из готового образа или с помощью скрипта установки, куда можно уже включить и управляющего пользователя и ключ сервера управления и много разных и полезных вещей.
Linux ворвался в умы широкого круга пользователей, однако unix-way остался где-то позади. Это очень печально, так как в *nix обычно надо подумать, потом почитать доки, потом опять подумать, а вот после всего этого уже делать, а не кликать мышкой в надежде на интуицию.
Edit: Посмотрел на возраст автора, нормально всё, далеко пойдет ;)
Про ssh ключи уже сказали, вводить пароль sudo через expect это жесть какая-то. На то он и sudo, чтобы настроить какие команды и кому можно выполнять от суперпользователя без запроса пароля.
Режим работы программы всё же лучше задавать ключами, а не вводить с клавиатуры. А то если захочется потом это автоматизировать, то так просто в скрипт это уже не обернешь.
Перестанавливать можно или из готового образа или с помощью скрипта установки, куда можно уже включить и управляющего пользователя и ключ сервера управления и много разных и полезных вещей.
Linux ворвался в умы широкого круга пользователей, однако unix-way остался где-то позади. Это очень печально, так как в *nix обычно надо подумать, потом почитать доки, потом опять подумать, а вот после всего этого уже делать, а не кликать мышкой в надежде на интуицию.
Edit: Посмотрел на возраст автора, нормально всё, далеко пойдет ;)
Полез тут гуглить про скрипты обновлений для puppet, наткнулся вот на такую вещь — apt-dater
Конечно не puppet, зато в настройке гораздо проще и удобно если нужно следить за кучей хостов
Конечно не puppet, зато в настройке гораздо проще и удобно если нужно следить за кучей хостов
Подумайте о следующем админе вашей конторы — ему же, бедняге, во всём этом разбираться придётся!
Минус вашего решения в том, что оно не универсально: мало того, что не на всех дистрибутивах работает, так ещё и только обновление умеет. В один прекрасный день добавится пара серверов с CentOS и придется ещё добавлять проверку дистрибутива и поддержку работы с yum. Поэтому, как сказали выше, лучше посмотреть в сторону SCM, таких как Chef и Puppet.
Пакеты можно и автоматом обновлять
APT::Periodic::Enable "1";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "5";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::RandomSleep "1800";
Можно. Если хочешь огрести проблемы в какой-то момент.
А что делать если с новым пакетов приехали новые конфиги, отличающиеся от старых?
А если после автообновления что-то упадёт или начнёт работать не так, как надо?
А что делать если с новым пакетов приехали новые конфиги, отличающиеся от старых?
А если после автообновления что-то упадёт или начнёт работать не так, как надо?
Конфиги никогда сами не перезаписываются, только если это явно подтвердить. Если что-то пойдет не так,
//Unattended-Upgrade::Mail «root@localhost»;
//Unattended-Upgrade::MailOnlyOnError «true»;
//Unattended-Upgrade::Mail «root@localhost»;
//Unattended-Upgrade::MailOnlyOnError «true»;
Знаю что не перезаписываются.
Но бывает так, что в новой версии слегка меняется формат конфига и старые настройки будут вызывать ошибку либо работать не так, как задумано.
Я веду к тому, что процесс обновления должен проходить под контролем человека с возможностью остановить его или подправить что-то на лету.
Но бывает так, что в новой версии слегка меняется формат конфига и старые настройки будут вызывать ошибку либо работать не так, как задумано.
Я веду к тому, что процесс обновления должен проходить под контролем человека с возможностью остановить его или подправить что-то на лету.
дополню: в случае принудительных автоматических апдейтов, репозиторий собирается свой. Туда просто не смогут попасть «новые конфиги».
UFO just landed and posted this here
Я apticron юзаю для Ubuntu/Debian и yum-updatesd для CentOS/RHEL
Sign up to leave a comment.
Централизованная система обновления пакетов в Ubuntu