Вопрос про ifup, ifdown и NetworkManager.

Почему NetworkManager не заменил собой всё?

У меня нет if(up|down|query) в отличии от nm*

Конечная цель - выпил NetworkManager из железки-одноплатника с целью упрощения работы с сетью

Дело хозяйское. Если проще, то удалите.

Вот есть файлик /etc/network/interfaces. Это конфиг для бинарников ifup и ifdown.

Это старый (и устаревший, obsoleted) механизм настройки сети в debian и его потомках

Когда они запускаются?

Чаще всего при загрузке системы. Ещё из udev

например, так:

# cat /lib/udev/rules.d/80-ifupdown.rules
# Allow rfkill for users in the netdev group
KERNEL=="rfkill", MODE="0664", GROUP="netdev"

# Handle allow-hotplug interfaces
SUBSYSTEM=="net", ACTION=="add|remove", RUN+="ifupdown-hotplug"

Если у интерфейса написано auto, значит надо получить адрес по DHCP на него. А какой бинарник физически этим занят? dhclient?

ЕМНИП, dhclient

Какая сязь ifup/ifdown с NetworkManager?

Если интерфейс есть в конфиге /etc/network/interfaces, networkmanager его не трогает

Почему NetworkManager не заменил собой всё?

Потому, что он не должен ломать исторически сложившиеся механизмы. Как в rhel, так и в debian

Область применения: терминал продажи еды в торговом центре, куда очень бы не хотелось ездить и который бы был максимально тупым и надёжным в плане попыток «найти интернетик».

Какой-нибудь watchdog, который периодически тыкает твой сайт, и если не достучался, пробует перезапустить сеть

Какой-нибудь watchdog, который периодически тыкает твой сайт, и если не достучался, пробует перезапустить сеть

Почти так. Именно почти, но направление мысли вы очень правильно озвучили.

Про watchdog: понятно, что это не тыкание сайта, а более сложно: тыкнуть надо несколько НАДЁЖНЫХ ip-адресов просто пингом. Решение о перезапуске сети делается по недоступности ВСЕХ этих адресов. Перезапускать сеть даже если недоступно стало 99% этих адресов, а отвечает только один - тоже странно, поскольку это всё ещё означает, что интернет есть и он нормален, у меня ведь на оконечном клиентском девайсе нет никаких хитрых таблиц маршрутизации. Хотя, возможно изменился дефолтный гейтвей, а старый видит только этот один айпишник и скоро его вообще погасят. В общем, да, наверное осмысленно начинать перезапускать сеть, когда пропало, скажем, 70% от списка айпишников.

Итого скрипт примерно такой:

1. Пингануть по очереди все айпишники, послав штуки 4 запроса в каждый. Все ответы складывать в файлик специального своего формата. На каждый айпишник - секунды 4 времени. Что за айпишники: DNS-ы гугла, яндекса, какие-то стабильные серваки mail.ru и прочих корпораций, айпишники больших новостных сайтов. Этот список надо держать актуальным, возможно периодически загружать в рамдиск с какого-то внешнего управляющего центрального сервака.

2. После обхода списка, запускается скрипт-анализатор, который читает вышесформированный отчёт (на формирование которого могла уйти минута), делает выводы о проценте недоступности и принимает решения.

3. Слип 2 минуты и всё по-новой.

Не очевидно как вести себя с DNS. Возможно надо иметь в /etc/resolv.conf просто штук 5 разных адресов: пару популярных гугловых, пару яндексовых, что-то ещё. Возможно этого гарантированно навсегда хватит. Пинг не должен пинговать по доменным именам, поскольку таким образом он может споткнуться о недоступность DNS в целом (незнаю по какой причине) и таким образом неудачно пингануть ничего вообще. Хотя наверное это и правильно - если ты пинуту пинговал разные доменные адреса и у тебя всё зафейлилось, то точно стоит пнуть сеть целиком…

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

Я такое без промежуточных файликов делал. Делаем цикл с пингом по одному! запросу (но несколько штук), и на разные свои! хосты, если хоть один прошел, значит живы. Если все не прошли, значит сибирский пушистик.

Это старый (и устаревший, obsoleted) механизм настройки сети в debian и его потомках

4.2