Ads
Comments 24
+1

Очень интересное приключение.
Занятно, а разработчики дебиан почему не сделали единый интерфейс для создания настроенных файлов? Или это в принципе на этой стадии установки системы невозможно ?

+4

Такой интерфейс есть, называется conffiles. К сожалению, в общем случае provenance (происхождение) файла конфигурации очень трудно установить административными методами, потому что иногда эти файлы генерируются утилитами софта (я смотрю на тебя, pg_cluster). В теории такая система была бы крутой, но… Поверьте мне, в мире update-initramfs/update-grub есть куда большие ужасы, чем отсутствие единой базы конфигов… Там гигантские стопки баша, вызвающие Си, который вызывает баш, который вызывает Си… Боль, легаси и привет из конца 90ых, когда это было "ок.

+2

по мне вообще весь deb как принцип ущербен. Чего стоит миграции баз между версиями в пост-инсталл mysql пакета. Блин, парни, а ничего, что это не должно никогда на автомате производиться?
Я уж не говорю, что транзакционность установки пакетов в rpm-based на порядок лучше, чем в дебиан (видели необходимость делать apt install с ключом force или dpkg reconfigure, если что-то пошло не так?)
По идее может спасти этот мир CoreOS с докеризованными приложениями… но нет...


Самое обидное в этой истории, что приходится двигаться за большинством… и тут внезапно в продакшене оказывается убунта… и хорошо, если еще LTS, ога.

0

Хм, а мне вот наоборот, удобно что миграция версий происходит автоматически. Меньше ручной работы — обновил пакет, все что надо перезапустилось, если пакет использует debconf и я руками ничего не исправлял, то и конфиг обновился сам, и все — все работает.
Минимум ручных операций.
В чем тут проблема? Пакет же сам не прилетит с новой мажорной версией, а если я сам это делаю то явно и базы обновить хочу.


Транзакционность — оно то да, но я вот даже не вспомню когда у меня что-то ломалось по этой причине. Бывало что пакет остаётся half-installed из-за ошибки в postinst-скрипте, но тут можно найти причину и поправить — скрипты лежат себе распакованные на своем месте, и продолжить процесс через apt -f install

+2

Удивительные приключения цитаты при квотировании...


Сказали apt -f install, в квоте появилось apt с ключом force. Хотя man страница говорит, что -f — это --fix-broken.


А дальше с удобной цитатой удобно спорить.

0
Да нет, там gecube именно про ключ force сказал. Ошибся, видимо. Или не так понял параметр.
0

ну, может я и ошибся ) по памяти писал, а на абсолютное знание дебиан систем я не претендую )

0

Да, кстати, на ситуации по ссылкам я попадал. И как-то с грехом пополам их решал.

0
А единая база конфига на реальной, работающей системе (т.е. у нас есть несколько сотен пакетов — включая служебные, которые в этой системе работают минимум два релиза, т.е. есть legacy-параметры) приводит… внезапно, к появлению свалки типа «реестр».
Несколько могло бы помочь решение с разделением полномочий (т.е. один пользователь пишет в одну ветку, одно приложение пишет в одну ветку), которого так не хватает Windows Registry. Но проблемы бессмысленных, не читаемых никем параметров это не снимает.

Если каждому параметру добавить last_access_time — эта помойка ещё и тормозить будет.
0

Ага. А в распределенных системах роль такой базы выполняет Consul, который при неаккуратном обращении так же превращается в свалку неактуальных k/v значений. Но это судьба любого стейтфул — рано или поздно превратиться в помойку.

+2

Наличие свалки определяется тем, является ли полученная конструкция жёсткой или нет. Теоретически, при должном фашизме, у нас может быть схема, которая позволяет отвечать на вопрос "кто отвечает за эту настройку?" и "когда это можно удалять?". Например, даже при многих своих недостатках, debian может сказать, когда конфиги приложения надо удалять и что именно "конфиг" (так называемый purge).


Но полноценная поддержка такого требует реального схемо-фашизма и проверки связности всех узлов графа. Может быть, кто-нибудь, когда-нибудь осилит такое. Пока что наслаждаемся креативным анархизмом.

+8

— Мы уже много раз обсуждали, что все артефакты должны помещаться в централизованное хранилище с заданной retention policy.

0
Эх, когда же будут по дефолту конфиги по типу git, чтобы было ясно, кто, откуда, когда и какую строчку. Сохранил как шпаргалку, так как часто подобное приходилось делать в RPM-based.
оператор ЭВМ

Вспомнил свои корочки оператора ЭВМ на втором курсе универа, вытер скупую слезу.
0

Отчасти эту проблему решает etckeeper — он умеет на каждое изменение в /etc писать в commit message, какие пакеты были удалены/установлены (как для deb так и для rpm). Кто конкретно создал файл он не покажет, но поможет с точностью до дня/пакета установить причастных.

-1

отчасти эту проблему решает любой SCM (да даже ансибл в принципе, не говоря уже о нормальных системах — chef/puppet/salt), тем более, если в нем (в конф файле) пришивается заголовок, что все ручные изменения файла будут перетерты. Но, к сожалению, SCM и пакетный менеджер иногда тоже устраивает драку за то, чьи правки более верные )

0
Ansible не решит части проблем, если при апдейте системы приползёт новый системный скрипт, который внезапно добавит или изменит конфиг, который до этого Ansible вообще не трогал. Но etcd/consul выглядит для конфигов более удобным, чем Ансибл, хотя проблемы остаются те же, все системные конфиги в него не запихаешь. (Как девелопер сейчас смотрю на эту кухню более со стороны)
0
Вычислитель — это же железяка, за которой работает математик?
0
update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
Судя по номеру ядра, это Ubuntu 18.04 Bionic Beaver — в Debian 10.0.0 Buster ядро 4.19.
+1

Ага. Но пост как раз про дебиановскую подсистему, которая в убунте до сих пор основная (сколько бы они не пытались своё придумать).

+1
сколько бы они не пытались своё придумать
Использую разные сборки Ubuntu (на десктопе, нетбуке и VPS) с 2009 года, а недавно поставил на нетбук Debian Buster. И чем больше я с ним знакомлюсь, тем больше удивляюсь: зачем нужна Ubuntu, когда есть Debian.
Only those users with full accounts are able to leave comments.  , please.