On Mon, 2014-10-27 at 21:24 -0500, R. W. Rodolico wrote:
I said it was a band-aid. And will add it was a kludge also. I never, ever said it was elegant.
I'll give it a try. I hope like Hell you are talking Perl, or at worst BASH scripts. Just so long as you don't make me work too much with with IPTables.
Yes it is all perl and shell script.
It is basically replacing all code that is reading from and writing to /var/ipfire/dns/settings and change it to read from /var/ipfire/ethernet/settings.
I think we will then also be able to support changing DNS servers on the setup tool. That will be written in C, but I don't think that anything needs to be changed here at all.
Any hints on where to start looking? It looks like something is going on in /etc/rc.d/init.d/networking/red
http://git.ipfire.org/?p=ipfire-2.x.git&a=search&h=HEAD&st=grep&... %2Fsettings
There is a bit in /etc/init.d/networking and of course the dns.cgi file.
Haven't looked at it, but I don't think that there should be any hurdles.
I'm building out a couple of networks this week, but may be able to get to it this weekend.
This doesn't have high priority.
Rod
On 10/27/2014 08:41 PM, Michael Tremer wrote:
On Mon, 2014-10-27 at 20:27 -0500, R. W. Rodolico wrote:
I'm ok with leaving as is, but if you'd like, I could definitely write a Perl script that would go through and sync all the different locations. Something that would run every 5 minutes or so and just see if the date/time stamp had changed on any of the locations. I'd have to figure out which file was the primary (one with most recent date), then update the others. Actually, a BASH script might be better simply because of the overhead of loading the Perl interpreter.
I don't really regard this as a very elegant solution for the problem. It doesn't fix the problem, but rather applies a band-aid which has to be taken care of.
Maybe we can at least start with moving the DNS servers from /var/ipfire/dns/settings to /var/ipfire/ethernet/settings for DHCP, too. That leaves us with the PPP profiles which is not that bad I guess.
Doing that would just require to fix the system scripts that read the configuration and changing the CGI script.
That may not be the best idea, since it would increase the load on the system, and it would not be instantaneous. But, it could be a band-aid.
Or, like you said, just leave it alone and wait for v3. Most people will use the GUI, and it definitely says in there that a reboot must happen before that change takes effect (or, disconnect/connect).
Anyway, let me know if you want a script. I think the patches would be too much since I assume it is written by more than one place? However, it if it only changed from setup and the GUI, I can dust off my 20 year old C skills and see if I can figure out a patch.
If you want to fix it now, let me know if it is only changed in setup and the WebUI, and I'll be happy to take a look at it.
Let me know if you want to do this task.
-Michael
Rod
On 10/27/2014 07:51 PM, Michael Tremer wrote:
Hi,
DNS settings are actually stored in even more locations. These depend on the method you use for connecting with the Internet.
I have thought about cleaning this up a couple of times. None of the easy solutions makes the situation any better and therefore all remained untouched.
This has been solved in IPFire 3 by just using one pool of DNS servers and prioritizing them by the preference of the admin. This solution is way over the top for IPFire 2 which always has just one uplink.
So I would still say to leave this as it is - unless you have got a really good idea (or even better patches) for an easy solution that doesn't make things worse.
Best, -Michael
On Sat, 2014-10-25 at 22:46 -0500, R. W. Rodolico wrote:
I was having some problems with a remote router not resolving addresses, so I started 'setup' from the CLI to change them. When I did this, I had the same problem (and suspected a network issue). Clearing dnsmasq (dnsmasqctl restart) showed it was still using the old DNS servers.
The router is using DHCP for the red interface, but I am trying to override the DNS given by them (it is their little monitoring tool).
Investigating, I found the following happened:
DNS settings appear in two places /var/ipfire/ethernet/settings /var/ipfire/dns/settings
'setup' modifies /var/ipfire/ethernet/settings, but does not modify
/var/ipfire/dns/settings. It appears dnsmasql uses /var/ipfire/dns/settings.
- In the webui, 'Network | Assign DNS Server' reads
/var/ipfire/dns/settings, so changes made there correctly work.
Resolution:
Either fix the code or simply remove the text that says you can change the DNS for DHCP there:
Enter the DNS and gateway information. These settings are used only with Static IP (and DHCP if DNS set) on the RED interface.
Frankly, the latter would be easiest, and most people will use the WebGUI, and weirdos like me will simply edit the settings file if I happen to need to change it from the CLI.
Rod