Hello,
After activating the second network interface I lost the name resolution. In the /etc/resolv.conf there was just nameserver 127.0.0.1 inside.
So I entered 8.8.8.8 and everything is working again for now. But after each reconfiguration this entry will be overwritten again.
I was looking for another way to set a permanent default value. So I edited the /etc/sysconfig/network-scripts/ifcfg-* file of the green interface DNS1=8.8.8.8
This did not help, because the entry disappears again.
The next attempt was to added to /etc/e-smith/templates/etc/resolv.conf/40dnsRole/Resolver
$OUT .=“nameserver 8.8.8.8\n”
Nothing helps and I’m out of ideas. So here’s the question:
Where can I store the default DNA resolver?
Why is there no possibility to configure the name resolver in the frontend?
Sincerly, Marko
Ps.: in principle, the activation of a second interface or configuration changes should not lead to the loss of name resolution
Yes, it should be persistent.
Values are saved in a db property (config show dns) and put into dnsmasq config file (/etc/dnsmasq.conf) through template system.
I found a basic problem with CentOS:
It seems that by default the network manager does not connect the network interfaces. I changed this behavior in the file /etc/sysconfig/network-scripts/ifcfg-eth* with NM_CONTROLLED=yes and restarted the network manager. The individually defined DNS servers now exist permanently after all.
Step by step I hope to climb the tree of knowledge. There is a realization growing within me…
I should forget my Linux console (especially the CentOS-Config files) and preferably administrate everything via the Server Manager of Nethserver.
For special cases I should use the template system of Nethserver, because all config files are generated on Linux level…
Is that right?
If so, how do I get a structured introduction to the template system?
In short, within /etc/e-smith/templates/ the directory hierarchy for the config files managed by NethServer is recreated in order for the templates (fragments) to programmatically generate config files. Some events (config change, update…) trigger the expansion of related templates that build the resulting config file.
Behavior of templates can be customized through properties set in plain text database. Those db props are usually set from the server-manager or from the command line.
If desired application behavior cannot be accomplished with default templates and db props, those templates can be extended by custom fragments or override with custom templates.
For better explanation you can take a look at the developer manual.
