Re: portmaster not ask for port deletion
Kevin Oberman wrote: Date: Wed, 26 Aug 2009 12:59:19 -0700 From: Doug Barton do...@freebsd.org Sender: owner-freebsd-sta...@freebsd.org Skip Ford wrote: Well, it wasn't immediately obvious to me that someone would ever want to mark a port ignore and then want to upgrade it. So, it just seemed like a silly question to me (and still does to be honest, unless that's the behavior of portupgrade you're trying to match.) I honestly don't know what portupgrade does in that situation. There are at least 2 classes of users that I am trying to protect in this case: 1. Users who believe that -f should override +IGNOREME 2. Users who create an +IGNOREME file for some reason, then forget it's there. portupgrade does the same thing except that you hold them instead of ignoring them. I believe that this is the correct way. I have ports (e.g. openoffice.org) that take a VERY long time to build or that are run in production out of a crontab (rancid). I don't want to inadvertently update these with the '-a' option. (Especially th latter case.) When I really, really want to do them, I use '-f'. I think of '-f' as YES, I REALLY, REALLY, REALLY want to update this port now and I expect you to believe me. I don't really have a problem with portmaster asking to build +IGNOREME ports, especially if that's how portupgrade works. But, according to the man page, portmaster asks to upgrade IGNOREME ports whenever '-a' is present. That still just seems wrong to me, and that's what bit me (holding up my build for a few hours is all.) It's been years since I used portupgrade, but I thought I remembered that +IGNOREME was designed just for that purpose: to have portupgrade automatically skip certain ports when it was invoked with '-a'. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: portmaster not ask for port deletion
Doug Barton wrote: Skip Ford wrote: So, basically, portmaster stopped and asked for input because it thought I might've forgotten that I installed an +IGNOREME file 10 minutes prior. I'd prefer to not have tools that try to think about what I'm doing. It should do what I say it should do, not what it thinks I may have meant. Certainly, enough information was provided by me for portmaster to DTRT without causing any harm whatsoever if it didn't request input. You obviously have very strong opinions about how you think portmaster should operate, I wouldn't say that at all. I honestly haven't put any thought into it. I'm saying, that I used the tool and expected it to operate, with regard to +IGNOREME files, in the same way that all of the package tools and portupgrade (IIRC) have worked for the years I've been using the system. It didn't, and it caught me off-guard. That's just my review of using your code to upgrade a machine, not some strongly-held belief. At least now we know why it didn't, because it was worried about me possibly forgetting someday that I'd installed an +IGNOREME file. Frankly, that's none of it's business if my memory's failing. :) I think it should do what I tell it to do like the other tools have over the years. But whatever. I can change the code if I want. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: portmaster not ask for port deletion
Doug Barton wrote: Skip Ford wrote: Doug Barton wrote: Second, without knowing what command line you used I couldn't tell you for sure what happened of course, but assuming you used some combination of '-af' what you saw was expected behavior. There is a conflict (I think a fairly obvious one) between the -f option and +IGNOREME. Since different users would have different ideas of how to resolve that conflict, portmaster takes the safe path and asks you. Well, it wasn't immediately obvious to me that someone would ever want to mark a port ignore and then want to upgrade it. So, it just seemed like a silly question to me (and still does to be honest, unless that's the behavior of portupgrade you're trying to match.) I honestly don't know what portupgrade does in that situation. There are at least 2 classes of users that I am trying to protect in this case: 1. Users who believe that -f should override +IGNOREME 2. Users who create an +IGNOREME file for some reason, then forget it's there. So, basically, portmaster stopped and asked for input because it thought I might've forgotten that I installed an +IGNOREME file 10 minutes prior. I'd prefer to not have tools that try to think about what I'm doing. It should do what I say it should do, not what it thinks I may have meant. Certainly, enough information was provided by me for portmaster to DTRT without causing any harm whatsoever if it didn't request input. Great script anyway though compared to the alternatives. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: portmaster not ask for port deletion
Nenhum_de_Nos wrote: On Mon, 24 Aug 2009 12:54:54 -0700 Doug Barton do...@freebsd.org wrote: It sounds to me like what you're seeing is portmaster asking whether or not you want to delete the distfiles after an upgrade. The easiest way to deal with that is to use '-aD' and then when it's done use either --clean-distfiles or --clean-distfiles-all. Once again, see the man page for more information on those options. I just want to fire the command and it work alone till is done. Good luck with unattended runs of portmaster. That's the only real remaining shortfall of portmaster, IMO. It still needs hand-holding to finish its job often times. For example, I just did the big rebuild you're getting ready for. I spent a good 45 minutes updating ports.conf beforehand, fetching a good number of distfiles in advance, and configuring ports before starting the massive build. I also told portmaster to ignore 3 ports (1 broken, 2 would most likely fail to build for one reason or another.) So, I started the build and left. Came back 7 hours later and portmaster had barely run an hour and was stuck waiting for input. What was so important? It wanted to know if it should go ahead an update the 3 ports that I had just explicitly told it not to upgrade 10 minutes before I started it (by using .IGNOREME files). Of course I don't want it to upgrade them anyway. If I wanted them upgraded, I wouldn't have installed IGNOREME files. So, portmaster still needs some hand-holding compared to other tools. But, it still beats portupgrade IMO. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: portmaster not ask for port deletion
Doug Barton wrote: Skip Ford wrote: Nenhum_de_Nos wrote: On Mon, 24 Aug 2009 12:54:54 -0700 Doug Barton do...@freebsd.org wrote: It sounds to me like what you're seeing is portmaster asking whether or not you want to delete the distfiles after an upgrade. The easiest way to deal with that is to use '-aD' and then when it's done use either --clean-distfiles or --clean-distfiles-all. Once again, see the man page for more information on those options. I just want to fire the command and it work alone till is done. Good luck with unattended runs of portmaster. That's the only real remaining shortfall of portmaster, IMO. It still needs hand-holding to finish its job often times. Yes, unfortunately it's not omniscient. :) Well, to be honest, it wouldn't need to be. It would just need a flag to know when nobody is present from whom to request input, and then take the default action. But, if all input is requested during config, then that's pointless. For example, I just did the big rebuild you're getting ready for. I spent a good 45 minutes updating ports.conf beforehand, fetching a good number of distfiles in advance, and configuring ports before starting the massive build. I also told portmaster to ignore 3 ports (1 broken, 2 would most likely fail to build for one reason or another.) So, I started the build and left. Came back 7 hours later and portmaster had barely run an hour and was stuck waiting for input. What was so important? It wanted to know if it should go ahead an update the 3 ports that I had just explicitly told it not to upgrade 10 minutes before I started it (by using .IGNOREME files). First, you mean +IGNOREME files, just to be sure no one is confused. Second, without knowing what command line you used I couldn't tell you for sure what happened of course, but assuming you used some combination of '-af' what you saw was expected behavior. There is a conflict (I think a fairly obvious one) between the -f option and +IGNOREME. Since different users would have different ideas of how to resolve that conflict, portmaster takes the safe path and asks you. Well, it wasn't immediately obvious to me that someone would ever want to mark a port ignore and then want to upgrade it. So, it just seemed like a silly question to me (and still does to be honest, unless that's the behavior of portupgrade you're trying to match.) You only have to answer the question once, during the config phase. Once it starts building things you should not have any more prompts from portmaster. Looking at the man page I see that the dividing line between when to expect interaction and when not to is not as clear as it could be. I'll update that for the next version. No, that was clear enough. The behavior I saw was documented, I just didn't see the ambiguity in IGNOREME in advance so I didn't read the fine print until I was trying to figure out how my big plan went so wrong. Your code worked as documented. I just expected the presence of an IGNOREME file to always mean, the port will be ignored for all purposes. In any case, I find it highly unlikely that it ran for a full hour before prompting for the answer. On my system with over 500 ports installed the full run through the config phase takes just a little over 6 minutes. It might take you a little longer than that if you have a lot of OPTIONS dialogs to make choices on, but those would have been pretty obvious. I was just giving a guess at an hour. I wasn't here. :) That hour (out of the 7 I was gone) was supposed to mean that it didn't run for very long. My guess is that you literally started it and walked away. In the end, that has to be what happened. I spent 45 minutes going through several config runs of portmaster and/or configuring ports by hand. Once I knew I had everything configured, I launched it for the final time and left. So, it probably ran for 2 minutes, not an hour. I screwed that up and I also didn't prevent the recursive make config on the final run which sounded after the fact like it would've helped. But, besides that, the upgrade was painless. Everything built, installed, and works. Pretty amazing all things considered. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: visibility of release process
Ken Smith wrote: With the 7.0 release I tried giving just the URL of the primary site (ftp.freebsd.org) but that proved people don't just want easy - they're lazy. For the most part they just clicked on that and didn't look around for a mirror. Hence your observation about the difference in bandwidth when you're listed versus when you're not listed. Any idea if most of those ISO downloaders are really installing a fresh system or are just updating from a previous release by reinstalling? It seems to me many more people could be using freebsd-update(8) so the announcement really could focus on upgrades rather than fresh installs. I obviously like FreeBSD myself, but how many new users who need to download ISOs really come on board with each new release? The freebsd-update(8) portion of Updating existing systems could be the main focus of the announcement, and the Availability section and updating existing systems from source sections could just contain a link pointing to the web site since (I believe) the number of users needing those should be limited. No FTP listing in the announcement at all. I guess freebsd-update(8) currently has some limitations that make it not so cut-and-dry. But I'm a little confused anyway at this point as to what the long-term plans are. There's a CVS repo, SVN repo which appears to be the way things will be, a projects svn repo, a projects p4 repo, cvs(1) in base, csup(1) in base which is still being worked on even though there appears to be a slow migration to svn, svn(1) is in ports, there's no SVN repo for the ports tree but there is for src, freebsd-update(8) exists for binary upgrades which seems to be the way of the future for a huge majority of end-users, and yet the official mirrors are missing both the SVN src repo and binary update files. It seems to me the mirrors and release announcement are behind the times by pointing to source upgrades and ISO downloads, or maybe I'm just a little too early. I hope core has a plan for all of this. :) -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DVD-RW doesn't write
Greg Black wrote: On 2008-06-10, Joe Kelsey wrote: I have never managed to use burncd with any drive. Just for the record, I've been using burncd successfully with a variety of drives from the early days of FreeBSD through to at least 7.0-R, so I doubt if the above means very much. I certainly used to use burncd(8) to burn anything on any drive, but it hasn't worked for me for years now. Last I knew, it was known to be broken for 5.0 with a fix in the works at some point after that, but I've checked occasionally since then with different drives and it's still never worked. Using atapicam(4) with burning tools from ports always works. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2-STABLE = 7.0-STABLE Upgrade root partition more full
Gavin Spomer wrote: I successfully did my first FreeBSD upgrade yesterday after looking at the manual, and cross referencing with Googling and getting help from our network engineer here at CWU. Before the upgrade, running df showed: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a507630 7766238935817%/ devfs 1 1 0 100%/dev /dev/da0s1e507630 588466432 0%/tmp /dev/da0s1f 268217320 4866120 241893816 2%/usr /dev/da0s1d 4298926 162066 3792946 4%/var Now it shows: Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a507630 18483428218640%/ devfs 1 1 0 100%/dev /dev/da0s1e507630 426466594 0%/tmp /dev/da0s1f 268217320 5514844 241245092 2%/usr /dev/da0s1d 4298926 187570 3767442 5%/var Notice the the increase in the root partition. Should I have made this partition bigger when I first installed? Is there any cleaning up I can do after version upgrades? I would've thought /usr would be the one that grew more, but then again my /usr partition is fairly sizeable. Does 7.0 just take up a lot more of the root partition than 6.2? 7.0 installs debugging symbols for the kernel and modules by default. You can avoid that by defining INSTALL_NODEBUG during installkernel. If already installed, you can delete the symbol files without causing problems as long as you don't need to debug the kernel. Also, when you install a new kernel, the old kernel is saved as kernel.old so you now have 2 kernels in /boot instead of one. If you're positive the new kernel works fine, the old kernel can be removed as that's only used to recover from a new kernel with problems. But, your space really isn't that close to the limit, IMO. You appear to have enough space to have an old and new kernel installed both with symbols, so I'd leave it as is in case you need to debug something or boot the old kernel. You can always take care of it later if you're about to run out of space. Why do today what you can put off 'til tomorrow? Also, consider reading UPDATING before every upgrade. The entry for 20060118 covers this issue. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading to 7.0 - stupid requirements
Marko Lerota wrote: In http://www.freebsd.org/releases/7.0R/announce.html says Updating Existing Systems An upgrade of any existing system to FreeBSD 7.0-RELEASE constitutes a major version upgrade, so no matter which method you use to update an older system you should reinstall any ports you have installed on the machine. This will avoid binaries becoming linked to inconsistent sets of libraries when future port upgrades rebuild one port but not others that link to it. This can be done with: # portupgrade -faP etc... Why!!! If you never rebuild any ports at all after upgrading to a new major version, then your ports should all continue to work as long as they can find the old libraries they need. However, once you rebuild a port, it will link to new libraries, and may also link to other libraries that continue to be linked to the old libraries. You may end up with a binary being linked against libc.so.6 and libc.so.7, which will not work. Then the servers. Why should I reinstall all my databases and such? I always liked that FreeBSD base (OS) is separated from packages. And no matter what I do with the packages, my OS will always work. I don't want dependency hell like in Linux. Now you are telling me that my database might not work after upgrade to a new version. Is that it? Ports that depend on other ports are vulnerable to this problem. Ports that only require base libraries are not. The more ports a port depends on, the more likely you are to run into problems if you don't rebuild all ports to begin with. So, if you don't ever rebuild any of your ports at all, everything should still work until you finally do rebuild a port. At that point, if that port doesn't depend on other ports and only links to base libraries, you'll still be fine. Once you rebuild a port that depends on other ports, things may break if you don't force a rebuild of every port that port depends on. The paragraph you quoted above attempts to avoid that breakage and the mailing list questions that ensue, by forcing a rebuild of all ports to begin with. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7: GENERIC and options LOCK_PROFILING are breaking sockstat and netstat -a
Boris Samorodov wrote: The system updated a couple of hours ago (RELENG_7), the kernel config is GENERIC with options LOCK_PROFILING, default /etc/make.conf, i386 (I have this problem at current-amd64 as well): - bb% uname -a FreeBSD bb.ipt.ru 7.0-BETA4 FreeBSD 7.0-BETA4 #1: Mon Dec 10 10:12:24 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 bb% sockstat sockstat: struct xtcpcb size mismatch sockstat: struct xinpcb size mismatch sockstat: struct xunpcb size mismatch sockstat: struct xunpcb size mismatch USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS bb% netstat -a | head Active UNIX domain sockets Address Type Recv-Q Send-QInode Conn Refs Nextref Addr 0 #0 131073 0 ca5c6580000 0 #0 1 00 d36bda9000 0 #0 1 00 d2e1175000 0 #0 1 00 d36bdd0000 0 #0 1 00 d2e120d000 0 #0 1 00 d2e128f000 0 #0 1 00 d2e1282000 0 #0 262145 00 d2e12a9000 - Can somebody confirm? Is it a feature? Should I file a PR? That error occurs when your kernel and world are out of sync. You need to rebuild netstat(1) and sockstat(1) with LOCK_PROFILING defined to match your kernel, or rebuild your kernel without the option LOCK_PROFILING to match your world. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7: GENERIC and options LOCK_PROFILING are breaking sockstat and netstat -a
Boris Samorodov wrote: On Mon, 10 Dec 2007 06:22:01 -0500 Skip Ford wrote: Boris Samorodov wrote: The system updated a couple of hours ago (RELENG_7), the kernel config is GENERIC with options LOCK_PROFILING, default /etc/make.conf, i386 (I have this problem at current-amd64 as well): - bb% uname -a FreeBSD bb.ipt.ru 7.0-BETA4 FreeBSD 7.0-BETA4 #1: Mon Dec 10 10:12:24 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 bb% sockstat sockstat: struct xtcpcb size mismatch sockstat: struct xinpcb size mismatch sockstat: struct xunpcb size mismatch sockstat: struct xunpcb size mismatch USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS bb% netstat -a | head Active UNIX domain sockets Address Type Recv-Q Send-QInode Conn Refs Nextref Addr 0 #0 131073 0 ca5c6580000 0 #0 1 00 d36bda9000 0 #0 1 00 d2e1175000 0 #0 1 00 d36bdd0000 0 #0 1 00 d2e120d000 0 #0 1 00 d2e128f000 0 #0 1 00 d2e1282000 0 #0 262145 00 d2e12a9000 That error occurs when your kernel and world are out of sync. You need to rebuild netstat(1) and sockstat(1) with LOCK_PROFILING defined to match your kernel, or rebuild your kernel without the option LOCK_PROFILING to match your world. Ah, that's it! The world is also affected by this option. It's not clear from LOCK_PROFILING(9): - NOTES The LOCK_PROFILING option increases the size of struct lock_object, so a kernel built with that option will not work with modules built without it. - I've read it as if only kernel (i.e. modules) should be at sync... I think the reason it doesn't go into detail about userland tools is because a LOCK_PROFILING kernel is expected to be booted and run for very brief periods of time to test, and during that testing sockstat(1) and netstat(1) probably aren't needed. So, the man page just assumes one will have broken userland utilities while the ABI is temporarily broken. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3 PRERELEASE
Jon Holstrom wrote: I had 6.2 stable all setup had gnome 2.18 all humming along 100% java eclipse, tomcat, bah bah bah! updated src rebuilt only to find 6.2 is gone 6.3 prerelease! ( I think there should be a button we need to push to get software we DONT want! j/k) with my setup as it is, can i back date my cvsup file rebuild back to 6.2 stable not losing any settings or software ? If you go back to 6.2-STABLE, you'll be left with a system that can never be updated again since 6.2-STABLE no longer exists. Any time you updated it, the name would change again which you seem to have a problem with. If you keep following RELENG_6, you'll end up running 6.3-STABLE after the release. Or, you could choose to run 6.2-RELEASE (RELENG_6_2) or 6.3-RELEASE (RELENG_6_3) after it's released. For right now, there's really no difference between 6.2-STABLE and 6.3-PRERELEASE. If you do nothing, you'll eventually be running 6.3-STABLE. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOCK_PROFILING in -stable
Robert Watson wrote: On Sat, 20 Oct 2007, Alfred Perlstein wrote: This is my feeling also -- I would consider ABI breakage a show stopper for 6.x, but feel otherwise that the new code is much more mature and capable and would be quite beneficial to people building appliances and related products on 6.x. You might check with Attilio about whether there are any remaining outstanding issues that need to be resolved first, and make sure to send a heads up out on stable@ and put a note in UPDATING that the option and details have changed. I still get confused as to the meaning of this... It only breaks ABI when it's enabled. I think that is OK, right? As we're eliminating MUTEX_PROFILING and replacing it with LOCK_PROFILING, I think it is OK that the ABI for one differs from the other as long as the base kernel ABI remains static. I.e., this seems OK to me also. If -stable will have LOCK_PROFILING, it'd be really nice to have it compatible with a standard world in some way, even if just with a makefile hack that builds netstat_lp(1) in addition to netstat(1) (and other utilities.) One can easily boot a diskless email, web, or name server into kernels with other debug-type options without maintaining multiple worlds. One might want to run a LOCK_PROFILING stable kernel on a diskless email server for a period of time, but that will require either a matching world, or putting up with breakage for that period of time, neither of which is a fair expectation in a stable environment, IMO. I can maintain local makefile hacks for production if somebody with some makefile foo gets me started. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
Doug Barton wrote: In an effort to find some kind of balance (I won't even try to say consensus) between those who hate the idea of slaving the root zones, those who like the idea but don't want it to be the default, and those who like the idea, I've made the following change: 1. Change the default behavior back to using a hint zone for the root. 2. Leave the root slave zone config as a commented out example. 3. Remove the B and F root servers from the example at the request of their operators. I hope that we can now dial down the volume on the meta-issue of how the change was done, and focus on the operational issues of whether it's a good idea or not. Thanks. I'm afraid the consensus has to come from the operators, not from FreeBSD folks. If the operators were required to support it, I think everyone should slave the roots, not just those running busy servers. Just like I'd think everyone should sync with stratum-1 servers if those operators supported everyone doing that. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
Doug Barton wrote: Skip Ford wrote: Just like I'd think everyone should sync with stratum-1 servers if those operators supported everyone doing that. I've already pointed out that this is a silly analogy, as the two things have nothing in common. At the most basic level: Individual hosts don't need Everyone needs the root data to sync with a strat 1 ntpd The strat 1 folks have asked The roots are open to all by design people not to do that It really is an apt analogy. You don't see it because you believe the roots are open to all. If they really were open to all, there would've been no objections to your change. The methods by which the data made available by the roots is available to all is well-defined, and AXFR isn't included in that definition. In fact, it's recommended against. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Randy Bush wrote: the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). did i miss the discussion here? No. There was none. i have spent some hours turning off the default bind and going custom on a dozen or so machines around the planet. i am not happy. what am i missing here? I don't have an axe to grind. I don't run the default config on any of my 2 dozen name servers (not all of which run bind anyway) so I wasn't really affected by the change. However, I thought it was a really, really, terrible idea, and a rather rude act considering it relies on the charity of others to not break. There is no requirement that FreeBSD users be permitted to slave the roots. Everyone who uses the default config can have their setups broken the day after installation. We never asked permission to use the resources of others in this way, and they're not required to allow us to do so. It's rude to assume they'll allow it, and it's risky to not receive permission beforehand to ensure slaving the roots will continue to work after RELEASE. The original commit message for the change indicated it was done to bring us in line with current best practices but that commit message is the only place I have ever seen anyone say that slaving the roots is current best practice. Again, I don't have an axe to grind and I really don't want to get in the middle of a personal attack. I don't think the world will explode, and in reality, there will probably be no problems at all, but if there aren't, it's because of pure luck not good planning or decision making. Microsoft makes much worse assumptions about the availability of the resources of others, but this is a Microsoft-ish decision, IMO. Just not a good plan. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Doug Barton wrote: If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, If that's a shot at me, you're out of line. I specifically said I didn't have an axe to grind with anyone, and I never piled on in my comments. The reason I provided *is* purely technical. The roots can decide tomorrow to block AXFR requests from FreeBSD users who install 6.3-RELEASE or 7.0-RELEASE. They may. They may not. But they can. It's not a production feature and therefore should not be relied upon. If the operators state they will support AXFR for the life of those releases, I have no objections. Such a statement would indicate all at once that they don't mind the traffic and that such a config will not break. I haven't kept up-to-date with cached(8) but if we're able to cache lookups now without a name server, we don't even need BIND in the base system anymore IMO. We still have very well maintained ports. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Doug Barton wrote: Skip Ford wrote: The reason I provided *is* purely technical. The roots can decide tomorrow to block AXFR requests from FreeBSD users who install 6.3-RELEASE or 7.0-RELEASE. They may. They may not. But they can. Here is where the problem lies. What you're saying here is simply not true. I know several of the root operators personally, and in my previous position as GM of IANA I worked with them directly both individually and collectively. Everything involving a change to a root server is done at a near-glacial pace. There no more danger that we will wake up tomorrow unable to AXFR the root from any server than there is that we'll wake up tomorrow not able to send resolver queries to any root server. To say that this IS possible is FUD. So, it seems simple enough then if what you're saying is true. Have your friends running the roots state that they will support our AXFRs. I will have no objections once they do that. It's a randomly provided service already. Not all of them answer AXFR now, so how many of them will 2 years from now is a legitimate question, and is my only concern. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Mark Andrews wrote: I don't think that all of the drama could have been avoided in any case, there is too much emotion surrounding this issue. I'll concur with Doug on this. I've been discussing doing just this for the last 10+ years. Why don't you update 2870 then to make it so? If all the roots provided it and were required to, there's no problem. But current best practice as defined by 2870 are for roots to only answer AXFRs from other roots. How can you advocate an OS pushing a configuration that isn't guaranteed to be functional? I understand the odds of it breaking, and I understand the benefits. That's not the issue. This is a configuration that should be guaranteed to work for 2 years after every OS release that includes it. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Mark Andrews wrote: I don't think that all of the drama could have been avoided in any case, there is too much emotion surrounding this issue. I'll concur with Doug on this. I've been discussing doing just this for the last 10+ years. Why don't you update 2870 then to make it so? Why don't you? You seem to be the one worried about it :-) I just figured you'd be able to snap your fingers, click your heels, and be done with it. I want to get draft-ietf-dnsop-default-local-zones through first before dealing with the issue of how to get every iterative resolver serving the root. FWIW, I reviewed your draft back in March and had no objections. :-) If all the roots provided it and were required to, there's no problem. But current best practice as defined by 2870 are for roots to only answer AXFRs from other roots. How can you advocate an OS pushing a configuration that isn't guaranteed to be functional? I understand the odds of it breaking, and I understand the benefits. That's not the issue. There is a difference between saying we should do this and just doing it. Part of process is to get consenus that this is reasonable or at least won't hurt and working what needs to be changed to make it happen. Ah, sorry for putting words in your mouth then. Now I understand, and I agree. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
