Comments 11
у нас есть одни люди, которые ОЧЕНЬ любят писать интерактивные инсталляционные скрипты. Из-за чего херится вся возможность автоматической инсталляции, ибо оставленный на ночь апдейт базы стопается на вопросе «are you sure that you want update database?». А тут интерактивные скрипты запуска сервисов…
Ну, обновлять ночью без присмотра, своими скриптами…
А что мешает написать скрипт с параметрами автоматической установки? Или параметр, указывающий файл с конфигурацией установки? Я не говорю про Tk/Tcl.
Ваш комментарий не имеет отношения к статье.
А что мешает написать скрипт с параметрами автоматической установки? Или параметр, указывающий файл с конфигурацией установки? Я не говорю про Tk/Tcl.
Ваш комментарий не имеет отношения к статье.
1. в базах данных бывают таблички побольше чем «5 полей, 10 записей». И если делать на такой таблице alter table… Он занимает некоторое время, если коротко. Если учесть что мы не одни такие на сервере — можно представить. Плюс оракл, ага
2. мешает чОтко написанная процедура, которой мы должны следовать. В больших конторах большая бюрократия, как правило.
3. чтобы закомиттить свое — необходимо пройти такой квест, что ад по Данте покажется легкой прогулкой.
это все ответ на Ваш каммент. А по отношению к статье уточню:
1. мое имхо — интерактив в старт\стоп сервисах — лишнее. Сервис должен быть полностью работоспособен после ребута. А не идти на сервер и дергать его ручками
2. слабо представляю зачем вообще это все необходимо. Если дернули апдейт по какому-то событию (нажатие аппаратной кнопки, ребут, что-то там еще) — то он должен пойти самостоятельно, без интерактива. Ибо что, например, делать в случае no-tty девайса?
2. мешает чОтко написанная процедура, которой мы должны следовать. В больших конторах большая бюрократия, как правило.
3. чтобы закомиттить свое — необходимо пройти такой квест, что ад по Данте покажется легкой прогулкой.
это все ответ на Ваш каммент. А по отношению к статье уточню:
1. мое имхо — интерактив в старт\стоп сервисах — лишнее. Сервис должен быть полностью работоспособен после ребута. А не идти на сервер и дергать его ручками
2. слабо представляю зачем вообще это все необходимо. Если дернули апдейт по какому-то событию (нажатие аппаратной кнопки, ребут, что-то там еще) — то он должен пойти самостоятельно, без интерактива. Ибо что, например, делать в случае no-tty девайса?
Моё ИМХО — думать надо что, где и как применять. Мне не приходит в голову делать скрипт запуска веб-сервиса интерактивным, не попадалось таких задач. Но инсталлятор ОС в консольном режиме — его придётся делать интерактивным.
Если не устраивает организационная сторона — лучше взять самому за ситуацию. Проблемы с процедурой — пишите и пробивайте новую. НО проблемы с организацией это не повод ненавидеть те или иные технические решения.
Если не устраивает организационная сторона — лучше взять самому за ситуацию. Проблемы с процедурой — пишите и пробивайте новую. НО проблемы с организацией это не повод ненавидеть те или иные технические решения.
Если напрягает, а тяга к автоматизации велика, то expect — ваш выбор:
expect в помощь.
А о чем вообще статья, какую проблему автор пытается решить? Где-то в середине статьи внезапно появилось слово "прошивка" (embedded-системы?), потом postgresq и zabbix (нет, показалось, наверное). И в конце — странная потребность выключать систему в интерактивном режиме, но через systemd.
Поясню, что и зачем применялось.
Выбор final.target и свои target — для выбора режима загрузки — live-диск, инсталлятор, нормальная работа. А также для удобной группировки своих скриптов.
Интерактивный скрипт включения — инсталлятор должен иметь возможность взаимодействовать с пользователем.
Интерактивный скрипт выключения — редко, но потребовалось запросить подтверждение от пользователя на выполнение обновления.Потому что так захотел заказчик.
Zabbix и postgresql вполне могут жить на встроенной системе. Не вижу противоречия. Собственно, такую прошивку я и описывал в другой статье — arm(2 разных платы)/x86_64 с zabbix-server и web-интерфейсом для управления.
Выбор final.target и свои target — для выбора режима загрузки — live-диск, инсталлятор, нормальная работа. А также для удобной группировки своих скриптов.
Интерактивный скрипт включения — инсталлятор должен иметь возможность взаимодействовать с пользователем.
Интерактивный скрипт выключения — редко, но потребовалось запросить подтверждение от пользователя на выполнение обновления.Потому что так захотел заказчик.
Zabbix и postgresql вполне могут жить на встроенной системе. Не вижу противоречия. Собственно, такую прошивку я и описывал в другой статье — arm(2 разных платы)/x86_64 с zabbix-server и web-интерфейсом для управления.
А если вызывать systemctl start my_shutdown@reboot то внутри юнита мы можем выполнить exec с переменной %i которая раскроется в отличии от Шелл окружения.
Sign up to leave a comment.
Systemd, интерактивные скрипты и таймеры