Re: FreeBSD Boot Times
On 2012-Jun-13 21:55:22 +0200, Hans Petter Selasky hsela...@c2i.net wrote: Try setting: sysctl hw.usb.no_boot_wait=1 Note that this is a tunable and will need to be specified in /boot/loader.conf to have any effect. -- Peter Jeremy pgpojiOBCDYfk.pgp Description: PGP signature
Re: Upcoming release schedule - 8.4 ?
On 6/15/12 4:25 AM, Adrian Chadd wrote: Hi, 9 will mature as people use it and report bugs/regressions. It would be really great if you could try some of your workload on -9 and provide feedback and file PRs. Engaging with the community (and hiring developers :) is by far the best way to get things to mature quickly. 2c, Adrian I wholeheartedly agree, however the cheer number of problem reports I've seen on the ml when 9.0 came out really chilled me away. There are not many boxes I could try 9.0 on, because they're in production with pfsync to conserve client sessions and I'm loath to take risks with most of our firewalls. I'm thinking we might jump straight from 8.x to 10 when the time comes, I'm really looking forward to Gleb's work on CARP and PF ;) ___ 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: Upcoming release schedule - 8.4 ?
10.x will likely be more stable if 9.x gets stressed, and the bugs from there get fixed in -HEAD. I know this goes against what users expect, but as a software developer, QA is only as good as your testing and validation procedures. :) Adrian ___ 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: Upcoming release schedule - 8.4 ?
On 2012-Jun-14 08:09:30 +0100, Chris Rees utis...@gmail.com wrote: Except STABLE is no good for production, and the problem is EoL- updates and support stop. There's nothing stopping you from from running -stable in production. Obviously, you will need to do more extensive testing than you might need to for a -release. As for EoL, all software goes EoL and support for that software stops. FreeBSD releases are typically supported for 4 years - IMO, that's excellent value for money. On 2012-Jun-14 12:48:19 +0100, Chris Rees utis...@gmail.com wrote: On Jun 14, 2012 9:30 AM, Damien Fleuriot m...@my.gd wrote: I've moved us to 8.3-STABLE recently and am quite happy with it, so far. Too strong wording perhaps; but you can't claim that an EOL stable branch will have the level of support afforded to live branches. That was supposed to be my point, as Mark has also explained. You are the only person that is claiming that 8.x is EOL. I have not seen any official announcement to that effect. The absence of an announcement of 8.4-release does not make it EOL. -- Peter Jeremy pgpxLxs9FqeLP.pgp Description: PGP signature
Re: Upcoming release schedule - 8.4 ?
On Fri, Jun 15, 2012 at 1:18 AM, Adrian Chadd adr...@freebsd.org wrote: 10.x will likely be more stable if 9.x gets stressed, and the bugs from there get fixed in -HEAD. I know this goes against what users expect, but as a software developer, QA is only as good as your testing and validation procedures. :) Being a realist (once again) most groups I've dealt with that have the resources to test their releases lag behind by CURRENT-2 major releases to avoid pushing unqualified code out on to customers. Not everyone is willing to bet on the bleeding edge of things, but this needs to change in order for things to move forward (this is something that my previous mentor at IronPort -- ambrisko@ -- encouraged for me to do and he exercised on a regular basis). The problem is time when it comes to pushing features forward to a newer OS release and testing them (IronPort used to do this, but no longer does as the individuals who used to do this left the group for other greener pastures). Thanks, -Garrett ___ 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: Upcoming release schedule - 8.4 ?
On Fri, Jun 15, 2012 at 10:16:30AM +0200, Damien Fleuriot wrote: I'm thinking we might jump straight from 8.x to 10 when the time comes, I'm really looking forward to Gleb's work on CARP and PF ;) I don't know why you might think one .0 release would be more mature than another .0 release. Maybe I'm misunderstanding. There are not many boxes I could try 9.0 on, because they're in production with pfsync to conserve client sessions and I'm loath to take risks with most of our firewalls. This is where having one or more systems for development is key. Installations like yours are in a far better situation to test FreeBSD under realistic loads than are all but a few of the FreeBSD developers. I would urge testing long before the leadup to a .0 release, not afterwards. Apologies if I'm just repeating myself here, but FreeBSD does not have a dedicated QA department. We are reliant on our users to test in real- world conditions. mcl ___ 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: Upcoming release schedule - 8.4 ?
On Jun 15, 2012 9:39 AM, Peter Jeremy pe...@rulingia.com wrote: On 2012-Jun-14 08:09:30 +0100, Chris Rees utis...@gmail.com wrote: Except STABLE is no good for production, and the problem is EoL- updates and support stop. There's nothing stopping you from from running -stable in production. Obviously, you will need to do more extensive testing than you might need to for a -release. As for EoL, all software goes EoL and support for that software stops. FreeBSD releases are typically supported for 4 years - IMO, that's excellent value for money. On 2012-Jun-14 12:48:19 +0100, Chris Rees utis...@gmail.com wrote: On Jun 14, 2012 9:30 AM, Damien Fleuriot m...@my.gd wrote: I've moved us to 8.3-STABLE recently and am quite happy with it, so far. Too strong wording perhaps; but you can't claim that an EOL stable branch will have the level of support afforded to live branches. That was supposed to be my point, as Mark has also explained. You are the only person that is claiming that 8.x is EOL. I have not seen any official announcement to that effect. The absence of an announcement of 8.4-release does not make it EOL. Of course not. The fear that this whole thread is about the possibility of EoL this year or soon; the OP wants support for longer. Chris ___ 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: Upcoming release schedule - 8.4 ?
On 6/15/12 10:52 AM, Mark Linimon wrote: On Fri, Jun 15, 2012 at 10:16:30AM +0200, Damien Fleuriot wrote: I'm thinking we might jump straight from 8.x to 10 when the time comes, I'm really looking forward to Gleb's work on CARP and PF ;) I don't know why you might think one .0 release would be more mature than another .0 release. Maybe I'm misunderstanding. 10.0 hasn't scared the hell out of me, yet, on the ml... :p There are not many boxes I could try 9.0 on, because they're in production with pfsync to conserve client sessions and I'm loath to take risks with most of our firewalls. This is where having one or more systems for development is key. My problem here is that the dev and preprod platforms are actively used by our devs, which means that it costs us money if we have an outage. I suppose I could try upgrading the backup box to 9.0 then swapping over to it. My main problem here is that we've got many machines to administer, on top of the network and security, and there's just me and myself that touch the firewalls. It always comes down to time being short... Installations like yours are in a far better situation to test FreeBSD under realistic loads than are all but a few of the FreeBSD developers. I would urge testing long before the leadup to a .0 release, not afterwards. I guess it couldn't hurt overmuch for me to test 9.0 on one of our projects, I could update 1 of the 4 boxes to 9.0 and make it carp master. If that goes well, 1-2 weeks later I could push 9.0 on another project which uses 4 *active* firewalls. This is a medium packet-rate [2][3] real life [1] project and could yield interesting results for you guys. @gleb Are there any counter indications against running 8-STABLE and 9-STABLE sets of firewalls with CARP and pfsync ? [1] Firewalls share 8 CARP IPs and are each master on 2 at a given time. Firewalls use VLAN tagging over a link aggregation interface. Firewalls use relayd to dynamically rdr packets to backend servers. [2] IRQs on broadcom NIC: # vmstat -i interrupt total rate irq9: acpi0 22 0 irq20: uhci3 20 0 irq21: uhci2 uhci4+ 25 0 cpu0: timer 2089687121 2000 irq256: bce033684311 32 irq257: bce1 8636578820 8266 [3] PF output: Status: Enabled for 12 days 02:10:48 Debug: Urgent Interface Stats for vlan20IPv4 IPv6 Bytes In5225964204350 Bytes Out 55365130031720 Packets In Passed 48930005750 Blocked 1449678030 Packets Out Passed 60052575430 Blocked 4783780 State Table Total Rate current entries16556 searches 2264698647621679.1/s inserts 1368370473 1309.9/s removals 1368353917 1309.9/s Counters match 1650605688 1580.1/s ___ 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
Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, even though it's UI is somewhat irritating. When configured correctly, you can trust SMF to deal with any problem; when a needed resource for a given service is down, that service isn't started. When the service is malfunctioning, it's restarted at a configured interval or marked as malfunctioning and stopped and admin is contacted. And so forth. Faster boot times come as a simple added bonus from proper design. Anyone serious about replacing rc(8) should take a good look at SMF feature list, then decide if such a thing is worth spending time reimplementing. Doing a dozen half-assed implementations like Linux is doing is just dumb and aggravates sysadmins. Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. -- Atte Peltomäki atte.peltom...@iki.fi http://kameli.org Your effort to remain what you are is what limits 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 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
mergemaster bug?
I'm runing FreeBSD 9.0-RELEASE-p3 Sys is upgraded and all files in sync, but just for fun: Without any args: # mergemaster --- *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot + ln -s ../var/named/etc/namedb /var/tmp/temproot/etc/namedb + ln -s mail/aliases /var/tmp/temproot/etc/aliases *** Beginning comparison *** Checking /etc/rc.d for stale files *** The following files exist in /etc/rc.d but not in /var/tmp/temproot/etc/rc.d/: sshd The presence of stale files in this directory can cause the dreaded unpredictable results, and therefore it is highly recommended that you delete them. *** Delete them now? [n] *** Files will not be deleted --- I did a check update via 'csup' and all was fine. Status (exit code is 0): # diff /usr/src/etc/rc.d/sshd /etc/rc.d/sshd This is a bug?! Bitch wanted to nuke my sshd! If I've pressed 'yes' sshd would never start again, after a reboot! Domagoj Smolčić ___ 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: Upcoming release schedule - 8.4 ?
So what , this fell on deaf ears or was it a horridly bad idea ? Anyone care to share ? On Thu, Jun 14, 2012 at 5:12 PM, Mark Saad nones...@longcount.org wrote: All I have an partial solution to this issue I was thinking about this on my morning train ride, so its a bit bumpy. Here are my solutions they are not complete but I think its a good start. 1. When official errata and security updates hit the tree . Providing updated install media could be step one . Maybe rebuild install media periodical say every 3 months, if it warrants it. 2. Change FreeBSD-update to allow you to select what updates you want, and make it work for stable. Simply put think freebsd-update fetch stable kernel or freebsd-update fetch release base 3. Change FreeBSD-update to tweak a library so the -pN level is not hardcoded into the kernel at compile time. Currently FreeBSD's patch or p level -pN is a newvers.sh function . 4. Publish a longer time line for future releases and make it easier to find. While ken smith's email about the 9.1-RELEASE time line was a good start , for 9.1,I feel that a short general time line on http://www.freebsd.org/releases/ would do a world of good for people want to know whats up next and when can I expect it. It does not need to be exact just a rough estimate. The sum total of all of this , in my eyes, is when updated drivers ( I know its a still a wish and not reality ) , bug fixes , security updates are released , new installs done around that time will start out with all of the good bits. Secondly when new updates are released users can apply base updates and kernel updates to both release and stable as needed. Lastly updates released via this new method would be easily checked via uname -a or maybe freebsd-update show version Fire away. --- Mark Saad | mark.s...@longcount.org -- mark saad | nones...@longcount.org ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi wrote: On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, even though it's UI is somewhat irritating. When configured correctly, you can trust SMF to deal with any problem; when a needed resource for a given service is down, that service isn't started. When the service is malfunctioning, it's restarted at a configured interval or marked as malfunctioning and stopped and admin is contacted. And so forth. Faster boot times come as a simple added bonus from proper design. Anyone serious about replacing rc(8) should take a good look at SMF feature list, then decide if such a thing is worth spending time reimplementing. Doing a dozen half-assed implementations like Linux is doing is just dumb and aggravates sysadmins. Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. Theres always Launchd also. -- Atte Peltomäki atte.peltom...@iki.fi http://kameli.org Your effort to remain what you are is what limits 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 ___ 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
EFI development tools
I've been working on EFI support for intel platforms. I've managed to build the EFI Development Kit (EDK II) and the IASL compiler for FreeBSD, which raises the possibility of integrating them either as ports, or possibly into the base system. Here is some background: Right now, there is only one EFI program that gets built in the entire system: loader.efi (for IA64, and in the future, i386 and amd64). This is done by building a standard ELF program with a custom linker script which produces code at a base address of 0x1000 (This is a trick to get the effects of compiling for position-independent code, as required by the PE format, as the actual .text section starts at that offset into the file). It then uses objcopy to translate to the PE executable format. I've had some strange behavior in some of the EFI interfaces (notably, ConOut), which smacks of some sort of subtle ABI issue. EDK seems to be made for development on a windows box, with marginal support for Darwing and some Linux distros added as an afterthought. It takes a bit of shoehorning to get it to build and run on FreeBSD, but I did get it to work. However, it would take a nontrivial effort to get it in shape for importation into the base FreeBSD system. It also relies on mingw32 binutils and gcc, as well as python (though it only uses python for build purposes; an effort to import it into the base system would probably remove all the python bits). The IASL compiler comes with a bunch of other ACPI components, some of which may very well be in the base system already. However, the EFI programs I produce using the EDK system work properly, and don't have the same issues as the ones I produce using what's in the base system. As for what to do with EDK and the IASL compiler, there seem to be two possibilities: 1) create ports for them, 2) plan on importing them into the base system. Here's the advantages and disadvantages as I see them: Port advantages: less work, doesn't mess with the base system, less need to change the EDK and IASL compiler sources and build tools, less work to keep up to date with releases Port disadvantages: won't be available for building EFI boot loaders Base system advantages: tools will be available for building boot loaders and other components, easier to maintain compliance with UEFI (EDK is published by Intel, and represents the official EFI toolchain), less likely to run into subtle ABI-related bugs in EFI programs, makes future EFI support efforts (ie on ARM) significantly easier. Base system disadvantages: more work, would require rewriting the build process to avoid dependence on python, gmake, mingw32, and others, adds more to the base system. I'd like to get some discussion/commentary on these options, to figure out which is the best way forward. Thanks ___ 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: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 10:25 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, 9 will mature as people use it and report bugs/regressions. It would be really great if you could try some of your workload on -9 and provide feedback and file PRs. Engaging with the community (and hiring developers :) is by far the best way to get things to mature quickly. As an aside, its more projects like this that need to happen: http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068129.html ___ 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: Upcoming release schedule - 8.4 ?
The suggestions are all good, but they require volunteers to volunteer more of their time (for free, hence volunteering) to maintain longer branches; it requires more resources from volunteer mirrors (for free, hence volunteer) to store even more ports and CD-ROM ISO snapshots. What we as a community need is more people standing up and taking these jobs on. No-one will complain if you decide to tackle, say, the ISO snapshots based on security releases. But you'd then have to do all of the QA that goes into generating the release, building the ports, doing some tests to make sure there aren't any glaring gotchas, asking users to test out your pre-.0 release image (and they don't, then complain when .0 didn't work), etc, etc. So please, if you can step up, take ownership and start attacking these issues, we'll embrace you with open arms. :) Adrian ___ 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: mergemaster bug?
On 06/15/2012 11:37, rank1see...@gmail.com wrote: *** The following files exist in /etc/rc.d but not in /var/tmp/temproot/etc/rc.d/: sshd man src.conf, and search for SSH. You have one of those options defined in your environment. Doug -- This .signature sanitized for your protection ___ 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
