Ага, спасибо, теперь понятна суть претензий к initrd. Да, в простых случаях (если загрузчик в состоянии прочесть файловую систему с модулями) можно было бы обойтись без него — но тут уже встает вопрос интеграции ядра и загрузчика (и ее осмысленности — раз уж мы все равно не планируем ограничиваться простыми случаями). Скажите, а как в FreeBSD принято грузиться с nfs/nbd/luks?
Что касается исправления системы — ну так нам же никто не обещал, что систему изуродовали исключительно в рамках возможностей пакетного менеджера, иначе линксовые пакетные менеджеры тоже справились бы. Можно ведь и в основной системе отлично поиграться — и разломать FreeBSD таким же точно образом. Да, отчасти явное выделение базовой системы спасает положение (и одновременно его усугубляет если сломали саму базовую систему), но раз уж на то пошло — chroot/jail & snap & flatpack & контейнеры & виртуалки решают проблему еще более радикальным образом.
Каюсь, сфокусировался на самом очевидном. А вы с самого начала после предложения клонировать бардак с помощью zfs ожидали конструктивного обсуждения? Ну так более терпеливые участники дискуссии ниже уже объяснили, в чем вы неправы, нет?
Я вроде бы понял ваш тезис: вы, кажется, хотите сказать, что пакеты/порты FreeBSD на голову выше всех линуксовых реализаций того же самого и не позволят устроить бардак в принципе (или, как минимум, не будут провоцировать его устраивать), верно? Т.е. это не вопрос дисциплины? Ну не знаю… опыта с FreeBSD у меня нет и чисто теоретически я готов такое допустить, но вряд ли это так. Или у вас есть жизненные примеры?
Насчет совместимости rsync и selinux ничего не скажу, я последний просто не использую (и поэтому setenforce 0 не делаю). А zfs позволит все корректно перенести потому что работает уровнем ниже? Т.е. dd+resize2fs тоже справятся?
Насчет пересборки и адаптации ядра: ну да, в линуксе тоже можно втянуть в ядро больше модулей, чем обычно принято делать — и initrd станет не нужным (если в нем нет никакой загрузочной логики вроде корня по nfs/nbd, но допустим, что нет) — однако зачем? И расскажите уж тогда, что такое адаптация? Это что-то отличное от пересборки? Повторюсь, что про FreeBSD я мало что знаю и практического интереса у меня к ней нет, но теоретически любопытно, что там действительно сделано лучше.
Тут — developer.gnome.org/NetworkManager/stable/NetworkManager.html — пишут, что NM таки пользуется услугами udev для обнаружения сетевых интерфейсов. Но udev — это такой же точно клиент netlink, поэтому я не вижу теоретических препятствий к тому, чтобы реагировать на появление/исчезновение сетевых интерфейсов самостоятельно — тот же networkd, насколько я понимаю, именно так и делает (а еще умеет переименовывать сетевые интерфейсы без помощи udev).
Вообще я могу ошибаться в деталях, поэтому как эксперта могу как раз посоветовать автора вышеприведенной библиотеки для работы с netlink — лет десять назад он был довольно общительным и делал (сначала на AWK, а потом на python) свою свободную систему управления сетевыми интерфейсами (и не только) поверх netlink c JunOS-like CLI — но, видимо, опередил свое время :(
Linux ездит с помощью rsync ничуть не хуже, и даже ядро адаптировать не нужно, в худшем случае собрать новый initrd потребуется. А от помойки из пакетов и самосбора FreeBSD еще меньше застрахована в силу того, что пользовательская база меньше и пространства для рукоприкладства больше :)
Для замороченных конфигураций самое просто и удобное — альт-специфичный www.altlinux.org/Etcnet — в отличие от net-scripts из RH это минимальная надстройка над ip l/a/r/ru с идентичной семантикой. Отсюда же и минусы по сравнению NM или systemd-networkd (и netplan поверх них) — поднятие десятка вланов реально сопровождается как минимум десятком вызовов ip l add + еще столько же на ip a add + еще какие-нибудь ip r/ru
Спасибо, отличный обзор! Больше десяти лет назад мы (региональный LUG) пробовали делать что-то похожее для школьных учителей информатики, презентация до сих пор жива — enp.itx.ru/linux/alt/schools/linux-inside.pdf — но местами устарела (потому как в ней нет ничего про systemd, dbus и прочий freedesktop)
По тексту я бы еще чуть больше сказал про сеть (от systemd-networkd до Ubuntu-специфичного netlplan и ALT-специфичного etcnet + всякие детали резолвинга, включающие resolvconf) — но наверняка кто-то из читателей найдет другой свой любимый молоток, придерется к тому, что нет ничего про виртуализацию и контейнеры — и т.д. :)
А расскажите, пожалуйста, как вместо микротика использовать тот же самый bird? Я попытался сделать это так:
log stderr all;
router id 127.0.0.127;
protocol bgp antifilter {
neighbor 192.3.134.152 as 65432;
import all;
export none;
local as 64999;
hold time 240;
multihop;
next hop self;
}
protocol kernel {
import none;
export all;
}
При этом я получаю во-первых:
# bird -d
2018-12-30 20:54:07 <INFO> Started
2018-12-30 20:54:07 <ERR> KRT: Received route 0.0.0.0/0 with unknown ifindex 4
2018-12-30 20:54:07 <ERR> KRT: Received route 192.168.32.0/20 with unknown ifindex 8
хотя я просил ничего из ядра не импортировать, а во-вторых ко мне в ядро экспортируются префиксы в таком виде:
# ip r
...
unreachable 13.56.0.0/14 proto bird
unreachable 13.125.0.0/16 proto bird
...
Подозреваю, что мне вместо next hop self нужно указать адрес, за которым стоит искать эти сети — но я не сумел в мануале bird найти подходящую опцию.
Резолвер переезжал в 2014-2015, а на какой FreeBSD он был раньше — никто уж и не помнит. Зоны переезжали в 2015-2016, а для варианта с хранением данных в SQL (+ веб-интерфейс) как раз задним умом и подумали о PowerDNS, но даже если б вовремя придумали такой вариант — не факт, что заморочились бы. Текстовые файлы — не такой уж плохой вариант, особенно когда что-нибудь сломается или пойдет не так…
Мы после миграции с feebsd/bind на linux/unbound настолько впечатлились результатами (справедливости ради стоит сказать, что feebsd/bind были виноваты не сами по себе, а способ, которым все это было собрано и запущено), что зоны (больше 100 прямых и раз в десять больше обратных) мигрировали на ПО от того же производителя (nsd) — и результатами остались ничуть не менее довольны.
Да, была мысль использовать БД и забыть о master/slave и *XFR — но решили пойти более простым классическим путем. Файлы зон лежат в git, не забыть после редактирования исправить сериал и сказать nsd-control reload — не такая уж сверхъестественная задача. Не забыть о git commit можно уже и крону поручить, если самому лень.
Уже некоторое время спустя пришла мысль, что можно было бы использовать powerdns c БД в качестве мастера (а по сути в качестве веб-редактора зон), а несколько экземпляров nsd — в качестве слейвов (и их уже выставили бы наружу). Но не сложилось, а когда еще сложится — может и никогда…
О выборе дистрибутива linux могу сказать одно — удобно, когда майнтейнер nsd ты сам, а с майнтейнером unbound нет никаких разногласий по поводу упаковки :)
Довольно давно (больше 5 лет назад, а с предыдущими попытками и больше) исходя именно из эстетических соображений (собрать себе необходимый но достаточный минимум по функциональности и дизайну) я прошел похожий путь подъема солнца вручную (не с LFS конечно, а с Sisyphus — включая сборку, развешивание багов или допиливание некоторых пакетов в нем же) — но еще я выкроил время на то, чтобы описать процедуру не словами, а кодом/конфигурацией (благо удобные инструменты имелись).
Результатом пользуюсь (на серверах, десктопах и бездисковых станциях) до сих пор, пересобирая образы как минимум при выходе каждого стабильного бранча, но иногда и чаще.
Это именно слой абстракции для решения задач CI средствами k8s - но немного толстоватый. Есть еще толще - Argo Workflows.
Я даже попробовал было сделать прототип простого контроллера, читающего https://github.com/apache/bigtop/blob/master/bigtop.bom и запускающий джобы с помощью https://github.com/fabric8io/kubernetes-client - но тут обнаружил, что можно было бы сначала сгенерить tekton pipeline c декларативно описанными зависимостями между тасками и т.д., а потом запустить его средствами того же самого фреймворка
Слушайте, ну ни слова ни сказать про SWT/JFace
и Eclipse — это совершенно неприлично. И даже тот факт, что это перевод, переводчика не извиняет.
Что касается исправления системы — ну так нам же никто не обещал, что систему изуродовали исключительно в рамках возможностей пакетного менеджера, иначе линксовые пакетные менеджеры тоже справились бы. Можно ведь и в основной системе отлично поиграться — и разломать FreeBSD таким же точно образом. Да, отчасти явное выделение базовой системы спасает положение (и одновременно его усугубляет если сломали саму базовую систему), но раз уж на то пошло — chroot/jail & snap & flatpack & контейнеры & виртуалки решают проблему еще более радикальным образом.
Я вроде бы понял ваш тезис: вы, кажется, хотите сказать, что пакеты/порты FreeBSD на голову выше всех линуксовых реализаций того же самого и не позволят устроить бардак в принципе (или, как минимум, не будут провоцировать его устраивать), верно? Т.е. это не вопрос дисциплины? Ну не знаю… опыта с FreeBSD у меня нет и чисто теоретически я готов такое допустить, но вряд ли это так. Или у вас есть жизненные примеры?
Насчет совместимости rsync и selinux ничего не скажу, я последний просто не использую (и поэтому setenforce 0 не делаю). А zfs позволит все корректно перенести потому что работает уровнем ниже? Т.е. dd+resize2fs тоже справятся?
Насчет пересборки и адаптации ядра: ну да, в линуксе тоже можно втянуть в ядро больше модулей, чем обычно принято делать — и initrd станет не нужным (если в нем нет никакой загрузочной логики вроде корня по nfs/nbd, но допустим, что нет) — однако зачем? И расскажите уж тогда, что такое адаптация? Это что-то отличное от пересборки? Повторюсь, что про FreeBSD я мало что знаю и практического интереса у меня к ней нет, но теоретически любопытно, что там действительно сделано лучше.
Вообще я могу ошибаться в деталях, поэтому как эксперта могу как раз посоветовать автора вышеприведенной библиотеки для работы с netlink — лет десять назад он был довольно общительным и делал (сначала на AWK, а потом на python) свою свободную систему управления сетевыми интерфейсами (и не только) поверх netlink c JunOS-like CLI — но, видимо, опередил свое время :(
По тексту я бы еще чуть больше сказал про сеть (от systemd-networkd до Ubuntu-специфичного netlplan и ALT-специфичного etcnet + всякие детали резолвинга, включающие resolvconf) — но наверняка кто-то из читателей найдет другой свой любимый молоток, придерется к тому, что нет ничего про виртуализацию и контейнеры — и т.д. :)
В примерах к apidocjs только REST однако
При этом я получаю во-первых:
хотя я просил ничего из ядра не импортировать, а во-вторых ко мне в ядро экспортируются префиксы в таком виде:
Подозреваю, что мне вместо next hop self нужно указать адрес, за которым стоит искать эти сети — но я не сумел в мануале bird найти подходящую опцию.
Да, была мысль использовать БД и забыть о master/slave и *XFR — но решили пойти более простым классическим путем. Файлы зон лежат в git, не забыть после редактирования исправить сериал и сказать nsd-control reload — не такая уж сверхъестественная задача. Не забыть о git commit можно уже и крону поручить, если самому лень.
Уже некоторое время спустя пришла мысль, что можно было бы использовать powerdns c БД в качестве мастера (а по сути в качестве веб-редактора зон), а несколько экземпляров nsd — в качестве слейвов (и их уже выставили бы наружу). Но не сложилось, а когда еще сложится — может и никогда…
О выборе дистрибутива linux могу сказать одно — удобно, когда майнтейнер nsd ты сам, а с майнтейнером unbound нет никаких разногласий по поводу упаковки :)
Результатом пользуюсь (на серверах, десктопах и бездисковых станциях) до сих пор, пересобирая образы как минимум при выходе каждого стабильного бранча, но иногда и чаще.