Начиная примерно с Ubuntu 18.04 разработчики Ubuntu перестали использовать классический /etc/init.d/networking и /etc/network/interfaces способ настройки сети и переключился на какой-то вещь называемый netplan. Это очень разозлило многих людей и было расценено многими как плохой ход. Можно ли удалить netplan и используйте правильный /etc/network/interfaces способ настройки сети?
Следующая процедура работает для Ubuntu 18.04 (Бионический Бобр)
Я. Переустановите ifupdown пакет:
# apt-get update# apt-get install ifupdownii. Настройте свой /etc/сеть/интерфейсы файл с конфигурационными строфами, такими как:
source /etc/network/interfaces.d/*# The loopback network interfaceauto loiface lo inet loopbackallow-hotplug enp0s3auto enp0s3iface enp0s3 inet static address 192.168.1.133 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 # Only relevant if you make use of RESOLVCONF(8) # or similar... dns-nameservers 1.1.1.1 1.0.0.1iii. Сделайте конфигурацию эффективной (перезагрузка не требуется):
# ifdown --force enp0s3 lo && ifup -a# systemctl unmask networking# systemctl enable networking# systemctl restart networkingiv. Отключите и удалите нежелательные службы:
# systemctl stop systemd-networkd.socket systemd-networkd \networkd-dispatcher systemd-networkd-wait-online# systemctl disable systemd-networkd.socket systemd-networkd \networkd-dispatcher systemd-networkd-wait-online# systemctl mask systemd-networkd.socket systemd-networkd \networkd-dispatcher systemd-networkd-wait-online# apt-get --assume-yes purge nplan netplan.ioТогда все готово.
Примечание: Вы должен Конечно, адаптируйте значения в соответствии с вашей системой (сеть, имя интерфейса ...).
V. Распознаватель DNS
Поскольку Ubuntu Bionic Beaver (18.04) использует распознаватель заглушек DNS, предоставляемый SYSTEMD-RESOLVED.SERVICE(8), вы должен также добавьте DNS для контакта в файл /etc/systemd/resolved.conf. Например:
....DNS=1.1.1.1 1.0.0.1....а затем перезапустите службу systemd-resolved после завершения:
# systemctl restart systemd-resolvedЗаписи DNS в файле ifupdown INTERFACES(5), как показано выше, актуальны только в том случае, если вы используете RESOLVCONF(8) или аналогичный.
Команда Netplan опубликовала официальный ответ на свой часто задаваемый вопрос здесь:
Как вернуться к ifupdown
...
В работающей системе netplan можно удалить, установив ifupdown и настроив /etc/network/interfaces вручную, как это делали пользователи ранее.
Во время установки пользователь может выбрать использование ifupdown, предварительно указав netcfg/do_not_use_netplan=true. Это делается путем добавления предварительной строки в командную строку при загрузке установочного носителя (т.е. в меню загрузки установочного носителя нажмите клавишу F6, введите "e" и добавьте в командную строку).
Смотрите Ответ Nuxwin для получения более полных инструкций.
То ответ Нуксвина это здорово и почти завершено, я бы просто добавил строки:
rm /etc/resolv.confln -s /run/systemd/resolve/resolv.conf /etc/resolv.confЭто гарантирует, что распознаватель может быть обновлен DHCP-клиентом, как это было раньше при использовании интерфейсов.
(Я бы добавил это в качестве комментария, но почему-то для публикации комментария нужно 50 репутации)
Почему бы просто не настроить с помощью netplan?
Что ж, поскольку он настроен в 18.04-Desktop, он представляет собой единую строку, передающую управление всеми интерфейсами NetworkManager.
Хотя это, вероятно, подходит для 95% пользователей, помните, что NetworkManager запускается только после того, как вы вошли в сеанс.
Если вы хотите, чтобы ваш компьютер действовал как сервер / рабочий стол, например, начал обслуживать файлы на локальных компьютерах, действуя как сервер VNP и т. Д. ... Или что-нибудь "необычное", Прежде чем кто-либо войдет в систему, просто из-за того, что он включен, у вас возникнут проблемы с тем, как он настроен в стандарт 18.04-Рабочий стол.
Конечно, альтернативой было бы использовать конфигурацию server-Netplan, которая, насколько я прочитал (не проверял сам), вместо этого передает управление systemd-networkd.В этом случае вам лучше узнать, как systemd выполняет работу в качестве замены старой инициализации System V.
Если вы пойдете по этому пути, вам все равно придется внести изменения в netplan yaml, поскольку в настольной версии управление передается NetworkManager.
Почему бы просто не удалить netplan:
$ sudo apt remove netplan$ rm -rf /etc/netplanРаз и навсегда!
Ключ в том, чтобы знать, что cloud.init это настоящая управляющая программа.
При этом строка в netplan конфигурационный файл "необязательно: true" является обязательным.
Знание этого облегчало задачу.
Я только что удалил 01-network-manager-all.yaml и скопировал его в /root/save/.Затем вместо него установите заведомо хорошую конфигурацию, 50-cloud-init.yaml: его содержание следует:
network: version: 2 renderer: networkd ethernets: eports: match: name: enp* optional: true bonds: bond0: interfaces: [eports] addresses: [192.168.2.5/24] gateway4: 192.168.2.1 nameservers: addresses: [127.0.0.1, 8.8.4.4] parameters: mode: 0 mii-monitor-interval: 100Затем перезагрузитесь, и все должно работать нормально.
Известная хорошая конфигурация исходила от Настройте ad-сеть 802.3ad с помощью netplan в Ubuntu 18.04.
Согласно этому ответу, решение состоит в том, чтобы удалить все рабочие файлы .yaml: Ubuntu 17.10 отключить netplan
Я бы ничего не стал удалять без резервного копирования. Мы можем сделать это легко, просто отодвинув файлы в сторону. Во-первых, найдите файлы:
sudo updatedblocate netplan | grep yamlВ моей системе 18.04, похоже, единственным рабочим файлом является /etc/netplan/01-network-manager-all.yaml. Давайте сдвинем его с места:
mkdir ~/netplansudo mv /etc/netplan/01-network-manager-all.yaml /home/user/netplan...где user - это ваше имя пользователя.
Теперь проверьте, чтобы убедиться, что файл действительно исчез:
ls /etc/netplanТеперь внесите свои дополнения в /etc/network/interfaces по мере необходимости.
Перезагрузить.
Есть какие-нибудь улучшения?
Примечание: Точный процесс для этого найти трудно. Возможно, нам придется немного доработать по ходу дела.
@chili 555 Возможно, мне просто нужно принять перемены и научиться чему-то новому. Я просто хотел бы знать, тривиально ли вернуться к тому, как это должно быть. Так же, как и “systemd”, я понимаю, что разрушительные изменения иногда могут быть полезными и их следует принять. Однако это, конечно, не один из тех случаев, когда изменения были необходимы или полезны.
Почему бы просто не настроить с помощью netplan? В большинстве ситуаций это довольно просто.
Или просто правильно настройте netplan и готово.
@chili555 Netplan не поддерживает виртуальные сетевые интерфейсы. Смотрите здесь: networking - Virtual interface in netplan - Ask Ubuntu
Это не тривиально и нелегко обратимо в случае ошибки. Если вы хотите жить в опасности, я буду рад предложить ответ. С другой стороны, мы можем настроить netplan за пару минут. Что вы предпочитаете? PS - Я не претендую на полное понимание того, как netplan, за исключением “/etc/network/interfaces”, вписывается в общую картину systemd. Все, что я могу сделать, это верить, что те, кто ввел это изменение, действительно знают, почему оно лучше подходит.
@IRGeekSauce Это полезно? cat /usr/share/doc/netplan/examples/static_multiaddress.yaml
@chili555 Этот вопрос более или менее академический, и, конечно, я бы не рекомендовал кому-либо заниматься производством. Но это может послужить стимулом для обиженных пользователей, таких как я, неохотно признать, что “netplan” - это правильный способ настройки сети в Ubuntu сейчас, поэтому, во что бы то ни стало, предлагайте все, что приходит на ум, если вам захочется изучить этот вопрос.
Некоторые обходные пути, о которых я подумал, следующие: 1) поместите скрипт в /etc/init.d/networking, который просто вызывает netplan apply. 2) Напишите скрипт, который преобразует содержимое файла /etc/network/interfaces в синтаксис netplan в стиле YAML и добавляет его в конфигурацию netplan.
Я думаю, что netplan был разработан в основном для упрощения настройки и инициализации облачных экземпляров, потому что формат “/ etc / network / interfaces” не стандартизирован, что затрудняет его редактирование / изменение с помощью скрипта. Так что это и аналогичные цели (например, инструменты централизованной настройки) были бы преимуществом.
Кстати: отсутствие стандартизации / etc / network / interfaces также является причиной того, что сценарий преобразования никогда не будет работать для всех (хотя он, вероятно, мог бы обрабатывать наиболее распространенные случаи).