Re: Results of BIND RFC
On 02.04.2010 9:24, Stanislav Sedov wrote: While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? Hi, All. I'm agree with Stas. If it is not so hard to maintain bind-tools in the base, It is very useful to still having them in base system. -- WBR, Andrey V. Elsukov ___ 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: Results of BIND RFC
While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? i don't mind if dig, doc, et alia are not in base, as long as they are a separate port from the bind hippo. randy ___ 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: Results of BIND RFC
On Fri, 02 Apr 2010 17:26:13 +0900 Randy Bush ra...@psg.com mentioned: i don't mind if dig, doc, et alia are not in base, as long as they are a separate port from the bind hippo. The major benefit of having them in the base is the ability to cross-compile them when building the distribution for another platform. Ports doesn't support cross-compilation yet, and it would be a pity to find yourself bootstrapping another tiny arm platform and having to use ports to have a usable system. -- Stanislav Sedov ST4096-RIPE ___ 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: Results of BIND RFC
In message 20100402013353.f544e8ad.s...@freebsd.org, Stanislav Sedov writes: On Fri, 02 Apr 2010 17:26:13 +0900 Randy Bush ra...@psg.com mentioned: Ports doesn't support cross-compilation yet, and it would be a pity to find yourself bootstrapping another tiny arm platform and having to use ports to have a usable system. The result of the RFC was that bind is not a mandatory component to make a usable system, so you argument suffers from bad logic. The fact that you want BIND on your arm, is no different from somebody else wanting postfix on a MIPS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Results of BIND RFC
On Fri, 02 Apr 2010 08:55:07 + Poul-Henning Kamp p...@phk.freebsd.dk mentioned: In message 20100402013353.f544e8ad.s...@freebsd.org, Stanislav Sedov writes: On Fri, 02 Apr 2010 17:26:13 +0900 Randy Bush ra...@psg.com mentioned: Ports doesn't support cross-compilation yet, and it would be a pity to find yourself bootstrapping another tiny arm platform and having to use ports to have a usable system. The result of the RFC was that bind is not a mandatory component to make a usable system, so you argument suffers from bad logic. The fact that you want BIND on your arm, is no different from somebody else wanting postfix on a MIPS. Sorry, I think I was not clear enough. What I actually want is to have a couple of the important tools in the base while moving everything also in ports. By important tools I mean nslookup (and maybe dig), and at least the first one is cruicial for the system bringup. That one is also nice to have on the livecd, which currently includes (I believe) only the base system. -- Stanislav Sedov ST4096-RIPE ___ 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: Results of BIND RFC
In message 20100402021715.669838e0.s...@freebsd.org, Stanislav Sedov writes: On Fri, 02 Apr 2010 08:55:07 + Poul-Henning Kamp p...@phk.freebsd.dk mentioned: Sorry, I think I was not clear enough. Sorry for misunderstanding. Yes, the case can certainly be made that DNS query tool belongs in the base system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Results of BIND RFC
On Fri, Apr 02, 2010 at 09:24:51AM +, Poul-Henning Kamp wrote: In message 20100402021715.669838e0.s...@freebsd.org, Stanislav Sedov writes: On Fri, 02 Apr 2010 08:55:07 + Poul-Henning Kamp p...@phk.freebsd.dk mentioned: Sorry, I think I was not clear enough. Sorry for misunderstanding. Yes, the case can certainly be made that DNS query tool belongs in the base system. I disagree (so what else is new?) It should be kept out of the base system. KISS: Doug pulling BIND out of the base system / going ports-only = excellent. Doug making a separate port for BIND-esque DNS query/maintenance tools = excellent. Both of the above can be made into packages. Vendors who use FreeBSD can incorporate said package(s) into their build infrastructure. Folks who do not have Internet connections (yet for some reason want said DNS tools) can install the package(s) from CD/DVD/USB. I want the bikeshed to be black. :-) [1]: FreeBSD really needs to move away from the base system as a concept, as I've ranted about in the past. Or if it cannot, the base system needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32. Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Results of BIND RFC
[1]: FreeBSD really needs to move away from the base system as a concept, as I've ranted about in the past. Strongly disagree. Or if it cannot, the base system needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32. Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. So please don't destroy this. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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: Results of BIND RFC
On 02.04.2010 12:28, sth...@nethelp.no wrote: [1]: FreeBSD really needs to move away from the base system as a concept, as I've ranted about in the past. Strongly disagree. Or if it cannot, the base system needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32. Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. So please don't destroy this. With the risk of sounding like a me-too-ist: me too! I can see the point some have in wanting to run a version from ports over running the base system one. This is doable in the current setup. However the bundled versions of bind (and the other base system packages) are rock stable and there for a reason. Following the I want this slimmed down and moved to the ports/packages section, further, you could argue that ls, dd, and basically most of /usr/bin could go the same way. Giving FreeBSD the same distribution nightmare that some of the ... other unix-like os'es have. Is this really where the users of the OS want it to go? We'll end up spending more time updating tidbits of the system now moved to packages, than actually using it. But why stop there? We could do the same to the src/sys/dev subdirectories as well... Let's not do that, please? //Svein -- +---+--- /\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. Picture Gallery: https://gallery.stillbilde.net/v/svein/ signature.asc Description: OpenPGP digital signature
Re: Results of BIND RFC
On Fri, 2 Apr 2010, Poul-Henning Kamp wrote: The result of the RFC was that bind is not a mandatory component to make a usable system, so you argument suffers from bad logic. With an eye on the date of Doug's suggestive e-mail, I actually am concerned that we maintain support for DNSSEC validation in the base system. If this can be accomplished by keeping DNS debugging tools and the lightweight resolver in the base, then I'm fine with that world view. However, if we can't do DNSSEC record validation without installing the BIND package, then that worries me. As we go forward, DNSSEC is going to become increasingly important, and being unable to bootstrap a system will be a problem, and it will become an increasingly critical part of the security bootstrap process for networked systems. While some DNSSEC folk consider it anathema (DNS is not a directory service!), the ability to securely distribute keying material via an existing network service has enourmous value: for example, early DNSSEC prototypes in the late 1990's/early 2000's included SSH key distribution via cert records in DNSSEC. Similarly, as proposals to tie DHCP security and mobility security to DNSSEC expand, any decision to require a package to do DNSSEC would mean any component depending on that also has to be outside our base. If all requirements along these lines are met by the lightweight resolver, then this is less of a concern. Robert ___ 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: Results of BIND RFC
On Fri, Apr 02, 2010 at 03:14:54AM -0700, Jeremy Chadwick wrote: [1]: FreeBSD really needs to move away from the base system as a concept, as I've ranted about in the past. Or if it cannot, the base system needs to start using pkg_* (somehow) No, it does not need to do that. It might be a good idea (but I am far from convinced of it), but there most certainly is no *need* to move in that direction. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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: Results of BIND RFC
Strongly disagree. Or if it cannot, the base system needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32. Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. me +1 If I wanted to go Gnu/BSD (or Loonix) route, I'd already installed either thank you. Funny though that BIND which is pretty straightforward as configuration goes and as much essential system component as Sendmail is getting the axe. I thought one of the main philosophies in FreeBSD always was being a system in itself, rather than kernel with some haphazardly thrown in components added. -Reko ___ 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: Results of BIND RFC
On Fri, Apr 02, 2010 at 10:11:50AM +0400, Andrey V. Elsukov wrote: On 02.04.2010 9:24, Stanislav Sedov wrote: While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? Hi, All. I'm agree with Stas. If it is not so hard to maintain bind-tools in the base, It is very useful to still having them in base system. +1 here. Dig and some of the other tools are extremely useful and important, so it would be nice if they were in the base system instead of a separate port. -- Denny Lin ___ 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: panic during work with jailed postgresql8.4
On Thu, 1 Apr 2010, Oleg Lomaka wrote: Hi, I have a kernel panic when connect to postgresql8.4 server installed in one of jails from another jail. It's 100% reproducible. Also I have tried to connect from host machine to jailed pg server. That way it works fine without crash. Server configuration uses geli and zfs. Four disks encrypted using geli. And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli providers. All jails located at this raidz2 pool. Also I use ezjail for jails management. And it uses NFS to mount directories with base system. atal double fault rip = 0x8063510a rsp = 0xff80eaec5f50 rbp = 0xff80eaec6040 cpuid = 1; apic id = 02 panic: double fault cpuid = 1 Uptime: 7m11s Physical memory: 8169 MB uname -a FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 r...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 Link to dmesg.boot: http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZlhl=en Link to kernel core backtrace: http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRwhl=en Can I help to spot this trouble by providing additional info? Looking at the info I doubt it's related to jails or Pg in first place. Have you been running that same setup already before your Apr 1st, r206031, kernel? If so, from when was your last kernel? /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: Results of BIND RFC
On Fri, Apr 02, 2010 at 12:44:55PM +0200, Svein Skogen (Listmail Account) wrote: On 02.04.2010 12:28, sth...@nethelp.no wrote: [1]: FreeBSD really needs to move away from the base system as a concept, as I've ranted about in the past. Strongly disagree. Or if it cannot, the base system needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32. Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. So please don't destroy this. With the risk of sounding like a me-too-ist: me too! Since I made a bikeshed reference I don't want to continue arguing my point -- I've said my piece, and that's that. But I'm just one man, with one opinion (that IS in fact shared by others), but I hold high respect for others' views despite being different from my own. However, I want to make some things perfectly clear, because there's some misconceptions (IMHO), addressed below. I won't respond to this thread past this point. I can see the point some have in wanting to run a version from ports over running the base system one. This is doable in the current setup. However the bundled versions of bind (and the other base system packages) are rock stable and there for a reason. 1) In most scenarios (historically speaking), what gets updated quicker: base or ports? Answer: ports. For **security issues only**, the base system gets updated quickly. Of course, in some cases (depending on the software), this requires an **entire world rebuild**. Why not just rebuild only what's dependent upon what got fixed? OpenSSL security hole fixed, gotta rebuild uh, world? Yes, there are sometimes exceptions to this rule, but depending upon what the software is, world is usually what you have to resort to. 2) What has proper infrastructure for dependencies and tracking of installed files as part of a software package? Answer: ports. The base system has src/ObsoluteFiles.inc which has been stated *by developers* as being regularly neglected and is a hack, not fully effective. This is what make delete-old and make delete-old-libs uses, and where WITHOUT_xxx comes into play. Ponder this for a while. 3) How often do you see people posting problems with key pieces of FreeBSD infrastructure (device support/reliability or storage-related subsystems), followed by a response from a developer stating this has been fixed in -STABLE or can you try the code from HEAD? Answer: often. What all this means: change is happening much more rapidly than in the past. The days of I installed FreeBSD on a box and didn't touch it for 60,000 years are long gone -- assuming you care about true reliability and security. Following the I want this slimmed down and moved to the ports/packages section, further, you could argue that ls, dd, and basically most of /usr/bin could go the same way. Yes, and it should be, IMHO. Have you ever looked in src/contrib? A lot of FreeBSD's software these days -- the stuff you've come to rely upon -- is in src/contrib. Let me know if you don't use any of the software in there. :-) Giving FreeBSD the same distribution nightmare that some of the ... other unix-like os'es have. Is this really where the users of the OS want it to go? We'll end up spending more time updating tidbits of the system now moved to packages, than actually using it. Nothing *forces* you to update a package/port. If you want to run some old crusty version of some software (maybe there's legitimate reason for it, maybe the newer stuff is buggy), you can do this with ports. You could do this with the base system being package-ised or port-ised like I describe as well. But you cannot easily do this with the base -- the instant you csup to update base (for something else), you've now updated everything. And it's been stated many times by developers that your supfiles should use src-all and NOT select src-xxx pieces -- because world/kernel WILL break during build. To this day there are still I tried to build world but it didn't work Show us your supfile random src-xxx stuff removed which the user felt they didn't need reports coming in. But why stop there? We could do the same to the src/sys/dev subdirectories as well... That probably should happen too, *especially* for the networking and storage subsystems, which are being constantly updated to fix bugs. Not just improvements, but downright bugs.
Re: panic during work with jailed postgresql8.4
On Apr 2, 2010, at 3:02 PM, Bjoern A. Zeeb wrote: On Thu, 1 Apr 2010, Oleg Lomaka wrote: I have a kernel panic when connect to postgresql8.4 server installed in one of jails from another jail. It's 100% reproducible. Also I have tried to connect from host machine to jailed pg server. That way it works fine without crash. Server configuration uses geli and zfs. Four disks encrypted using geli. And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli providers. All jails located at this raidz2 pool. Also I use ezjail for jails management. And it uses NFS to mount directories with base system. atal double fault rip = 0x8063510a rsp = 0xff80eaec5f50 rbp = 0xff80eaec6040 cpuid = 1; apic id = 02 panic: double fault cpuid = 1 Uptime: 7m11s Physical memory: 8169 MB uname -a FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 r...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 Link to dmesg.boot: http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZlhl=en Link to kernel core backtrace: http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRwhl=en Can I help to spot this trouble by providing additional info? Looking at the info I doubt it's related to jails or Pg in first place. Have you been running that same setup already before your Apr 1st, r206031, kernel? If so, from when was your last kernel? Yes, this configuration works on another server fine (8.0-STABLE FreeBSD 8.0-STABLE #3 r205202) Made few more tests. All tests I make using psql command (as it is 100% reproducible, may be now try spot it using telnet/netcat, without involving pg). psql accomplish login operation fine, panic appears after i run any command like \d, so I think it depends on packet size. Current picture is: 1. When connect from host machine - works fine. 2. When I connect from other server - works fine. 3. When connect from another jail on the same box as db's jail (tried from few jails) - kernel fault. Also tried security.jail.allow_raw_sockets on/off - nothing changes. ___ 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: Results of BIND RFC
On Fri, Apr 02, 2010 at 12:28:36PM +0200, sth...@nethelp.no wrote: [1]: FreeBSD really needs to move away from the base system as a concept, as I've ranted about in the past. Strongly disagree. I'm with you! Or if it cannot, the base system needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32. Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. Also, more than that, won't splitting the base system in many smaller pieces moving around by themselves make every single part of freeBSD a moving target? What I mean is that what may look like a way to simplify things could make matters worse with incompatibilities in between the base packages. having everythign in the base system guarantees much more control. I'm also thinking about the nightmares this kind of splitting could cause to release engineering. This is not pure speculation. Such problems do appear in many other known open source OSes with such a split base system. In fact, if I wanted such a thing I'd install that other open source OS. I did in fact, and observed many annoying things about not having a rich base system like ours(like wasting time figuring which packet contained commands I'm used to see in the base system on any unix. So please don't destroy this. I hope not. Another good reason not to destroy this is again that there are already many alternative OSes doing it, and I think FreebSD has a strong point in being different, not a weak spot. -- Guido Falsi m...@madpilot.net ___ 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: panic during work with jailed postgresql8.4
On Fri, 2 Apr 2010, Oleg Lomaka wrote: Hey, uname -a FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 r...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 Link to dmesg.boot: http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZlhl=en Link to kernel core backtrace: http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRwhl=en Can I help to spot this trouble by providing additional info? Looking at the info I doubt it's related to jails or Pg in first place. Have you been running that same setup already before your Apr 1st, r206031, kernel? If so, from when was your last kernel? Yes, this configuration works on another server fine (8.0-STABLE FreeBSD 8.0-STABLE #3 r205202) Made few more tests. All tests I make using psql command (as it is 100% reproducible, may be now try spot it using telnet/netcat, without involving pg). psql accomplish login operation fine, panic appears after i run any command like \d, so I think it depends on packet size. Current picture is: 1. When connect from host machine - works fine. 2. When I connect from other server - works fine. 3. When connect from another jail on the same box as db's jail (tried from few jails) - kernel fault. Also tried security.jail.allow_raw_sockets on/off - nothing changes. In addition to the private mail I have just sent you, the first thing you might try it to updat again; I hadn't realized before that your r206031 seems to be in the middle of a multi-commit merge from two people. It would be worth to update to the latest stable/8 and try again first. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ 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: panic during work with jailed postgresql8.4
On Apr 2, 2010, at 4:12 PM, Bjoern A. Zeeb wrote: On Fri, 2 Apr 2010, Oleg Lomaka wrote: uname -a FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 r...@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 Link to dmesg.boot: http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZlhl=en Link to kernel core backtrace: http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRwhl=en Can I help to spot this trouble by providing additional info? Looking at the info I doubt it's related to jails or Pg in first place. Have you been running that same setup already before your Apr 1st, r206031, kernel? If so, from when was your last kernel? Yes, this configuration works on another server fine (8.0-STABLE FreeBSD 8.0-STABLE #3 r205202) Made few more tests. All tests I make using psql command (as it is 100% reproducible, may be now try spot it using telnet/netcat, without involving pg). psql accomplish login operation fine, panic appears after i run any command like \d, so I think it depends on packet size. Current picture is: 1. When connect from host machine - works fine. 2. When I connect from other server - works fine. 3. When connect from another jail on the same box as db's jail (tried from few jails) - kernel fault. Also tried security.jail.allow_raw_sockets on/off - nothing changes. In addition to the private mail I have just sent you, the first thing you might try it to updat again; I hadn't realized before that your r206031 seems to be in the middle of a multi-commit merge from two people. It would be worth to update to the latest stable/8 and try again first. That's it. r206088 works fine. Thank you for help. ___ 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: Results of BIND RFC
Date: Fri, 2 Apr 2010 03:14:54 -0700 From: Jeremy Chadwick free...@jdc.parodius.com Sender: owner-freebsd-sta...@freebsd.org On Fri, Apr 02, 2010 at 09:24:51AM +, Poul-Henning Kamp wrote: In message 20100402021715.669838e0.s...@freebsd.org, Stanislav Sedov writes: On Fri, 02 Apr 2010 08:55:07 + Poul-Henning Kamp p...@phk.freebsd.dk mentioned: Sorry, I think I was not clear enough. Sorry for misunderstanding. Yes, the case can certainly be made that DNS query tool belongs in the base system. I disagree (so what else is new?) It should be kept out of the base system. KISS: Doug pulling BIND out of the base system / going ports-only = excellent. Doug making a separate port for BIND-esque DNS query/maintenance tools = excellent. Both of the above can be made into packages. Vendors who use FreeBSD can incorporate said package(s) into their build infrastructure. Folks who do not have Internet connections (yet for some reason want said DNS tools) can install the package(s) from CD/DVD/USB. I want the bikeshed to be black. :-) I have very mixed feelings on this. I agree with arguments I have seen on both sides. I like being able to install FreeBSD and have a well integrated system with all of the basic tools installed for basic use. Things play together well. I don't use many of the base system tools. I use cups, postfix, customized ssh, and the ports version of BIND. I don't build the stuff I don't need (src.conf) and I don't mind them being there. On the other hand, for complex, heavy duty ports, keeping up to date with externally maintains tools (contrib) is a pain and the base system can get stuck with rather out of date tools as a result. (Remember perl?) Unless there is very strong support for a contributed tools, it's hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, it's still hopeless. I have seen suggestions that some tools be kept in the base system. nslookup (an evil tool that I think should be put out of its misery) and dig (a good tool that not enough people understand how to use) have been explicitly mentioned. The problem is that dig needs to be in reasonable feature sync with the resolver or it can have problems. Finally, what about a stub resolver? This really MUST be in the base system and, it should understand DNSSEC soon, which just complicates things. I prefer my bikeshed in green. Black is too goth and too hot for my tastes. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: Results of BIND RFC
Based on the inspection of the source tree, I want my bikeshed mauve. I've not been had by AFD jokes in a while but Doug pulled this one off... -Reko ___ 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: Results of BIND RFC
On 2 April 2010, at 04:27, Denny Lin wrote: On Fri, Apr 02, 2010 at 10:11:50AM +0400, Andrey V. Elsukov wrote: On 02.04.2010 9:24, Stanislav Sedov wrote: While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? Hi, All. I'm agree with Stas. If it is not so hard to maintain bind-tools in the base, It is very useful to still having them in base system. +1 here. Dig and some of the other tools are extremely useful and important, so it would be nice if they were in the base system instead of a separate port. The reason dig and nslookup are used is because you have a problem with the internet connection. Thats a bit late to say you need to install the DNS tools. If you could, you wouldn't need them. Not everyone will create a ports CD. ___ 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: Results of BIND RFC
Can we do sendmail next April 1? Sent from a device with a tiny keyboard On Apr 2, 2010, at 1:22 PM, Reko Turja reko.tu...@liukuma.net wrote: Based on the inspection of the source tree, I want my bikeshed mauve. I've not been had by AFD jokes in a while but Doug pulled this one off... -Reko ___ 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 ___ 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: Results of BIND RFC
On Fri, 2 Apr 2010, Kevin Oberman wrote: Date: Fri, 2 Apr 2010 03:14:54 -0700 From: Jeremy Chadwick free...@jdc.parodius.com Sender: owner-freebsd-sta...@freebsd.org I disagree (so what else is new?) It should be kept out of the base system. KISS: Doug pulling BIND out of the base system / going ports-only = excellent. Doug making a separate port for BIND-esque DNS query/maintenance tools = excellent. Both of the above can be made into packages. Vendors who use FreeBSD can incorporate said package(s) into their build infrastructure. Folks who do not have Internet connections (yet for some reason want said DNS tools) can install the package(s) from CD/DVD/USB. I want the bikeshed to be black. :-) I have very mixed feelings on this. I agree with arguments I have seen on both sides. I like being able to install FreeBSD and have a well integrated system with all of the basic tools installed for basic use. Things play together well. I don't use many of the base system tools. I use cups, postfix, customized ssh, and the ports version of BIND. I don't build the stuff I don't need (src.conf) and I don't mind them being there. On the other hand, for complex, heavy duty ports, keeping up to date with externally maintains tools (contrib) is a pain and the base system can get stuck with rather out of date tools as a result. (Remember perl?) Unless there is very strong support for a contributed tools, it's hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, it's still hopeless. I really dread having to update my ports. I hate all the bloated dependencies that a lot of ports have. It's sometimes a hit or miss situtation; you never know whether your ports are going to build (update) fully or not. And it takes forever. Our ports team does a fantastic job, so no diss intended. But I am concerned about moving BIND into ports, even if there is a tools-only port. With BIND in base, I don't have to worry about updating or when to update - someone else decides when to update/patch the base BIND and I am happy with that. All I have to do is buildworld, which I do much more often than update ports. If there is already a WITHOUT_BIND knob, then I really don't see what advantage there is in moving BIND out of base. Anyone that wants to use a different resolver can already do that, with the only limitation that they have to buildworld to remove the base bind. -- DE ___ 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: Results of BIND RFC
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 So first of all, yes Virginia, this was an April Fool's Day joke. To both those for whom this post created a false sense of despair, and (perhaps more importantly) to those for whom it created a false sense of joy, my apologies. :) And for the record, everything from here on is just the facts. I have always said that I will remove BIND from the base when there is clear community consensus to do so, and I stand by that. However the discussion always seems to go along the lines that this thread did. A vocal group who say, YES! and then a lot of people who want the resolution tools (dig, host, nslookup) to stay, and the other end of the bell-shaped curve with those who like having the whole thing in the base. Toss in a few choruses of The whole base should be more modular, (a viewpoint with which I have a great deal of sympathy btw) and the soup is pretty well complete. In regard to the tools issue, the problem is that you need a pretty good majority of the code in order to build them. They require the libraries to be built, and once you've done that, you might as well do the rest. :) Total size of code in: contrib/bind9: 14.0M contrib/bind9/lib: 7.6M contrib/bind9/bin: 2.5M contrib/bind9/bin/dig: 0.4M The last is the directory that has the code for all 3 resolution tools, FYI. Therefore I think that the status quo of having it all in there, and knobs to turn off the bits you don't want is a good one since it seems to please the majority of our users. I will continue to maintain the bind-tools port though, that's something that's been requested often, and I think it's a good thing to have for those who want a different DNS solution but still want access to those tools in a fairly painless manner. And of course the ability to easily change/upgrade/manage what version of BIND you use via the ports will continue to be a key component of how we deal with this going forward. Of course, the release synchronization problems I described in both the original post and the AFD post are real, so stay tuned. :) Answers to DNSSEC concerns below. On 4/2/2010 3:52 AM, Robert Watson wrote: With an eye on the date of Doug's suggestive e-mail, I actually am concerned that we maintain support for DNSSEC validation in the base system. If this can be accomplished by keeping DNS debugging tools and the lightweight resolver in the base, then I'm fine with that world view. However, if we can't do DNSSEC record validation without installing the BIND package, then that worries me. Unfortunately this answer is more complicated than I'd like it to be. In general, DNS resolution requires 4 components (and yes, this is pretty well simplified, but I think the illustration serves to clarify my point): 1. An end-user application that makes a request 2. A stub resolver located on the local system 3. A resolving name server 4. An authoritative name server At this time the DNSSEC protocol only clearly addresses the behavior of 4, and partially addresses the behavior of 3. There is no protocol specification for 1 or 2. So in general if you want to be able to validate DNSSEC signatures on the local system the only option available to you is to run a local validating resolver. It doesn't have to be BIND, unbound is also a good candidate, but you have to run something locally to be sure that the response(s) you've received are valid. Now that said, if you have a special purpose in mind to validate records in a specific domain (or specific few domains) for which you are prepared to individually manage trust anchors (the generic term of art for DNSSEC keys) then you could do that using dig alone. However that solution would not scale well, and I wouldn't recommend it for a critical piece of the base or ports. As we go forward, DNSSEC is going to become increasingly important, and being unable to bootstrap a system will be a problem, and it will become an increasingly critical part of the security bootstrap process for networked systems. Since your description above is generic, I will generically agree with you. :) I think as time goes on and more intelligence about DNSSEC is pushed to the edges I think it will be possible to have a validating stub resolver, and on a trusted network reasonable to rely on an external validating resolving name server. However there's an awful lot of supposition there, and as I said above, the spec doesn't even exist yet, never mind the code. While some DNSSEC folk consider it anathema (DNS is not a directory service!), the ability to securely distribute keying material via an existing network service has enourmous value: for example, early DNSSEC prototypes in the late 1990's/early 2000's included SSH key distribution via cert records in DNSSEC. The CERT record still exists, although not for ssh. See http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the SSHFP record,
Re: 6.4-RELEASE missing from mirrors
On Thu, 2010-04-01 at 11:07 -0400, David Boyd wrote: The link (actually file) called 6.4 moved to ftp-archive is missing from most/all mirrors. We have been using these files to follow the releases when they move. It works as long as the 6.4 moved to ftp-archive file is present. Please help. Thanks. ___ 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 Sorry about that, it should be fixed on ftp-master now and will propagate out to the mirrors as they do their next sync. -- Ken Smith - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: Results of BIND RFC
On Fri, Apr 2, 2010 at 3:14 AM, Jeremy Chadwick free...@jdc.parodius.comwrote: [1]: FreeBSD really needs to move away from the base system as a concept, as I've ranted about in the past. Or if it cannot, the base system needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32. Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. Maybe I'm just a lowly sysadmin and ex-port maintainer, but ... No, no, no, definitely no, no, and no!! The greatest thing about FreeBSD is that there is a clear separation between the base OS and everything else (ports, local installs, etc). You get a nice, clearly defined, base to build on. You get a stable base that changes infrequently, that you can add software to on whatever schedule you want. The worst thing about Linux distros is the lack of this clear separation between the base and third-party apps. If you want to install an updated version of Apache, you either have to update the whole damned distro, go searching for some unsupported backports repos, or compile everything by hand defeating the whole point of binary packages. Making the tools do deal with the base could be interesting, but please, please, please don't shove everything into the pkg_tools and turning FreeBSD into just a random collection of packages that kind of work together. IOW, don't go down the distro path. Keep the base OS separate from third-party apps. Keep the tools to deal with them separate. -- Freddie Cash fjwc...@gmail.com ___ 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: Results of BIND RFC
On Fri, Apr 2, 2010 at 3:08 PM, Freddie Cash fjwc...@gmail.com wrote: Maybe I'm just a lowly sysadmin and ex-port maintainer, but ... No, no, no, definitely no, no, and no!! The greatest thing about FreeBSD is that there is a clear separation between the base OS and everything else (ports, local installs, etc). You get a nice, clearly defined, base to build on. You get a stable base that changes infrequently, that you can add software to on whatever schedule you want. The worst thing about Linux distros is the lack of this clear separation between the base and third-party apps. If you want to install an updated version of Apache, you either have to update the whole damned distro, go searching for some unsupported backports repos, or compile everything by hand defeating the whole point of binary packages. Making the tools do deal with the base could be interesting, but please, please, please don't shove everything into the pkg_tools and turning FreeBSD into just a random collection of packages that kind of work together. IOW, don't go down the distro path. Keep the base OS separate from third-party apps. Keep the tools to deal with them separate. True word, brother! If we wanted to run linux there are options for it. debs suck, rpms really suck. Those types of systems are sometimes faster to get up and rolling as long as you want vanilla apps, but they are a major PITA for many types of customizations which are a breeze with the ports tree. You'd be killing of one of the more elegant approaches in FreeBSD. Sure there are problem with it, but IMO adopting more severe problems isn't a good answer. Maybe that was a 4/1 too though. If so, good work. -- Adam Vande More ___ 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: Results of BIND RFC
Firstly, congratualtions to do...@.
On 2010-Apr-02 05:15:26 -0700, Jeremy Chadwick free...@jdc.parodius.com wrote:
1) In most scenarios (historically speaking), what gets updated quicker:
base or ports? Answer: ports.
In some ways this is a problem. On the downside, it means that a
-RELEASE will never have bleeding edge features. On the upside, it
means that a -RELEASE will never have bleeding edge bugs.
2) What has proper infrastructure for dependencies and tracking of
installed files as part of a software package? Answer: ports.
I agree that this is a deficiency in the base system. I have often
wished that there was some way of tracking exactly what part of
installworld had installed what file - but I accept that this is
a difficult problem. It might be useful if there was a target as
part of install{world,kernel} that built a mtree database of what
was installed.
3) How often do you see people posting problems with key pieces of
FreeBSD infrastructure (device support/reliability or storage-related
subsystems), followed by a response from a developer stating this has
been fixed in -STABLE or can you try the code from HEAD? Answer:
often.
That's true of any non-trivial piece of software that has distinct
developer and end-user branches. Moving to ports won't really
resolve the problem - the answer will still be you need to update
to a newer version of that code.
Whilst I'd occasionally like to see less bloat (ie anything that I
don't use) in base, there is one significant benefit that I don't
recall seeing discussed in this thread - integration testing. The
base system it built and tested as a whole. This isn't practical for
the ports system. Without the integration testing, you wind up in the
situation where port A and port B work in isolation but don't work
together - the port A maintainer says that the problem is port B and
the port B maintainer says that port A is relying on an optional part
of port B that they don't have the time/interest/expertise to
maintain.
--
Peter Jeremy
pgpAipJBtdd3d.pgp
Description: PGP signature
Re: Results of BIND RFC
On Fri, 2 Apr 2010, Doug Barton wrote: So first of all, yes Virginia, this was an April Fool's Day joke. To both those for whom this post created a false sense of despair, and (perhaps more importantly) to those for whom it created a false sense of joy, my apologies. :) And for the record, everything from here on is just the facts. You're a proper bastard, Doug - in the strictly affectionate Aussie sense of the term. Talk about stirring the possum! Had me fired up to figure out how to add a choice menu to sysinstall .. Good to hear the DNSSEC stuff is coming along, however ponderously. KUTGW, Ian ___ 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
