> Но у NM довольно много закидонов и в хитрых конфигурациях это как-то анноит.Есть немного. Лично я видел такой: распарзен конфиг eth-интерфейса с ipv6 на роутере, которая сама предоставляет ipv6 интерфейс через туннельный sit. Обычный текстовый конфиг ifcfg- в редхатовском стиле через плагин NM для работы с этим форматом. NM почему-то упорно пытается поднять маршрут по умолчанию для ipv6 на eth, который мешает, если опустить настоящий туннель с настоящим маршрутом по-умолчанию (проходящие пакеты вместо того, чтобы отвергаться, пытаются уйти в другую сеть). Решилось ручным удалением через nmcli, т.к. из собственно конфига такое требование никак не следовало (наоборот, было по-всякому выключено) и зачем он это делает, непонятно.
> Очевидный пример: он привязывается к MAC и весьма дурно реагирует на девайсы не имеющие постоянного мак-адреса. А такие бывают. Особенно какой-нибудь эзернет-поверх-юсб к вон той платке. И вот nm судорожно пытается dhcp поднять. Хотя сказали гаду по людски - сделай там статику. Но мак уехал - все, это новый ифейс и нии...т. Хоть это и тот же компьютер и то же название ифейса. При сильном желании можно откостылить, но почему нельзя иметь простой и очевидный вариант работы "мне пофиг с какого потолка взялся usb0, вкатить ему настройки, невзирая на мак" - я не понял.
Чтобы не поднимал dhcp, можно сказать
no-auto-default=*
(это делает серверный конфиг для NM в RHEL7)
Про привязку к интерфейсу - да, не хватает. Пилят.
http://fedoraproject.org/wiki/Features/NetworkManagerNameBas...
> Оно как бы да. Но не очень наглядно, несколько инопланетно и временами на всяких краевых случаях можно познакомиться со странными закидонами типа вышеупомянутых.
Лично меня в 99% случаев устраивает, как он понимает обычный текстовый конфиг из ifcfg-файла. В текущей версии это работает почти-почти идеально, мелкие проблемы вроде упомянутых выше или фичи итпа привязки к имени, думаю, скоро доделают.
