* [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
@ 2014-02-04 8:56 Alexander Vasiliev
2014-02-04 10:41 ` Андрій Добровольський
0 siblings, 1 reply; 17+ messages in thread
From: Alexander Vasiliev @ 2014-02-04 8:56 UTC (permalink / raw)
To: ALT Linux Community general discussions
Система - рабочая станция с systemd с обновлениями из репозитария Кентавра.
$ cat /etc/altlinux-release
ALT Linux 7.0.3 Centaurus (Pholus)
Включаем компьютер. После загрузки все работает.
Выполняем
$sudo systemctl restart network.service
Сеть работает, а DNS запросы не резолвятся.
$ dig www.yandex.ru
; <<>> DiG 9.9.3-P2 <<>> www.yandex.ru
;; global options: +cmd
;; connection timed out; no servers could be reached
Если указать сервер DNS руками, то все нормально.
$ dig @8.8.8.8 www.yandex.ru
; <<>> DiG 9.9.3-P2 <<>> @8.8.8.8 www.yandex.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9652
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.yandex.ru. IN A
;; ANSWER SECTION:
www.yandex.ru. 290 IN A 213.180.193.3
www.yandex.ru. 290 IN A 213.180.204.3
www.yandex.ru. 290 IN A 93.158.134.3
;; Query time: 18 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Feb 04 12:25:27 MSK 2014
;; MSG SIZE rcvd: 90
Список
$systemctl > /home/vav/before_network_restart.txt
совершенно идентичен списку
$systemctl > /home/vav/after_network_restart.txt
Подскажите, пожалуйста, что нужно перезапускать кроме nework.service,
чтобы DNS работал? Просто иногда нужно временно менять ip для настройки
различных сетевых устройств, а перезагружаться каждый раз не хочется.
--
Alexander Vasiliev
vav.email@gmail.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-04 8:56 [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы Alexander Vasiliev
@ 2014-02-04 10:41 ` Андрій Добровольський
2014-02-04 10:53 ` Alexander Vasiliev
0 siblings, 1 reply; 17+ messages in thread
From: Андрій Добровольський @ 2014-02-04 10:41 UTC (permalink / raw)
To: ALT Linux Community general discussions
2014-02-04 Alexander Vasiliev <vav.email@gmail.com>:
> Система - рабочая станция с systemd с обновлениями из репозитария Кентавра.
>
> $ cat /etc/altlinux-release
> ALT Linux 7.0.3 Centaurus (Pholus)
>
> Включаем компьютер. После загрузки все работает.
> Выполняем
> $sudo systemctl restart network.service
>
> Сеть работает, а DNS запросы не резолвятся.
>
А у Вас сеть через NM или Etcnet? Адрес DNSа раздается автоматом?
Или статика?
Что в resolve.conf до и после рестарта?
И смотреть надо вывод ip....
--
Regards,
Andrii Dobrovol`s`kyj
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-04 10:41 ` Андрій Добровольський
@ 2014-02-04 10:53 ` Alexander Vasiliev
2014-02-04 10:58 ` Андрій Добровольський
2014-02-04 12:23 ` Mikhail Efremov
0 siblings, 2 replies; 17+ messages in thread
From: Alexander Vasiliev @ 2014-02-04 10:53 UTC (permalink / raw)
To: ALT Linux Community general discussions
4 февраля 2014 г., 14:41 пользователь Андрій Добровольський
<adobrovolskii@gmail.com> написал:
> А у Вас сеть через NM или Etcnet? Адрес DNSа раздается автоматом?
Etcnet
> Или статика?
статика
# ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 14:da:e9:dd:92:2e brd ff:ff:ff:ff:ff:ff
inet6 fe80::16da:e9ff:fedd:922e/64 scope link
valid_lft forever preferred_lft forever
3: enp6s0.1024@enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UP
link/ether 14:da:e9:dd:92:2e brd ff:ff:ff:ff:ff:ff
inet 192.168.104.245/24 scope global enp6s0.1024
inet6 fe80::16da:e9ff:fedd:922e/64 scope link
valid_lft forever preferred_lft forever
4: enp6s0.2@enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP
link/ether 14:da:e9:dd:92:2e brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/24 scope global enp6s0.2
inet6 fe80::16da:e9ff:fedd:922e/64 scope link
valid_lft forever preferred_lft forever
[root@vav_work_comp ~]#
> Что в resolve.conf до и после рестарта?
До рестарта
# resolvconf -l
# resolv.conf from enp6s0.1024
nameserver 91.207.25.226
nameserver 91.207.24.10
# cat /etc/resolv.conf
# Generated by resolvconf
# Do not edit manually, use
# /etc/net/ifaces/<interface>/resolv.conf instead.
nameserver 91.207.25.226
nameserver 91.207.24.10
После рестарта
# resolvconf -l
# resolv.conf from lo
nameserver 127.0.0.1
# resolv.conf from enp6s0.1024
nameserver 91.207.25.226
nameserver 91.207.24.10
# cat /etc/resolv.conf
# Generated by resolvconf
# Do not edit manually, use
# /etc/net/ifaces/<interface>/resolv.conf instead.
nameserver 127.0.0.1
> И смотреть надо вывод ip....
Что именно показать в выводе ip ?
--
Alexander Vasiliev
vav.email@gmail.com
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-04 10:53 ` Alexander Vasiliev
@ 2014-02-04 10:58 ` Андрій Добровольський
2014-02-04 11:59 ` Alexander Vasiliev
2014-02-04 12:23 ` Mikhail Efremov
1 sibling, 1 reply; 17+ messages in thread
From: Андрій Добровольський @ 2014-02-04 10:58 UTC (permalink / raw)
To: ALT Linux Community general discussions
2014-02-04 Alexander Vasiliev <vav.email@gmail.com>:
>
>> Что в resolve.conf до и после рестарта?
> До рестарта
> # resolvconf -l
> # resolv.conf from enp6s0.1024
> nameserver 91.207.25.226
> nameserver 91.207.24.10
>
> # cat /etc/resolv.conf
> # Generated by resolvconf
> # Do not edit manually, use
> # /etc/net/ifaces/<interface>/resolv.conf instead.
> nameserver 91.207.25.226
> nameserver 91.207.24.10
>
> После рестарта
> # resolvconf -l
> # resolv.conf from lo
> nameserver 127.0.0.1
>
> # resolv.conf from enp6s0.1024
> nameserver 91.207.25.226
> nameserver 91.207.24.10
>
> # cat /etc/resolv.conf
> # Generated by resolvconf
> # Do not edit manually, use
> # /etc/net/ifaces/<interface>/resolv.conf instead.
> nameserver 127.0.0.1
>
>> И смотреть надо вывод ip....
>
> Что именно показать в выводе ip ?
>
Да пока можно и не показывать.
Просто разберитесь почему не обновляется
/etc/resolv.conf правильным образом.
--
Regards,
Andrii Dobrovol`s`kyj
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-04 10:58 ` Андрій Добровольський
@ 2014-02-04 11:59 ` Alexander Vasiliev
0 siblings, 0 replies; 17+ messages in thread
From: Alexander Vasiliev @ 2014-02-04 11:59 UTC (permalink / raw)
To: ALT Linux Community general discussions
[-- Attachment #1: Type: text/plain, Size: 524 bytes --]
4 февраля 2014 г., 14:58 пользователь Андрій Добровольський
<adobrovolskii@gmail.com> написал:
> Да пока можно и не показывать.
> Просто разберитесь почему не обновляется
> /etc/resolv.conf правильным образом.
Вопрос как разобраться?
Выхлоп journalctl при рестарте сети приложен в файле.
--
Alexander Vasiliev
vav.email@gmail.com
[-- Attachment #2: journalctl_output.txt --]
[-- Type: text/plain, Size: 10469 bytes --]
root@vav_work_comp sysconfig]# journalctl --since="2014-02-04 14:50:37"
-- Logs begin at Mon 2013-08-05 11:58:36 MSK, end at Tue 2014-02-04 15:46:52 MSK. --
Feb 04 14:50:37 vav_work_comp.localdomain systemd[1]: Stopping Network Connectivity...
Feb 04 14:50:37 vav_work_comp.localdomain network[4828]: Computing interface groups: .... 4 interfaces found
Feb 04 14:50:37 vav_work_comp.localdomain network[4828]: Stopping group 2/hostedphys (2 interfaces)
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Withdrawing address record for 192.168.104.245 on enp6s0.1024.
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Leaving mDNS multicast group on interface enp6s0.1024.IPv4 with address 192.168.104.245.
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Interface enp6s0.1024.IPv4 no longer relevant for mDNS.
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Withdrawing address record for fe80::16da:e9ff:fedd:922e on enp6s0.1024.
Feb 04 14:50:37 vav_work_comp.localdomain systemd[1]: Stopping Name Service Cache Daemon...
Feb 04 14:50:37 vav_work_comp.localdomain systemd[1]: Starting Name Service Cache Daemon...
Feb 04 14:50:37 vav_work_comp.localdomain systemd[1]: Started Name Service Cache Daemon.
Feb 04 14:50:37 vav_work_comp.localdomain systemd[1]: Reloading Avahi mDNS/DNS-SD Stack.
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Got SIGHUP, reloading.
Feb 04 14:50:37 vav_work_comp.localdomain systemd[1]: Reloaded Avahi mDNS/DNS-SD Stack.
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Withdrawing workstation service for enp6s0.1024.
Feb 04 14:50:37 vav_work_comp.localdomain network[4828]: Stopping enp6s0.1024: ....OK
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Withdrawing address record for 10.0.0.2 on enp6s0.2.
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Leaving mDNS multicast group on interface enp6s0.2.IPv4 with address 10.0.0.2.
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Interface enp6s0.2.IPv4 no longer relevant for mDNS.
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Withdrawing address record for fe80::16da:e9ff:fedd:922e on enp6s0.2.
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Withdrawing workstation service for enp6s0.2.
Feb 04 14:50:37 vav_work_comp.localdomain network[4828]: Stopping enp6s0.2: ...OK
Feb 04 14:50:37 vav_work_comp.localdomain network[4828]: Processing /etc/net/vlantab: empty.
Feb 04 14:50:37 vav_work_comp.localdomain network[4828]: Stopping group 1/realphys (1 interfaces)
Feb 04 14:50:37 vav_work_comp.localdomain avahi-daemon[869]: Withdrawing address record for fe80::16da:e9ff:fedd:922e on enp6s0.
Feb 04 14:50:37 vav_work_comp.localdomain network[4828]: Stopping enp6s0: ...OK
Feb 04 14:50:37 vav_work_comp.localdomain network[4828]: Stopping group 0/virtual (1 interfaces)
Feb 04 14:50:37 vav_work_comp.localdomain network[4828]: Stopping lo: ..OK
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Stopping iptables for default
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "OUTPUT" chain in the "filter" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "FORWARD" chain in the "filter" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "INPUT" chain in the "filter" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "POSTROUTING" chain in the "nat" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "OUTPUT" chain in the "nat" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "PREROUTING" chain in the "nat" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "POSTROUTING" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "OUTPUT" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "FORWARD" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "INPUT" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Flushing the "PREROUTING" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Unloading module ip_conntrack_ftp
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Setting ACCEPT policy for the "INPUT" chain in the "filter" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Setting ACCEPT policy for the "FORWARD" chain in the "filter" table
Feb 04 14:50:38 vav_work_comp.localdomain network[4828]: Setting ACCEPT policy for the "OUTPUT" chain in the "filter" table
Feb 04 14:50:38 vav_work_comp.localdomain systemd[1]: Starting Network Connectivity...
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Starting iptables for default
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Setting ACCEPT policy for the "INPUT" chain in the "filter" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Setting ACCEPT policy for the "FORWARD" chain in the "filter" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Setting ACCEPT policy for the "OUTPUT" chain in the "filter" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading module ip_conntrack_ftp
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "PREROUTING" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "INPUT" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "FORWARD" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "OUTPUT" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "POSTROUTING" chain in the "mangle" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "PREROUTING" chain in the "nat" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "OUTPUT" chain in the "nat" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "POSTROUTING" chain in the "nat" table
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "INPUT" chain in the "filter" table....
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "FORWARD" chain in the "filter" table....
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Loading rules for the "OUTPUT" chain in the "filter" table....
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Computing interface groups: .... 4 interfaces found
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Starting group 0/virtual (1 interfaces)
Feb 04 14:50:38 vav_work_comp.localdomain systemd[1]: Stopping Name Service Cache Daemon...
Feb 04 14:50:38 vav_work_comp.localdomain systemd[1]: Starting Name Service Cache Daemon...
Feb 04 14:50:38 vav_work_comp.localdomain systemd[1]: Started Name Service Cache Daemon.
Feb 04 14:50:38 vav_work_comp.localdomain systemd[1]: Reloading Avahi mDNS/DNS-SD Stack.
Feb 04 14:50:38 vav_work_comp.localdomain avahi-daemon[869]: Got SIGHUP, reloading.
Feb 04 14:50:38 vav_work_comp.localdomain systemd[1]: Reloaded Avahi mDNS/DNS-SD Stack.
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Starting lo: .....OK
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Starting group 1/realphys (1 interfaces)
Feb 04 14:50:38 vav_work_comp.localdomain kernel: r8169 0000:06:00.0 enp6s0: link down
Feb 04 14:50:38 vav_work_comp.localdomain kernel: IPv6: ADDRCONF(NETDEV_UP): enp6s0: link is not ready
Feb 04 14:50:38 vav_work_comp.localdomain kernel: r8169 0000:06:00.0 enp6s0: link down
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Starting enp6s0: ....OK
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Processing /etc/net/vlantab: empty.
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Starting group 2/hostedphys (2 interfaces)
Feb 04 14:50:38 vav_work_comp.localdomain systemd-sysctl[6196]: Duplicate assignment of kernel/sysrq in file '/lib/sysctl.d/50-default.conf', ignoring.
Feb 04 14:50:38 vav_work_comp.localdomain kernel: IPv6: ADDRCONF(NETDEV_UP): enp6s0.1024: link is not ready
Feb 04 14:50:38 vav_work_comp.localdomain avahi-daemon[869]: Joining mDNS multicast group on interface enp6s0.1024.IPv4 with address 192.168.104.245.
Feb 04 14:50:38 vav_work_comp.localdomain avahi-daemon[869]: New relevant interface enp6s0.1024.IPv4 for mDNS.
Feb 04 14:50:38 vav_work_comp.localdomain avahi-daemon[869]: Registering new address record for 192.168.104.245 on enp6s0.1024.IPv4.
Feb 04 14:50:38 vav_work_comp.localdomain network[5534]: Starting enp6s0.1024: ......OK
Feb 04 14:50:39 vav_work_comp.localdomain systemd-sysctl[6322]: Duplicate assignment of kernel/sysrq in file '/lib/sysctl.d/50-default.conf', ignoring.
Feb 04 14:50:39 vav_work_comp.localdomain kernel: IPv6: ADDRCONF(NETDEV_UP): enp6s0.2: link is not ready
Feb 04 14:50:39 vav_work_comp.localdomain avahi-daemon[869]: Joining mDNS multicast group on interface enp6s0.2.IPv4 with address 10.0.0.2.
Feb 04 14:50:39 vav_work_comp.localdomain avahi-daemon[869]: New relevant interface enp6s0.2.IPv4 for mDNS.
Feb 04 14:50:39 vav_work_comp.localdomain avahi-daemon[869]: Registering new address record for 10.0.0.2 on enp6s0.2.IPv4.
Feb 04 14:50:39 vav_work_comp.localdomain network[5534]: Starting enp6s0.2: ....OK
Feb 04 14:50:39 vav_work_comp.localdomain systemd[1]: Started Network Connectivity.
Feb 04 14:50:40 vav_work_comp.localdomain kernel: r8169 0000:06:00.0 enp6s0: link up
Feb 04 14:50:40 vav_work_comp.localdomain kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp6s0: link becomes ready
Feb 04 14:50:40 vav_work_comp.localdomain kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp6s0.2: link becomes ready
Feb 04 14:50:40 vav_work_comp.localdomain kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp6s0.1024: link becomes ready
Feb 04 14:50:41 vav_work_comp.localdomain avahi-daemon[869]: Registering new address record for fe80::16da:e9ff:fedd:922e on enp6s0.*.
Feb 04 14:50:41 vav_work_comp.localdomain avahi-daemon[869]: Registering new address record for fe80::16da:e9ff:fedd:922e on enp6s0.2.*.
Feb 04 14:50:41 vav_work_comp.localdomain avahi-daemon[869]: Registering new address record for fe80::16da:e9ff:fedd:922e on enp6s0.1024.*.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-04 10:53 ` Alexander Vasiliev
2014-02-04 10:58 ` Андрій Добровольський
@ 2014-02-04 12:23 ` Mikhail Efremov
2014-02-04 12:57 ` Alexander Vasiliev
2014-02-05 2:40 ` REAL
1 sibling, 2 replies; 17+ messages in thread
From: Mikhail Efremov @ 2014-02-04 12:23 UTC (permalink / raw)
To: community
On Tue, 4 Feb 2014 14:53:10 +0400 Alexander Vasiliev wrote:
> > Что в resolve.conf до и после рестарта?
> До рестарта
> # cat /etc/resolv.conf
> # Generated by resolvconf
> # Do not edit manually, use
> # /etc/net/ifaces/<interface>/resolv.conf instead.
> nameserver 91.207.25.226
> nameserver 91.207.24.10
>
> После рестарта
> # resolvconf -l
> # resolv.conf from lo
> nameserver 127.0.0.1
>
> # resolv.conf from enp6s0.1024
> nameserver 91.207.25.226
> nameserver 91.207.24.10
>
> # cat /etc/resolv.conf
> # Generated by resolvconf
> # Do not edit manually, use
> # /etc/net/ifaces/<interface>/resolv.conf instead.
> nameserver 127.0.0.1
У вас почему-то при загрузке не
обработался /etc/net/ifaces/lo/resolv.conf.
Похоже на #28983, но он уже давно должен быть закрыт.
А рестарт network как раз отработал правильно.
Посмотрите что у вас с bind.service.
И вообще определитесь, нужен ли вам локальный DNS-сервер, если нет, то
просто rm /etc/net/ifaces/lo/resolv.conf
--
WBR, Mikhail Efremov
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-04 12:23 ` Mikhail Efremov
@ 2014-02-04 12:57 ` Alexander Vasiliev
2014-02-05 2:40 ` REAL
1 sibling, 0 replies; 17+ messages in thread
From: Alexander Vasiliev @ 2014-02-04 12:57 UTC (permalink / raw)
To: ALT Linux Community general discussions
4 февраля 2014 г., 16:23 пользователь Mikhail Efremov <sem@altlinux.ru> написал:
>
> У вас почему-то при загрузке не
> обработался /etc/net/ifaces/lo/resolv.conf.
> Похоже на #28983, но он уже давно должен быть закрыт.
> А рестарт network как раз отработал правильно.
> Посмотрите что у вас с bind.service.
bind.service и до и после рестарта
# systemctl status bind.service
bind.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/lib/systemd/system/bind.service; disabled)
Active: inactive (dead)
> И вообще определитесь, нужен ли вам локальный DNS-сервер, если нет, то
> просто rm /etc/net/ifaces/lo/resolv.conf
Отодвинул /etc/net/ifaces/lo/resolv.conf и после рестарта сети все заработало.
Теперь
# cat /etc/resolv.conf
# Generated by resolvconf
# Do not edit manually, use
# /etc/net/ifaces/<interface>/resolv.conf instead.
nameserver 91.207.25.226
nameserver 91.207.24.10
Большое спасибо!
--
Alexander Vasiliev
vav.email@gmail.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-04 12:23 ` Mikhail Efremov
2014-02-04 12:57 ` Alexander Vasiliev
@ 2014-02-05 2:40 ` REAL
2014-02-05 9:09 ` Mikhail Efremov
1 sibling, 1 reply; 17+ messages in thread
From: REAL @ 2014-02-05 2:40 UTC (permalink / raw)
To: ALT Linux Community general discussions
04.02.2014 19:23, Mikhail Efremov пишет:
> У вас почему-то при загрузке не
> обработался /etc/net/ifaces/lo/resolv.conf.
А он вообще обрабатывается? У меня - нет (но у меня сизиф).
--
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-05 2:40 ` REAL
@ 2014-02-05 9:09 ` Mikhail Efremov
2014-02-05 9:13 ` REAL
0 siblings, 1 reply; 17+ messages in thread
From: Mikhail Efremov @ 2014-02-05 9:09 UTC (permalink / raw)
To: ALT Linux Community general discussions
On Wed, 05 Feb 2014 09:40:26 +0700 REAL wrote:
> 04.02.2014 19:23, Mikhail Efremov пишет:
> > У вас почему-то при загрузке не
> > обработался /etc/net/ifaces/lo/resolv.conf.
>
> А он вообще обрабатывается? У меня - нет (но у меня сизиф).
Как выяснилось в случае systemd настройки из /etc/net/ifaces/lo не
используются вообще: systemd сам поднимает и настраивает lo, но к такому
счастью наш etcnet не готов. Ручки для изменения такого поведения авторы
systemd не предусмотрели. С этим надо что-то делать, но это уже тема
для devel@.
--
WBR, Mikhail Efremov
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-05 9:09 ` Mikhail Efremov
@ 2014-02-05 9:13 ` REAL
2014-02-05 9:22 ` Mikhail Efremov
0 siblings, 1 reply; 17+ messages in thread
From: REAL @ 2014-02-05 9:13 UTC (permalink / raw)
To: ALT Linux Community general discussions
05.02.2014 16:09, Mikhail Efremov пишет:
>>> У вас почему-то при загрузке не
>>> обработался /etc/net/ifaces/lo/resolv.conf.
>>
>> А он вообще обрабатывается? У меня - нет (но у меня сизиф).
>
> Как выяснилось в случае systemd настройки из /etc/net/ifaces/lo не
> используются вообще
/etc/net/ifaces/lo/resolv.conf не обрабатывается и в случае sysV.
--
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-05 9:13 ` REAL
@ 2014-02-05 9:22 ` Mikhail Efremov
2014-02-06 2:05 ` REAL
0 siblings, 1 reply; 17+ messages in thread
From: Mikhail Efremov @ 2014-02-05 9:22 UTC (permalink / raw)
To: ALT Linux Community general discussions
On Wed, 05 Feb 2014 16:13:31 +0700 REAL wrote:
> 05.02.2014 16:09, Mikhail Efremov пишет:
> >>> У вас почему-то при загрузке не
> >>> обработался /etc/net/ifaces/lo/resolv.conf.
> >>
> >> А он вообще обрабатывается? У меня - нет (но у меня сизиф).
> >
> > Как выяснилось в случае systemd настройки из /etc/net/ifaces/lo не
> > используются вообще
>
> /etc/net/ifaces/lo/resolv.conf не обрабатывается и в случае sysV.
Должен обрабатываться. Что в /var/log/messages сервис network говорит
про lo при загрузке?
А также resolvconf -l.
--
WBR, Mikhail Efremov
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-05 9:22 ` Mikhail Efremov
@ 2014-02-06 2:05 ` REAL
2014-02-06 10:10 ` Mikhail Efremov
0 siblings, 1 reply; 17+ messages in thread
From: REAL @ 2014-02-06 2:05 UTC (permalink / raw)
To: ALT Linux Community general discussions
05.02.2014 16:22, Mikhail Efremov пишет:
>> /etc/net/ifaces/lo/resolv.conf не обрабатывается и в случае sysV.
>
> Должен обрабатываться. Что в /var/log/messages сервис network говорит
> про lo при загрузке?
Ничего криминального.
> А также resolvconf -l.
Этот показывает всё из /et/net/ifaces/*/resolv.conf. Только в
/etc/resolv.conf всё равно один 127.0.0.1.
--
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-06 2:05 ` REAL
@ 2014-02-06 10:10 ` Mikhail Efremov
2014-02-06 10:13 ` REAL
0 siblings, 1 reply; 17+ messages in thread
From: Mikhail Efremov @ 2014-02-06 10:10 UTC (permalink / raw)
To: ALT Linux Community general discussions
On Thu, 06 Feb 2014 09:05:31 +0700 REAL wrote:
> 05.02.2014 16:22, Mikhail Efremov пишет:
> >> /etc/net/ifaces/lo/resolv.conf не обрабатывается и в случае sysV.
> >
> > А также resolvconf -l.
>
> Этот показывает всё из /et/net/ifaces/*/resolv.conf. Только в
> /etc/resolv.conf всё равно один 127.0.0.1.
Сформулируйте внятно в чем у вас проблема. Потому что то, что написано
в этом письме полностью противоречит тому, что вы писали в предыдущих
письмах. Или у вас в /etc/net/ifaces/lo/resolv.conf не 127.0.0.1?
--
WBR, Mikhail Efremov
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-06 10:10 ` Mikhail Efremov
@ 2014-02-06 10:13 ` REAL
2014-02-06 14:23 ` Mikhail Efremov
0 siblings, 1 reply; 17+ messages in thread
From: REAL @ 2014-02-06 10:13 UTC (permalink / raw)
To: ALT Linux Community general discussions
06.02.2014 17:10, Mikhail Efremov пишет:
>> Этот показывает всё из /et/net/ifaces/*/resolv.conf. Только в
>> /etc/resolv.conf всё равно один 127.0.0.1.
>
> Сформулируйте внятно в чем у вас проблема. Потому что то, что написано
> в этом письме полностью противоречит тому, что вы писали в предыдущих
> письмах.
В чём противоречие?
> Или у вас в /etc/net/ifaces/lo/resolv.conf не 127.0.0.1?
Нет, там реальный DNS прописан. Его resolvconf -l показывает. А вот в
/etc/resolv.conf его нет.
--
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-06 10:13 ` REAL
@ 2014-02-06 14:23 ` Mikhail Efremov
2014-02-07 2:48 ` REAL
0 siblings, 1 reply; 17+ messages in thread
From: Mikhail Efremov @ 2014-02-06 14:23 UTC (permalink / raw)
To: community
On Thu, 06 Feb 2014 17:13:18 +0700 REAL wrote:
> 06.02.2014 17:10, Mikhail Efremov пишет:
> >> Этот показывает всё из /et/net/ifaces/*/resolv.conf. Только в
> >> /etc/resolv.conf всё равно один 127.0.0.1.
> >
> > Сформулируйте внятно в чем у вас проблема. Потому что то, что написано
> > в этом письме полностью противоречит тому, что вы писали в предыдущих
> > письмах.
>
> В чём противоречие?
То, что у вас такая странная конфигурация как-то не очевидно. Это
нужно было рассказать сразу.
> > Или у вас в /etc/net/ifaces/lo/resolv.conf не 127.0.0.1?
>
> Нет, там реальный DNS прописан.
Прописывать что-то кроме 127.0.0.1 в resolv.conf для lo довольно
странная идея. Зачем он там, а не в resolv.conf для того интерфейса,
через который реально можно ходить к этому DNS?
> Его resolvconf -l показывает. А вот в
> /etc/resolv.conf его нет.
Это нормально. С некоторых пор при наличии 127.0.0.1 в /etc/resolv.conf
больше ничего не добавляется. Что правильно, зачем там другие сервера
если есть локальный. Но при желании можно включить старое поведение,
см. опцию resolv_conf_local_only в resolvconf.conf(5).
Кстати, откуда тогда приезжает 127.0.0.1, если не
из /etc/net/ifaces/lo/resolv.conf? Вообще стоило все-таки показать вывод
resolvconf -l, сразу бы все стало понятно.
--
WBR, Mikhail Efremov
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-06 14:23 ` Mikhail Efremov
@ 2014-02-07 2:48 ` REAL
2014-02-07 16:25 ` Mikhail Efremov
0 siblings, 1 reply; 17+ messages in thread
From: REAL @ 2014-02-07 2:48 UTC (permalink / raw)
To: ALT Linux Community general discussions
06.02.2014 21:23, Mikhail Efremov пишет:
> Прописывать что-то кроме 127.0.0.1 в resolv.conf для lo довольно
> странная идея. Зачем он там, а не в resolv.conf для того интерфейса,
> через который реально можно ходить к этому DNS?
Я пробовал всюду DNS'ы пихать. не помогает. Был уже разговор об этом,
правда, не помню, в этой ли рассылке. Помогает прямое прописывание в
/etc/resolv.conf и chattr +i /etc/resolv.conf.
>> Его resolvconf -l показывает. А вот в
>> /etc/resolv.conf его нет.
>
> Это нормально. С некоторых пор при наличии 127.0.0.1 в /etc/resolv.conf
> больше ничего не добавляется. Что правильно, зачем там другие сервера
> если есть локальный. Но при желании можно включить старое поведение,
> см. опцию resolv_conf_local_only в resolvconf.conf(5).
Спасибо, гляну.
> Кстати, откуда тогда приезжает 127.0.0.1, если не
> из /etc/net/ifaces/lo/resolv.conf?
Из resolv.conf для eth интерфейса (как-то он сейчас коряво называется,
enpчтототам).
--
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы
2014-02-07 2:48 ` REAL
@ 2014-02-07 16:25 ` Mikhail Efremov
0 siblings, 0 replies; 17+ messages in thread
From: Mikhail Efremov @ 2014-02-07 16:25 UTC (permalink / raw)
To: community
On Fri, 07 Feb 2014 09:48:51 +0700 REAL wrote:
> 06.02.2014 21:23, Mikhail Efremov пишет:
> > Прописывать что-то кроме 127.0.0.1 в resolv.conf для lo довольно
> > странная идея. Зачем он там, а не в resolv.conf для того интерфейса,
> > через который реально можно ходить к этому DNS?
>
> Я пробовал всюду DNS'ы пихать. не помогает. Был уже разговор об этом,
> правда, не помню, в этой ли рассылке. Помогает прямое прописывание в
> /etc/resolv.conf и chattr +i /etc/resolv.conf.
Не надо всюду пихать, надо правильно настроить. В самом крайнем случае
можно ns прибить гвоздями прямо в /etc/resolvconf.conf, см. опции
name_servers и name_servers_append. Но лучше сдать так, чтобы ns
добавлялся только тогда, когда его действительно нужно/можно
использовать.
> > Кстати, откуда тогда приезжает 127.0.0.1, если не
> > из /etc/net/ifaces/lo/resolv.conf?
>
> Из resolv.conf для eth интерфейса (как-то он сейчас коряво называется,
> enpчтототам).
Т.е. ns 127.0.0.1 из конфига конкретного интерфейса, а сторонний ns -
из конфига для lo? Что-то тут не так :).
--
WBR, Mikhail Efremov
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-02-07 16:25 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-04 8:56 [Comm] Кентавр 7.0.3 после systemctl restart network.service не резолвятся DNS запросы Alexander Vasiliev
2014-02-04 10:41 ` Андрій Добровольський
2014-02-04 10:53 ` Alexander Vasiliev
2014-02-04 10:58 ` Андрій Добровольський
2014-02-04 11:59 ` Alexander Vasiliev
2014-02-04 12:23 ` Mikhail Efremov
2014-02-04 12:57 ` Alexander Vasiliev
2014-02-05 2:40 ` REAL
2014-02-05 9:09 ` Mikhail Efremov
2014-02-05 9:13 ` REAL
2014-02-05 9:22 ` Mikhail Efremov
2014-02-06 2:05 ` REAL
2014-02-06 10:10 ` Mikhail Efremov
2014-02-06 10:13 ` REAL
2014-02-06 14:23 ` Mikhail Efremov
2014-02-07 2:48 ` REAL
2014-02-07 16:25 ` Mikhail Efremov
ALT Linux Community general discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 community community/ http://lore.altlinux.org/community \
mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com
public-inbox-index community
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.community
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git