А что в вашем комментарии может вызвать негативную эмоцию? Ну да, таких историй за всю историю человечества накопилось несчетное количество, вы правы. Но детали важны, тем более что конкретно эта история в большей степени про людей (ну а телеком - знакомый фон, который делает ее понятнее как раз старичкам, а не новичкам)
Спасибо не то слово ... прямо таки ностальгия накатила (и технически, ну разве к DSL/FTTB/MPLS у меня еще VoIP/SIP/MGCP/H.323 рядом - но это много еще кто вспомнит, а вот Курс/Онима/Аргус - это уже наша местечковая южная история)
Но я ушел сам (причем не сразу, какое-то время сидел на двух стульях) и уже со стороны наблюдал, во что это превращается (в т.ч. с абонентской стороны, когда неделю не мог техподдержке объяснить, что у меня не просто техническая возможность есть, а я даже вижу кусочек технологической сети и служебный трафик в ней - и вопрос исключительно в том, чтоб выдать мне актуальную пару логин/пароль для PPPоE)
Пробовал использовать geesefs + csi provider некоторое время назад и обнаружил, что при падении самого процесса geesefs (panic по коду там достаточно и один из них у меня срабатывал при параллельной записи один объект бакета) с pv/pvc ничего нельзя было сделать кроме как размонтировать сетевое устройство прямо на ноде кубера - https://github.com/yandex-cloud/k8s-csi-s3/issues/86
Собственно проблему, приводящую к падению в моем случае, похоже исправили, но как это эксплуатировать в общем случае без возможности автоматического восстановления после падения - непонятно
Разумеется. А ниша для классических админов тоже никогда полностью не исчезнет - примерно так же, как при наличии супермаркетов мелкие магазинчики и ларьки в шаговой доступности все еще живы :)
Собственно, нагуглил это все как только понял, что моя задача отлично ложится на модель CGI - и после этого стало интересно, нет ли других реализаций кроме apache/lighttpd/openresty?
Ага, спасибо, теперь понятна суть претензий к 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) — но наверняка кто-то из читателей найдет другой свой любимый молоток, придерется к тому, что нет ничего про виртуализацию и контейнеры — и т.д. :)
А что в вашем комментарии может вызвать негативную эмоцию? Ну да, таких историй за всю историю человечества накопилось несчетное количество, вы правы. Но детали важны, тем более что конкретно эта история в большей степени про людей (ну а телеком - знакомый фон, который делает ее понятнее как раз старичкам, а не новичкам)
Спасибо не то слово ... прямо таки ностальгия накатила (и технически, ну разве к DSL/FTTB/MPLS у меня еще VoIP/SIP/MGCP/H.323 рядом - но это много еще кто вспомнит, а вот Курс/Онима/Аргус - это уже наша местечковая южная история)
Но я ушел сам (причем не сразу, какое-то время сидел на двух стульях) и уже со стороны наблюдал, во что это превращается (в т.ч. с абонентской стороны, когда неделю не мог техподдержке объяснить, что у меня не просто техническая возможность есть, а я даже вижу кусочек технологической сети и служебный трафик в ней - и вопрос исключительно в том, чтоб выдать мне актуальную пару логин/пароль для PPPоE)
"Новую сеть" я тоже в итоге нашел :)
Пробовал использовать geesefs + csi provider некоторое время назад и обнаружил, что при падении самого процесса geesefs (panic по коду там достаточно и один из них у меня срабатывал при параллельной записи один объект бакета) с pv/pvc ничего нельзя было сделать кроме как размонтировать сетевое устройство прямо на ноде кубера - https://github.com/yandex-cloud/k8s-csi-s3/issues/86
Собственно проблему, приводящую к падению в моем случае, похоже исправили, но как это эксплуатировать в общем случае без возможности автоматического восстановления после падения - непонятно
Разумеется. А ниша для классических админов тоже никогда полностью не исчезнет - примерно так же, как при наличии супермаркетов мелкие магазинчики и ларьки в шаговой доступности все еще живы :)
Не могу не привести в ответ взгляд на работу админа с другой стороны - https://habr.com/ru/articles/343644/
CGI настолько хорошо забыли, что даже неоднократно переизобрели:
https://github.com/adnanh/webhook
https://github.com/soulteary/webhook
https://github.com/ncarlier/webhookd
Собственно, нагуглил это все как только понял, что моя задача отлично ложится на модель CGI - и после этого стало интересно, нет ли других реализаций кроме apache/lighttpd/openresty?
Это именно слой абстракции для решения задач 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 однако