6.4-RELEASE missing from mirrors
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
panic during work with jailed postgresql8.4
Hello, 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? Thanks.
Results of BIND RFC
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Greetings, SUMMARY On February 21 I sent a message to freebsd-a...@freebsd.org detailing the current state of BIND on FreeBSD, and plans for the future. You can see that message here: http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html In that message I asked for feedback on my plans for dealing with BIND in the base. There wasn't much response on the lists, however I did receive a great deal of response privately, all more or less to the effect of, Do we really need to continue having BIND in the base at all? After careful consideration and private discussion about this issue the conclusion has been reached that the answer to this question is, No. Therefore we will be removing BIND from the FreeBSD base. BACKGROUND Back in the day when the FreeBSD project started there was really only one show in the DNS town, BIND. In the last 10 years several truly viable, first-class DNS options have been developed, in both the authoritative and resolving server spaces. There are ports available for each of these options, and many FreeBSD users take advantage of them. There are of course also ports available for all supported BIND versions, as well as dns/bind9 for BIND version 9.3 which has been EOL'ed by ISC but is still in FreeBSD version 6. This also leads to the issue mentioned in the post above, the desynchronization between FreeBSD and ISC release schedules. While FreeBSD 6 is scheduled to EOL in November of this year, it contains BIND version 9.3.6-P1, which has long been EOL. There are a number of problems related to upgrading the version of BIND in a release branch of FreeBSD. Given the ease with which FreeBSD users can upgrade BIND with the ports tree, and given the characteristics of the vulnerabilities that have come to light with BIND 9.3.x to date, this hasn't been a problem. There is no guarantee that this will continue to be the case. This problem will reappear again in FreeBSD version 7 with BIND 9.4, and FreeBSD version 8 with BIND 9.6. PROS This change will have several advantages. 1) Users of all FreeBSD versions will be able to have easy access to the latest versions of BIND, and an easy upgrade path that does not involve a full OS upgrade. 2) The release synchronization problem mentioned above will no longer be a problem. 3) Users of other DNS solutions will no longer need to customize their build using the various WITH/WITHOUT_BIND* knobs. CONS Of course this change will have some costs. Users of named who rely on the current defaults will have some change management to deal with, however the costs will be minimal. The one area that has come up repeatedly in previous discussions about this topic is that users like having access to the command line tools dig, host, and nslookup. To deal with that issue I will be creating a bind-tools port so that those who want just those tools can easily add them, without the overhead of the rest of the BIND suite. If anyone has suggestions for other BIND tools that should be included in the port, please let me know. IMPLEMENTATION TIMELINE I will be removing BIND from HEAD today. Removal from the other branches will occur far enough in advance of their upcoming releases to ensure that the users have a chance to shake things out first. I'll also be committing the bind-tools and bind-config ports today so that users will continue to have easy access to the work I've done on named.conf, rc.d/named, etc. I have been maintaining BIND in the base for almost 8 years now, and while it's been challenging in a lot of ways, it's also been a great privilege to be able to help the FreeBSD community in this way. I can't say that I'll miss the drama of src updates though. :) Many happy returns of the day, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAku1G1sACgkQyIakK9Wy8PuPgQCfdrhgscMQ+KPLcoRXx66f4f6M T8wAniZqULdwM+4oRsbOkFSDZIceWn0u =Syor -END PGP SIGNATURE- ___ 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
May I only hope this is legit and not a April Fool's joke :) ___ 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 1 April 2010 22:18, Oleg Lomaka oleg.lom...@gmail.com wrote: Hello, 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 Looking at backtrace, I wonder whether tp-t_maxseg changes in tcp_mtudisc() at all. You should be able to extract its value on each 2*n frame in that big recursive call. -- wbr, pluknet ___ 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
May I only hope this is legit and not a April Fool's joke :) actually, as an unbound user, i would be quite happy to have bind removed. bloated, ever-buggy, config religion, ... 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 04/01/2010 23:48, Randy Bush wrote: May I only hope this is legit and not a April Fool's joke :) actually, as an unbound user, i would be quite happy to have bind removed. bloated, ever-buggy, config religion, ... randy At least I hope that this will be removed and added to the distribution as a package upon release time. -- jhell ___ 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 Thu, 01 Apr 2010 15:16:59 -0700 Doug Barton do...@freebsd.org mentioned: Of course this change will have some costs. Users of named who rely on the current defaults will have some change management to deal with, however the costs will be minimal. The one area that has come up repeatedly in previous discussions about this topic is that users like having access to the command line tools dig, host, and nslookup. To deal with that issue I will be creating a bind-tools port so that those who want just those tools can easily add them, without the overhead of the rest of the BIND suite. If anyone has suggestions for other BIND tools that should be included in the port, please let me know. Hey, Doug! 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? -- Stanislav Sedov ST4096-RIPE pgprZIyg771Gg.pgp Description: PGP signature
Re: panic during work with jailed postgresql8.4
On Apr 2, 2010, at 4:52 AM, pluknet wrote: On 1 April 2010 22:18, Oleg Lomaka oleg.lom...@gmail.com 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 Looking at backtrace, I wonder whether tp-t_maxseg changes in tcp_mtudisc() at all. You should be able to extract its value on each 2*n frame in that big recursive call. You are right, pt-t_maxseg doesn't change (kgdb) frame 9 #9 0x807097e8 in tcp_mtudisc (inp=0xff00193c53f0, errno=Variable errno is not available. ) at tcp_offload.h:282 282 return (tcp_output(tp)); (kgdb) p tp-t_maxseg $1 = 14336 (kgdb) frame 11 #11 0x807097e8 in tcp_mtudisc (inp=0xff00193c53f0, errno=Variable errno is not available. ) at tcp_offload.h:282 282 return (tcp_output(tp)); (kgdb) p tp-t_maxseg $2 = 14336 ... (full log at http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfNGQ4cWpia2dzhl=en ) (kgdb) frame 81 #81 0x807097e8 in tcp_mtudisc (inp=0xff00193c53f0, errno=Variable errno is not available. ) at tcp_offload.h:282 282 return (tcp_output(tp)); (kgdb) p tp-t_maxseg $37 = 14336 (kgdb)
