Re: Results of BIND RFC
On 2 Apr 2010, at 23:07, Doug Barton wrote:
-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
Re: random FreeBSD panics
On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras wrote: > On 28 March 2010 16:42, Masoom Shaikh wrote: > >> lets assume if this is h/w problem, then how can other OSes overcome >> this ? is there a way to make FreeBSD ignore this as well, let it >> result in reasonable performance penalty. > > Very probably, if only we could detect where the problem is. > Try adding "options PRINTF_BUFR_SIZE=128" to the kernel > configuration file if you can, to see if you can get a less mangled > log outout. > ok, after few days of silence I am back with more questions this time system feels little better, it is able to sustain for more time that what 7.3-RELEASE could FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64 I am using KDE4, and when OS freezes, well it freezes, means I cannot change to tty0 and see the panic text, if any it might possibly have spit. the stuck frozen GUI keeps staring there. So the question is how to I capture that panic text ? unfortunately I am not getting core files too, so there is nothing I can pick up hints is there some option (KDB, DDB), so that on panic system drop to debugger ? Masoom Shaikh ___ 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: 8-STABLE/amd64: kernel panic after a minute of mounting xfs
On Fri, Mar 26, 2010 at 06:11:06PM +1100, Peter Jeremy wrote: > On 2010-Mar-25 21:32:10 +0200, Nezmer wrote: > >This is the 1st time FreeBSD panics on me. It happened after a > >minute of mounting an XFS partition. I'm not sure It's XFS but It's the > >only part of the OS I try for the 1st time. > > > >kernel: vn_iowait doing nothing on FreeBSD? > > This is part of XFS. I'm not sure how important it is. > > >kernel: Fatal trap 12: page fault while in kernel mode > ... > >kernel: Cannot dump. Device not defined or unavailable. > > Unfortunately, there's not much that can be done given this > information. As a minimum, you need a backtrace. Ideally, you need a > core-dump to investigate the cause. > > See > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > > -- > Peter Jeremy I got a chance to get a backtrace with revision 206096 today. You can find it with relevant source files here(1). I hope It's enough. (1) https://nezmer.info/public/xfs_report.tar.gz ___ 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 02:08:27PM -0400, Charles Sprickman typed: > Can we do sendmail next April 1? Better yet, defer all questions about moving out of the base system by referring to the Grand Discussion that'll take place *next year* on the first of april. ___ 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: random FreeBSD panics
On Sat, 3 Apr 2010 12:51:46 + Masoom Shaikh wrote: > On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras wrote: > > On 28 March 2010 16:42, Masoom Shaikh wrote: > > > >> lets assume if this is h/w problem, then how can other OSes overcome > >> this ? is there a way to make FreeBSD ignore this as well, let it > >> result in reasonable performance penalty. > > > > Very probably, if only we could detect where the problem is. > > Try adding "options __ __ PRINTF_BUFR_SIZE=128" to the kernel > > configuration file if you can, to see if you can get a less mangled > > log outout. > > > > ok, after few days of silence I am back with more questions > this time system feels little better, it is able to sustain for more > time that what 7.3-RELEASE could > > FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1 > 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64 > > I am using KDE4, and when OS freezes, well it freezes, means I cannot > change to tty0 and see the panic text, if any it might possibly have > spit. the stuck frozen GUI keeps staring there. So the question is how > to I capture that panic text ? unfortunately I am not getting core > files too, so there is nothing I can pick up hints > > is there some option (KDB, DDB), so that on panic system drop to debugger ? > [trimmed Cc - no need to send this to 3 MLs] There's no code in the kernel to switch back out of graphics mode (i.e. what X uses) when a panic happens. You probably can switch to v0, but you won't be able to see it. The only sure-fire way is to hook up a screen (terminal, laptop or another computer) to a serial port. -- Gary Jennejohn ___ 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"
install touching mbr
hail, I just installed a 8.0R amd64 from memstick. when asked, I said to leave mbr untouched. when I rebooted, it was freebsd bootloader that was on control. this options is not what I think it should, or there is really a issue here ? thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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: install touching mbr
On Sat, Apr 03, 2010 at 05:48:12PM -0300, Nenhum_de_Nos wrote: > I just installed a 8.0R amd64 from memstick. when asked, I said to > leave mbr untouched. when I rebooted, it was freebsd bootloader that > was on control. this options is not what I think it should, or there > is really a issue here ? I can confirm this behaviour. Someone may have broken something when tinkering around in that part of sysinstall (since the Standard vs. BootMgr options were moved around compared to previous releases). -- | 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: install touching mbr
On Sat, 3 Apr 2010, Jeremy Chadwick wrote: On Sat, Apr 03, 2010 at 05:48:12PM -0300, Nenhum_de_Nos wrote: I just installed a 8.0R amd64 from memstick. when asked, I said to leave mbr untouched. when I rebooted, it was freebsd bootloader that was on control. this options is not what I think it should, or there is really a issue here ? I can confirm this behaviour. Someone may have broken something when tinkering around in that part of sysinstall (since the Standard vs. BootMgr options were moved around compared to previous releases). Not sure how to repeat the bug, but it's been there at least a few months: http://docs.freebsd.org/cgi/mid.cgi?alpine.BSF.2.00.0909262030060.13303 http://docs.freebsd.org/cgi/mid.cgi?58c737d70909262054k7c7b1402w4f9c902fdca2640c -Warren Block * Rapid City, South Dakota USA ___ 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
Ruben de Groot wrote: > defer all questions about moving out of the base system ... Last I knew, X was not _in_ the base system :) ___ 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: install touching mbr
On Saturday 03 April 2010 21:58:56 Jeremy Chadwick wrote: > On Sat, Apr 03, 2010 at 05:48:12PM -0300, Nenhum_de_Nos wrote: > > I just installed a 8.0R amd64 from memstick. when asked, I said to > > leave mbr untouched. when I rebooted, it was freebsd bootloader that > > was on control. this options is not what I think it should, or there > > is really a issue here ? > > I can confirm this behaviour. Someone may have broken something when > tinkering around in that part of sysinstall (since the Standard vs. > BootMgr options were moved around compared to previous releases). I have a patch at http://reviews.freebsdish.org/r/15/ waiting to be committed. I believe the "None" option won't change the bootcode itself but will still mark the FreeBSD partition as active. -- Bruce Cran ___ 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"
