[root@hosting ~]# nslookup google.fr
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can’t find google.fr.ovh.net: REFUSED
Can you check if the specified DNS servers are in dnsmasq.conf?
grep server= /etc/dnsmasq.conf[root@hosting ~]# grep server= /etc/dnsmasq.conf
server=127.0.0.1
# server=/ovh.net/Just as a test, you may edit /etc/dnsmasq.conf file, replacing the dns ip in server=127.0.0.1 with your dns, and restaring dnsmasq service.
example:
sed -ibak s/server=127.0.0.1/server=8.8.8.8/ /etc/dnsmasq.conf
systemctl restart dnsmasq
1 Like
The problem is with VPS, the server wasnt abble to connect with DNS
- We changed dns from 127.0.0.1 to 8.8.8.8
- and after we updated dnsmasq with the new address
Now the warning has disappeared and php requests works
Sorry to be more pessimistic but your issue is not solved, we must understand what it occurs.
You have simply changed a value in a configuration file, if you do a ‘signal-event nethserver-dnsmasq-update’ the older value will probably back again.
I guess that you have manually added some custom values (I mean this when I read ‘# server=/ovh.net/’) but I’m not sure.
Normally we write the IPs of /etc/resolv.conf in /etc/e-smith/templates/etc/dnsmasq.conf/25NameServers
@giacomo @davidep what do you think please
in order to see if all is good now
config show dns
config show dnsmasq
signal-event nethserver-dnsmasq-update
post back the output of this and go to the /var/log/messages (less /var/log/messages) and write down here the relevant end of log for nethserver-dnsmasq-update
at the end you can go to /etc/dnsmasq.conf (less /etc/dnsmasq.conf) to see if the server=8.8.8.8 is there
2 Likes
Yes, probably OVH does something wired with DNS configuration.
If you set the DNS from the web interface, it should be good.
[root@hosting ~]# config show dns
dns=configuration
NameServers=8.8.8.8
----------
[root@hosting ~]# config show dnsmasq
dnsmasq=service
CacheSize=4000
TCPPort=53
UDPPorts=53,67,69
access=green
dhcp-boot=
except-interface=virbr0
status=enabled
tftp-status=enabled
----------
Dnsmasq.conf :
# Specify IP address of upstream servers directly. Setting this flag
# does not suppress reading of /etc/resolv.conf, use "no-resolv" to do
# that.
server=8.8.8.8well, I suppose you did signal-event nethserver-dnsmasq-update, the log you posted is not relevant of the event you launched, you need to go to the end of the log file 
I suppose that you can use the dns resolving name
less /var/log/messages
Dec 27 23:10:02 hosting esmith::event[20541]: Event: nethserver-dnsmasq-update
Dec 27 23:10:02 hosting esmith::event[20541]: Migrating existing database configuration
Dec 27 23:10:02 hosting dbus[537]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service'
Dec 27 23:10:02 hosting dbus-daemon: dbus[537]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service'
Dec 27 23:10:02 hosting systemd: Starting Time & Date Service...
Dec 27 23:10:02 hosting dbus[537]: [system] Successfully activated service 'org.freedesktop.timedate1'
Dec 27 23:10:02 hosting dbus-daemon: dbus[537]: [system] Successfully activated service 'org.freedesktop.timedate1'
Dec 27 23:10:02 hosting systemd: Started Time & Date Service.
Dec 27 23:10:02 hosting esmith::event[20541]: Migrating existing database certificates
Dec 27 23:10:02 hosting esmith::event[20541]: Migrating existing database networks
Dec 27 23:10:02 hosting esmith::event[20541]: Migrating existing database accounts
Dec 27 23:10:02 hosting esmith::event[20541]: Migrating existing database routes
Dec 27 23:10:02 hosting esmith::event[20541]: Migrating existing database hosts
Dec 27 23:10:03 hosting esmith::event[20541]: Migrating existing database fwrules
Dec 27 23:10:03 hosting esmith::event[20541]: Migrating existing database fwservices
Dec 27 23:10:03 hosting esmith::event[20541]: Migrating existing database portforward
Dec 27 23:10:03 hosting esmith::event[20541]: Migrating existing database tc
Dec 27 23:10:03 hosting esmith::event[20541]: Migrating existing database dhcp
Dec 27 23:10:03 hosting esmith::event[20541]: Migrating existing database vhosts
Dec 27 23:10:03 hosting esmith::event[20541]: Migrating existing database contentfilter
Dec 27 23:10:03 hosting esmith::event[20541]: Migrating existing database proxypass
Dec 27 23:10:03 hosting esmith::event[20541]: Migrating existing database vpn
Dec 27 23:10:03 hosting esmith::event[20541]: Action: /etc/e-smith/events/nethserver-dnsmasq-update/S00initialize-default-databases SUCCESS [0.344155]
Dec 27 23:10:03 hosting esmith::event[20541]: expanding /etc/dnsmasq-dhcp-hosts
Dec 27 23:10:03 hosting esmith::event[20541]: expanding /etc/dnsmasq.conf
Dec 27 23:10:03 hosting esmith::event[20541]: ERROR in /etc/e-smith/templates//etc/dnsmasq.conf/80tftp: Program fragment delivered error <<Can't call method "prop" on an undefined value at /etc/e-smith/templates//etc/dnsmasq.conf/80tftp line 11.>> at template line 4
Dec 27 23:10:03 hosting esmith::event[20541]: ERROR: Template processing failed for //etc/dnsmasq.conf: 1 fragment generated errors
Dec 27 23:10:03 hosting esmith::event[20541]: at /etc/e-smith/events/actions/generic_template_expand line 64.
Dec 27 23:10:03 hosting esmith::event[20541]: [WARNING] expansion of /etc/dnsmasq.conf failed
Dec 27 23:10:03 hosting esmith::event[20541]: expanding /etc/resolv.conf
Dec 27 23:10:03 hosting esmith::event[20541]: Action: /etc/e-smith/events/actions/generic_template_expand FAILED: 1 [0.229901]
Dec 27 23:10:03 hosting systemd: Reloading.
Dec 27 23:10:03 hosting esmith::event[20541]: [INFO] service dnsmasq restart
Dec 27 23:10:03 hosting dnsmasq[20525]: exiting on receipt of SIGTERM
Dec 27 23:10:03 hosting systemd: Stopping DNS caching server....
Dec 27 23:10:03 hosting systemd: Started DNS caching server..
Dec 27 23:10:03 hosting systemd: Starting DNS caching server....
Dec 27 23:10:03 hosting dnsmasq[20569]: started, version 2.66 cachesize 4000
Dec 27 23:10:03 hosting dnsmasq[20569]: compile time options: IPv6 GNU-getopt DBus no-i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth
Dec 27 23:10:03 hosting dnsmasq-tftp[20569]: TFTP root is /var/lib/tftpboot
Dec 27 23:10:03 hosting dnsmasq[20569]: using nameserver 8.8.8.8#53
Dec 27 23:10:03 hosting dnsmasq[20569]: read /etc/hosts - 1 addresses
Dec 27 23:10:03 hosting esmith::event[20541]: [INFO] dnsmasq restart
Dec 27 23:10:03 hosting esmith::event[20541]: Action: /etc/e-smith/events/actions/adjust-services SUCCESS [0.245993]
Dec 27 23:10:03 hosting esmith::event[20541]: Event: nethserver-dnsmasq-update FAILED
1 Like
you have a failed template expansion, therefore it is a bug @giacomo @davidep
what is the output of
db networks show
[root@hosting ~]# db networks show
eth0=ethernet
bootproto=dhcp
gateway=51.255.160.1
ipaddr=51.255.166.207
netmask=255.255.255.255
role=red
eth0:0=alias
ipaddr=94.23.67.98
netmask=255.255.255.0
role=alias
eth0:1=alias
ipaddr=92.222.231.186
netmask=255.255.255.254
role=alias
ppp0=xdsl-disabled
AuthType=auto
Password=
name=PPPoE
provider=xDSL provider
role=red
user=
red1=provider
interface=eth0
weight=1well I’m not sure that the bug you are facing at the beginning is the same than this one, but when you don’t have a green NIC role, the template expansion fails. I can reproduce the same thing when I set my only green NIC to red.
did you try to manually modify the /etc/dnsmasq.conf to set the dns server of ovh manually like I saw it above ?
In fact in /etc/e-smith/templates//etc/dnsmasq.conf/80tftp the test is not made if a green interface exists, since the esmit::NetworkDB returns undef, we cannot get the ‘prop’ value.
In fact the template should be rewritten something like this
#
# 80tftp
#
{
use esmith::NetworksDB;
my $ndb = esmith::NetworksDB->open_ro() || return;
$status = $dnsmasq{'tftp-status'} || 'disabled';
$dhcpboot = $dnsmasq{'dhcp-boot'}|| '';
if ($status eq 'enabled' && $ndb->green() ) {
my $LocalIP = $ndb->green()->prop('ipaddr') || return;
$OUT.="enable-tftp\n";
if ($dhcpboot ne '')
{
$OUT.="dhcp-boot=$dhcpboot\n";
}
$OUT.="tftp-root=/var/lib/tftpboot\n";
$OUT.="dhcp-option=66,\"$LocalIP\"";
}
}The template of course could be rewritten to have stronger conditions checking, but as said many times, currently we do not support a red-only scenario.
Please @Sebastian reconfigure your machine to have at least one green interface.
In your case, the green interface is the one with public IP.
Also, please be sure to tune network service access from the “Network interfaces” page.
I have got the same problem after resetting my network configuration following the guide http://docs.nethserver.org/projects/nethserver-devel/en/v7/nethserver-base.html#reset-network-configuration (this I had to do because I had tested to implement a bridge which didn’t work at all…). Of course, I had created a green interface like before but I got exactly the same error message as @Sebastian had got by trying to access the software center… also, like it was the case in sebastian’s situation, my server didn’t resolve any host names any more (also google.com didn’t work). hence, it was definitely the same problem…
The workaround proposed by @dnutan [quote=“dnutan, post:24, topic:5297”]
sed -ibak s/server=127.0.0.1/server=8.8.8.8/ /etc/dnsmasq.conf
systemctl restart dnsmasq
[/quote]worked fine… no error message is shown any more when accessing the software center. and also the resolution of host names is again working…
however, I don’t know how to change the nameserver via the server manager as proposed by @stephdl [quote=“stephdl, post:16, topic:5297”]
change it to 8.8.8.8 by the server-manager
[/quote]config show dns still points to 127.0.0.1 and also # grep server= /etc/dnsmasq.conf server=127.0.0.1 server=/uribl.com/127.0.0.1#10053 server=/dnswl.org/127.0.0.1#10053 server=/spamhaus.org/127.0.0.1#10053
Nevertheless, I can ping google.com and also nslookup google.com works again…
For the moment, it seems to work despite the wrong nameserver address… but how long?
I checked the /etc/e-smith/db/configuration/defaults/dns/NameServer file: 8.8.4.4,8.8.8.8
What do you think, is everything OK again and I can simply ignore the fact that the results of config show dns and grep server= /etc/dnsmasq.conf don’t look as they should (also in the /etc/dnsmasq.conf the IP address is 127.0.0.1, after a signal-event nethserver-dnsmasq-update event… but still I can access the software center and ping google and so…)??? or is the workaround only temporarily? which files do I need to change to make it permanently working? especially if I have to change something in my configuration of the network adapters again (for whatever reason…)?
EDIT: moved to DNS Issue/bug after resetting the network adapters
1 Like