На этот вопрос уже есть ответ здесь:
После редактирования dns-nameservers
в / etc / network / interfaces
, как мне указать resolvconf (8)
читать новое значение без перезапуска сети? (вызывает прерывание обслуживания)
Параметр -u
, похоже, не работает, он просто обновляется до тех же значений.
Недавно я столкнулся с этим дважды.
В первый раз я сделал sudo ifdown eth0
, что, конечно, разорвало мое ssh-соединение и оставил машину, игнорируя ее NIC. Уч. Мне пришлось пройти через интерфейс IPMI на сервере, чтобы снова получить контроль.
Во второй раз я учился на своих предыдущих ошибках и сделал sudo ifdown eth0 ; sudo ifup eth0
. Конечно, окно ssh умерло, но машина быстро отреагировала на новое соединение ssh, и мои изменения DNS вступили в силу. Я сделал то же самое на втором сервере, но на этот раз я ждал, прежде чем что-то набирать в окне ssh. Окно осталось, и изменения DNS были применены. Высокий.
Критическим моментом было использование оператора с запятой оболочки, чтобы обе команды были в одной строке. Таким образом, команда восстановления интерфейса уже была введена к моменту выхода из строя интерфейса. Я полагаю, что мог бы написать сценарий и выполнить его, но это казалось проще.
ОБНОВЛЕНИЕ: Есть еще один способ сделать это. Вы также можете перезапустить сетевую службу Ubuntu за один шаг: sudo /etc/init.d/networking restart
или sudo service network-interface restart INTERFACE=eth0
. Спасибо JFA за вдохновение.
Вы правы: «resolvconf -u» недостаточно для активации внесенного вами изменения. Эта команда обновляет resolv.conf только из базы данных resolvconf, тогда как вам нужно обновить базу данных.
Предположим, что рассматриваемый интерфейс - eth0. Предположим, что в / etc / network / interfaces есть раздел, который выглядит следующим образом.
iface eth0 inet static
[...]
dns-nameservers 1.1.1.1 2.2.2.2
Теперь вы измените строку «dns-nameservers». Чтобы активировать это изменение, сделайте (обратите внимание на & amp; & amp; избежать разрыва потенциально открытого ssh-соединения)
ifdown eth0 && ifup eth0
или перезагрузите компьютер.
Просто прошел через эту же проблему; даже перезагрузка потеряет изменения при ручном вызове ловушки libc.
Итак, самый стабильный способ, который я нашел, - после помещения нужного контента в /etc/network/interfaces
, отредактировать /etc/resolvconf/resolv.conf.d/original
, чтобы включить нужные строки, убедиться, что tail
(в этом каталоге) нет, [ 113], а затем вызвать /etc/resolvconf/update.d/libc
.
Обратите внимание, что если присутствует tail
(по умолчанию указано original
, то за содержимым, полученным из /etc/network/interfaces
, последует также исходная настройка.
) что эти изменения наиболее безопасно можно Честно говоря, применение перезагрузки является безумным. Нынешняя система берет то, что раньше было «редактировать этот файл, возможно, развертывание из системы управления конфигурацией», и скрывает его за несколькими уровнями абстракции и не имеет чистого способа вызвать для обслуживания за пределами обычного каркас загрузки.