On Tue, 2006-04-18 at 09:52 +0200, Robert Millan wrote: > On Mon, Apr 17, 2006 at 07:14:10PM +0000, Brian M. Carlson wrote: > > I tried upgrading my server from 5.4 to 6.0 the other day. I noticed a > > couple of things: > > > > pfctl does not work with 6.0. It complains about certain ioctls, so I > > would assume that the interface has changed. pf(4) on the FreeBSD > > website should show you the difference. This was rather inconvenient, > > because (as I'm sure you probably know) if you load pf.ko, the default > > is deny, and therefore ssh doesn't work. Luckily, the server sits in my > > apartment, so I could log in via the console. > > Note that pfctl lives currently in freebsd-hackedutils (i.e. it is a hacked > binary we copied from freebsd 5). We can try to hack it to support both kernels > at the same time, but we really need to get it to build from source first ;). This I can work on. I will yank the source from the 6.0-RELENG branch and see how it works. > Have you tried if pfctl from freebsd 6 works with kernel 5.x ? No, I have not. I don't think it will, though, as 6.0 has additional ioctls that 5.4 does not. From the manpages, pfctl is neither forward nor backwards compatible. > > bind9, while not stellar on 5.4, hangs on 6.0. On 5.4, it eventually > > returns SERVFAIL for every request. On 6.0, it won't even start. > > What is the error on 6.0 ? Unknown. It hangs when init starts it, making the machine useless and requiring the use of the reset button, as neither getty nor sshd have started yet. I'll reboot into GNU/kFreeBSD and test. Not having strace may make it difficult, though. > > So, in order, someone should probably pull a diff of pfctl from 6.0, and > > see if they can hack it to support both at once (deciding by uname, I > > guess). I might do this if I have some time. > > Maybe it's feasible to do it at the source level. Who knows? Perhaps it's > just an ioctl code (either API or ABI) that changed or something. If it is too difficult to do in C, we could always put pfctl-6 and pfctl-5 in /lib/freebsd, and then write a C or sh wrapper around them. > I'd like to avoid adding more cruft to freebsd-hackedutils, though. This > package is supposed to shrink, not grow! :) I agree. However, if I can get it to build from source with glibc, this would be a non-issue, because it could be included in -utils, not -hackedutils. I don't know how ambitious this is, but I have 1.5 to 2 hours to hack right now.
Attachment:
signature.asc
Description: This is a digitally signed message part