Пробовал использовать 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) — но наверняка кто-то из читателей найдет другой свой любимый молоток, придерется к тому, что нет ничего про виртуализацию и контейнеры — и т.д. :)
А расскажите, пожалуйста, как вместо микротика использовать тот же самый 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 найти подходящую опцию.
Пробовал использовать 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 однако
При этом я получаю во-первых:
хотя я просил ничего из ядра не импортировать, а во-вторых ко мне в ядро экспортируются префиксы в таком виде:
Подозреваю, что мне вместо next hop self нужно указать адрес, за которым стоит искать эти сети — но я не сумел в мануале bird найти подходящую опцию.