P10 -> P11: проблемы с сетью

[kiav]

Всё когда-то ставил со стартер кита. И обновлялся уже с P9 до P10. Переходил на systemd. История длинная у сервера.
На P10 болячек не было.

Сразу после обновления на P11 (всё по Вики) потерялась сеть. До обновления NetworkManager не использовался.
Ок, в VNC семейством команд ip поднял сеть.

Спойлер

ip addr add 111.222.333.444/255.255.255.255 dev ens32
ip link set dev ens32 up

ip route add 555.666.777.888 dev ens32
ip route add default via 555.666.777.888

Все файлы в /etc/net/ifaces/eth0 сохранились. IP и шлюз взял оттуда.
/etc/net/ifaces/eth0/resolve.conf скопировал в /etc/resolve.conf

Для дальнейшего управления сетью поставил NetworkManager-tui (он подтянул остальное, службу я запустил, она и активирована из коробки).
На всякий случай, в /etc/net/ifaces/eth0/options добавил

Код: [Выделить]

NM_CONTROLLED=no
DISABLED=yes
Это убрало устройство eth0 из nmtui. Осталось только ens32. Вот оно настроено в nmtui автоматически подключаться и быть доступным всем.

CONFMETHOD=etcnet в /etc/sysconfig/network не трогал (он у меня и на ПК c Рабочей станцией К 10 такой, а там NetworkManager).

Проблема с таким софтом, как nginx и bind. Будет заметна, если в конфигах есть явная привязка к внешнему IP, а не к "любому" адресу.

Тогда в логе можно увидеть такое

Код: [Выделить]

nginx[1692]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx[1692]: nginx: [emerg] bind() to xxx.xxx.xxx.xxx:80 failed (99: Cannot assign requested address)
nginx[1692]: nginx: configuration file /etc/nginx/nginx.conf test failed
systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: nginx.service: Failed with result 'exit-code'.
systemd[1]: Failed to start nginx.service - The nginx HTTP and reverse proxy server
и такое

Код: [Выделить]

named[1592]: listening on IPv4 interface ens32, xxx.xxx.xxx.xxx#53
named[1592]: creating IPv4 interface ens32 failed; interface ignored
Само собой, из-за этого недоступны nginx и bind извне (порты открыты, всё с этим в порядке).

Простейшее решение - перезапуск служб после загрузки и входа в систему. Вариант паршивый - сервер боится перезагрузки.

Замечено, что проблема не возникает, если такая служба запускается после вот этой записи в логе

Код: [Выделить]

NetworkManager[1413]: <info>  [1755984276.1333] device (ens32): state change: ip-config -> ip-check (reason 'none', managed-type: 'full')
Для успеха не требуется ни

Код: [Выделить]

NetworkManager[1413]: <info>  [1755984276.2409] device (ens32): state change: secondaries -> activated (reason 'none', managed-type: 'full')
NetworkManager[1413]: <info>  [1755984276.2411] manager: NetworkManager state is now CONNECTED_SITE
ни более крутое

Код: [Выделить]

NetworkManager[1413]: <info>  [1755984276.2566] device (ens32): Activation: successful, device activated.
NetworkManager[1413]: <info>  [1755984276.2580] manager: NetworkManager state is now CONNECTED_GLOBAL
NetworkManager[1413]: <info>  [1755984276.2587] manager: startup complete
Что нужно сделать, чтобы nginx и bind запускались после CONNECTED_GLOBAL?

[kiav]

Поискал в Яндексе. Там Алиска подключилась.

Упоминают службу systemd-networkd-wait-online.service из пакета systemd-networkd. Он на сервере не установлен, службы нет.
Предлагается в unit-файлах прописать в After= строку network-online.target (не network.target).

Оно?

[kiav]

Установил. Проблемные unit-файлы изменил (копированием в /etc).

Сервер перезагрузки больше не боится. Но сама служба systemd-networkd-wait-online имеет проблемы с таймаутами.

Код: [Выделить]

авг 28 20:45:20 example.com systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Configured...

авг 28 20:45:51 example.com systemd-networkd-wait-online[809]: Timeout occurred while waiting for network connectivity.

авг 28 20:47:20 example.com systemd-networkd-wait-online[608]: Timeout occurred while waiting for network connectivity.
авг 28 20:47:20 example.com systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
авг 28 20:47:20 example.com systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
авг 28 20:47:20 example.com systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Configured.
авг 28 20:47:20 example.com systemd[1]: Reached target network-online.target - Network is Online.
авг 28 20:47:20 example.com systemd[1]: Starting bind.service - Berkeley Internet Name Domain (DNS)...
авг 28 20:47:20 example.com systemd[1]: Starting dovecot.service - Dovecot IMAP/POP3 email server...
авг 28 20:47:20 example.com systemd[1]: Starting openvpn.service - OpenVPN daemons...
авг 28 20:47:20 example.com systemd[1]: Starting postfix.service - Postfix Mail Transport Agent...
авг 28 20:47:20 example.com systemd[1]: Starting rsyslog.service - System Logging Service...
авг 28 20:47:20 example.com systemd[1]: Starting xinetd.service - xinetd is a powerful replacement for inetd...

[ruslandh]

Но сама служба systemd-networkd-wait-online имеет проблемы с таймаутами.

Ну, она ждёт установки соединения.

[kiav]

Но сама служба systemd-networkd-wait-online имеет проблемы с таймаутами.

Ну, она ждёт установки соединения.

Т.е., это нормальное поведение? По логу кажется, что это страшная ошибка.

Судя по отметкам времени, на первую попытку отводится 30 секунд. На вторую - 90.

[ruslandh]

Да, чем быстрее создастся соединение, тем меньше уму ждать.

[asy]

Для дальнейшего управления сетью поставил NetworkManager-tui (он подтянул остальное, службу я запустил, она и активирована из коробки).
На всякий случай, в /etc/net/ifaces/eth0/options добавил

Код: [Выделить]

NM_CONTROLLED=no
DISABLED=yes
Это убрало устройство eth0 из nmtui. Осталось только ens32. Вот оно настроено в nmtui автоматически подключаться и быть доступным всем.

Зачем?

Во-первых, NM_CONTROLLED=no. Какой тогда NM? Во-вторых, если нужен только NM, сейчас (в p11), как выясняется, можно в системе etcnet вовсе не иметь. Хотя для меня загадка, зачем нужно NM, а не etcnet. В-третьих, если есть eth0, наверное установлен пакет udev-rule-generator-net. Его можно удалить тогда (и udev-rule-generator), если устраивает безобразие вида ens32 (и генерируемый им файл /etc/udev/rules.d/70-persistent-net.rules вместе с симлинком 80-net-setup-link.rules).

[kiav]

Хотя для меня загадка, зачем нужно NM, а не etcnet

Оно (etcnet) упало после обновления. В целом, опять таки, мне все равно что именно поднимает сеть. etcnet подвела и идет на ... Теперь NetworkManager. Мне показалось, что нет смысла разбираться в причинах падения. К nmcli и nmtui я, более менее, привык. bugreport карябать по теме? А кому оно надо кроме меня (у кого еще сервер установлен 10 лет назад и кто потерял сеть при последнем обновлении)?

В-третьих, если есть eth0, наверное установлен пакет udev-rule-generator-net.

Установлен. Удалил. Сеть не убита. Спасибо.

Спойлер

авг 30 14:43:41 example.com kernel: e1000 0000:02:00.0 eth0: (PCI:66MHz:32-bit) 00:50:56:08:29:32
авг 30 14:43:41 example.com kernel: e1000 0000:02:00.0 eth0: Intel(R) PRO/1000 Network Connection
авг 30 14:43:41 example.com kernel: e1000 0000:02:00.0 ens32: renamed from eth0
авг 30 14:43:41 example.com systemd-networkd[552]: eth0: Interface name change detected, renamed to ens32.
авг 30 14:43:41 example.com systemd[1]: Starting NetworkManager.service - Network Manager...

если устраивает безобразие вида ens32

В целом, да. Мне абсолютно все равно как называется сетевой интерфейс. Нужно, чтобы он работал. Название несколько лет назад удивило. Но я не стал разбираться откуда вообще такие названия. Это идентификатор. Может быть каким угодно.

udev-rule-generator

Не разбираюсь настолько. udev-rule-generator-net удалил по совету а-ля rm -rf / Показалось, что полезно удалить. Но система в своем брюхе все равно использует наименование eth0 (в спойлере выше).

Вижу, что /sysconfig/udev-rule-generator удален. И там масса комментариев по проблемам и ссылки на ошибки типа https://bugzilla.altlinux.org/32167 и https://bugzilla.altlinux.org/29282#c30

Видно, что там не так все просто. Вероятно, и udev-rule-generator более не нужен. Потом посмотрю что да как, если тут идею не подкинет никто.

[asy]

Оно (etcnet) упало после обновления.

Оно не может упасть. Оно - разово запускающийся набор скриптов, настраивающий сеть. Прост и надёжен, как валенок. В отличие от.

И там масса комментариев по проблемам и ссылки на ошибки типа https://bugzilla.altlinux.org/32167 и https://bugzilla.altlinux.org/29282#c30

Вот udev-rule-generator, как раз, эти ошибки и пытается исправить, так как в udev исправлять никто не чешется. Но если ахинея вида enp* устраивает, эти ошибки значения не имеют.

[kiav]

Оно не может упасть.

Провел обновление по инструкции, перезагрузил ОС, получил неработающую сеть и лечил проблему по VNC. Так что, определенно, может

[kiav]

и udev-rule-generator

Удалил, сеть жива (после перезагрузки). Судя по содержимому и описанию, там библиотеки функций и сервис, который отрабатывает скрипты из таких пакетов, как udev-rule-generator-net.

[asy]

Оно не может упасть.

Провел обновление по инструкции, перезагрузил ОС, получил неработающую сеть и лечил проблему по VNC. Так что, определенно, может

Потому, что где-то что-то не переименовалось вовсемя, или что-то не подняло интерфейс. Это на 100% не проблема etcnet, уж я-то знаю, ибо пользуюсь. И про udev-rule-generator-net тоже знаю много, как мантейнер пакета. И да, на systemd он не рассчитан, так как я systemd практически не пользуюсь. Тем не менее сейчас в задании https://packages.altlinux.org/en/tasks/393331/ лежит обновление для p11, которое с systemd должно работатать. Но, опять же, не сразу после обновления с p10, сначала надо будет сделать systemctl enable для сервиса.

При всём при этом, если кто-то когда-то уже создал правильный /etc/udev/rules.d/70-persistent-net.rules, всё должно работать вовсе без установленного udev-rule-generator. В общем однозначно

1. etcnet работает.
2. если при перезагрузке нет сети, значит кто-то (init) не запустил /etc/rc.d/network start.
3. если всё же запустил, значит etcnet настроен для почему-то несуществующего на момент его старта интерфейса.

С этим 3 не очень ясно. Если это обновление с p10, а там udev-rule-generator-net был установлен, то 70-persistent-net.rules есть и udev должен работать в плане переименования. В общем 3 случиться было не должно.

[asy]

и udev-rule-generator

Удалил, сеть жива (после перезагрузки). Судя по содержимому и описанию, там библиотеки функций и сервис, который отрабатывает скрипты из таких пакетов, как udev-rule-generator-net.

И да, единственное, что делает эта группа пакетов, это задаёт правила для формирования 70-persistent-net.rules и заставляет udev исполнить эти правила, если они только что, при этой же загрузке, созданы (при следующей загрузке udev это сделает сам). В случае статической конфигурации железа udev-rule-generator и udev-rule-generator-net становятся не нужны при последующих перезагрузках, если 70-persistent-net.rules не удалять.

[kiav]

если 70-persistent-net.rules не удалять

А вот его то и нет.

И сам я его не удалял. Не удалял и apt-get.
После восстановления работоспособности системы, подчистки с соответствующими изменениями всех .rpmsave, .rpmnew и .rpmorig я поставил etckeeper.

Код: [Выделить]

etc# hg log --removed udev/rules.d/70-persistent-net.rules
 etc#
Его после обновления ОС P10 -> P11 уже не было (есть архив /etc сразу после первой загрузки). Проверил протокол работ по .rpmsave и Ко. Там по udev нет ничего. Так что, и случайно замочить не мог.

Не в этом ли причина потери сети после обновления? Железо стабильно (VDS).