Comments 24
Очень интересное приключение.
Занятно, а разработчики дебиан почему не сделали единый интерфейс для создания настроенных файлов? Или это в принципе на этой стадии установки системы невозможно ?
Такой интерфейс есть, называется conffiles. К сожалению, в общем случае provenance (происхождение) файла конфигурации очень трудно установить административными методами, потому что иногда эти файлы генерируются утилитами софта (я смотрю на тебя, pg_cluster). В теории такая система была бы крутой, но… Поверьте мне, в мире update-initramfs/update-grub есть куда большие ужасы, чем отсутствие единой базы конфигов… Там гигантские стопки баша, вызвающие Си, который вызывает баш, который вызывает Си… Боль, легаси и привет из конца 90ых, когда это было "ок.
по мне вообще весь deb как принцип ущербен. Чего стоит миграции баз между версиями в пост-инсталл mysql пакета. Блин, парни, а ничего, что это не должно никогда на автомате производиться?
Я уж не говорю, что транзакционность установки пакетов в rpm-based на порядок лучше, чем в дебиан (видели необходимость делать apt install с ключом force или dpkg reconfigure, если что-то пошло не так?)
По идее может спасти этот мир CoreOS с докеризованными приложениями… но нет...
Самое обидное в этой истории, что приходится двигаться за большинством… и тут внезапно в продакшене оказывается убунта… и хорошо, если еще LTS, ога.
Хм, а мне вот наоборот, удобно что миграция версий происходит автоматически. Меньше ручной работы — обновил пакет, все что надо перезапустилось, если пакет использует debconf и я руками ничего не исправлял, то и конфиг обновился сам, и все — все работает.
Минимум ручных операций.
В чем тут проблема? Пакет же сам не прилетит с новой мажорной версией, а если я сам это делаю то явно и базы обновить хочу.
Транзакционность — оно то да, но я вот даже не вспомню когда у меня что-то ломалось по этой причине. Бывало что пакет остаётся half-installed из-за ошибки в postinst-скрипте, но тут можно найти причину и поправить — скрипты лежат себе распакованные на своем месте, и продолжить процесс через apt -f install
Особенно «полезен» этот совет, когда в процессе установки заканчивается место на /boot
www.linux.org.ru/forum/general/11955554
askubuntu.com/questions/345588/what-is-the-safest-way-to-clean-up-boot-partition/430944#430944
Удивительные приключения цитаты при квотировании...
Сказали apt -f install, в квоте появилось apt с ключом force. Хотя man страница говорит, что -f — это --fix-broken.
А дальше с удобной цитатой удобно спорить.
Да, кстати, на ситуации по ссылкам я попадал. И как-то с грехом пополам их решал.
Несколько могло бы помочь решение с разделением полномочий (т.е. один пользователь пишет в одну ветку, одно приложение пишет в одну ветку), которого так не хватает Windows Registry. Но проблемы бессмысленных, не читаемых никем параметров это не снимает.
Если каждому параметру добавить last_access_time — эта помойка ещё и тормозить будет.
Ага. А в распределенных системах роль такой базы выполняет Consul, который при неаккуратном обращении так же превращается в свалку неактуальных k/v значений. Но это судьба любого стейтфул — рано или поздно превратиться в помойку.
Наличие свалки определяется тем, является ли полученная конструкция жёсткой или нет. Теоретически, при должном фашизме, у нас может быть схема, которая позволяет отвечать на вопрос "кто отвечает за эту настройку?" и "когда это можно удалять?". Например, даже при многих своих недостатках, debian может сказать, когда конфиги приложения надо удалять и что именно "конфиг" (так называемый purge).
Но полноценная поддержка такого требует реального схемо-фашизма и проверки связности всех узлов графа. Может быть, кто-нибудь, когда-нибудь осилит такое. Пока что наслаждаемся креативным анархизмом.
— Мам, отстань, это — артефакты!
оператор ЭВМ
Вспомнил свои корочки оператора ЭВМ на втором курсе универа, вытер скупую слезу.
Отчасти эту проблему решает etckeeper — он умеет на каждое изменение в /etc писать в commit message, какие пакеты были удалены/установлены (как для deb так и для rpm). Кто конкретно создал файл он не покажет, но поможет с точностью до дня/пакета установить причастных.
отчасти эту проблему решает любой SCM (да даже ансибл в принципе, не говоря уже о нормальных системах — chef/puppet/salt), тем более, если в нем (в конф файле) пришивается заголовок, что все ручные изменения файла будут перетерты. Но, к сожалению, SCM и пакетный менеджер иногда тоже устраивает драку за то, чьи правки более верные )
Вы еще, наверно, "математик-вычислитель" не видели...
update-initramfs: Generating /boot/initrd.img-4.15.0-54-genericСудя по номеру ядра, это Ubuntu 18.04 Bionic Beaver — в Debian 10.0.0 Buster ядро 4.19.
Откуда этот конфиг? [Debian/Ubuntu]