Bug Report - setup

Bug Report - setup

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

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:

1. DNS settings appear in two places
   /var/ipfire/ethernet/settings
   /var/ipfire/dns/settings

2. 'setup' modifies /var/ipfire/ethernet/settings, but does not modify
/var/ipfire/dns/settings. It appears dnsmasql uses /var/ipfire/dns/settings.

3. 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
-- 
"Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net

Re: Bug Report - setup

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

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:
> 
> 1. DNS settings appear in two places
>    /var/ipfire/ethernet/settings
>    /var/ipfire/dns/settings
> 
> 2. 'setup' modifies /var/ipfire/ethernet/settings, but does not modify
> /var/ipfire/dns/settings. It appears dnsmasql uses /var/ipfire/dns/settings.
> 
> 3. 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Bug Report - setup

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 3571 bytes --]

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.

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.

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:
>>
>> 1. DNS settings appear in two places
>>    /var/ipfire/ethernet/settings
>>    /var/ipfire/dns/settings
>>
>> 2. 'setup' modifies /var/ipfire/ethernet/settings, but does not modify
>> /var/ipfire/dns/settings. It appears dnsmasql uses /var/ipfire/dns/settings.
>>
>> 3. 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

-- 
"Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net

Re: Bug Report - setup

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 4227 bytes --]

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:
> >>
> >> 1. DNS settings appear in two places
> >>    /var/ipfire/ethernet/settings
> >>    /var/ipfire/dns/settings
> >>
> >> 2. 'setup' modifies /var/ipfire/ethernet/settings, but does not modify
> >> /var/ipfire/dns/settings. It appears dnsmasql uses /var/ipfire/dns/settings.
> >>
> >> 3. 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
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Bug Report - setup

[R. W. Rodolico]

[-- Attachment #1: Type: text/plain, Size: 4912 bytes --]

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.

Any hints on where to start looking? It looks like something is going on
in /etc/rc.d/init.d/networking/red

I'm building out a couple of networks this week, but may be able to get
to it this weekend.

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:
>>>>
>>>> 1. DNS settings appear in two places
>>>>    /var/ipfire/ethernet/settings
>>>>    /var/ipfire/dns/settings
>>>>
>>>> 2. 'setup' modifies /var/ipfire/ethernet/settings, but does not modify
>>>> /var/ipfire/dns/settings. It appears dnsmasql uses /var/ipfire/dns/settings.
>>>>
>>>> 3. 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
>>

-- 
"Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net