Charles Steinkuehler wrote:
>
> > > Never mind the patch, I'm way over thinking this......sorry!
> > >
> > > The simplest route will be to edit your 'network.conf' file as
> > > suggested by Charles.
> > >
> > > Note this:
> > >
> > > # CONFIG_DNS=(YES/NO) Default: NO
> > > # Create /etc/resolv.conf file using DOMAINS and DNSx entries.
> > > # Any current resolv.conf file will be **OVERWRITTEN**
> > >
> > > Scroll down (most of the file) to the DNS config, change to "YES" and
> > > simply enter your desired information. It will NOT be changed with
> > > this option. Charles has already accounted for this bug, sorry I
> > > went braindead. It seems to be my weekend.
> >
> > Please, pay careful attention to my posts. Notice, that this problem
> > does *not* occur at bootup; rather, it occurs later on ;>
> >
> > Yes, I have *always* used CONFIG_DNS=YES, which is why this problem is
> > so surprising!
>
> OK, a few points of order:
>
> - The dhcp client *WILL* overwrite your /etc/resolv.conf file...that's what
> it's *supposed* to do. When you think about it, the dhcp client has no idea
> you're getting a static IP assigned, and don't want name resolution
> configuration changed unless you explicitly tell it.
I'm still confused ;<
What does this have to do with fixed-address?
> - You can explicitly append, pre-pend, and replace information from the dhcp
> server using entries in /etc/dhclient.conf...that's why it's there.
OK
> - If you assign CONFIG_DNS=YES in /etc/network.conf, *AND* you're running
> dhclient, you have two pieces of software trying to update the same
> file...you should expect problems. I suggest setting CONFIG_DNS=NO in
> network.conf if you're running dhclient, and this is how my disk images are
> configured.
Again, I'm confused -- how does CONFIG_DNS=NO help my situation?
Actually, even after reading the dhclient.conf manpage, I was not aware
that most dhclient actions are in shell scripts, rather than compiled
into the dhclient executable. Now that I know this, I've read the
scripts and see what is happening -- but, I still do not understand
*why* ;> Of course, why is less important now than what to do about
this . . .
> - While it would be possible to remove the code (or over-ride the specific
> procedure) that writes /etc/resolv.conf, I would advise against taking this
> sort of approach...using the built-in hooks for defining specific settings
> (/etc/dhclient.conf) is the "approved" way to do this, and will be easier to
> understand/maintain/upgrade in the future.
Yes, I agree -- dhclient-enter|exit-hooks are provided to this end.
Speaking of which, I am unclear why you implicitly exclude these
scenarios from reload_all():
[ x$old_ip_address = x$new_ip_address ]
[ x$reason = xRENEW ]
[ x$reason = xREBIND ]
I've still *not* figured out how $reason gets set, nor am I completely
clear about the meanings for BOUND, REBIND, RENEW, &c. If my ISP is
going to change my leased address ( [ x$old_ip_address !=
x$new_ip_address ] ), I would think that would be one time that I'd want
my ISP to change resolv.conf ?!?!
However, if the address remains unchanged (RENEW ?), then what could it
hurt? Ah-h-h-h, yes, maybe I've got some tunnels open and ipsec is
handling firewall holes that are not permanently there -- but, I should
fix that -- right?
Even if I supersede and CONFIG_DNS=NO, dhclient-script is *still* going
to diddle my resolv.conf -- right??? What if I want *both* my original
content _and_ all ISP additions? I continue to think that ISP changes
-- especially for a fixed-address -- are few and far between . . .
What do you think?
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
