> tl;dr Пастернака не читал, но осуждаю?
> 1) Мы говорим не о последовательности загрузки, мы говорим о systemd-delta.
А чтобы о нем разговаривать - ман сначала прочитайте, вместо того чтобы хамить и улюлюкать. Подсказываю: systemd-delta - инструмент systemd показывающий дельту системной конфигурации относительно оригинала. Т.е. boot sequence. Опа?
> 2) Дефолтная конфигурация может быть получена в результате выполнения мейнтейнерского
> скрипта, к тому же её может не быть вовсе.
Дефолтная конфигурация в бинарных дистрах - то что майнтайнеры завернули в пакеты. Удобная точка отсчета. Даже если я набрал свой образ из пакетов, можно говорить о майнтайнерских дефолтах. Удобно тем что админы которые более-менее в теме своей системы - быстро посмотрят дельту и поймут чем именно этот экземпляр отличается.
> Так мы и говорим не о ней. Мы говорим о systemd-delta, которая
> вроде как должна сравнивать конфигурационные файлы.
Systemd-delta занимается исключительно конфигурацией системды. Но маны читать не модно, понимаю. Гораздо веселее впаривать "ценное" хейтерское мнение.
> С обеспечением boot sequence у systemd -- тоже тема весьма кислая, и
> мне есть много чего сказать по этому поводу.
Мне тоже. Лейтмотив - жизнь стала проще. Если что-то отваливается - по крайней мере понятно почему. Есть логи и коды возврата. И отслежвание таймаутов. Оно может даже в kmsg плеваться, если например rootfs - R/O.
> не будем удаляться от предмета нашего разговора, а именно, systemd-delta.
Сложно, когда хейтер мануал не изволил почитать, но ценное мнение - заимел. Это называется ламерством. У хейтеров системды оно серьезно прокачалось.
> В deb для этого используется специальный файл debian/conffiles, в котором помечаются все
> конфигурационные файлы.
У них есть и другие механизмы для всего этого, исторически там довольно много cruft'а. Некоторые чуть ли не divert из установочных скриптов делают. Но соль не в том. Какого дьявола я должен лезть в майнтайнерско-разработчиковские файлы для настройки boot sequence?
> автоматически помечает все файлы пакета, находящиеся в /etc как конфигурационные, и
> потому затереть их так просто не выйдет.
Красиво было на бумаге. А на практике пакеты дебиана ведут себя по отношению к стартовым скриптам кто как. И как только по какой-то причине надо поменять стартовый скрипт - это залет на изучение работы конкретного пакета. Теперь же, прописав свое добро в /etc/systemd можно быть уверенным что майнтайнер не сунет туда свои лапы, хоть там что. А в свой /usr/... - пусть вываливает свои юниты наздоровье, если они мне не понравятся, /etc для админов как раз и есть.
> Но даже если вам действительно так необходимо подменить какой-либо файл из пакета,
> и чтобы апдейт этого не убил, всегда есть dpkg-divert.
Это замечательно, я про него знаю, но это в данном случае костыль.
> Подменяйте на здоровье. А также по возможности сообщите мейнтейнеру, чтобы он был в
> курсе, что у пользователя в силу некоторых обстоятельств может возникнуть такая потребность.
Поттеринг доходчиво сообщил всем майнтайнерам. Чем сэкономил мне массу времени на левые костыли и контакты с майнтайнерами. PROFIT.
> Да и раньше, в общем-то, не приходилось. Может быть Вы расскажете о
> каком-нибудь случае из Вашей практики?
Какой-нибудь случай в моей практике: надо запускать свою программу, при том - строго до (или после) другой. Автор и майнтайнеры програмы не знали и не могли этого знать. А вот без трогания их скрипта это может и не получиться. Тут случается попадение на знакомство с анатомией пакета и как он стартовый скрипт тащит. Делать мне больше нечего как чужой пакет с лупой изучать! Каноникал с апстартом тоже это залажали - там тоже возможны ситуации когда надо править конфиг чужого пакета. А у системд - юнит самодостаточен, он может в любое место boot sequence встроиться своим файлом. А админ может перекрыть дефолтное поведение и никто не посмеет это затирать. В этом случае не очень принципиально, rpm это будет или deb. Или даже что-то еще.
> Я что-то не понял: а если использовать systemd, явной поддержки этого "перекрытия"
> конфигов в самой программе не требуется, что ли?
Системд не настолько крут, он только в вопросах стартовой конфигурации порядок немного навел, так что теперь майнтайнеры и админы могут друг другу не мешать хотя-бы там. Бардак в конфигурационных файлах и взаимодействие админов и майнтайнеров в остальных аспектах - тоже неплохо бы пролечить, по образу и подобию. Дебианщики что-то такое пытались изобразить в виде /etc/default, но поскольку они не Поттеринг, масштабы их успехов и близко не стояли, поэтому вопрос беспроблемного сосуществования майнтайнеров и админов по прежнему не закрыт.
> У вас какое-то непонимание вопроса. Я вот выше на примере postfix-а вам
> и объясняю, что предложенная мейнтейнером конфигурация может быть файликом, который генерируется
> скриптом post-install.
Это у вас непонимание вопроса. Systemd занимается только стартовой конфигурацией. Хотя generator'ы он таки позволяет и если будете много шуметь, можете все-таки разбудить Ктулху :)
> И этот скрипт, вообще говоря, может спросить у пользователя
> много дополнительных параметров, в зависимости от которых будут получены
> разные "дефолтные мейнтейнерские" конфигурации.
С чем тоже проблемы. Системы бывают разные. В том числе неинтерактивные, где отвечать некому и/или некуда. И когда какой-то хочет что-то спросить, это виснет при установке. В дебиане по этому поводу пробовали изобрести решение. Но как обычно, получилось наполовину и с рядом своих проблем. Одна из причин по которой стоит минимизировать использование чрезмерно умных скриптов. И в стартовой последовательности и при установке. Никогда не знаешь где эти 5 кило сложной логики подложат внезапную свинью, сумничав лишний раз.
> Вот и вопрос: как в этом случае дифф брать? Такое предусмотрено?
Нет, конечно. Системд только своей конфигурацией занимается. А теперь вам вашим же вопросом по лбу: а чего делать с системой контроля версий? И вообще, как апгрейд пакета нормально обрабатывать предлагается? Сможете протелепать - хочет ли админ ответить на эти вопросы заново или пусть старое будет? А если старое, вероятно, несовместимо? Вот так путем размножения сущностей начинается бардак в системе. А потом кто-нибудь желающий раскидать пакет на 500 хостов сношается с этими умными скриптами, задающими вопросы вникуда и очень радуется. Ну ок, дебианщики попробовали изобрести какое-никакое апи которое относительно нейтрально относительно реализации и возможность задать дефолтные ответы для неинтерактива. А другие? Ну и вообще, сработало это едва ли на половину.
Поэтому если какая-нибудь шапка выкатит решение и для конфигов вообще и в большинстве дистров волевым решением майнтайнеров придется строиться - извините, но...
>> SCM и все сделать самому. Можно даже написать свою ОС. Но
>> это требует времени и не способствует решению изначальной задачи.
> И в чём же заключается изначальная задача?
О, про это уже все забыли? :) По логике вещей - в том чтобы новый админ мог быстро понять что и почему творится в системе. А также неплохо бы иметь "reset to factory defaults". Потому что исследование на три дня почему все нагнулось - прекрасно, но три дня впашки квалифицированного спеца - слишком дорого и клинит задачу "сервера должны работать".
> Вообще, существование этого инструмента -- это в некотором роде попытка внедрить в
> systemd ещё и SCM.
Поскольку systemd всяко читает майнтайнерские конфиги и потом оверрайдит админскими, у него по любому есть это view и очень здорово что он умеет вывешивать его админу.
> Ну, как бы, спасибо, конечно. Но этой SCM ещё надо учиться,
> и работать она будет только в системах на базе systemd.
На самом деле довольно простая но полезная утилита. Оно не хранит state - state это то что есть от майнтайнеров в usr и от админа в etc. То что оно может это по человечески показать - ну и отличненько, удобно. Но это только для юнитов системды, увы.
> Почему бы админу не выучить какую-нибудь SCM более
> общего назначения? Тот же ansible, например?
Наверное потому что systemd-delta это мелкий системный тул, который и близко не стоял к таким переросткам. И наличие оного в любой системе с системд жирный плюс для быстрого въезда чем эта система отличается от дефолтного состояния. Сразу видно кого еще дописали в старт. Но там и масштаб решаемых задач помельче. Показ чем текущий конфиг системд отличается от майнтайнерского. А в sysv rc так вообще нельзя без рояля в кустах. Извините но ansible встречается не на каждой системе с sysv rc, что сильно усложняет жизнь.
