Re: /etc/resolv.conf getting over written with dhcp
On Wed, 2012-06-20 at 13:39 +0530, Varuna wrote: Ian Lepore wrote: Using the 'prepend' or 'supercede' keywords in /etc/dhclient.conf is pretty much the standard way of handling a mix of static and dhcp interfaces where the static config needs to take precedence. I'm not sure why you dismiss it as essentially good, but somehow not good enough. It's been working for me for years. -- Ian The issue that I had indicated that the issue with the /etc/resolv.conf is being caused by an error in /sbin/dhclient-script; hence, I am definitely not looking at solving the issue either with /etc/dhclient.conf or /etc/dhclient-exit-hooks configuration file. BTW, resolver(5) / resolv.conf(5) does not mention the usage of /etc/dhclient-exit-hooks file to protect the earlier contents of /etc/resolv.conf file. Will put this issue in the freebsd-doc mailing list. With regards, Varuna Eudaemonic Systems Simple, Specific Insightful I have re-read your original message and I think the confusion is here: 2***# When resolv.conf is not changed actually, we don't # need to update it. # If /usr is not mounted yet, we cannot use cmp, then # the following test fails. In such case, we simply # ignore an error and do update resolv.conf. 3***if cmp -s $tmpres /etc/resolv.conf; then rm -f $tmpres return 0 fi 2/dev/null [...] I guess, the 1***, 3*** and 4*** is causing the recreation of /etc/resolv.conf. Is this correct? I did a small modification to 3*** which is: if !(cmp -s $tmpres /etc/resolv.conf); then rm -f $tmpres return 0 fi 2/dev/null This seems to have solved the issue of /etc/resolv.conf getting overwritten with just: nameserver 192.168.98.4. This ensures that: If there is a difference between $tmpres and /etc/resolv.conf, then it exits post removal of $tmpres. If the execution of 3*** returns a 0, a new file gets created. I guess the modification get the intent of 3*** working. Have I barked up the wrong tree? I think yes, you have barked up the wrong tree. The intent of the code at 3*** is not to exit if there is a difference, it is to exit if there is NO difference. In other words, if the old and new files are identical then there is no need to re-write the file, just cleanup and exit. If the files are different then replace the existing file with the new one. This is just the (sometimes annoying) way dhcp works. If the dhcp server provides new resolver info it completely replaces any existing resolver info unless you've configured your dhclient.conf to prevent it. It only does so if the interface being configured is the current default-route interface, or there is no current default-route interface. -- Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc/resolv.conf getting over written with dhcp
Ian Lepore wrote: Using the 'prepend' or 'supercede' keywords in /etc/dhclient.conf is pretty much the standard way of handling a mix of static and dhcp interfaces where the static config needs to take precedence. I'm not sure why you dismiss it as essentially good, but somehow not good enough. It's been working for me for years. -- Ian The issue that I had indicated that the issue with the /etc/resolv.conf is being caused by an error in /sbin/dhclient-script; hence, I am definitely not looking at solving the issue either with /etc/dhclient.conf or /etc/dhclient-exit-hooks configuration file. BTW, resolver(5) / resolv.conf(5) does not mention the usage of /etc/dhclient-exit-hooks file to protect the earlier contents of /etc/resolv.conf file. Will put this issue in the freebsd-doc mailing list. With regards, Varuna Eudaemonic Systems Simple, Specific Insightful IT Consultants, Continued Education Systems Distribution +91-88-92-47-62-63 http://www.eudaemonicsystems.net http://enquiry.eudaemonicsystems.net -- This email is confidential, and may be legally privileged. If you are not the intended recipient, you must not use or disseminate this information in any format. If you have received this email in error, please do delete it along with copies of it existing in any other format, and notify the sender immediately. The sender of this email believes it is virus free, and does not accept any liability for any errors or omissions arising thereof. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
/etc/resolv.conf getting over written with dhcp
Hello Folks, Noticed a strange issue with the creation / update of /etc/resolv.conf. The details of the system that I noticed the issue on is: Version : FreeBSD 8.0 Patch level: not patched Uname: FreeBSD shastry.eudaemonicsystems.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Sep 29 22:37:51 IST 2011 r...@shastry.bhuta.in:/usr/obj/usr/src/sys/SHASTRY i386 I generally have a static IP 192.168.98.6 (via rc.conf) for my Beastie. The contents of my /etc/resolv.conf is as follows: domain eudaemonicsystems.net nameserver 208.67.222.222 nameserver 208.67.220.220 nameserver 4.2.2.2 No matter how many times I reboot the system, the resolv.conf does not get overwritten when configured with a static IP. I modified the /etc/rc.conf to have the flag: ifconfig_re0=DHCP The next reboot of the system caused the /etc/resolv.conf to be overwritten with the following contents: nameserver 192.168.98.4 I was baffled with this behaviour and checked /etc/rc.d/resolv script and there was no reason as to why [ ! -e /etc/resolv.conf] should fail at any given instance. Out of curiosity executed /bin/kenv dhcp.domain-name which returned with the info: kenv: unable to get dhcp.domain-name. Would it be fair to assume that /etc/rc.d/resolv not to cause the issue? What is causing this behaviour? Have I missed something? Had a look at network-dhcp.html, and found /etc/dhclient.conf to be empty on my system. Digging further, was looking at the scripts under /etc/rc.d, found /etc/rc.d/named to be another script creating the /etc/resolv.conf and this was in the routine named_precmd(). I have not enabled 'named_enable' flag in /etc/rc.conf, while it is commented; by default; in /etc/defaults/rc.conf file. Found /sbin/dhclient-script to be another script that creates /etc/resolv.conf, and this; as I understand; is being referred to by /usr/src/sbin/dhclient/clparse.c and /usr/src/sbin/dhclient/dhclient.c. The script /sbin/dhclient-script has a case option which is: BOUND|RENEW|REBIND|REBOOT). I suppose this is causing the function add_new_resolv_conf() to be invoked. In this function, found the following code (yes, I have marked the code of interest with 1***, 2***, 3*** and 4***): 1***if [ -n $new_domain_name_servers ]; then for nameserver in $new_domain_name_servers; do echo nameserver $nameserver $tmpres done fi if [ -f $tmpres ]; then if [ -f /etc/resolv.conf.tail ]; then cat /etc/resolv.conf.tail $tmpres fi 2***# When resolv.conf is not changed actually, we don't # need to update it. # If /usr is not mounted yet, we cannot use cmp, then # the following test fails. In such case, we simply # ignore an error and do update resolv.conf. 3***if cmp -s $tmpres /etc/resolv.conf; then rm -f $tmpres return 0 fi 2/dev/null # In case (e.g. during OpenBSD installs) /etc/resolv.conf # is a symbolic link, take care to preserve the link and write # the new data in the correct location. to a system if [ -f /etc/resolv.conf ]; then cat /etc/resolv.conf /etc/resolv.conf.save fi 4***cat $tmpres /etc/resolv.conf rm -f $tmpres # Try to ensure correct ownership and permissions. chown -RL root:wheel /etc/resolv.conf chmod -RL 644 /etc/resolv.conf return 0 fi I guess, the 1***, 3*** and 4*** is causing the recreation of /etc/resolv.conf. Is this correct? I did a small modification to 3*** which is: if !(cmp -s $tmpres /etc/resolv.conf); then rm -f $tmpres return 0 fi 2/dev/null This seems to have solved the issue of /etc/resolv.conf getting overwritten with just: nameserver 192.168.98.4. This ensures that: If there is a difference between $tmpres and /etc/resolv.conf, then it exits post removal of $tmpres. If the execution of 3*** returns a 0, a new file gets created. I guess the modification get the intent of 3*** working. Have I barked up the wrong tree? Consider the scenarios when DHCP is enabled on my laptop which is shutdown and started at change of location of usage: 1. Office IP address space is different from the home router IP address range. 2. Office IP address space = home IP address space, router has different IP address. 3. Scenario 2 + IP address is reserved for my laptop is fixed with the MAC address in the router. The /sbin/dhclient-script get even more complex to handle such scenarios; yes, I still have not yet reached that stage. About 2***, so what are the conditions to be true to figure
Re: /etc/resolv.conf getting over written with dhcp
Varuna wrote: Hello Folks, Noticed a strange issue with the creation / update of /etc/resolv.conf. The details of the system that I noticed the issue on is: Version : FreeBSD 8.0 Patch level: not patched Uname: FreeBSD shastry.eudaemonicsystems.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Sep 29 22:37:51 IST 2011 r...@shastry.bhuta.in:/usr/obj/usr/src/sys/SHASTRY i386 I generally have a static IP 192.168.98.6 (via rc.conf) for my Beastie. The contents of my /etc/resolv.conf is as follows: domain eudaemonicsystems.net nameserver 208.67.222.222 nameserver 208.67.220.220 nameserver 4.2.2.2 No matter how many times I reboot the system, the resolv.conf does not get overwritten when configured with a static IP. 1. Since 9.0 we already have resolveconf(8) for this. 2. Empty dhclient.conf means default configuration, you can make your own, refusing nameserver updates coming from DHCP. 3. You can always chflags noschg any precious file. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc/resolv.conf getting over written with dhcp
15.06.2012 23:09, Varuna написал:
Hello Folks,
Noticed a strange issue with the creation / update of
/etc/resolv.conf. The details of the system that I noticed the issue
on is:
Version : FreeBSD 8.0
Patch level: not patched
Uname: FreeBSD shastry.eudaemonicsystems.net 8.0-RELEASE FreeBSD
8.0-RELEASE #0: Thu Sep 29 22:37:51 IST 2011
r...@shastry.bhuta.in:/usr/obj/usr/src/sys/SHASTRY i386
I generally have a static IP 192.168.98.6 (via rc.conf) for my
Beastie. The contents of my /etc/resolv.conf is as follows:
domain eudaemonicsystems.net
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 4.2.2.2
No matter how many times I reboot the system, the resolv.conf does not
get overwritten when configured with a static IP.
I modified the /etc/rc.conf to have the flag:
ifconfig_re0=DHCP
The next reboot of the system caused the /etc/resolv.conf to be
overwritten with the following contents:
nameserver 192.168.98.4
I was baffled with this behaviour and checked /etc/rc.d/resolv script
and there was no reason as to why [ ! -e /etc/resolv.conf] should
fail at any given instance. Out of curiosity executed /bin/kenv
dhcp.domain-name which returned with the info: kenv: unable to get
dhcp.domain-name. Would it be fair to assume that /etc/rc.d/resolv
not to cause the issue?
What is causing this behaviour? Have I missed something?
Had a look at network-dhcp.html, and found /etc/dhclient.conf to be
empty on my system.
Digging further, was looking at the scripts under /etc/rc.d, found
/etc/rc.d/named to be another script creating the /etc/resolv.conf and
this was in the routine named_precmd(). I have not enabled
'named_enable' flag in /etc/rc.conf, while it is commented; by
default; in /etc/defaults/rc.conf file.
From my /etc/dhclient.conf:
interface lagg0 {
send dhcp-lease-time 3600;
prepend domain-name-servers 127.0.0.1, 4.4.4.4, 8.8.8.8;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers;
require subnet-mask, domain-name-servers;
}
And result is /etc/resolv.conf:
# Generated by resolvconf
nameserver 127.0.0.1
nameserver 4.4.4.4
nameserver 8.8.8.8
nameserver 192.168.1.1
--
Dima Panov (flu...@freebsd.org)
(KDE, Office)@FreeBSD team
Facebook: http://www.facebook.com/fluffy.khv
IRC: fluffy@EFNet, fluffykhv@FreeNode
twitter: fluffy_khv | skype: dima.panov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc/resolv.conf getting over written with dhcp
On Jun 15, 2012, at 5:47 AM, Volodymyr Kostyrko c.kw...@gmail.com wrote: Varuna wrote: Hello Folks, Noticed a strange issue with the creation / update of /etc/resolv.conf. The details of the system that I noticed the issue on is: Version : FreeBSD 8.0 Patch level: not patched Uname: FreeBSD shastry.eudaemonicsystems.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Sep 29 22:37:51 IST 2011 r...@shastry.bhuta.in:/usr/obj/usr/src/sys/SHASTRY i386 I generally have a static IP 192.168.98.6 (via rc.conf) for my Beastie. The contents of my /etc/resolv.conf is as follows: domain eudaemonicsystems.net nameserver 208.67.222.222 nameserver 208.67.220.220 nameserver 4.2.2.2 No matter how many times I reboot the system, the resolv.conf does not get overwritten when configured with a static IP. 1. Since 9.0 we already have resolveconf(8) for this. 2. Empty dhclient.conf means default configuration, you can make your own, refusing nameserver updates coming from DHCP. 3. You can always chflags noschg any precious file. schg to disallow changes. noschg is incorrect. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc/resolv.conf getting over written with dhcp
15.06.2012 19:09, Varuna пишет:
About 2***, so what are the conditions to be true to figure out that
/etc/resolv.conf has not changed?
There is simple solution: create file /etc/dhclient-enter-hooks
and override add_new_resolv_conf() there to do nothing:
add_new_resolv_conf() {
return 0
}
Works just fine for my systems.
Eugene Grosbein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc/resolv.conf getting over written with dhcp
Thanks for the pointers.
Dima Panov wrote:
From my /etc/dhclient.conf:
interface lagg0 {
send dhcp-lease-time 3600;
prepend domain-name-servers 127.0.0.1, 4.4.4.4, 8.8.8.8;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers;
require subnet-mask, domain-name-servers;
}
And result is /etc/resolv.conf:
# Generated by resolvconf
nameserver 127.0.0.1
nameserver 4.4.4.4
nameserver 8.8.8.8
nameserver 192.168.1.1
True indeed this will work and I did have a look at dhclient.conf(5) to setup
the freebsd8:/etc/dhclient.conf. This will still call /sbin/dhclient-script
which will overwrite the configuration done to the /etc/resolv.conf each time
the system power is recycled. As per /usr/src/include/resolv.h, the MAXNS is by
default set to 3; which the default configuration user will not be aware of as
the entire focus will be on the ifconfig related flags in /etc/rc.conf. BTW,
the example indicated in dhclient.conf(5) has a typo which says
/etc/dhclient-script instead of /sbin/dhclient-script, indeed the system does
not fail if the typo exists in dhclient.conf.
Eugene Grosbein wrote:
There is simple solution: create file /etc/dhclient-enter-hooks
and override add_new_resolv_conf() there to do nothing:
add_new_resolv_conf() {
return 0
}
Works just fine for my systems.
Indeed this is a good suggestion, and this is if the user is aware of what to
look for and where in /sbin/dhclient-script it is documented.
A general sysadmin would be aware of /etc/nsswitch.conf and /etc/resolv.conf for
name resolution issues and I do not think they will be aware of so many possible
ways to handle the issue of resolv.conf getting overwritten by the usage of dhcp.
What would be the way out? Do you think it would be a good idea to push the
nameserver configuration information into /etc/rc.conf which happens to be the
single file that would handle the system configuration?
With regards,
Varuna
Eudaemonic Systems
Simple, Specific Insightful
IT Consultants, Continued Education Systems Distribution
+91-88-92-47-62-63
http://www.eudaemonicsystems.net
http://enquiry.eudaemonicsystems.net
--
This email is confidential, and may be legally privileged. If you
are not the intended recipient, you must not use or disseminate
this information in any format. If you have received this email in
error, please do delete it along with copies of it existing in any
other format, and notify the sender immediately. The sender of this
email believes it is virus free, and does not accept any liability
for any errors or omissions arising thereof.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc/resolv.conf getting over written with dhcp
On Fri, 2012-06-15 at 23:02 +0530, Varuna wrote:
Thanks for the pointers.
Dima Panov wrote:
From my /etc/dhclient.conf:
interface lagg0 {
send dhcp-lease-time 3600;
prepend domain-name-servers 127.0.0.1, 4.4.4.4, 8.8.8.8;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers;
require subnet-mask, domain-name-servers;
}
And result is /etc/resolv.conf:
# Generated by resolvconf
nameserver 127.0.0.1
nameserver 4.4.4.4
nameserver 8.8.8.8
nameserver 192.168.1.1
True indeed this will work and I did have a look at dhclient.conf(5) to setup
the freebsd8:/etc/dhclient.conf. This will still call /sbin/dhclient-script
which will overwrite the configuration done to the /etc/resolv.conf each time
the system power is recycled. As per /usr/src/include/resolv.h, the MAXNS is
by
default set to 3; which the default configuration user will not be aware of
as
the entire focus will be on the ifconfig related flags in /etc/rc.conf. BTW,
the example indicated in dhclient.conf(5) has a typo which says
/etc/dhclient-script instead of /sbin/dhclient-script, indeed the system does
not fail if the typo exists in dhclient.conf.
Eugene Grosbein wrote:
There is simple solution: create file /etc/dhclient-enter-hooks
and override add_new_resolv_conf() there to do nothing:
add_new_resolv_conf() {
return 0
}
Works just fine for my systems.
Indeed this is a good suggestion, and this is if the user is aware of what to
look for and where in /sbin/dhclient-script it is documented.
A general sysadmin would be aware of /etc/nsswitch.conf and /etc/resolv.conf
for
name resolution issues and I do not think they will be aware of so many
possible
ways to handle the issue of resolv.conf getting overwritten by the usage of
dhcp.
What would be the way out? Do you think it would be a good idea to push the
nameserver configuration information into /etc/rc.conf which happens to be
the
single file that would handle the system configuration?
With regards,
Varuna
Eudaemonic Systems
Simple, Specific Insightful
IT Consultants, Continued Education Systems Distribution
+91-88-92-47-62-63
http://www.eudaemonicsystems.net
http://enquiry.eudaemonicsystems.net
--
This email is confidential, and may be legally privileged. If you
are not the intended recipient, you must not use or disseminate
this information in any format. If you have received this email in
error, please do delete it along with copies of it existing in any
other format, and notify the sender immediately. The sender of this
email believes it is virus free, and does not accept any liability
for any errors or omissions arising thereof.
Using the 'prepend' or 'supercede' keywords in /etc/dhclient.conf is
pretty much the standard way of handling a mix of static and dhcp
interfaces where the static config needs to take precedence. I'm not
sure why you dismiss it as essentially good, but somehow not good
enough. It's been working for me for years.
-- Ian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc/resolv.conf getting over written with dhcp
On 2012-06-15 07:14, Eugene Grosbein wrote:
15.06.2012 19:09, Varuna пишет:
About 2***, so what are the conditions to be true to figure out that
/etc/resolv.conf has not changed?
There is simple solution: create file /etc/dhclient-enter-hooks
and override add_new_resolv_conf() there to do nothing:
add_new_resolv_conf() {
return 0
}
Works just fine for my systems.
Or just add something like:
interface eth0 {
supersede domain-name example.com.;
supersede domain-name-servers 192.0.2.1;
}
To your /etc/dhclient.conf and make dhclient do the right thing.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
