Debian и сеть
Продолжение предыдущего поста или почему я был не прав. Но прежде чем перейти к рассмотрению вопроса по существу, необходимо сперва сделать два лирических отступления.
Первое: про саму суть проблемы. Из предыдущего поста стало ясно, что если какой-то сетевой демон (например тот же NginX) во время старта хочет сделать системный вызов bind() на какой-то конкретный IP-адрес, а сам этот адрес ни на один интерфейс ещё не назначен, то демон вывалится с ошибкой. Но тут возникает следующий вопрос: а как так вообще получается, что интерфейс уже есть, а адреса ещё нет?
Первый вариант: происходит конфигурация сети по DHCP. В таком случае DHCP-клиент должен запуститься, послать запрос, дождаться ответа от сервера, всякие там discover - offer - request - ack. Это всё не быстро. За это время на локальной машине может очень много всего произойти. Но даже если у вас всё настроено статически, остаётся ещё и...
Второй вариант: IPv6. У него есть механизм DAD (Duplicate Address Detection). Он опрашивает всех соседей возгласом вида "а нет ли тут ещё кого-нибудь случайно с таким же адресом как у меня". На это уходит одна-две секунды, но по меркам современных серверов это тоже овердохрена.
Стало быть, мало просто скомандовать сетевому интерфейсу "назначь такой-то адрес", нужно ещё выждать какое-то разумное время для устаканивания DHCP / DAD, а в идеале получить какую-то обратную связь о результате. Поэтому второе лирическое отступление о том какие вообще в Deb-based дистрибутивах бывают способы настройки сети, если отбросить совсем уж лютое legacy.
- Запустить напрямую dhcpd. Иногда такое практикуют в embedded-системах. На серверах и десктопах встречается редко.
- ifupdown . Это тот самый "/etc/network/interfaces". С одной стороны, привет из очень далекого прошлого. С другой стороны, отточен и надежен как топор деревенского плотника. Идет в Debian-е из коробки по умолчанию. Вот для него есть специальный systemd-юнит "ifupdown-wait-online.service". Это тупо набор bash-евых скриптов, который пытается раз в секунду пинговать самого себя. И если получилось, значит можно считать что сеть поднялась. Незамысловато, но работает.
- ifupdown2 . Это тот же самый ifupdown, только переписанный на python-е. Он полностью совместим с синтаксисом ifupdown и добавляет к нему некоторые весьма удобные фичи наподобие "ifreload -a" плюс дополнительное удобство при написании конфига. Признаться, он мне нравится. Но вот беда: юнит "ifupdown-wait-online.service" с ifupdown2 уже несовместим. А чего-либо с аналогичным функционалом в ifupdown2, увы, не завезли.
- network-manager . Весьма удобен для десктопного применения, в том числе и наличием GUI. Но вот настраивать какие-нибудь 802.3ad LACP или порты OpenVSwitch с его помощью - это боль. Пробовал, больше не хочу.
- systemd-networkd . Всерьёз его гонять персонально я не пробовал. В принципе, если речь идёт только о сервере, который использует только статику, то почему бы и нет. Ещё весьма удобно применять в связке с systemd-nspawn. Как и все что связано с systemd, он активно использует D-Bus. И вот "systemd-networkd-wait-online.service" из предыдущего поста - это как раз про него, а не про ifupdown2. В этом и заключалась моя принципиальная ошибка. И да, если этот самый "systemd-networkd-wait-online.service" почему-то "подвешивает" систему, то в первую очередь нужно проверять работоспособность D-Bus.
- netplan . По мне так, это какое-то извращение, являющееся надстройкой над networkd или NetworkManager с YAML-конфигом для хипстеров-смузихлёбов и адептов Docker-а. Идёт по умолчанию "из коробки" в Ubuntu. Впрочем, никто не запрещает снести его и воткнуть что-нибудь из вышеперечисленного.
Возвращаясь к нашим баранам. А именно, к вопросу "дождаться окончания конфигурации сети". Тезисно.
- Если сетевой демон bindится на 0.0.0.0 и/или [::], то проблемы нет.
- Если интерфейс, куда хочется заbindиться, настроен статикой и без IPv6, то проблемы тоже нет.
- ifupdown "классический" (первой версии) и systemd-networkd умеют решать эту проблему "из коробки", поэтому если позволяют условия задачи, то можно применять их.
- В ifupdown2 отсутствуют встроенные средства, позволяющие отследить готовность сети к работе (либо они мне неизвестны). Поэтому в случае наличия DHCP и/или IPv6 лучше выбрать какой-нибудь другой инструмент.
- При использовании последних трёх инструментов из списка выше нужно следить за наличием и работоспособностью D-Bus, потому что там задействуется целый набор разных программ, которые обмениваются между собой сообщениями именно по этой шине.
P.S. Да, есть ещё ifupdown-ng и некоторая другая экзотика, но это немного уже "за рамками".
P.P.S. Пока копался в кишках systemd, обнаружил что в Debian-е "из коробки" идут два заподлянских таймера: "apt-daily.timer", "apt-daily-upgrade.timer". Это они конечно зря... Впрочем, это уже совсем другая история... ©