Re: IPFIREWALL_FORWARD kernel config option gone?
On Thu, Nov 20, 2003 at 10:12:44AM -0800, Wade Klaver wrote: > Hello all, > When trying to bring a box up to date, we noticed that the > IPFIREWALL_FORWARD kernel option has been removed somewhere between the 2'nd > of this month and now. Has it been obsoleted by other options? I saw > nothing in UPDATING rearding this. Here's the info: The functionality of IPFIREWALL_FORWARD is always "just there." IPFIREWALL_FORWARD has been a null option for about two and a half years. It was removed from the ipfw(8) documentation in 1.105, 2002/08/10. However, killing it from the kernel configuration files only happened this month. Since it's been gone from the documentation for so long, whether it needs an entry in UPDATING is debatable. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_4 to RELENG_5_1
On Wed, Jun 04, 2003 at 10:15:41AM +1000, Matthew Gardiner wrote: > >> > >> Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I > >> have been getting the same failure originally quoted when building > >> HEAD on RELENG_4 for several days now. > >> > >> I suggest that the original poster double-check that he has RELENG_5_1 > >> and not HEAD. And I do have buildworld logs. I'll send in a separate > >> mail. > > > > No need that. This is a bug and it needs to be fixed. I am working on > > this. Thanks for the reports. > > Just a quick question, what version of GCC is going to appear in FreeBSD > 5.1? I heard that it maybe GCC 3.2.3 and that GCC 3.3 (depending on its > stability) will be used for 5.2. Could someone either confirm or correct me > on this assumption? gcc 3.2.2 is in RELENG_5_1. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_4 to RELENG_5_1
On Tue, Jun 03, 2003 at 12:02:44PM -0400, Alexander Kabaev wrote: > > On Tue, 03 Jun 2003 18:51:59 +0300 > Petri Helenius <[EMAIL PROTECTED]> wrote: > > > I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make > > buildworld compiles > > a while and then stops with: > > > > Question is if this is supported and if yes, what should I do > > differently? > > > > Pete > > Got your buildworld log saved somewhere? Could you send it to me please. Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I have been getting the same failure originally quoted when building HEAD on RELENG_4 for several days now. I suggest that the original poster double-check that he has RELENG_5_1 and not HEAD. And I do have buildworld logs. I'll send in a separate mail. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Create linker.hints at boot
On Mon, Mar 17, 2003 at 01:07:53PM -0800, David O'Brien wrote:
> On Mon, Mar 17, 2003 at 12:43:19PM -0800, Crist J. Clark wrote:
> > On Mon, Mar 17, 2003 at 09:11:12AM -0800, David O'Brien wrote:
> > > On Mon, Mar 17, 2003 at 12:28:34AM -0800, Crist J. Clark wrote:
> > > > +kldxref_start () {
> > > > + if [ -z "$kldxref_module_path" ]; then
> > > > + MODULE_PATHS=`sysctl -n kern.module_path`
> > > > + else
> > > > + MODULE_PATHS="$kldxref_module_path"
> > > > + fi
> > >
> > > Please change the logic to positive logic:
> > >
> > > if [ -n "$kldxref_module_path" ]; then
> > > MODULE_PATHS="$kldxref_module_path"
> > > else
> > > MODULE_PATHS=`sysctl -n kern.module_path`
> > > fi
> >
> > Is there a technical reason for that or is it just a "style" issue?
>
> Style, easier to read out loud, easier to understand w/o having to think.
> Just like this is hard to "read". It certainly doesn't do what one reads
> out loud: "if not string compaire equal".
>
> if (!strcmp(a,b) {
> printf("same\n");
> }
I don't see what that code snipit has to do with the script (but I am
in the camp that would go ahead and waste the four bytes of source
code to write that as (strcmp(a, b) == 0)).
I _did_ write the original script the way I was thinking/would say it,
"If $kldxref_module_path is empty, use the sysctl(8), otherwise, use
its contents."
I guess I was thinking of '-z' as a positive, "is empty," rather than
a negative, "is not filled."
But whatever. I've changed it to the "positive" in my repository. I'll
commit the latest version later and everyone can make there own
fixes/additions/changes/PRs.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Create linker.hints at boot
On Mon, Mar 17, 2003 at 09:11:12AM -0800, David O'Brien wrote:
> On Mon, Mar 17, 2003 at 12:28:34AM -0800, Crist J. Clark wrote:
> > +kldxref_start () {
> > + if [ -z "$kldxref_module_path" ]; then
> > + MODULE_PATHS=`sysctl -n kern.module_path`
> > + else
> > + MODULE_PATHS="$kldxref_module_path"
> > + fi
>
> Please change the logic to positive logic:
>
> if [ -n "$kldxref_module_path" ]; then
> MODULE_PATHS="$kldxref_module_path"
> else
> MODULE_PATHS=`sysctl -n kern.module_path`
> fi
Is there a technical reason for that or is it just a "style" issue?
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Create linker.hints at boot
On Fri, Mar 14, 2003 at 07:27:42PM -0800, Peter Wemm wrote:
> "Crist J. Clark" wrote:
> >
> > --C7zPtVaVf+AK4Oqc
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> >
> > Perhaps it would be a good idea to build a linker.hints file with
> > kldxref(8) at boot time. At least, I can't think of any really good
> > reasons why _not_ to do it.
>
> Yes, we need to do this, but your patch needs a little more work.
>
> Specifically.. There is a linker.hints file in each directory in the module
> path, not just /boot/kernel. You need to look at the kern.module_path
> sysctl to find the search path.
>
> [EMAIL PROTECTED]:26pm]~-101> sysctl -n kern.module_path
> /boot/kernel;/boot/kernel;/boot/modules;/modules
Ah. There that is.
> This also needs to be robust in the case where /boot might be another file
> system or readonly or NFSROOT or not even mounted, or something.
I think the easiest thing to do here is if the kldxref(8) command
fails, it shouldn't kill the boot. Specifically, force the script to
always exit on success. Anything failing here is simply not bad enough
that we should interupt the boot.
In the case of a read-only filesystem, we get an error message like,
Building /foo/modules/linker.hints
kldxref: /foo/lhint.caF5Wl: Read-only file system
For non-existent directories, kldxref(8) actually doesn't return a
failure anyway,
# kldxref /nonexistent
# echo $?
0
Someone who's mount root read-only or booting from a partition that
doesn't get mounted is someone who better know what they are doing. If
they don't like the error messages they have the knob to completely
disable the script or I have added an option for a rc.conf(5)
specified directory listing rather than kern.module_path.
There are always going to be that small fraction of real or imagined
users doing some wild things that won't fit into the startup scripts
no matter how many knobs we give them. Making things overly
complicated for that small percentile just confuses the bulk of the
users and makes more room for more bugs. KISS. Just turn this off if
you don't want to or can't use it.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
Index: src/etc/defaults/rc.conf
===
RCS file: /export/freebsd/ncvs/src/etc/defaults/rc.conf,v
retrieving revision 1.170
diff -u -r1.170 rc.conf
--- src/etc/defaults/rc.conf15 Mar 2003 08:14:42 - 1.170
+++ src/etc/defaults/rc.conf17 Mar 2003 08:25:09 -
@@ -28,6 +28,9 @@
apmd_enable="NO" # Run apmd to handle APM event from userland.
apmd_flags="" # Flags to apmd (if enabled).
devd_enable="NO" # Run devd, to trigger programs on device tree changes.
+kldxref_enable="NO"# Build linker.hints files with kldxref(8).
+kldxref_clobber="NO" # Overwrite old linker.hints at boot.
+kldxref_module_path="" # Override kern.module_path. A ';'-delimited list.
pccard_enable="NO" # Set to YES if you want to configure PCCARD devices.
pccard_mem="DEFAULT" # If pccard_enable=YES, this is card memory address.
pccard_beep="2"# pccard beep type.
Index: src/etc/rc.d/network1
===
RCS file: /export/freebsd/ncvs/src/etc/rc.d/network1,v
retrieving revision 1.145
diff -u -r1.145 network1
--- src/etc/rc.d/network1 12 Feb 2003 04:26:10 - 1.145
+++ src/etc/rc.d/network1 15 Mar 2003 00:36:05 -
@@ -4,7 +4,7 @@
#
# PROVIDE: network1
-# REQUIRE: atm1 ipfilter mountcritlocal pccard serial sppp sysctl tty
+# REQUIRE: atm1 ipfilter kldxref mountcritlocal pccard serial sppp sysctl tty
# KEYWORD: FreeBSD
. /etc/rc.subr
Index: src/etc/rc.d/kldxref
===
RCS file: src/etc/rc.d/kldxref
diff -N src/etc/rc.d/kldxref
--- /dev/null 1 Jan 1970 00:00:00 -
+++ src/etc/rc.d/kldxref17 Mar 2003 08:23:09 -
@@ -0,0 +1,35 @@
+#!/bin/sh
+#
+# $FreeBSD:$
+#
+
+# PROVIDE: kldxref
+# REQUIRE: root
+# BEFORE: network1
+# KEYWORD: FreeBSD
+
+. /etc/rc.subr
+
+rcvar="kldxref_enable"
+name="kldxref"
+stop_cmd=":"
+start_cmd="kldxref_start"
+
+kldxref_start () {
+ if [ -z "$kldxref_module_path" ]; then
+ MODULE_PATHS=`sysctl -n kern.module_path`
+ else
+ MODULE_PATHS="$kldxref_module_path"
+ fi
+ IFS=';'
+ for KERNDIR in $MODULE_PATHS; do
+ if [ ! -f "$KERNDIR/linker.hints" ] ||
+ checkyesno kldxref_clobber; then
+ echo "Building $KERNDIR/linker.hints"
+ kldxref "$KERNDIR"
+ fi
+ done
+}
+
+load_rc_config $name
+run_rc_command "$1"
Create linker.hints at boot
Perhaps it would be a good idea to build a linker.hints file with
kldxref(8) at boot time. At least, I can't think of any really good
reasons why _not_ to do it.
Personally, I like it because when I buildworld and installworld
CURRENT/RELENG_5 on RELENG_4, the linker.hints file is not built. This
prevents the kernel from automatically loading the nfsclient.ko when I
try to mount something. A mild annoyance, but why not just auto
generate one the first time I boot the CURRENT/RELENG_5 box?
I made a quick rc-ng script to do this and two rc.conf knobs. I think
the rest is pretty self-explanitory. Anyone have any opinions on
whether or not to add this, and whether it should default on or off?
I'm inclined to adding it, default OFF (simply for POLA sake), and
perhaps later turning it to default ON once the idea settles in?
Also, what's the best way/is there a way to figure out the boot
directory rather than hardwire /boot/kernel?
This is my first stab at rc-ng for a long while, so please be gentle
if I've not handled that the best way. Patches attached.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
Index: etc/defaults/rc.conf
===
RCS file: /ncvs/src/etc/defaults/rc.conf,v
retrieving revision 1.169
diff -u -r1.169 rc.conf
--- etc/defaults/rc.conf8 Mar 2003 09:50:11 - 1.169
+++ etc/defaults/rc.conf14 Mar 2003 23:04:09 -
@@ -28,6 +28,8 @@
apmd_enable="NO" # Run apmd to handle APM event from userland.
apmd_flags="" # Flags to apmd (if enabled).
devd_enable="NO" # Run devd, to trigger programs on device tree changes.
+kldxref_enable="NO"# Build a linker.hints file with kldxref(8).
+kldxref_clobber="NO" # Overwrite old linker.hints at boot.
pccard_enable="NO" # Set to YES if you want to configure PCCARD devices.
pccard_mem="DEFAULT" # If pccard_enable=YES, this is card memory address.
pccard_beep="2"# pccard beep type.
Index: etc/rc.d/network1
===
RCS file: /ncvs/src/etc/rc.d/network1,v
retrieving revision 1.145
diff -u -r1.145 network1
--- etc/rc.d/network1 12 Feb 2003 04:26:10 - 1.145
+++ etc/rc.d/network1 15 Mar 2003 00:04:42 -
@@ -4,7 +4,7 @@
#
# PROVIDE: network1
-# REQUIRE: atm1 ipfilter mountcritlocal pccard serial sppp sysctl tty
+# REQUIRE: atm1 ipfilter kldxref mountcritlocal pccard serial sppp sysctl tty
# KEYWORD: FreeBSD
. /etc/rc.subr
Index: etc/rc.d/kldxref
===
RCS file: etc/rc.d/kldxref
diff -N etc/rc.d/kldxref
--- /dev/null 1 Jan 1970 00:00:00 -
+++ etc/rc.d/kldxref15 Mar 2003 00:04:12 -
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# $FreeBSD:$
+#
+
+# PROVIDE: kldxref
+# REQUIRE: root
+# BEFORE: network1
+# KEYWORD: FreeBSD
+
+. /etc/rc.subr
+
+rcvar="kldxref_enable"
+name="kldxref"
+stop_cmd=":"
+start_cmd="kldxref_start"
+
+kldxref_start () {
+ KERNDIR=/boot/kernel
+ if [ ! -f "$KERNDIR/linker.hints" ] || checkyesno kldxref_clobber; then
+ echo "Building $KERNDIR/linker.hints"
+ kldxref "$KERNDIR"
+ fi
+}
+
+load_rc_config $name
+run_rc_command "$1"
Re: Cisco vpnclient
On Fri, Jan 31, 2003 at 11:53:24AM +0100, Christoph Kukulies wrote: > > Cisco is offering a VPN client for Linux. I wonder if it would be possible > to run this under FreeBSD. An extra linux kernel module is being built. > Is this already the 'ruled out'? That's just it. FreeBSD can run Linux userland applications really well... compatibility within the kernel is a cow of another color. To do /some/ of the things the standard Cisco VPN client does, it would need to be a kernel module. To do /a lot/ of what it does, including just a basic IPsec implementation, it could all run in userland. I doubt that they will break things up that way. But if enough people ask, Cisco will make a client for FreeBSD. Or they might be willing to open up their protocol so that third parties can build their own clients. > If this won't work, I'm afraid I will have to set a dedicated redhat 6.x/7.x > beside my FreeBSD gateway. Would it be possible to use NAT to > extend the VPN (I only have one dedicated fixed IP on the gateway). Cisco VPN clients do work behind NAT (provided the NAT gateway can deal with the traffic). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Mounting Other *BSD Partitions
I've got a test box that boots Windows, NetBSD, and both FreeBSD STABLE and CURRENT. The FreeBSD CURRENT system is having trouble mounting the NetBSD partitions. The STABLE system has no problem with the NetBSD slice and its partitions. Have all of the CURRENT changes made it impossible to mount some old NetBSD partitions? Or is there some magical incantation to get this to work? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
On Tue, Sep 24, 2002 at 06:13:33PM -0400, Alexander Kabaev wrote: > > Nope, still getting it. > > I was able to reproduce the crash with your config file and unpatched > GCC, however crash does not happen when I use the patch. Are you using > make buildkernel or old config/make method? Since I'm building a CURRENT kernel on a STABLE box, I think buildkernel is the only practical choice. With the latest patch, today's automated build ran fine. Thanks. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
On Tue, Sep 24, 2002 at 11:43:22AM -0400, Alexander Kabaev wrote: > On Tue, 24 Sep 2002 00:00:45 -0700 > "Crist J. Clark" <[EMAIL PROTECTED]> wrote: > > > Not too sure about that. Now I'm getting SIGSEGV again, > > You are right. There was a stupid mistake in the latest version, sorry. > Could you try yet another patch? > > http://people.freebsd.org/~kan/gcc-cpp.diff Nope, still getting it. As for your other question about the configuration, it looks like it's, options IPSEC_ESP That is killing it. If I comment out that option, I get past that initial mkdep. The whole configuration is attached. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] # # $Id: GOKU,v 1.7 2002/07/30 07:50:02 cjc Exp cjc $ # machine i386 cpu I686_CPU ident GOKU maxusers0 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options FFS #Berkeley Fast Filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING options SOFTUPDATES device isa device pci options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity options IPV6FIREWALL#firewall for IPv6 options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPDIVERT#divert sockets #optionsIPFILTER#ipfilter support #optionsIPFILTER_LOG#ipfilter logging #optionsIPFILTER_DEFAULT_BLOCK #block all packets by default device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives # Floating point support - do not disable. device npx # Power management support #device apm # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device # PCI Ethernet NICs. device miibus device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices - the number indicates how many units to allocated. device random # Entropy device device loop# Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf #Berkeley packet filter # Give sound a shot device pcm # USB device device usb
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
On Mon, Sep 23, 2002 at 03:59:46PM -0400, Alexander Kabaev wrote: > On Mon, 23 Sep 2002 12:55:49 -0700 > "Crist J. Clark" <[EMAIL PROTECTED]> wrote: > > > It seems to have worked. Thanks. > > Sorry for inconvenience, but could you please check that you got the > latest version of the patch. Both versions will fix the bug, but the > version I copied on freefall several hours ago appears to be more > correct. Not too sure about that. Now I'm getting SIGSEGV again, make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src.CURRENT/sys -I/usr/src.CURRENT/sys/dev -I/usr/src.CURRENT/sys/contrib/dev/acpica -I/usr/src.CURRENT/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See http://www.gnu.org/software/gcc/bugs.html> for instructions. mkdep: compile failed *** Error code 1 Stop in /home/cjc/obj/usr/src.CURRENT/sys/GOKU. *** Error code 1 Stop in /home/cjc/obj/usr/src.CURRENT/sys/GOKU. *** Error code 1 Stop in /usr/src.CURRENT. *** Error code 1 Stop in /usr/src.CURRENT. And I had this patch, $ cvs diff cppmacro.c Index: cppmacro.c === RCS file: /export/freebsd/ncvs/src/contrib/gcc/cppmacro.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 cppmacro.c --- cppmacro.c 1 Sep 2002 20:37:29 - 1.1.1.4 +++ cppmacro.c 23 Sep 2002 20:39:38 - @@ -349,6 +349,8 @@ /* Commit the memory, including NUL, and return the token. */ len = dest - BUFF_FRONT (pfile->u_buff); + if ((size_t) (BUFF_LIMIT (pfile->u_buff) - dest) < 1) +_cpp_extend_buff (pfile, &pfile->u_buff, 1); BUFF_FRONT (pfile->u_buff) = dest + 1; return new_string_token (pfile, dest - len, len); } For the buildworld and buildkernel. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
On Sun, Sep 22, 2002 at 11:09:56PM -0400, Alexander Kabaev wrote: > I am asking people having CPP0 dying with SIG11 to try the patch at URL > below. Success/failure reports are appreciated. > > http://people.freebsd.org/~kan/gcc-cpp.diff It seems to have worked. Thanks. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Trouble Building CURRENT on STABLE, cpp seg. fault
/usr/src.CURRENT/sys/dev/sound/pcm/feeder_if.m -c awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/sound/pcm/mixer_if.m -c awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/usb/usb_if.m -c awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/isa/isa_if.m -c awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/kern/device_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/kern/bus_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/kern/linker_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/mii/miibus_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/pccard/card_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/pccard/power_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/pci/pci_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/pci/pcib_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/ppbus/ppbus_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/sound/pcm/ac97_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/sound/pcm/channel_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/sound/pcm/feeder_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/sound/pcm/mixer_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/dev/usb/usb_if.m -h awk -f /usr/src.CURRENT/sys/tools/makeobjops.awk /usr/src.CURRENT/sys/isa/isa_if.m -h if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src.CURRENT/sys -I/usr/src.CURRENT/sys/dev -I/usr/src.CURRENT/sys/contrib/dev/acpica -I/usr/src.CURRENT/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See http://www.gnu.org/software/gcc/bugs.html> for instructions. mkdep: compile failed *** Error code 1 Stop in /home/cjc/obj/usr/src.CURRENT/sys/GOKU. *** Error code 1 Stop in /home/cjc/obj/usr/src.CURRENT/sys/GOKU. *** Error code 1 Stop in /usr/src.CURRENT. *** Error code 1 Stop in /usr/src.CURRENT. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel doesnt let root to edit labels anymore?
On Sat, Sep 21, 2002 at 12:32:47PM +0300, mika ruohotie wrote: > > eh? > > it seems regardless of the flags i'm giving to disklabel it prevents > me from editing/restoring/whatever labels. only thing i can do is > to read them. What error are you getting? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: question about ipl.ko
On Fri, Aug 16, 2002 at 03:01:47PM +0200, Radko Keves wrote: > i try to load ipl.ko > > #kldload -v /boot/kernel/ipl.ko > kldload: can't load /boot/kernel/ipl.ko: Exec format error [snip] > it's my problem, for example in the kernel module loading sequence, or current >problem ? Both. If you are getting an 'Exec format error,' there is something wrong at your end. However, ipl.ko has been broken in CURRENT for a "long time" (over a year at least) and will not load (albeit with a different error message). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bug in awk implementation?
On Tue, Jul 16, 2002 at 04:57:42PM -0700, Gordon Tetlow wrote: > On Tue, 16 Jul 2002, Crist J. Clark wrote: > > > And since it is clearly documented, awk(1) says, > > > >Records > >Normally, records are separated by newline characters. > >You can control how records are separated by assigning > >values to the built-in variable RS. If RS is any single > >character, that character separates records. Otherwise, > >RS is a regular expression. Text in the input that > >matches this regular expression will separate the record. > >However, in compatibility mode, only the first character > >of its string value is used for separating records. If RS > >is set to the null string, then records are separated by > >blank lines. When RS is set to the null string, the new- > >line character always acts as a field separator, in addi- > >tion to whatever value FS may have. > > > > It is not a bug. > > No, you are quoting from the gawk(1) man page. The awk(1) man page makes > no such statement. I pulled it from a RELENG_4_6_0_RELEASE box where awk == gawk. I said 'awk(1)' since I typed 'man awk' to get it, but of course you're right, I did mean gawk(1). But the point is that there's still no bug in gawk or one-true-awk with respect to how they deal with RS. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bug in awk implementation?
On Mon, Jul 15, 2002 at 04:00:29PM -0400, Garrett Wollman wrote: > < >said: > > > You are right. However, I still consider it a bug. :-) > > The standard says that the behavior is ``undefined''. That means that > you computer is allowed to turn into a frog. Actually doing something > useful is also permitted. And since it is clearly documented, awk(1) says, Records Normally, records are separated by newline characters. You can control how records are separated by assigning values to the built-in variable RS. If RS is any single character, that character separates records. Otherwise, RS is a regular expression. Text in the input that matches this regular expression will separate the record. However, in compatibility mode, only the first character of its string value is used for separating records. If RS is set to the null string, then records are separated by blank lines. When RS is set to the null string, the new- line character always acts as a field separator, in addi- tion to whatever value FS may have. It is not a bug. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installworld failure in libncurses
On Sat, Jun 01, 2002 at 08:15:28PM -0400, Andrew Gallatin wrote: > > ===> lib/libncurses > install -C -o root -g wheel -m 444 libncurses.a /usr/lib > install -c -s -o root -g wheel -m 444 libncurses.so.5 /usr/lib > ln -fs libncurses.so.5 /usr/lib/libncurses.so > install -C -o root -g wheel -m 444 curses.h term.h termcap.h unctrl.h >/usr/src/lib/libncurses/../../contrib/ncurses/include/ncurses_dll.h /usr/include > /usr/include/ncurses.h -> curses.h > ln -s /usr/src/lib/libncurses/../../contrib/ncurses/man/curs_addstr.3x curs_addstr.3 > ln: curs_addstr.3: File exists > *** Error code 1 > > Stop in /usr/src/lib/libncurses. > *** Error code 1 That ln(1) command should be happening during the build and NOT during install. I've seen this problem after interupted installworlds (although I'm not exactly sure why) and when there are clock issues. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 05:11:14PM -0400, Robert Watson wrote:
>
> On Sun, 28 Apr 2002, Crist J. Clark wrote:
>
> > On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
> > [snip]
> >
> > > In FreeBSD 5.0, all this information is exported from the kernel using the
> > > sysctl() interface, which provides much more information gating, and
> > > flexibe policy controls. This exists in part in 4.x, but not completely.
> > > In 5.0, ps requires no special privilege, and access control is done
> > > entirely in the kernel.
> >
> > I think I'm missing something here.
> >
> > $ uname -r
> > 4.5-RELEASE
> > $ ls -l /bin/ps
> > -r-xr-xr-x 1 root wheel 213796 Jan 30 14:30 /bin/ps
> >
> > ps(1) has no special privileges in 4.x, but I may not understand what
> > you mean by "special privileges?" (To me it means s{u,g}id.)
>
> Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was
> probably thinking of top, which still is setgid in -STABLE. You'll find
> however, that -e won't work without setgid kmem being turned on.
'-e' for ps(1) seems to work fine on processes you own. You cannot see
the environments of other users' processes (of course root can see
everyone's). But you do need /proc for '-e' to work.
> There
> are a number of other tools in -CURRENT that aren't setgid kmem where they
> are in -STABLE (top, iostat, etc).
You know, I'm not sure why top(1) needs it if ps(1) doesn't.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
> In FreeBSD 5.0, all this information is exported from the kernel using the
> sysctl() interface, which provides much more information gating, and
> flexibe policy controls. This exists in part in 4.x, but not completely.
> In 5.0, ps requires no special privilege, and access control is done
> entirely in the kernel.
I think I'm missing something here.
$ uname -r
4.5-RELEASE
$ ls -l /bin/ps
-r-xr-xr-x 1 root wheel 213796 Jan 30 14:30 /bin/ps
ps(1) has no special privileges in 4.x, but I may not understand what
you mean by "special privileges?" (To me it means s{u,g}id.)
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: upgrade from 4.5 to current fails
On Wed, Apr 24, 2002 at 01:29:49PM -0400, John Baldwin wrote: > > On 24-Apr-2002 Christian Flügel wrote: [snip] > > make buildworld: works ok. > > make buildkernel: works ok. > > copy GENERIC.hints to /boot/device.hints: works ok. > > make installkernel: stops with error: "kldxref not found" > > This is a bug in installkernel. Bug Peter Wemm [EMAIL PROTECTED] to fix it > since he broke it. :) Or find somone else who groks the src/Makefile.inc1 > stuff. It's already been pointed out that this is a non-fatal error in 'installworld.' However, I have (and think I posted somewhere?) some kludgey patches that build kldxref(8) as a cross-tool so that it works for 4.5 to 5.0 upgrades. But it's not really the "right" fix (since it is not a true cross-tool), so I haven't committed it. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Mon, Apr 22, 2002 at 11:16:58AM -0700, Doug White wrote: > On Sat, 20 Apr 2002, Lyndon Nerenberg wrote: > > > For the benefit of packet sniffers and other things that only want > > read-only access to /dev/bpf*, what do people think of adding a 'bpf' > > group for those programs? This allows bpf devices to be read by > > programs running with an effective gid of 'bpf' instead of the current > > requirement for an effective user of root. I've been running this way > > on many of our servers for several months now, and things like snort, > > tcpdump, etc., are quite happy with it (under stable). > > There's the other small problem that you have to be root to set > promiscuous mode. Nope. Just read access to bpf(4). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Sat, Apr 20, 2002 at 04:27:18PM -0600, Lyndon Nerenberg wrote:
> >>>>> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
>
> Crist> OK. Now you've really lost me. What do ports have to do with
> Crist> this? Which ports? None of the sniffing programs I am aware
> Crist> of use set{g,u}id bits. They rely on the permissions of the
> Crist> user running them.
>
> Sorry -- keyboard and brain disconnect on my part. What I was trying to
> get at was the need to run sniffers as root by default. The fewer
> things that need to be run as root, the better (e.g. I don't want snort
> and trafdump running as root on my firewalls if I can avoid it).
> Programs like snort can attempt to lose uid-0 after opening the bpf
> device, but others like tcpdump do not.
>
> As David Wolfskill mentioned in a previous message, this idea is the
> same as how the operator group is used for dump. kmem did the same
> thing for ps and top.
These are actually very different in that they are set{u,g}id commands
(well, ps(1) is not set{u,g}id anymore and is root:wheel owned). The
sniffing tools we've been discussing, and pretty much all of the ones
I've used, tcpdump(1), snort(8), nmap(1), etc., are not. When
tcpdump(1) or one of these ports is installed, there is no reason to
give it any special group ownership. The thing that determines whether
someone can sniff is the {u,g}id of the user executing the
command. The port's Makefile doesn't need to know anything about your
/etc/group; it just installs the file -r-xr-x-r-x root:wheel. The
local administrator simply needs to execute the simple commands I put
in my last mail to give a group sniffing powers. The files'
permissions and ownership are never changed.
Since the ports would really make no use of a preordained 'bpf' group,
I still don't see what purpose it really serves to add one. I really
hesitate to add groups and change default ownerships after seeing the
_steady_ stream of mail that the smmsp:smmsp ownership of
/var/spool/mqueue the sendmail(8) upgrade created.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Sat, Apr 20, 2002 at 04:02:13PM -0600, Lyndon Nerenberg wrote:
> >>>>> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
>
> Crist> I do this a lot too on systems where it makes sense. But I'm
> Crist> not sure I understand what you are asking to be done. Is it
> Crist> asking too much of an administrator to do,
>
> There are two ways to handle this. One is to modify the ports builds to
> conditionally create a 'bpf' group. This requires the ports all agree
> on the group, and I don't like the idea of a port install messing with
> permissions and ownerships of things in /dev (which aren't sticky across
> reboots, anyway). If the OS sets the access policy there cannot be any
> confusion.
OK. Now you've really lost me. What do ports have to do with this?
Which ports? None of the sniffing programs I am aware of use
set{g,u}id bits. They rely on the permissions of the user running
them.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Sat, Apr 20, 2002 at 03:39:14PM -0600, Lyndon Nerenberg wrote: > For the benefit of packet sniffers and other things that only want > read-only access to /dev/bpf*, what do people think of adding a 'bpf' > group for those programs? This allows bpf devices to be read by > programs running with an effective gid of 'bpf' instead of the current > requirement for an effective user of root. I've been running this way > on many of our servers for several months now, and things like snort, > tcpdump, etc., are quite happy with it (under stable). I do this a lot too on systems where it makes sense. But I'm not sure I understand what you are asking to be done. Is it asking too much of an administrator to do, # echo 'sniff:*:80:' >> /etc/group # chown root:sniff /dev/bpf* # chmod 640 /dev/bpf* To do the appropriate customizations? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Couple of weird messages in logs, and crashing to debuggier.
On Sat, Apr 13, 2002 at 04:50:44AM -0400, Jason wrote: > After finally getting machine to stop crashing, I noticed these, no clue > what they mean Any ideas > > link_elf: symbol pfil_add_hook undefined This is the ipl.ko (IPFilter) kernel module failing to load. It is currently broken. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Tue, Apr 02, 2002 at 10:52:07PM -0800, Terry Lambert wrote: > Quite the thread from hell... ;^)... This is nuthin'. But one reason it continues is... > Peter Wemm wrote: > > Using buildkernel/installkernel is your biggest mistake. It is no secret > > what I think of those two targets. > > I have to agree with this. They are attempts to idiot-proof > something that can't be idiot-proofed, because idiots are so > cunning. 8-). > > The real problem here is that these targets are such monsters > that they really can't be cross-targets. The doc stuff is > particularly nasty, viben that there are maybe 19 sets of > packages that have to be sucked down and installed to make > it work, because they aren't part of the default system, and > they aren't in the source repository. When the FTP.freebsd.org > blew up a while back, the only place you could get the tools > the the proper versions was a combination of a site in England, > a sunsite site, and two personal directories that lived on a > machine in Japan. Where'd this observation come from? buildkernel/installkernel don't pull packages from anywhere. Building the doc tree has almost nothing to do with building world or kernel from the source tree. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Tue, Apr 02, 2002 at 04:45:13PM -0800, Peter Wemm wrote:
> "Crist J. Clark" wrote:
> > On Mon, Apr 01, 2002 at 03:07:46PM -0800, Terry Lambert wrote:
> > > "Crist J. Clark" wrote:
> > > > This whole argument ignores what the real problem is. The really
> > > > correct way to handle this is to use the kldxref(8) built in the
> > > > 'buildworld' phase. (It's bad form to be using any executables from
> > > > the base system if we have a full object tree.) Actually using the one
> > > > in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better
> > > > thing to do is to have a version in /usr/obj/usr/src//usr/sbin
> > > > by making it a crosstool. The failure should not be ignored in this
> > > > case.
> > >
> > > Uh, that doesn't work incredibly well when the machine you
> > > are on is an x86, and the machine that the buildworld targets
> > > is, say, the Alpha.
> > >
> > > This came up in the first place because it's a cross-envrionment
> > > issue that needs resolving. The "workaround" exists because the
> > > workaround cops out on the cross-environment part of the process
> > > and spits out the warnming, instead.
> >
> > An 'installworld' doesn't even come close to working in a cross
> > environment for a whole variety of reasons, so I don't see the
> > relevance.
>
> It used to. If it no longer works, it should be fixed. I partially do this
> for cross-architecture builds quite often where the target system is NFS
> mounted somewhere.
If it ever worked, without actually digging into the history, I would
guess that it was because it only used existing binaries in the host
environment to run the install. However, now a (somewhat half-baked)
effort is made to use newly built tools to do the install, rather than
the ones already on the host.
But that's somewhat of a digression. 'installkernel' will work in the
cross-platform case. It doesn't try to use build tools, but the tools
in the system.
> kldxref however, does not have any cross capability, and is just a hint
> mechanism even then. It is not essential to run it.
I don't think it is essential either, but it does break module
auto-loading until someone does run it. And this whole thread started
because people don't think the error message is asthetically pleasing.
But to hopefully put an end to some of the idle chatter here, here are
patches to build a working kldxref(8) on 4-STABLE and 5-CURRENT in the
the cross-tool phase. The 'installkernel' of a 5-CURRENT build on
4-STABLE system should not error on kldxref(8).
Yes, it is a kludge. Comments?
Index: src/Makefile.inc1
===
RCS file: /export/freebsd/ncvs/src/Makefile.inc1,v
retrieving revision 1.246
diff -u -r1.246 Makefile.inc1
--- src/Makefile.inc1 26 Mar 2002 16:05:09 - 1.246
+++ src/Makefile.inc1 3 Apr 2002 05:54:54 -
@@ -457,7 +457,9 @@
#
installkernel:
cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \
- ${CROSSENV} ${MAKE} KERNEL=${INSTKERNNAME} install
+ ${CROSSENV} \
+ PATH=${PATH}:${STRICTTMPPATH} \
+ ${MAKE} KERNEL=${INSTKERNNAME} install
reinstallkernel:
cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \
${CROSSENV} ${MAKE} KERNEL=${INSTKERNNAME} reinstall
@@ -619,7 +621,8 @@
cross-tools:
.for _tool in ${_btxld} ${_elf2exe} \
-gnu/usr.bin/binutils usr.bin/objformat gnu/usr.bin/cc ${_xlint}
+gnu/usr.bin/binutils usr.bin/objformat gnu/usr.bin/cc ${_xlint} \
+usr.sbin/kldxref
cd ${.CURDIR}/${_tool}; \
${MAKE} obj; \
${MAKE} depend; \
Index: src/sys/modules/Makefile
===
RCS file: /export/freebsd/ncvs/src/sys/modules/Makefile,v
retrieving revision 1.236
diff -u -r1.236 Makefile
--- src/sys/modules/Makefile21 Mar 2002 09:15:38 - 1.236
+++ src/sys/modules/Makefile3 Apr 2002 01:57:18 -
@@ -184,7 +184,7 @@
.if !defined(NO_XREF)
.MAKEFLAGS:= ${.MAKEFLAGS} -DNO_XREF
afterinstall:
- -kldxref ${DESTDIR}${KMODDIR}
+ kldxref ${DESTDIR}${KMODDIR}
.endif
.include
Index: src/usr.sbin/kldxref/Makefile
===
RCS file: /export/freebsd/ncvs/src/usr.sbin/kldxref/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- src/usr.sbin/kldxref/Makefile 10 Dec 2001 21:13:35 - 1.4
+++ src/usr.sbin/kldxref/Makefile 3 Apr 2002 05:05:09 -
@@ -5,4 +5,11 @@
WARNS?=2
MAN= kldxref.8
+.if defined(BOOTSTRAPPING)
+CFLAGS+= -I${.CURDIR}/../../sys -I.
+mach
Re: kldxref problem
On Mon, Apr 01, 2002 at 06:08:40PM -0800, Terry Lambert wrote: > "Crist J. Clark" wrote: > > > This came up in the first place because it's a cross-envrionment > > > issue that needs resolving. The "workaround" exists because the > > > workaround cops out on the cross-environment part of the process > > > and spits out the warnming, instead. > > > > An 'installworld' doesn't even come close to working in a cross > > environment for a whole variety of reasons, so I don't see the > > relevance. > > > > The situation this question comes up is typically 5-CURRENT builds on > > 4-STABLE systems, not in cross-archetecture builds. > > Since this is the recommended upgrade path for going from 4.x > to 5.x right now, it's an issue, if you can't cross-build 5.x > on 4.x. You can't do it with 4.x .h-files. You need to use 5-CURRENT headers. The cross-tools phase, stage 3, uses the host system's headers. > That other things are broken doesn't really excuse this being > broken. > > The problem is that the kldxref deserves to get its own tools > build, so that there is a version that works against 5.x code > that can be built on 4.x (or NetBSD or Linux or Solaris or > whatever). It builds fine on 4.x as long as you use the correct headers. It appears to run fine on 4.x too. It's just that you pretty much need to add a new stage to the build process. A stage where one builds cross-tools with the new header files. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Mon, Apr 01, 2002 at 03:07:46PM -0800, Terry Lambert wrote: > "Crist J. Clark" wrote: > > This whole argument ignores what the real problem is. The really > > correct way to handle this is to use the kldxref(8) built in the > > 'buildworld' phase. (It's bad form to be using any executables from > > the base system if we have a full object tree.) Actually using the one > > in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better > > thing to do is to have a version in /usr/obj/usr/src//usr/sbin > > by making it a crosstool. The failure should not be ignored in this > > case. > > Uh, that doesn't work incredibly well when the machine you > are on is an x86, and the machine that the buildworld targets > is, say, the Alpha. > > This came up in the first place because it's a cross-envrionment > issue that needs resolving. The "workaround" exists because the > workaround cops out on the cross-environment part of the process > and spits out the warnming, instead. An 'installworld' doesn't even come close to working in a cross environment for a whole variety of reasons, so I don't see the relevance. The situation this question comes up is typically 5-CURRENT builds on 4-STABLE systems, not in cross-archetecture builds. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Mon, Apr 01, 2002 at 12:35:21AM -0800, David O'Brien wrote: > On Sun, Mar 31, 2002 at 12:38:24PM +0200, Emiel Kollof wrote: > > On Sun, 2002-03-31 at 09:51, Terry Lambert wrote: > > > > > > > > Perhaps if the kernel printf also "ignored" the request to print > > > the little S.O.B. out, there would be less confusion... > > > > I'm still sticking to the idea that one could test for kldxref, and if > > it isn't there, don't execute it. > > > > [ -x /usr/sbin/kldxref ] && /usr/sbin/kldxref > > > > like so, which is perfectly sane bourne shell syntax, which is also used > > by BSD make. > > Not really. Use: > > : > rule1 > rule2 > .if exists(/usr/sbin/kldxref) > /usr/sbin/kldxref > .endif This whole argument ignores what the real problem is. The really correct way to handle this is to use the kldxref(8) built in the 'buildworld' phase. (It's bad form to be using any executables from the base system if we have a full object tree.) Actually using the one in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better thing to do is to have a version in /usr/obj/usr/src//usr/sbin by making it a crosstool. The failure should not be ignored in this case. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installing Cross Builds
On Sun, Mar 31, 2002 at 05:57:31PM -0800, Marcel Moolenaar wrote:
> On Fri, Mar 29, 2002 at 01:10:17PM -0800, Crist J. Clark wrote:
> > After reviewing the world Makefiles, it sure looks like FreeBSD does
> > not support 'installworld' of a cross build?
>
> Running installworld on machine X, when you did a cross-build for
> machine X on machine Y is broken. All other cases should work,
> AFACT.
>
> The brokenness is directly caused by inconsistent setting of OBJTREE.
> This is indirectly caused make release, for make release expects the
> object tree to be under /usr/obj and not /usr/obj/${TARGET_ARCH}.
Well, the more direct reason for the breakage is caused by the fact
that the PATH during install is,
${WORLDTMP}/usr/sbin:${WORLDTMP}/usr/bin:${WORLDTMP}/usr/games:${INSTALLTMP}
Which is usually ${OBJTREE}${.CURDIR}/${MACHINE_ARCH}. But that
directory doesn't exist. (Or is that what you are saying?) If you fix
that, there is the same issue with ${OBJFORMAT_PATH}. Once you fix
that, you have shared lib problems. (I've never quite figured out what
${INSTALLTMP} is even there for.)
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Installing Cross Builds
After reviewing the world Makefiles, it sure looks like FreeBSD does not support 'installworld' of a cross build? There are some steps in the installworld which half-heartedly seem to try to support something along those lines, but don't really even come close. Am I correct that installworld doesn't work for cross builds? If not, I need to figure out what the heck I'm doing wrong. If I am right, I guess that means not too many people are interested in such a feature? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
nfsclient module panics
For a couple of days, I have been consistent panics whenever I mount an NFS filesystem on a newly made -CURRENT. Things seem to work fine when NFS is actually built into the kernel. But when mount(8) is auto loading the nfsclient.ko module, I get an immediate panic when something actually tries to access the filesystem, IdlePTD at phsyical address 0x00411000 initial pcb at physical address 0x00340ac0 panicstr: bdwrite: buffer is not busy panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc2 fault code = supervisor read, page not present instruction pointer = 0x8:0xc942baeb stack pointer = 0x10:0xc8ea1c10 frame pointer = 0x10:0xc8ea1cbc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 7 (syncer) trap number = 12 panic: page fault syncing disks... panic: bdwrite: buffer is not busy Uptime: 2m10s dumping to dev ad0s2b, offset 264864 dump ata0: resetting devices .. done 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc01b6b8a in dumpsys () Is this a known issue (I haven't noted mention of it on here) or does someone want to see some more debugging info? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Broken bktr(4) module
I believe the recent changes to the bktr(4) module Makefile broke it, ===> bktr ===> bktr/bktr make: don't know how to make smbus.h. Stop *** Error code 2 Stop in /usr/src/sys/modules/bktr. *** Error code 1 . . . A fresh checkout on freefall still seems to have this problem. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Building 5.0 on 4.5 Broken in xlint?
On Thu, Mar 21, 2002 at 11:17:18AM +0900, À强ȣ wrote: > Because I'm not a development only a sysadmin, > the next workaround would not fit in your case. :) > > Check out where you already have libc.so.t in /usr/obj/usr/src/lib/libc or > not. > If you have one, copy it into /usr/lib and 'make -DNOCLEAN buildworld' or > 'buildkernel' again. > If you don't, compile only libc.so.5 in /usr/src/lib/libc. It will make > libc.so.5 > in /usr/obj blah,blah, tree... Now you have one... Well, yeah, I could do that, but I really don't want to put a libc.so.5 in the -STABLE system. And I shouldn't be getting that error. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Building 5.0 on 4.5 Broken in xlint?
Looks like the correct lib hints aren't being used in the buildworld? Am I the only one? I'm setting MAKEOBJDIRPREFIX (properly, in the environment). ===> usr.bin/xlint/llib /c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint -cghapbx -L /usr/libdata/lint -Cposix /c/home/src/usr.bin/xlint/llib/llib-lposix /c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint -cghapbx -L /usr/libdata/lint -Cstdc /c/home/src/usr.bin/xlint/llib/llib-lstdc /usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found /usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found *** Error code 1 *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Unexpected Soft Update Inconsistency"
On Wed, Mar 20, 2002 at 07:20:52AM +0100, Poul-Henning Kamp wrote: > > Sounds like your disklabel is smaller than your filesystem ? Huh. That's what it looks like. "How'd that happen?"(tm) I don't recall ever touching the disklabel since the install. Oh, well. There was enough spare room on the disk to do a bare-bones OS install on an open slice, backed up the bad filesystem and the others on the slice, repartitioned the slice a little better now that I have a feel for how the system will be used, newfs'ed all of the partitions, and restored. > In message <[EMAIL PROTECTED]>, "Crist J. Clark" writes > : > >I've got a -CURRENT system that is seriously resisting attempts to > >revive it. No matter how many times I run fsck(8), it tells me, > > > >** /dev/ad0s1a > >** Last Mounted on / > >** Root file system > >** Phase 1 - Check Blocks and Sizes > > > >CANNOT READ BLK: 8407744 > >UNEXPECTED SOFT UPDATE INCONSISTENCY > > > >CONTINUE? yes > > > >THE FOLLOWING DISK SECTORS COULD NOT BE READ: 8407744, 8407745, 8407746, 8407747, >8407748, 8407749, 8407750, 8407751, 8407752, 8407753, 8407754, 8407755, 8407756, >8407757, 8407758, 8407759, > >** Phase 2 - Check Pathnames > >** Phase 3 - Check Connectivity > >** Phase 4 - Check Reference Counts > >** Phase 5 - Check Cyl groups > >133720 files, 1429523 used, 2651122 free (34074 frags, 327131 blocks, 0.8% >fragmentation) > > > >***** FILE SYSTEM STILL DIRTY * > > > >* PLEASE RERUN FSCK * > > > >There are no reports of hard errors, so I believe this is purely a > >"soft" error. Any advice on how to fix? > >-- > >Crist J. Clark | [EMAIL PROTECTED] > > | [EMAIL PROTECTED] > >http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] > >with "unsubscribe freebsd-current" in the body of the message > > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"Unexpected Soft Update Inconsistency"
I've got a -CURRENT system that is seriously resisting attempts to revive it. No matter how many times I run fsck(8), it tells me, ** /dev/ad0s1a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes CANNOT READ BLK: 8407744 UNEXPECTED SOFT UPDATE INCONSISTENCY CONTINUE? yes THE FOLLOWING DISK SECTORS COULD NOT BE READ: 8407744, 8407745, 8407746, 8407747, 8407748, 8407749, 8407750, 8407751, 8407752, 8407753, 8407754, 8407755, 8407756, 8407757, 8407758, 8407759, ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 133720 files, 1429523 used, 2651122 free (34074 frags, 327131 blocks, 0.8% fragmentation) * FILE SYSTEM STILL DIRTY * * PLEASE RERUN FSCK * There are no reports of hard errors, so I believe this is purely a "soft" error. Any advice on how to fix? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
disklabel(8) floppy panic
Have a crash box handy? $ disklabel fd0.1440 -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.5->5.0 kldxref:No such file or directory
On Wed, Mar 13, 2002 at 04:13:35AM +0100, Emiel Kollof wrote:
> * Crist J. Clark ([EMAIL PROTECTED]) wrote:
> > > *** Error code 1 (ignored)
> > >^
> >
> > Note.
> >
> > > Since there is no kldxref in 4.5, this should probably included in
> > > the bootstrap process somehow.
> >
> > A known issue. The install process deliberately ignores this as a
> > non-fatal error.
>
> Why not test for it like this (or similar):
>
> [ -x /usr/sbin/kldxref ] && /usr/bin/kldxref (etcetera...)
>
> If the new CURRENT testers upgrading from STABLE don't see it,
> they aren't likely to worry/complain about it. I think the warning is
> kinda nonsensical and redundant, IMHO.
The warning is just how make(1) works,
# Calling kldxref(8) for each module is expensive.
.if !defined(NO_XREF)
.MAKEFLAGS:=${.MAKEFLAGS} -DNO_XREF
afterinstall:
-kldxref ${DESTDIR}${KMODDIR}
.endif
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 4.5->5.0 kldxref:No such file or directory
On Tue, Mar 12, 2002 at 02:05:06PM -0700, [EMAIL PROTECTED] wrote: > > "make DESTDIR=/5.0 world kernel" encountered the following problem: > > [...] > -- > >>> Kernel build for GENERIC completed on Tue Mar 12 20:26:10 GMT 2002 > -- > [...] > -- > >>> Kernel build for GENERIC completed on Tue Mar 12 20:26:10 GMT 2002 > -- > cd /usr/obj/5.0/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj >MACHINE_ARCH=i3 > [...] > ===> xe > install -c -o root -g wheel -m 555 if_xe.ko /5.0/boot/kernel/ > kldxref /5.0/boot/kernel > kldxref:No such file or directory > *** Error code 1 (ignored) >^ Note. > Since there is no kldxref in 4.5, this should probably included in > the bootstrap process somehow. A known issue. The install process deliberately ignores this as a non-fatal error. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern_linker.c rev. 1.75 and newer cause loading problem
On Sat, Mar 09, 2002 at 10:13:25AM -0800, Steve Kargl wrote: > Well, I finally have narrowed the problem down to > > Revision 1.75 Fri Feb 22 04:14:49 2002 UTC (2 weeks, 1 day ago) by arr > Branch: MAIN > Changes since 1.74: +1295 -1271 lines > Diff to previous 1.74 (colored) > > - Massive style fixup. > > Reviewed by: mike > Approved by: dfr > > > > To recap: > > root[202] cat /boot/loader.conf > miibus_load="YES" > if_rl_load="YES" > snd_pcm_load="YES" > snd_maestro3_load="YES" > linux_load="YES" > agp_load="YES" > hint.acpi.0.disable="1" > root[203] kldstat > Id Refs AddressSize Name > 1 12 0xc010 262e40 kernel > 21 0xc0363000 18330linux.ko ^ > 32 0xc037c000 15480miibus.ko > 41 0xc0392000 7798 if_rl.ko > 52 0xc039a000 1a14csnd_pcm.ko > 61 0xc03b5000 9538 snd_maestro3.ko > 71 0xc03bf000 c860 agp.ko > 81 0xcb052000 2000 blank_saver.ko > root[204] kldload linprocfs > kldload: can't load linprocfs: Exec format error > root[206] tail -1 /var/log/messages > Mar 9 10:00:27 kernel: KLD linprocfs.ko: depends on \ > linux - not available > > root[209] kldunload linux > root[210] kldload linux > root[211] kldload linprocfs > root[213] kldstat > Id Refs AddressSize Name > 1 15 0xc010 262e40 kernel > 32 0xc037c000 15480miibus.ko > 41 0xc0392000 7798 if_rl.ko > 52 0xc039a000 1a14csnd_pcm.ko > 61 0xc03b5000 9538 snd_maestro3.ko > 71 0xc03bf000 c860 agp.ko > 81 0xcb052000 2000 blank_saver.ko > 92 0xcb425000 14000linux.ko ^ > 101 0xcab88000 5000 linprocfs.ko Are you sure the same module is being loaded? $ find -x / -name linux.ko -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 05:42:10PM +0100, Riccardo Torrini wrote:
> On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote:
>
> > How does one change the permissions on dynamically created
> > devices? That is, when the node comes into existence, it has
> > the permissions I want, and not necessarily the defaults.
>
> You can (must?) use /etc/rc.devfs
>
> [...]
> # Setup DEVFS, ie permissions, links etc.
> [...]
I think some people missed the point of the earlier question. My
problem is with devices that are created dynamically as they get
used.
I can put,
chmod 640 /dev/bpf{0,1,2,3}
In rc.devfs, and I will have joy for the first four bpf(4)
devices. That command creates them and gives them the permissions I
want. However, once someone tries to use /dev/bpf4, a new device is
dynamically created with the default permissions, not the permissions
I want.
But creating 'n' devices at boot will do for now (especially since we
used to be restricted to 'n' bpf(4) devices in the kernel
configuration, so it almost resembles historic behavior).
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
devfs(5) Permissions
I've checked the manpages, the files in /etc, and Googled, and I can't find the answer. I am begining to worry there isn't one. How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. My example is the bpf(4) device. The node only comes into existence the first time you try to use it. I want to give a certain group read permission to the device. There are terrible, terrible, ugly ways to work around this (some kind of script run at startup to create 'n' bpf(4) devices and which then modifies the permissions), but it would be much easier to be able to tell the system what the default permissions are. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NetBSD-style rc.d Project
Looking at the repository, I have not really seen anything done with building a NetBSD-style rc.d system that will provide FreeBSD functionality for a long time. In fact, I can find very little aside from the initial import. I also noticed there was no mention in the last Monthly Report. Did any of the stuff in the September report actually happen? The Yahoo! group seems pretty quiet. All of the stuff is there in HEAD, but is there a tag for this work? If not, I really think one would be needed. Or is there some work in p4 going on with this? (I'm just asking, I don't want to start another flame war about p4 and revision control.) Do people have work on this in local trees that they have not committed? I spent some time in the fall learning the NetBSD system (unfortunately I'm not running any NetBSD boxes at the moment or this would probably be a _lot_ easier), but have not really done any work. I thought some people were working on it, but not in the tree. I did not want to duplicate or conflict with work already done elsewhere. Is this project dead? Just lost momentum? Anyone still have interest in it? Is there anyone who really thinks we'll have switched to this by 5.0-RELEASE? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Install World fails in -Current
On Fri, Feb 22, 2002 at 10:25:03PM -0500, John Baldwin wrote:
>
> On 23-Feb-02 Dag-Erling Smorgrav wrote:
> > David Wolfskill <[EMAIL PROTECTED]> writes:
> >> Sounds like a botched (or not run) "mergemaster" execution:
> >
> > No - mergemaster will croak because it runs mtree to build its temp
> > directory, so if you're trying to update a pre-smmsp system you have
> > to add the smmsp user and group manually.
>
> I think this is a bug but can't think of a clean way to work around it.
I can think of a two "clean" ways... but it ain't pretty.
1) Do not enter users in the BSD.*.dist files by 'uname,' but only
by 'uid.' But this makes the files more difficult to maintain and
generally icky.
2) Keep 'uname's in BSD.*.dist files, but use the distributed
src/etc/master.passwd to process the BSD.*.dist files into a
format with 'uid's on the fly during buildworld-installworld.
These versions would only be built during buildworld and only
used by the mtree(8) commands during installworld. The source
BSD.*.dist files would be the ones actually installed of course.
Obviously, one could do the same with groups.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Minor rc.firewall{,6} Change
I just made a few _minor_ changes to the rc.firewall{,6} scripts. The
vast majority of users will not be affected. However, since a few may
be, and this is a security issue with the potential to cause some
subtle breakage, I felt a small HEADS UP was in order. (For the very
security conscious and paranoid, note that this change can only
"fail-safe" if people apply it blindly. You'll be "more secure," but
it may break stuff.)
If you do not use firewalling or rc.firewall{,6} at all (that is, you
do not have 'firewall_enable="YES"' and/or
'ipv6_firewall_enable="YES"') or if you use custom rc.firewall{,6}
scripts, you are not affected. Two groups of people who use the
provided firewall scripts are affected:
1) Those who put a rules file in the 'firewall_type' variable, or
2) Those who put a non-existent type in the 'firewall_type' variable.
In both cases, you will no longer get the rules,
100 pass all from any to any via lo0
200 deny all from any to 127.0.0.0/8
300 deny ip from 127.0.0.0/8 to any
In rc.firewall, and,
100 pass all from any to any via lo0
200 pass ipv6-icmp from :: to ff02::/16
300 pass ipv6-icmp from fe80::/10 to fe80::/10
400 pass ipv6-icmp from fe80::/10 to ff02::/16
In rc.firewall6 added to your firewall by the system scripts.
If you are in group (1), you should add whatever rules like these
_you_ want for _your_ site into your rule file. If you are in group
(2), use 'firewall_type="closed"' (which now works as advertised) will
give you the same effect as your current configuration.
The motivation for the change was mainly for the people in group
(1). Up until now, those rules were added _unconditionally_ by the
rc.network{,6} scripts. For people who want to define their own
rulesets outside of the simple ones provided in the rc.firewall{,6}
scripts, the system should make NO assumptions about your site's
policy and be adding rules.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Wed, Feb 13, 2002 at 11:03:47AM +0200, Ruslan Ermilov wrote: > Hi! > > Please test with and without this patch. Hmm. I'm having a little trouble testing this on -CURRENT. As a first step, I just deleted all of the 127/8 blocking code in ip_output.c, and tried to do a rdr to 127.0.0.1. First, make sure the stops on outging 127/8 are really gone, bubbles# ping 127.0.0.2 PING 127.0.0.2 (127.0.0.2): 56 data bytes ^C --- 127.0.0.2 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss bubbles# And I see, bubbles# tcpdump 'net 127.0.0.0/8' tcpdump: listening on ep0 15:46:29.954112 bubbles > 127.0.0.2: icmp: echo request 15:46:30.964695 bubbles > 127.0.0.2: icmp: echo request ^C 46 packets received by filter 0 packets dropped by kernel bubbles# OK, all great. So I fire up ipnat(1), bubbles# cat ipnat.rules # $Id$ # # Testing IPFilter interaction with loopback rdr ep0 192.168.64.20/32 port 23 -> 127.0.0.1 port 2323 tcp bubbles# ipnat -C -f ipnat.rules 1 entries flushed from NAT list bubbles# ipnat -l List of active MAP/Redirect filters: rdr ep0 192.168.64.20/32 port 23 -> 127.0.0.1 port 2323 tcp List of active sessions: bubbles# ipfstat -io pass out from any to any pass in from any to any bubbles# And I start a listener on 2323, $ nc -l -p 2323 And from another host, $ telnet bubbles 23 Trying 192.168.64.20... telnet: connect to address 192.168.64.20: Operation timed out telnet: Unable to connect to remote host That is, it doesn't work. However, bubbles# ipnat -l List of active MAP/Redirect filters: rdr ep0 192.168.64.20/32 port 23 -> 127.0.0.1 port 2323 tcp List of active sessions: RDR 127.0.0.1 2323 <- -> 192.168.64.20 23[192.168.64.60 1099] ipnat(1) is working. Where are the packets going? I couldn't find any being blocked or in the netstat statistics. Now, to see if this works at all, I change the ipnat.rules, bubbles# cat ipnat.rules # $Id$ # # Testing IPFilter interaction with loopback rdr ep0 192.168.64.20/32 port 23 -> 192.168.64.20 port 2323 tcp bubbles# ipnat -C -f ipnat.rules 1 entries flushed from NAT list bubbles# Now I try, $ telnet bubbles 23 Trying 192.168.64.20... Connected to bubbles.cjclark.org. Escape character is '^]'. And it works fine, bubbles# ipnat -l List of active MAP/Redirect filters: rdr ep0 192.168.64.20/32 port 23 -> 192.168.64.20 port 2323 tcp List of active sessions: RDR 192.168.64.20 2323 <- -> 192.168.64.20 23[192.168.64.60 1100] RDR 127.0.0.1 2323 <- -> 192.168.64.20 23[192.168.64.60 1099] bubbles# So at least in -CURRENT, did this 127.0.0.1 redirect doesn't seem to work even if you remove the code from ip_output.c completely. I'll give -STABLE a try, but these IPFilter people will have the same problem when 5.0-RELEASE comes around if my tests are accurate. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mergemaster niggle
On Wed, Feb 06, 2002 at 02:13:08PM -0600, David W. Chapman Jr. wrote: > > What I think mergemaster should do is compere the file with the original > > checked out one it claims to be and if it's the same, it should just > > update silently.. i.e. if the user didn't change anything in th old one > > he's unlikely to want to change anything in the new one > > > > (maybe a datafile that contains cksum outputs for each version of each > > file) > > > > I think part of the problem(from what I'm hearing on irc), someone made a > lot of commits to etc which weren't supposed to happen, but I cannot confirm > all > the facts at the moment. *Raises hand.* I had a botched cvs(1) command line run away and did some forced commits on /etc files. You would only have seen it if you updated over a few hour stretch; the Repo Lords fixed it. You lucked out and must have updated during the window. ;) Note that if you look at your diff, the revision number went _backwards._ -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: size of /usr/src
On Wed, Jan 16, 2002 at 01:02:31AM -0800, Joel M. Baldwin wrote: > > My current /usr/src is 524M. That include 83M of kernel > object files in /usr/src/sys/i386/compile from a couple > of different kernel builds. /usr/obj which holds the > object files from a buildworld is 460M. If you're going > to do a full cvs repository then /home/ncvs on my system > is 1391M. Hmmm... $ du -kd 0 /export/stable/src 315854 /export/stable/src $ du -kd 0 /export/stable/src 383116 /export/stable/src $ du -kd 0 /export/ncvs 1248390 /export/ncvs -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sftp and lastlog
On Mon, Dec 17, 2001 at 08:55:59PM +, David Hill wrote: > Hello - > Currently, if a user logs in using sftp, it does not log that user to the lastlog. >In my opinion, I think it should log the connection. > > Is this how it is supposed to be? Yes. You only see an entry in last(1) when there is tty allocation. For example, try, $ ssh -T host And have a look at the last(8) on host. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: periodic(8)-ifying daily security checks
On Fri, Dec 07, 2001 at 03:58:05PM -0800, Crist J . Clark wrote: [snip] > For those who do not have the time to do this the really quick work > around is, Oops, in my haste I forgot to put the very easiest workaround, don't update /etc/periodic/daily/450.status-security. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: periodic(8)-ifying daily security checks
I have just committed changes to how the daily security checks are done in -CURRENT. Long ago, there was just /etc/daily. Then /etc/security was split out of /etc/daily. Some time later, /etc/daily became a set of periodic(8) scripts. Now, this evolution continues, and /etc/security has been broken into periodic(8) scripts to make local customization easier and more maintainable. However, like any change, there may be some problems making the transition to the new system. If you are using the default /etc/security, the change will be transparent. Next time you update, mergemaster(8) will take care of everything for you. Note that /etc/security will no longer be used in any way, it can safely be removed. If you have local customizations to /etc/security, the best thing to do and the ultimate way to fix things "properly" is to break out the customizations into small scripts and drop the scripts into /usr/local/etc/periodic/security. Make sure the scripts are set executable and ls(1) in the order you wish them to execute. If your customizations are separate from the actions in the default /etc/security, this is all you need to do. If you have made customizations to actions in /etc/security, drop your customized script into /usr/local/etc/periodic/security, and then deactivate the default script with the same action by placing the appropriate, daily_status_security_
Re: daily run output & passwd diff
On Tue, Nov 13, 2001 at 02:31:48PM -0800, John Baldwin wrote: > > On 13-Nov-01 Robert Watson wrote: > > > > On Tue, 13 Nov 2001, John Baldwin wrote: > > > >> > My temptation would actually be to ignore any commented lines in either > >> > file for the purposes of the diff. For the purposes of security checking, > >> > you care mostly about the uncommented lines. This would allow the script > >> > to exclude content when it didn't understand its semantics (and hence > >> > might risk revealing information it wasn't intended to). > >> > >> So if some (admittedly weird) sysadmin temporarily comments out a > >> password line then the next day we will broadcast that crypted password > >> in plaintext e-mail? > > > > Not sure I follow. I was suggesting that any line beginning with '#' be > > excluded from the diffing, since the script can't know if information in > > the comment is sensitive or not, and therefore can't censor it. > > > > I.e., the conceptual equivilent of: > > > > grep -v '^#' master.passwd > master.passwd.tmp > > grep -v '^#' master.passwd.bak > master.passwd.bak.tmp > > diff -u master.passwd.bak master.passwd > > > > If an entry was commented out, then uncommented, then both events would > > show up, just as removal/addition. > > > > I could be missing something, of course :-). > > Oh. Hmm. That could work I suppose... Index: /export/current/src/etc/periodic/daily/200.backup-passwd === RCS file: /export/ncvs/src/etc/periodic/daily/200.backup-passwd,v retrieving revision 1.9 diff -u -r1.9 200.backup-passwd --- /export/current/src/etc/periodic/daily/200.backup-passwd11 Nov 2001 07:15:19 - 1.9 +++ /export/current/src/etc/periodic/daily/200.backup-passwd13 Nov 2001 23:27:50 +- @@ -41,8 +41,8 @@ then [ $rc -lt 1 ] && rc=1 echo "$host passwd diffs:" - diff $bak/master.passwd.bak /etc/master.passwd |\ - sed 's/^\([<>] [^#][^:]*\):[^:]*:/\1:(password):/' + diff -I '^#' $bak/master.passwd.bak /etc/master.passwd |\ + sed 's/^\([<>] [^:]*\):[^:]*:/\1:(password):/' mv $bak/master.passwd.bak $bak/master.passwd.bak2 cp -p /etc/master.passwd $bak/master.passwd.bak || rc=3 fi Good for everyone? The only odd thing about this is that the cmp(1) that causes this code to be executed can find differences that the diff(1) will ignore. I think this is a feature. You still get your old master.passwd(5) file backed up whenever there is _any_ change, but you get shown that nothing security-wise has changed with the empty diff(1). But it may be confusing to some. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: daily run output & passwd diff
On Mon, Nov 12, 2001 at 10:19:31PM -0800, John Baldwin wrote:
>
> On 13-Nov-01 Crist J. Clark wrote:
> >> What if someone comments out a line in the password file of a user? Then
> >> this
> >> won't hide that password. When this originally went in, it took a long
> >> while
> >> to get a sed line people were happy with. Replacing the version number is a
> >> minor thing, but getting it to work perfectly may be a bit difficult. If
> >> you
> >> do this, I'd rather you make sed handle the $FreeBSD$ case as a completely
> >> separate case, so something like:
> >>
> >> sed -e '/\$FreeBSD\$/; //s/blah blah/blah/' or some such (I forget how sed
> >> does
> >> multiple expressions).
> >
> > I thought about this, but then thought, "Who ever just comments out
> > password entries without clearing the password too?" I guess the
> > answer is, some people do.
> >
> > How about,
> >
> > sed -E 's/^([<>]
> > [^:]*):[^:]*:(([0-9]+:){2}[^:]*(:[0-9]+){2}(:[^:]*){3}$)/\1:(password)\2/'
> >
> > Which only touches entries that match the password format exactly, but
> > includes commented out ones?
>
> That's fine I suppose. I would rather err on the side of caution and just
> exclude the $FreeBSD$ line and perform the change on all other lines by
> default. You never know what weird contortion of a password file someone
> might be using.
I look at it the same way, but from the other side. I would like to
err on the side of caution and only mangle lines that look like a
passwd(5) entry. Afterall, if it doesn't really look like a passwd(5)
entry, (a) it probably has no password to hide and (b) if it does,
there is no reason to believe that we are even going to find and cover
the password with the existing sed(1) line.
However, thinking about it more, loosening up the regex so it isn't
fixed to the begining and end of the line,
sed -E 's/([^:]*):[^:]*:(([0-9]+:){2}[^:]*(:[0-9]+){2}(:[^:]*){3})/\1:(password):\2/'
May be a good idea. I'll put this new one in tomorrow unless someone
has better suggestion.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: daily run output & passwd diff
On Mon, Nov 12, 2001 at 08:08:37AM -0800, John Baldwin wrote:
>
> On 11-Nov-01 Crist J. Clark wrote:
> > On Fri, Nov 09, 2001 at 02:55:55PM +0100, Alexander Leidinger wrote:
> >> Hi,
> >>
> >> I think the CVS tag shouldn't be interpreted as an entry which contains
> >> a password.
> >>
> >> ---snip---
> >> Backup passwd and group files:
> >>
> >> 1c1
> >> < # $FreeBSD:(password):09:07 peter Exp $
> >> ---
> >> > # $FreeBSD:(password):27:16 ache Exp $
> >> 16a17
> >> > www:(password):80:80::0:0:World Wide Web Owner:/nonexistent:/sbin/nologin
> >> Magelan.Leidinger.net group diffs:
> >> 1c1
> >> < # $FreeBSD: src/etc/group,v 1.21 2001/10/18 16:53:20 sheldonh Exp $
> >> ---
> >> > # $FreeBSD: src/etc/group,v 1.22 2001/10/25 03:27:16 ache Exp $
> >> 20a21
> >> > www:*:80:
> >> ---snip---
> >
> > Makes sense. No need to hide the revision number.
> >
> > Committed to -CURRENT. MFC 1 week.
> >
> > Index: 200.backup-passwd
> > ===
> > RCS file: /home/ncvs/src/etc/periodic/daily/200.backup-passwd,v
> > retrieving revision 1.8
> > diff -u -r1.8 200.backup-passwd
> > --- 200.backup-passwd 2000/09/14 17:19:10 1.8
> > +++ 200.backup-passwd 2001/11/11 07:09:49
> > @@ -42,7 +42,7 @@
> > [ $rc -lt 1 ] && rc=1
> > echo "$host passwd diffs:"
> > diff $bak/master.passwd.bak /etc/master.passwd |\
> > - sed 's/^\([<>] [^:]*\):[^:]*:/\1:(password):/'
> > + sed 's/^\([<>] [^#][^:]*\):[^:]*:/\1:(password):/'
> > mv $bak/master.passwd.bak $bak/master.passwd.bak2
> > cp -p /etc/master.passwd $bak/master.passwd.bak || rc=3
> > fi
>
> What if someone comments out a line in the password file of a user? Then this
> won't hide that password. When this originally went in, it took a long while
> to get a sed line people were happy with. Replacing the version number is a
> minor thing, but getting it to work perfectly may be a bit difficult. If you
> do this, I'd rather you make sed handle the $FreeBSD$ case as a completely
> separate case, so something like:
>
> sed -e '/\$FreeBSD\$/; //s/blah blah/blah/' or some such (I forget how sed does
> multiple expressions).
I thought about this, but then thought, "Who ever just comments out
password entries without clearing the password too?" I guess the
answer is, some people do.
How about,
sed -E 's/^([<>]
[^:]*):[^:]*:(([0-9]+:){2}[^:]*(:[0-9]+){2}(:[^:]*){3}$)/\1:(password)\2/'
Which only touches entries that match the password format exactly, but
includes commented out ones?
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: daily run output & passwd diff
On Fri, Nov 09, 2001 at 02:55:55PM +0100, Alexander Leidinger wrote: > Hi, > > I think the CVS tag shouldn't be interpreted as an entry which contains > a password. > > ---snip--- > Backup passwd and group files: > > 1c1 > < # $FreeBSD:(password):09:07 peter Exp $ > --- > > # $FreeBSD:(password):27:16 ache Exp $ > 16a17 > > www:(password):80:80::0:0:World Wide Web Owner:/nonexistent:/sbin/nologin > Magelan.Leidinger.net group diffs: > 1c1 > < # $FreeBSD: src/etc/group,v 1.21 2001/10/18 16:53:20 sheldonh Exp $ > --- > > # $FreeBSD: src/etc/group,v 1.22 2001/10/25 03:27:16 ache Exp $ > 20a21 > > www:*:80: > ---snip--- Makes sense. No need to hide the revision number. Committed to -CURRENT. MFC 1 week. Index: 200.backup-passwd === RCS file: /home/ncvs/src/etc/periodic/daily/200.backup-passwd,v retrieving revision 1.8 diff -u -r1.8 200.backup-passwd --- 200.backup-passwd 2000/09/14 17:19:10 1.8 +++ 200.backup-passwd 2001/11/11 07:09:49 @@ -42,7 +42,7 @@ [ $rc -lt 1 ] && rc=1 echo "$host passwd diffs:" diff $bak/master.passwd.bak /etc/master.passwd |\ - sed 's/^\([<>] [^:]*\):[^:]*:/\1:(password):/' + sed 's/^\([<>] [^#][^:]*\):[^:]*:/\1:(password):/' mv $bak/master.passwd.bak $bak/master.passwd.bak2 cp -p /etc/master.passwd $bak/master.passwd.bak || rc=3 fi -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref broken, maybe?
On Wed, Oct 10, 2001 at 03:52:43PM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "Crist J. Clark" writes: > : I think just running 'installworld' twice will "fix" it. The error is > : non-fatal, but not without implications. The only one that I am aware > : of is that your system might have some trouble doing kldload(8) unless > : it is given the full path of the module. > > Ummm, installworld N times won't fix things because the modules are > are installed as part of installkernel. Sorry, I meant doing the whole install process twice, but that actually would be overkill. Just a repeat of 'installkernel' after the 'installworld' would be OK. > This is a database that should be rebuilt at boot time too. Are KLDs moving around between boots? Should klxref be moved to /sbin? -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref broken, maybe?
On Wed, Oct 10, 2001 at 11:09:30AM -0700, Mark Peek wrote: > At 9:29 AM -0700 10/10/01, Bruce A. Mah wrote: > >OK, sounds good. Seems to me this is something that might deserve a > >mention in UPDATING. Something like: > > > > During a source upgrade of a 4-STABLE machine to -CURRENT, the > > installkernel step will attempt to execute a non-existent kldxref > > executable. (kldxref exists in -CURRENT, but not in 4-STABLE.) > > This error is non-fatal and can be ignored. > > That looks good. Thanks for writing it up. I'm not sure how precise you want > to be but here's a slight change to include -CURRENT upgrades. > > During a source upgrade of a 4-STABLE (or -CURRENT prior to 20010910) > machine to -CURRENT, the installkernel step will attempt to execute a > non-existent kldxref executable. (kldxref exists in -CURRENT as of > 20010910, but not in 4-STABLE.) This error is non-fatal and can be > ignored. I think just running 'installworld' twice will "fix" it. The error is non-fatal, but not without implications. The only one that I am aware of is that your system might have some trouble doing kldload(8) unless it is given the full path of the module. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: options NO_KLD
On Mon, Oct 08, 2001 at 11:48:37AM -0700, Holtor wrote: > Will this NO_KLD option be commited to > -current and then hopefully -stable? > > I have been checking the LINT file each morning > after the nightly cvsup runs hoping to find this > option in there but so far havent seen it in > sight. > > Any ideas? I got four, count 'em, four, emails from people who thought it was the neatest thang since sliced bread. I was surprised there were no flames, but none of those. (Well, one came close.) As I said, I was never planning to commit it. The illusion of security is more dangerous than knowing the problem is there. The patch makes it a little harder to get code into a running kernel, but does not come close to stopping it. As lame as securelevel(8) is, you are much better off figuring out how to raise it and still retain whatever functionality you need. This is what I've already said on -security, http://docs.freebsd.org/cgi/getmsg.cgi?fetch=297347+0+archive/2001/freebsd-security/20011007.freebsd-security And the original patches, http://docs.freebsd.org/cgi/getmsg.cgi?fetch=172366+0+archive/2001/freebsd-security/20011007.freebsd-security But hey, if people want it, I CAN JUST WRITE THE WARNINGS IN ALL CAPS IN THE NOTES FILE and try not to be disappointed when they still don't read it. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Fri, Oct 05, 2001 at 11:18:18AM +0200, Bernd Walter wrote: > On Thu, Oct 04, 2001 at 03:33:35PM -0700, Crist J. Clark wrote: > > On Fri, Oct 05, 2001 at 12:03:02AM +0200, Bernd Walter wrote: > > [snip] > > > > > > It is not that big of a deal to hack this support for named into the > > > > rc scripts. It is a hassle when considering the "correct" way to > > > > handle this to make it extensible to other daemons we may wish to run > > > > in such a manner. > > > > > > The question is what is the correct way. > > > > It happens I've just been hacking around in /etc/rc where the clean-up > > of /var/run is done, and someone else mentioned mtree(8) in this > > thread (but in a different context). I think it would be easy enough > > to run mtree(8) right after /var/run is cleaned (and long after it would > > be mounted as an md(4)) to get it into good form. The problem reduces > > to maintaining the map file for this purpose. > > It's fine for the base system but what about ports? > They don't have an mtree entry but share /var/run. I didn't say maintaining the map file was going to be easy. ;) -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Fri, Oct 05, 2001 at 12:03:02AM +0200, Bernd Walter wrote: > On Thu, Oct 04, 2001 at 01:19:15PM -0700, Crist J. Clark wrote: [snip] > > That wouldn't work. The whole point of /var/run/named is to set the > > permissions on the directory such that a non-root user (the 'bind' > > user in FreeBSD typically) can write files in the directory. In order > > to create the named directory in /var/run, you need root privs. Give > > that to the program, and we are back where we started, no point in > > using /var/run/named, just use /var/run. > > Named is startet under root rights and drop these later. > It has to be so otherwise it's not possible to open port 53 for listen. > So there is no great magic in creating the pid file in /var/run. > If that's a problem I consider it as a bug in named. You've never 'HUPped' a named running as non-root then. It will complain about not being able to write the pid file (not that it is a fatal problem). This is the reason for /var/run/named. [snip] > > It is not that big of a deal to hack this support for named into the > > rc scripts. It is a hassle when considering the "correct" way to > > handle this to make it extensible to other daemons we may wish to run > > in such a manner. > > The question is what is the correct way. It happens I've just been hacking around in /etc/rc where the clean-up of /var/run is done, and someone else mentioned mtree(8) in this thread (but in a different context). I think it would be easy enough to run mtree(8) right after /var/run is cleaned (and long after it would be mounted as an md(4)) to get it into good form. The problem reduces to maintaining the map file for this purpose. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 06:17:13PM +0200, Leif Neland wrote: > > > On Thu, 4 Oct 2001, Jun Kuriyama wrote: > > > At Thu, 4 Oct 2001 11:21:19 + (UTC), > > Bernd Walter wrote: > > > I run an md based filesystem for /var/run so it is empty after startup. > > > Does that mean that I also need to take care of creating directories in > > > it during boot - and maintaining myself on every box. > > > Or it it the responsibility of the programms to enshure that the > > > directories they need are created? > > > > /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you > > want to use md(4) for /var/run, you should make directory after > > /var/run creation. > > Is it possible to make the md-filesystem automatically make the needed > subdirectories, when a program wants to create > /var/run/a/very/deeply/nested/file ? That wouldn't work. The whole point of /var/run/named is to set the permissions on the directory such that a non-root user (the 'bind' user in FreeBSD typically) can write files in the directory. In order to create the named directory in /var/run, you need root privs. Give that to the program, and we are back where we started, no point in using /var/run/named, just use /var/run. > Or would that just be too ugly, mixing device drivers with high-level file > operations? Guess so.. Yeah, that too. It is not that big of a deal to hack this support for named into the rc scripts. It is a hassle when considering the "correct" way to handle this to make it extensible to other daemons we may wish to run in such a manner. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Copyright Contradiction in libalias (Summary)
On Thu, Aug 23, 2001 at 09:50:27AM +1000, Andrew Kenneth Milton wrote: > I guess we can summarize now? :-) > > 1) If you are the author of software, it's a bad idea to simply release code >into the Public Domain, mainly because you can't protect your self from >litigation by placing disclaimers in your code. I don't remember that coming up. Licensing doesn't necessarily have anything to do with a copyright. I can tag whatever licensing restrictions I want on _my distribution_ of a public domain work (whether I am the original author or not). As an analogy, take the example of BSD-licensed code where someone else owns the copyright (like anything in FreeBSD). Provided I follow the limited restrictions of the BSD-license, I can pile additional licensing terms on top of that. I am not the copyright holder, but I can modify the licensing on _my distribution_ of the code (the terms under which I give it to someone else). It is the same situation with public domain code. I don't own the copyright (because no one does), but I can still license my distribution of the code how ever I want (e.g. THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES blah, blah, blah...). Very sorry I sent this thread to a list rather than just go to the committer who made the license change. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Copyright Contradiction in libalias
On Tue, Aug 21, 2001 at 04:46:07PM -0600, Nate Williams wrote: > > If you ever claimed to hold the copyright to software that has been > > released into the public domain, you would be commiting fraud. > > Not if I'm the author of the software. > > I can release my software under as many licenses as I'd like, including > putting it into the public domain. "Public domain" is not a license agreement. You are retracting your rights as a copyright holder when you put something in the public domain. > However, I can't retroactively take away the rights of anyone who has > gotten my 'public domain' software. You can't do anything. You have no more rights to the software than anyone else does (except the ability to say you wrote it). > That is all. I can release the exact same code under a zillion > different licenses, but once it's released, the people who have gotten > it can do whatever the license they received it under with the software, > and if that means 'public domain', that means they can do just about > anything with it. Again, putting something in the public domain is not a license agreement, but the fact they can do anything with it is true. > However, *I* (as the original author) can release the software to > someone else, and if they aren't aware of the other (potentially more > liberally licensed) versions, they can be perfectly happy with the > software I've given them. As can anyone else who gets their hands on the software. > As the original author, you never lose your rights to the software, > unless you assign your rights away to another entity, who knows has the > same rights as you normally have. That means they can release it under > multiple licenses, Yes, the original author does lose his rights when the copyright expires (which for things now-a-days only happens years after the author dies) at which time the work becomes public domain or when the author retracts his rights by explicitly placing the works in the public domain. > This is why folks can release software under both the GPL and BSD > licenses, and folks who work for the government must release it as PD, > and afterward someone takes that software and modifies it again, and the > modified version is licensed another way. Licensing has nothing to do with giving up a copyright. You can release any software you want under any license and you still have your copyright to the work. Again, placing something in the public domain is NOT a type of licensing agreement. You are surrendering your rights as the copyright holder. Oh, and you mention the fine point that nothing produced by the US Gov't is copyrighted. > > If I have the only existing copy of some forgotten work by > > Shakespeare, I could sell it however I want under any terms I chose > > (licensing), but I cannot claim the copyright and be protected by > > copyright law above and beyond what I put in my license. If someone > > else finds a copy of it, I'm screwed. > > Again, you aren't the author, or you have not been assigned the rights > by the original author (or whomever owned the copyright at the time). > However, most authors still have their original rights to do whatever > they please with their software, regardless of how they've released > their software in the past. But I am trying to point out that for something in the public domain, everyone has the same rights to use the work. The original author has the same rights to it as anyone else. > Back to the original question, Charles Mott is the original author of > said code, and he can release his software under any license he so > pleases. So can FreeBSD with or without his consent since it is public domain software. > If someone has a copy of his software released under the PD > license, There is no "PD license." > they are free to do with it as they please. However, he can > *also* release a version under the BSD license (which he has), and that > version is now being distributed by FreeBSD. This is all completely > free and legal, because Charles is within his legal rights to do so. And so is FreeBSD. Strictly speaking, the license might need to be slightly reworded for public domain software, but there is no reason FreeBSD cannot add the license to any public domain software it has. But IANAL, and this is all pretty pointless since no one is ever going to really care about the legal status of these few files. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Copyright Contradiction in libalias
On Tue, Aug 21, 2001 at 11:18:41PM +0300, Giorgos Keramidas wrote: > From: Crist J. Clark <[EMAIL PROTECTED]> > Subject: Re: Copyright Contradiction in libalias > Date: Tue, Aug 21, 2001 at 11:40:20AM -0700 > > > On Tue, Aug 21, 2001 at 08:14:59AM -0500, Thomas T. Veldhouse wrote: > > > > > So, if Microsoft > > > decides they want your software without the existing license (public domain) > > > you can relicense it to them for a fee under whatever terms you want, and > > > they must deal with you on it because of the copyright that you hold. > > > > No, they don't have to deal with you. MS can license code in the > > public domain however they like. They need not consult you at all. > > But can someone that did not know about the `public domain' state of > the program accuse you, tha author, later on that you 'cheated' on > him, if you do ask for money when they come to you and ask that they > `buy' the source? If you ever claimed to hold the copyright to software that has been released into the public domain, you would be commiting fraud. You would be vulnerable to whatever criminal or civil reprocusions that result. That does not mean you can't sell something you do not own the copyright too. If I have the only existing copy of some forgotten work by Shakespeare, I could sell it however I want under any terms I chose (licensing), but I cannot claim the copyright and be protected by copyright law above and beyond what I put in my license. If someone else finds a copy of it, I'm screwed. > I am not a lawyer, and I am probably mistaken here, but if someone > wants to pay me for a program, even if the program has been released > by me to the public domain, I think I will not refuse their money. > Of course, being the stupid^W ethical guy I am, I will note that the > program is public domain, and if they still want to buy it, then I > won't refuse selling it. Feel free. I think people are confusing the concept of license and copyright. They are two different things. FreeBSD can distribute public domain code under any license it wants (provided the licensing does not assume FreeBSD or someone else holds copyright to the code). It cannot claim the copyright of public domain code. "Public domain" is not a type of license. When a copyright owner puts something in the public domain, they are giving up the copyright since they have no recourse to stop anyone from doing _anything_ with the material. But again, IANAL. There are international copyright treaties, but laws still do vary from nation to nation. YMMV. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Copyright Contradiction in libalias
On Tue, Aug 21, 2001 at 08:14:59AM -0500, Thomas T. Veldhouse wrote: > > > > > Well since copyright was abandoned (being placed into the public domain is > > abandonment of copyright), the changed file can be copyrighted by whomever > > makes changes. The new file is then covered by the license from that point > > forward. > > > > Copyright is certainly not abaondoned when you place something in the public > domain. Your rights vary depending upon the license you choose, You can't chose a license for something put in the public domain. Putting something in the public domain implies that anyone can do whatever they want with it. You can't put it in the public domain _and_ place restrictions on its use. > but you > certainly do NOT lose your copyright. You've just given everyone permission to do whatever they want with the material. You do lose your copyright in the sense that you no longer have any legal recourse to prevent people from doing whatever they want with the work. > If you are the author of a piece of > software and you release the code to public domain, you still have the right > to sell the same code under a different license as well. But anyone else can sell the code under any license they want too. > So, if Microsoft > decides they want your software without the existing license (public domain) > you can relicense it to them for a fee under whatever terms you want, and > they must deal with you on it because of the copyright that you hold. No, they don't have to deal with you. MS can license code in the public domain however they like. They need not consult you at all. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Copyright Contradiction in libalias
On Tue, Aug 21, 2001 at 02:10:42AM +0100, Brian Somers wrote: > > +---[ Brian Somers ]-- > > | > Check with Charles to see if he really wants to abandon copyright claims > > | > to his code, or whether he was really implying some really liberal open source > > | > license. > > | > > | With the BSD Copyright (only) he keeps the intellectual copyright on > > | the original. That's what I've changed it to (as per his agreement). > > > > Oh, I thought he put in the comment to the effect it was in the Public Domain, > > if you did that you're naughty! d8) > > > > If he did that, he probably needs to rethink it. > > He originally wrote it to say it was in the public domain. I asked > him if he minded me making it a BSD license and he said ok only I > didn't do the whole job :*) If you look at the history of the files, they were imported into FreeBSD with the statement that they are public domain. I don't think there is any way he can take that back and claim copyright over them. Now, as to whether anyone can now claim a copyright over the contents since (not very substantial) changes have been made is something for lawyers to settle. It is now written policy, and I believe it was the understood, unwritten policy in the past, that any patches and additions to a file in FreeBSD are governed by the existing licensing of the file unless otherwise stated. This would indicate to me that this file is arguably still public domain. Again, IANAL. For now, as they stand, the licensing text within them is contradictory and should be "fixed." As for whether it's getting fixed the "right way" is something only a lawyer could answer, and I really doubt anyone is ever going to care enough about these couple of files to pay a lawyer to have a look. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Copyright Contradiction in libalias
I was doing some things in libalias when something caught my eye, $ cat alias.c /* -*- mode: c; tab-width: 8; c-basic-indent: 4; -*- */ /*- * Copyright (c) 2001 Charles Mott <[EMAIL PROTECTED]> * All rights reserved. * [snip usual BSD licence legalese and comments about the code.] This software is placed into the public domain with no restrictions on its distribution. This is contained in several files in there. This is a contradiction. Public domain software can't also have copyright notices and a bunch of license disclaimers. The BSD-style copyright header was added back in June. You can't just take something in the public domain and slap a copyright on it, but IANAL. Still, the comments in the code as written are self-contradictory. It can't have a BSD-license _and_ be public domain. And since again IANAL, I am not saying which needs to stay or which needs to go, but one of those statements does. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh rsa authentication
On Sun, Jul 22, 2001 at 12:09:34PM -0400, Aaron Angel wrote: > Not sure if this is actually freebsd-current ralated, but when I was last > in 4.3-release, I do recall having used rsa authentication correctly, and > I can't find info anywhere else. > > When I try to log into ssh (from anyway, even locally) using my rsa key, > it opens the session, and then immediately closes. It puts an entry in > /var/log/messages: > > fatal: PAM setcred failed[6]: Permission denied" > > Any ideas? You didn't mergemaster(8) or otherwise update /etc/pam.conf after an upgrade? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Broken CURRENT
Looks like installworld is broken in CURRENT. The /usr/share/examples/isdn/i4runppp directory was not added to etc/mtree/BSD.usr.dist. Who's got the pointy hat? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syslogd and -a
On Mon, Jul 02, 2001 at 09:38:42AM +0100, David Malone wrote: > On Sun, Jul 01, 2001 at 09:20:44PM -0700, Crist J. Clark wrote: > > Hmmm... Looks like, > > > > # syslogd -a 192.168.1.0/29 > > > > Will work and, > > > > # syslogd -a 192.168.1.1/29 > > > > Won't. > > That's the standard behaviour of a netmask, isn't it? The usual > way to check if host h is in network/netmask n/m is to check if: > > (h & m == n) > > this means that the bits of the network which are not in the mask > must be zero. That's exactly what happens in the syslogd(8) code. However, I think that should be, n &= m . . . ((h & m) == n) That is, why allow the user to enter a network number that is not /really/ the network number? Either flag an error or do the calculation for the user. I think doing the calculation is the more sensible choice. Commiting it to CURRENT now. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syslogd and -a
On Sun, Jul 01, 2001 at 11:41:25PM -0400, David Hill wrote: > Hello - > > It seems the -a option for syslogd does not work 100%. > I need to log from hosts from 192.168.1.1-.6 > > doing "/usr/sbin/syslogd -a 192.168.1.1/29" does not work (nothing gets logged) > > but, if i do > > /usr/sbin/syslogd -a 192.168.1.1/32 -a 192.168.1.2/32, etc... that works > > can anyone try this out? Hmmm... Looks like, # syslogd -a 192.168.1.0/29 Will work and, # syslogd -a 192.168.1.1/29 Won't. I'll have a look. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fd0c mount(8) Race
I mount a floppy at boot time. The entry was, /dev/fd0c /twfloppy ufs ro 0 0 However, as of a recent CURRENT build I started getting, [normal kernel boot messages] Mounting root from ufs:/dev/ad0s1a Entropy harvesting: interrupts ethernet point_to_point. Using /entropy as an entropy file swapon: adding /dev/ad0s1b as swap device Automatic boot in progress... /dev/ad0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 33463 free (647 frags, 4102 blocks, 0.7% fragmentation) /dev/ad0s1e: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1e: clean, 446216 free (12512 frags, 54213 blocks, 1.2% fragmentation) mount: /dev/fd0c: No such file or directory Mounting /etc/fstab filesystems failed, startup aborted Enter full pathname of shell or RETURN for /bin/sh: # ls -l /dev/fd0* crw-r- 1 root operator9, 0 Jun 29 23:26 /dev/fd0 lrw-rw-rw- 1 root wheel4 Jun 29 23:26 /dev/fd0c -> fd0 # That is, even though once I drop into single-user mode we see the symlink for /dev/fd0c, it does not seem like it was there when 'mount -a -t nonfs' is run in /etc/rc. It seems there is some type of race to get the fd0c symlink in place and I am not winning it. I switched to /dev/fd0 and the boot went fine, but if this is real, it should be fixed. Can anyone else reproduce the problem? Or is it well known (I can't find it in the mail archive)? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we need a 3. level between stable and cuurent?
On Mon, Feb 19, 2001 at 10:30:17AM -0800, Alfred Perlstein wrote: > * Leif Neland <[EMAIL PROTECTED]> [010219 08:54] wrote: > > We all know: -current is bleeding edge, expect it to break at random. Don't run it >if you don't know how to fix it. > > -stable is for production, it works all the time. > > > > Do we need a level in between for people who just run current for the fun of it >and for testing. > > So after the hardcore has tested it in -current, they commit it to all the monkeys >trying to break it, and we then try it on n^m' combinations of hardware/software. > > > > I might not be able to fix a problem, but I can report what happens, and if my >-current breaks for a few days, it is no big deal. > > > > While -current is not for everybody, I believe people like me helps in quality >testing before the stuff hits -stable. > > > > Perhaps not a level, just a separate file, which contained the date of the last >known version without known major problems. (or "." if no known problems) > > This is a good idea, however it would take someone dedicated to > maintaining this as well as doing regression testing. Those > regression tests could easily be ported to -stable making for > happier -stable as well as -current users. > > Are you volunteering? :) IMHO, people who are not actively developing -CURRENT, those running it for fun or only occasionally hacking non-essential portions just need to realize that blindly tracking -CURRENT with a daily, weekly, or perhaps any regular make-world schedule is just not going to work. Find a reasonably stable version of -CURRENT and stick with it until you know that the current -CURRENT is also in decent shape. For example, I did a make world early in February and started getting kernel panics at boot. I tried to get some help and provide some data on freebsd-current to fix it, but I just did not have the time and tools. I ended up just CVSuping a back to a version I knew was in good shape and the box has been fine. I can use it for what I want, and I'm not upping it until I hear things have settled a bit... And I hope that's soon, I don't want it to diverge too much or else merging my changes in might get painful. What would help me and others like me is some way to actually figure out if the current -CURRENT is stable (I like that sentence). I am not saying it would be a substitute for freebsd-current and the commit list, but those can be very, very hard to follow. Rather than two versions of -CURRENT provide the data for people to fairly quickly determine if today's -CURRENT is solid enough for them. In some sense, each commit makes a new version, people need to decide up to what recent earth-shaking commit they can go to and be safe. Possibly some webpage summarizing what is broken, which essential pieces are in active development, etc. Obviously, this would take effort, but it may be worth it to those who want to track a stable -CURRENT. It is definately less work than maintaining two versions. How does it differ than reading the mailing lists? You don't need to dig through a dozen me-toos for each problem. Someone more knowledgeble on things can filter the claims that -CURRENT is broken from people who can't read UPDATING. And so on. And no, I am not volunteering. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Tue, Feb 06, 2001 at 11:02:32AM -0800, John Baldwin wrote:
[snip]
> ARGH. The trap code is breaking this.
[snip]
> Just comment out that enable_intr() and please try again. This should give you
> a stack trace where the actual bug is. Thanks.
Done. And the winner is... (see attachment, did not repeat the kernel
config since it has not changed)
--
Crist J. Clark [EMAIL PROTECTED]
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #3: Tue Feb 6 13:59:53 PST 2001
[EMAIL PROTECTED]:/usr/obj/export/current/src/sys/BUBBLES
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P54C (132.96-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52b Stepping = 11
Features=0x1bf
real memory = 33554432 (32768K bytes)
avail memory = 30015488 (29312K bytes)
Preloaded elf kernel "kernel.BUBBLES" at 0xc02c5000.
Intel Pentium detected, installing workaround for F00F bug
apm0: on motherboard
apm0: found APM BIOS v1.1, connected at v1.1
npx0: on motherboard
npx0: INT 16 interface
pcib0: at pcibus 0 on motherboard
pci0: on pcib0
isab0: at device 7.0 on pci0
isa0: on isab0
pci0: at 8.0 (no driver attached)
ep0: <3Com 3C509-TP EtherLink III> at port 0x300-0x30f irq 10 on isa0
ep0: Ethernet address 00:20:af:17:a3:e9
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0: at port 0x3bc-0x3c3 irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: on ppbus0
lpt0: on ppbus0
lpt0: Interrupt-driven port
ppi0: on ppbus0
ppc1: cannot reserve I/O port range
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio2 at port 0x3e8-0x3ef irq 5 on isa0
sio2: type 16550A
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
IP packet filtering initialized, divert enabled, rule-based forwarding disabled,
default to deny, logging limited to 1000 packets/entry by default
ad0: 1222MB [2484/16/63] at ata0-master BIOSPIO
acd0: CDROM at ata0-slave using BIOSPIO
Mounting root from ufs:/dev/ad0s1a
kernel trap 9 with interrupts disabled
panic: blockable mtx_enter() of Giant when not legal @
/export/current/src/sys/i386/i386/trap.c:653
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db> trace
Debugger(c0215a83) at Debugger+0x44
panic(c0214bc0,c022fc74,c0230820,28d,c02782e0) at panic+0x70
witness_enter(c02782e0,0,c0230820,28d,0) at witness_enter+0x1d9
_mtx_enter(c02782e0,0,c0230820,28d,c02781a0) at _mtx_enter+0x106
trap(18,10,10,c3612a60,20) at trap+0x583
calltrap() at calltrap+0x5
--- trap 0x9, eip = 0xc01fc642, esp = 0xc3a29f50, ebp = 0xc3a29f64 ---
sw1b(4000) at sw1b+0x81
ithd_loop(0,c3a29fa8) at ithd_loop+0x10d
fork_exit(c0200d94,0,c3a29fa8) at fork_exit+0x2d
fork_trampoline() at fork_trampoline+0x8
db>
Re: Kernel Panic from Yesterday's CVSup
On Mon, Feb 05, 2001 at 02:51:59PM -0800, John Baldwin wrote:
>
> On 05-Feb-01 Crist J. Clark wrote:
> > I don't recall reports of trouble with recent CURRENT, but my CVSup
> > from yesterday afternoon is panicing. Before I try too debug this, has
> > anyone been getting these or knows what I might be missing?
> >
> > Boot messages and the panic info are attached.
>
> Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if
> you can reproduce this? Also, compile the kernel with debug symbols. Then
> type 'trace' at the db> prompt when it does to get a backtrace of where it blew
> up. Thanks.
OK. The boot messages and debug output is attachment one, the kernel
config is second. For the record, I have not made any changes to the
kernel; fresh CVSup.
--
Crist J. Clark [EMAIL PROTECTED]
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #2: Mon Feb 5 23:59:09 PST 2001
[EMAIL PROTECTED]:/usr/obj/export/current/src/sys/BUBBLES
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P54C (132.96-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52b Stepping = 11
Features=0x1bf
real memory = 33554432 (32768K bytes)
avail memory = 30015488 (29312K bytes)
Preloaded elf kernel "kernel.BUBBLES" at 0xc02c5000.
Intel Pentium detected, installing workaround for F00F bug
apm0: on motherboard
apm0: found APM BIOS v1.1, connected at v1.1
npx0: on motherboard
npx0: INT 16 interface
pcib0: at pcibus 0 on motherboard
pci0: on pcib0
isab0: at device 7.0 on pci0
isa0: on isab0
pci0: at 8.0 (no driver attached)
ep0: <3Com 3C509-TP EtherLink III> at port 0x300-0x30f irq 10 on isa0
ep0: Ethernet address 00:20:af:17:a3:e9
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0: at port 0x3bc-0x3c3 irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: on ppbus0
lpt0: on ppbus0
lpt0: Interrupt-driven port
ppi0: on ppbus0
ppc1: cannot reserve I/O port range
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio2 at port 0x3e8-0x3ef irq 5 on isa0
sio2: type 16550A
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
IP packet filtering initialized, divert enabled, rule-based forwarding disabled,
default to deny, logging limited to 1000 packets/entry by default
ad0: 1222MB [2484/16/63] at ata0-master BIOSPIO
acd0: CDROM at ata0-slave using BIOSPIO
Mounting root from ufs:/dev/ad0s1a
kernel trap 9 with interrupts disabled
panic: mutex sched lock recursed at /export/current/src/sys/kern/kern_synch.c:918
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db> trace
Debugger(c0215a83) at Debugger+0x44
panic(c02148a2,c022fc69,c02160a0,396,c0823f00) at panic+0x70
_mtx_assert(c0278140,9,c02160a0,396,c0823f00) at _mtx_assert+0x63
mi_switch(c3611b80,20,9,c3a29f08,c01f2a6d) at mi_switch+0x25
sched_ithd(e) at sched_ithd+0xd9
Xresume14() at Xresume14+0x8
--- interrupt, eip = 0x8, esp = 0xc3a29ee4, ebp = 0xc3a29ed4 ---
(null)(c01fcd58,8,80286,c02781a0,20) at 0x8
db>
# $Id: BUBBLES,v 1.4 2001/02/04 06:49:24 cjc Exp cjc $
#
# BUBBLES - 2000/11/11, cjc
#
# Kernel configuration for IBM Pentium 133
#
# 2000/12/09, cjc - DEVEL became BUBBLES
#
machine i386
cpu I586_CPU
ident BUBBLES
maxusers32
#To statically compile in device wiring instead of /boot/device.hints
#hints "GENERIC.hints" #Default places to look for devices.
#makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols
options WITNESS
options INVARIANTS
options DDB
options INET#InterNETworking
options INET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
#optionsFFS_ROOT#FFS usable as root device [keep this!]
options SOFTUPDATES #Enable FFS soft updates support
#optionsDEVFS #Device Filesystem
options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]
options UCONSOLE#Allow users to grab the console
options KTRACE #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM
Kernel Panic from Yesterday's CVSup
I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. -- Crist J. Clark [EMAIL PROTECTED] Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Sun Feb 4 20:09:00 PST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BUBBLES Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (132.96-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping = 11 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30130176 (29424K bytes) Preloaded elf kernel "kernel" at 0xc02a9000. Intel Pentium detected, installing workaround for F00F bug apm0: on motherboard apm0: found APM BIOS v1.1, connected at v1.1 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at 8.0 (no driver attached) ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc1: cannot reserve I/O port range sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2 at port 0x3e8-0x3ef irq 5 on isa0 sio2: type 16550A ep0: <3Com 3C509-TP EtherLink III> at port 0x300-0x30f irq 10 on isa0 ep0: Ethernet address 00:20:af:17:a3:e9 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging limited to 1000 packets/entry by default ad0: 1222MB [2484/16/63] at ata0-master BIOSPIO acd0: CDROM at ata0-slave using BIOSPIO Mounting root from ufs:/dev/ad0s1a kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xe fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f2553 stack pointer = 0x10:0xc3a2bf50 frame pointer = 0x10:0xc3a2bf64 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 16 (irq14: ata0) trap number = 12 panic: page fault syncing disks... done Uptime: 0s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot <-- # $Id: BUBBLES,v 1.4 2001/02/04 06:49:24 cjc Exp cjc $ # # BUBBLES - 2000/11/11, cjc # # Kernel configuration for IBM Pentium 133 # # 2000/12/09, cjc - DEVEL became BUBBLES # machine i386 cpu I586_CPU ident BUBBLES maxusers32 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support #optionsDEVFS #Device Filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE#Allow users to grab the console options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING #optionsKBD_INSTALL_CDEV# install a CDEV entry in /dev device isa device pci #optionsCOMPAT_OLDISA # compatability shims for lnc, le #optionsCOMPAT_OLDPCI # compatability shims for lnc # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd
Re: excessive paranoia in syslogd(8)?
On Mon, Jan 22, 2001 at 12:40:00PM -0500, Garrett Wollman wrote: > < said: > > > If you want to or need to use network sockets, > > > # syslogd -a localhost > > > Should provide the behavior you want. > > I.e., no security whatsoever. Well, yeah, it's syslogd(8) and as the manpage says, BUGS The ability to log messages received in UDP packets is equivalent to an unauthenticated remote disk-filling service... However, doing 'syslogd -a localhost' should really not be much worse than 'syslogd -s' or '-ss'. In all three cases, a local user can nail you. The only risk I see is 127.0.0.1 being forced in from the LAN, and even then, I can't recall if FreeBSD will ever accept loopback numbers coming in a non-loopback interface. And that still is only local net, 127/8 packets aren't going to be routed. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: excessive paranoia in syslogd(8)?
On Sat, Jan 20, 2001 at 11:39:37PM -0600, Steve Price wrote: > On Sat, Jan 20, 2001 at 09:20:39PM -0800, Crist J. Clark wrote: > # > # You can write to the /dev/log (usually symlinked to /var/run/log) > # socket with '-s' set. > # > # If you want to or need to use network sockets, > # > # # syslogd -a localhost > # > # Should provide the behavior you want. As you noted this is not the > # same as '-s'. It is a feature and not a bug. > > I'm still deciding on that... Here's what I see: > > steve@test1(~)$ telnet localhost 514 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > Connection closed by foreign host. > steve@test1(/tmp/tard)$ > > steve@bonsai(~)$ telnet 192.168.21.28 514 > Trying 192.168.21.28... > Connected to 192.168.21.28. > Escape character is '^]'. > Connection closed by foreign host. > > And here is what I see in syslogd: > > test1# syslogd -d -a localhost > ... > logmsg: pri 45, flags 0, from test1, msg Jan 20 23:34:52 rshd[53675]: > connection from 127.0.0.1 on illegal port 1186 > Logging to CONSOLE /dev/console > Logging to FILE /var/log/messages > Logging to USERS > logmsg: pri 45, flags 0, from test1, msg Jan 20 23:34:54 rshd[53676]: > connection from 192.168.21.1 on illegal port 2855 > Logging to CONSOLE /dev/console > Logging to FILE /var/log/messages > Logging to USERS It looks like syslogd(8) is working fine from this. Is something with syslogd(8) not working? 'tail /var/log/messages' aren't those messages there? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: excessive paranoia in syslogd(8)?
On Sat, Jan 20, 2001 at 10:49:44PM -0600, Steve Price wrote: > Is it just me or does 'syslogd -s' exhibit just a little bit too > much paranoia about allowing socket connections? I was futzing > with a Perl script that needed to syslog(3) some stuff and after > much hair pulling I realized that 'syslogd -s' didn't even allow > connections from localhost. Apparently Perl opens a socket > connection to syslog and with the '-s' syslogd doesn't read from > socket connections either from localhost or from hosts specified > with -a. This is a bad thing IMHO. Either I open syslogd up to > all socket connections (including from localhost) or I can't use > syslog from Perl. You can write to the /dev/log (usually symlinked to /var/run/log) socket with '-s' set. If you want to or need to use network sockets, # syslogd -a localhost Should provide the behavior you want. As you noted this is not the same as '-s'. It is a feature and not a bug. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/24444: syslogd(8) does not update hostname
On Fri, Jan 19, 2001 at 11:09:24PM +0100, Dag-Erling Smorgrav wrote:
> "Crist J. Clark" <[EMAIL PROTECTED]> writes:
> > On Fri, Jan 19, 2001 at 12:32:53PM +0100, Dag-Erling Smorgrav wrote:
> > > It should also log a message if the hostname changes.
> > Should that be a responsibility of syslogd(8) or hostname(1)?
>
> I meant syslogd(8), but putting it in hostname(1) might makes sense,
> except that hostname(1) is not the only way to set the hostname
> ('sysctl -w kern.hostname=foo' is another)
How about just logging a sethostname(3) call?
But anyway, syslogd(8) does not track the state of any other system
parameters, I think asking syslogd(8) to notice a change in the
hostname on its own in a real-time fashion is beyond its scope.
That said, I agree that syslogd(8) making a note when its own idea of
the hostname changes would be useful. If one is analyzing logs, an
entry indicating that messages from a given machine no longer will be
labeled as coming from 'foo' but 'foobar' would be very helpful.
Patches, patches, patches:
--- usr.sbin/syslogd/syslogd.c 2001/01/18 08:06:34 1.1
+++ usr.sbin/syslogd/syslogd.c 2001/01/21 00:55:53 1.3
@@ -318,7 +318,7 @@
struct sockaddr_un sunx, fromunix;
struct sockaddr_storage frominet;
FILE *fp;
- char *p, *hname, line[MAXLINE + 1];
+ char *hname, line[MAXLINE + 1];
struct timeval tv, *tvp;
struct sigaction sact;
sigset_t mask;
@@ -395,12 +395,6 @@
consfile.f_type = F_CONSOLE;
(void)strcpy(consfile.f_un.f_fname, ctty + sizeof _PATH_DEV - 1);
- (void)gethostname(LocalHostName, sizeof(LocalHostName));
- if ((p = strchr(LocalHostName, '.')) != NULL) {
- *p++ = '\0';
- LocalDomain = p;
- } else
- LocalDomain = "";
(void)strcpy(bootfile, getbootfile());
(void)signal(SIGTERM, die);
(void)signal(SIGINT, Debug ? die : SIG_IGN);
@@ -1340,10 +1334,23 @@
char cline[LINE_MAX];
char prog[NAME_MAX+1];
char host[MAXHOSTNAMELEN+1];
+ char oldLocalHostName[MAXHOSTNAMELEN+1];
+ char hostMsg[2*(MAXHOSTNAMELEN+1)+40];
dprintf("init\n");
/*
+* Load hostname (may have changed)
+*/
+ strncpy(oldLocalHostName, LocalHostName, sizeof(LocalHostName));
+ (void)gethostname(LocalHostName, sizeof(LocalHostName));
+ if ((p = strchr(LocalHostName, '.')) != NULL) {
+ *p++ = '\0';
+ LocalDomain = p;
+ } else
+ LocalDomain = "";
+
+ /*
* Close all open log files.
*/
Initialized = 0;
@@ -1492,6 +1499,17 @@
logmsg(LOG_SYSLOG|LOG_INFO, "syslogd: restart", LocalHostName, ADDDATE);
dprintf("syslogd: restarted\n");
+ /*
+* Log a change in hostname, but only on a restart
+*/
+ if ((signo != 0) &&
+ (strncmp(oldLocalHostName, LocalHostName, sizeof(LocalHostName)) != 0)) {
+ snprintf(hostMsg, sizeof(hostMsg),
+"syslogd: hostname changed, \"%s\" to \"%s\"",
+ oldLocalHostName, LocalHostName);
+ logmsg(LOG_SYSLOG|LOG_INFO, hostMsg, LocalHostName, ADDDATE);
+ dprintf("%s\n", hostMsg);
+ }
}
/*
--
Crist J. Clark [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: syslogd(8) does not update hostname
On Sat, Jan 20, 2001 at 11:24:16AM +0200, Mark Murray wrote: > I don't agree with this change. > > hostname != name-that-IP-address-resolves-to. Dunno what you are talking about. That has nothing directly to do with this. No one is talking about forcing you to change your hostname. The patch just allows syslogd(8) to take note if the hostname were to change. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/24444: syslogd(8) does not update hostname
On Fri, Jan 19, 2001 at 12:32:53PM +0100, Dag-Erling Smorgrav wrote: > [EMAIL PROTECTED] writes: > > I propose that syslogd(8) should reload the hostname with a > > SIGHUP. I cannot think of any reason that one should not update the > > hostname, but as I pointed out, there are reasons why one would want > > that behavior. > > It should also log a message if the hostname changes. Should that be a responsibility of syslogd(8) or hostname(1)? Personally, it might be a slippery slope to start adding things that syslogd(8) should maintain state on, but since syslogd(8) actually uses the hostname... One also could start arguing that syslogd(8) should check the hostname everytime it logs something despite the performance hit. As for what syslogd(8) does now, if you look at the example output in the PR, notice syslogd(8) didn't even log when it was HUP'ed. IMHO, I think it is beyond the scope of syslogd(8) to actually track changes in the hostname in real-time. Noticing a change when given a HUP signal, would seem reasonable, but if hostname(1) were to log changes, that would also be fairly redundant. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 11:52:43AM -0800, John Baldwin wrote: [snip] > Erm, many things live in both /stand and other places: > > > ll /stand/ | wc -l > 35 > > ll /stand/rm /bin/rm > -r-xr-xr-x 2 root wheel 255736 Jan 9 08:17 /bin/rm > -r-xr-xr-x 31 root wheel 1729520 Jul 28 07:32 /stand/rm I am not clear what you are saying here. Only sysinstall lives in /stand, [592:~] ls -li /stand total 45250 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 -sh 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 [ 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 arp 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 boot_crunch 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 cpio 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 dhclient 3 drwx-- 3 root wheel 512 Jun 19 2000 etc 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 find 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 fsck 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 gunzip 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 gzip 29952 drwxr-xr-x 2 root wheel 1024 Jun 19 2000 help 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 hostname 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 ifconfig 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 minigzip 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 mount_mfs 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 mount_nfs 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 newfs 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 pccardc 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 pccardd 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 ppp 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 pwd 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 rm 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 route 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 sed 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 sh 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 slattach 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 sysinstall 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 test 22465 -r-xr-xr-x 28 root wheel 1645704 Mar 20 2000 zcat But it lives by many names. (Ignoring the directories.) > Putting it in world wouldn't touch /stand, it would just add it to either > /usr/sbin or /sbin and keep that copy updated. [snip] > I vote for both, but not to touch /stand. We don't keep rm.1 in sync with > /stand/rm, we keep it in sync with /bin/rm, so this seems to be the most > consistent.. Well, /stand/rm is not _really_ rm at all, but I get the point. I guess the only question is whether to put it in /sbin or /usr/sbin. I think /sbin makes sense (so it is bootable), but it is 1.6MB of /-bloat... But from another thread about making 250MB the default / size, I guess few care too much about that anymore. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 10:53:43AM -0800, John Baldwin wrote: > > On 11-Jan-01 Jordan Hubbard wrote: > >> My personal opinion is that sysinstall.8 is a part of the base system > >> and shouldn't be optional. If we take your suggestion, it means that > >> installworld will sometimes install this manpage and sometimes it won't. > > > > I think we should simply move the stupid man page into man8. It's a bit > > weird to have a man page and its utility live in seperate places, but > > the release/ directory in the hierarchy has always been a red-headed > > stepchild in any case. If I had it to do over, it would have all gone > > into /usr/src/sbin somewhere. > > Let's put sysinstall back in sbin/ then. It _used_ to live there until someone > moved it. :) > > -r--r--r-- 1 root src 62356 Dec 30 1995 > /usr/cvs/src/sbin/sysinstall/Attic/sysinstall.c,v I had assumed that sysinstall was not part of the standard installworld for recovery purposes. That is, if a buildworld-installworld were to totally hose your system (but of course that _never_ happens), you would still have a reliable /stand/sysinstall uncorrupted by the errant installworld to aid in fixing things. Again, this is just what I assumed the reason for the design to be. And I have never actually used sysinstall to recover a hosed upgrade, I like the fixit.flp. But IMHO, either both /stand/sysinstall and sysinstall.8 get installed when building world or neither do. To me, that seems clear cut. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
On Thu, Jan 11, 2001 at 09:29:45AM -0800, Bruce A. Mah wrote: [snip] > My personal opinion is that sysinstall.8 is a part of the base system > and shouldn't be optional. If we take your suggestion, it means that > installworld will sometimes install this manpage and sometimes it won't. Bu-ut, as you point out... > A good counter-argument is that installworld doesn't touch > /stand/sysinstall, and therefore shouldn't touch the manpage either. I think getting the sysinstall binary and manpages out of sync, which is what the current configuration promises to do, is in itself a bug. > Idea: Maybe we need the release building process to do this instead? > On all of my systems, the sysinstall binary came from a CD, and never > got touched by any subsequent installworlds. I had assumed that the 'release' target would do something like this which explains why I was so puzzled by this change. I now understand why some people wanted it. > > Anyone have a good reason why everyone _must_ have src-release to > > buildworld? > > I never thought of trying to do a buildworld with anything less than > src-all. I guess my counter question is: Anyone have a good reason to > do buildworlds *without* /usr/src/release/? When I was CVSup'ing over a phone line to a notebook PC with a 750MB HDD, I trimmed my supfile to only what I needed, no src-games, no src-kerberosIV, no src-kerberos5, no src-release, etc. But to reiterate, I think the best reason not to do this is the potential for getting /stand/sysinstall and sysinstall(8) out of sync on your system. That is Just Wrong. The manpage should only be installed when /stand/sysinstall changes. The fact that src-release is now required was just an annoyance since I lost a build before I tracked it down. I woulda got over it. ;) I had not even noticed the change on some builds over the weekend since I do ususally grab src-release. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sysinstall.8 Breaking buildworld
I had some buildworld failures earlier this week. In src/share/man/man8 the Makefile includes code to get the sysinstall.8 manpage. Since the manpage lives in src/release, this requires that you CVSup src-release. I had not been. This broke buildworld which had worked in the past. sysinstall.8 is the only file in src-release that is required for a buildworld. It seems somewhat silly to me that you are required to grab the whole thing for that one file. I made the change to the Makefile which makes sysinstall.8 and src-release optional. I included it in a reply to the PR that precipitated the change, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19818 Steven G. Kargl ealier, independently submitted the almost exact same thing, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24122 In a separate PR. Anyone have a good reason why everyone _must_ have src-release to buildworld? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld Problems at NTP
On Fri, Jan 05, 2001 at 03:54:20PM -0800, Dima Dorfman wrote: > > Any more ideas what to try here? > > I'm sure you already thought of this, but have you made sure that you > aren't running any memory-hogging applications? I just compiled all > the ntp programs on my laptop which is a Pentium 75 with 24MB of > memory and 64MB of swap (I didn't do an entire buildworld; I don't > really want to wait a day). It's running 5.0-20001223-CURRENT, and > compiled the ntp suite from 5.0-20010101-CURRENT. Pretty lean on this machine, I make sure to turn off SETI@Home for builds or it'll swap like a maniac. ;) Perhaps I should point out that I am building with sources mounted via NFS, but /usr/obj is local. [170:~] ps uax USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root10 99.0 0.0 00 ?? RL 13Dec00 1239:51.83 (idle) root 1 0.0 0.5 552 128 ?? ILs 13Dec00 0:00.51 /sbin/init -- root11 0.0 0.0 00 ?? WL 13Dec00 11:00.26 (swi1: net) root12 0.0 0.0 00 ?? WL 13Dec00 178:01.38 (swi6: clock) root13 0.0 0.0 00 ?? WL 13Dec00 0:00.00 (swi4: vm) root14 0.0 0.0 00 ?? DL 13Dec00 11:48.92 (random) root15 0.0 0.0 00 ?? WL 13Dec00 0:00.00 (swi5: task queue) root16 0.0 0.0 00 ?? WL 13Dec00 52:22.08 (irq14: ata0) root17 0.0 0.0 00 ?? WL 13Dec00 0:17.18 (irq6: fdc0) root18 0.0 0.0 00 ?? WL 13Dec00 0:00.00 (irq7: ppc0) root19 0.0 0.0 00 ?? WL 13Dec00 0:00.01 (swi0: tty:sio) root20 0.0 0.0 00 ?? WL 13Dec00 28:27.06 (irq10: ep0) root 2 0.0 0.0 00 ?? DL 13Dec00 4:16.76 (pagedaemon) root 3 0.0 0.0 00 ?? DL 13Dec00 0:00.36 (vmdaemon) root 4 0.0 0.0 00 ?? DL 13Dec00 0:28.82 (bufdaemon) root 5 0.0 0.0 00 ?? DL 13Dec00 12:45.19 (syncer) root 114 0.0 1.2 932 360 ?? Ss 13Dec00 0:33.22 syslogd -s root 119 0.0 0.5 1252 132 ?? Is 13Dec00 0:09.18 timed root 126 0.0 0.0 2080 ?? IW - 0:00.00 nfsiod -n 4 root 127 0.0 0.0 2080 ?? IW - 0:00.00 nfsiod -n 4 root 128 0.0 0.0 2080 ?? IW - 0:00.00 nfsiod -n 4 root 129 0.0 0.0 2080 ?? IW - 0:00.00 nfsiod -n 4 root 147 0.0 0.9 996 248 ?? Ss 13Dec00 0:37.23 cron root 150 0.0 1.6 2648 476 ?? Is 13Dec00 0:05.21 /usr/sbin/sendmail -q30m root 154 0.0 0.9 2192 248 ?? Is 13Dec00 0:34.69 /usr/sbin/sshd root 198 0.0 0.0 9480 d0 IWs+ - 0:00.00 /usr/libexec/getty std.115200 ttyd0 root 48855 0.0 1.5 2280 448 ?? S10:02AM 0:02.85 sshd: cjc@ttyp0 (sshd) cjc 48877 0.0 2.7 1412 788 p0 Ss 10:02AM 0:01.35 -tcsh (tcsh) root 0 0.0 0.0 00 ?? DLs 13Dec00 0:10.73 (swapper) cjc 83227 0.0 1.2 520 336 p0 R+4:15PM 0:00.00 ps uax [171:~] swapinfo Device 1K-blocks UsedAvail Capacity Type /dev/rad0s1b 102272 2104 100168 2%Interleaved [172:~] vmstat procs memory pagedisks faults cpu r b w avm fre flt re pi po fr sr ad0 ac0 in sy cs us sy id 1 0 04632 14236 24 0 0 0 26 21 0 0 225 50 265 95 1 4 [173:~] uname -a FreeBSD bubbles.cjclark.org 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Wed Dec 13 23:14:41 PST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BUBBLES i386 Sources for the existing system would be from 2000/12/09. Again, the one I am trying to build has been re-cvsup'ed several times the last being about 0830 PST today. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld Problems at NTP
I am having a really weird problem trying to buildworld on a CURRENT box. The build starts just fine and gets though the first three steps. When it gets to building everything, it plows right along until it hits usr.sbin/ntp/ntpd, ===> usr.sbin/ntp/libparse cc -O -pipe -I/usr/src/usr.sbin/ntp/libparse/../../../contrib/ntp/include -I/usr/src/usr.sbin/ntp/libparse/../ -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/ntp/libparse/../../../contrib/ntp/libparse/parse.c -o parse.o . . . ===> usr.sbin/ntp/ntpd Killed What is happening is that the system is killing off the make process because it starts to swell up so much it consumes all swap. Here is the dmesg, Jan 4 15:21:08 bubbles /boot/kernel/kernel: swap_pager: out of swap space Jan 4 15:21:09 bubbles /boot/kernel/kernel: swap_pager_getswapspace: failed Jan 4 15:21:19 bubbles /boot/kernel/kernel: pid 11799 (make), uid 0, was killed: out of swap space Jan 4 15:21:22 bubbles /boot/kernel/kernel: pid 9428 (make), uid 0, was killed: out of swap space Jan 4 15:21:22 bubbles /boot/kernel/kernel: pid 58084 (make), uid 0, was killed: out of swap space Jan 4 15:21:22 bubbles /boot/kernel/kernel: pid 44119 (make), uid 0, was killed: out of swap space Jan 4 15:21:22 bubbles /boot/kernel/kernel: pid 12418 (make), uid 0, was killed: out of swap space I've nuked the /usr/obj tree and started over to get the same result. I took out /usr/src/contrib/ntp and re-cvsup'ed, but the above was the result. I'd really like to get this working so I can play with some kernel mods I made last week. Any ideas? Oh, the hardware is a Pentium 133 with 32MB RAM and 100 MB of swap. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #11: Wed Dec 13 23:14:41 PST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BUBBLES Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (132.96-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping = 11 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30126080 (29420K bytes) Preloaded elf kernel "kernel" at 0xc02aa000. Intel Pentium detected, installing workaround for F00F bug I had been building CURRENT fine for the two months I've had it. Thanks. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem building -current kernel with read-only /usr/src.
On Sat, Dec 23, 2000 at 09:43:29AM -0800, Matt Dillon wrote: [snip] > I tried 'make cleandir' in /usr/src and that does not fix the problem > either. Sorry, I was not clear enough. You need to do, # cd /usr/src/sys/modules # make cleandir A 'cleandir' from /usr/src will not climb up into the modules. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem building -current kernel with read-only /usr/src.
On Sat, Dec 23, 2000 at 12:24:51AM -0800, Matt Dillon wrote: > While trying to run 'make depend' in /usr/src/sys/compile/BLAH I got: > > ===> 3dfx > @ -> /FreeBSD/FreeBSD-current/src/sys > ln: @: Read-only file system > *** Error code 1 > > Stop in /FreeBSD/FreeBSD-current/src/sys/modules/3dfx. > *** Error code 1 > > It looks like it's trying to mess around with something in /usr/src, > which is a read-only NFS mount. Needless to say we do not want to > break being able to have a read-only /usr/src! > > Anyone been messing with the 3dfx module recently ? Myself and a few others found debris in our /usr/src/sys recently. Looks like it might be what you have there. None of us were sure if it was us messing it up or trouble somewhere else. Do a 'make cleandir' in your _source tree_ and try the build again. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
On Sun, Dec 17, 2000 at 01:15:41PM -0800, Doug Barton wrote: > Poul-Henning Kamp wrote: > > > > This patch is for the printf(9), log(9) & /dev/console stuff. > > The result is that you can watch the output from /etc/rc in > > your /var/log/messages. > > This works spectacularly for me on a UP -current with up to date > sources. The only nit I have is that it doesn't understand lines that > don't end in a newline very well (such as echo -n, or a printf with no > \n), so it produces log output like this: > > Dec 17 13:00:24 Master /boot/kernel/kernel: /dev/da1s1a: > Dec 17 13:00:24 Master /boot/kernel/kernel: FILESYSTEM > CLEAN; SKIPPING CHECKS > Dec 17 13:00:24 Master /boot/kernel/kernel: /dev/da1s1a: > Dec 17 13:00:24 Master /boot/kernel/kernel: clean, 42202 > free > Dec 17 13:00:24 Master /boot/kernel/kernel: (154 frags, > 5256 blocks, 0.2% fragmentation) > > and > > Dec 17 13:00:26 Master /boot/kernel/kernel: Doing > additional network setup: > Dec 17 13:00:26 Master /boot/kernel/kernel: ntpdate > Dec 17 13:00:26 Master /boot/kernel/kernel: ntpd > Dec 17 13:00:27 Master /boot/kernel/kernel: portmap > Dec 17 13:00:27 Master /boot/kernel/kernel: . > > Now, the first isn't a big deal, but the second is a little confusing. > Would there be any harm to changing the dots to something more > meaningful, like "Done with additional network setup" on its own line? I > seriously considered that when I was working on the echo's last night, > but I didn't want to be too revolutionary. :) s/\./(done)/ Or maybe '(finished)'? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel target breaks on pcivar.h
On Fri, Dec 15, 2000 at 11:01:48AM +0200, Sheldon Hearn wrote: > > > On Thu, 14 Dec 2000 14:28:34 PST, "Crist J. Clark" wrote: > > > Anyone else have one of those? And what makes me even more suspicious > > is I have that exact same .depend file (same name, not same contents) > > in my STABLE tree. It's the only one there too with roughly the same > > date (two days later). > > I've taken a closer look at the script I use to autobuild world and > kernel every night. > > Correct me if I'm wrong, but I should _never_ have any .depend files > lying around during a build if I do this before every world + kernel > build: > > rm -rf /usr/obj/usr/src > cd /usr/src > make cleandir > > If I'm wrong, great. That means it's finger trouble and I should get my > act together. If not, then I'm quite puzzled as to the origins of these > things, since I don't use parallel builds. Actually, a 'make cleandir' from /usr/src will not clean the sys/modules hierarchy unless MODULES_WITH_WORLD is set. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel target breaks on pcivar.h
On Thu, Dec 14, 2000 at 11:18:31AM +0200, Sheldon Hearn wrote: > > > On Wed, 13 Dec 2000 23:19:36 PST, "Crist J. Clark" wrote: > > > I had this problem this weekend. There was a rogue '.depend' file in > > my _source_ tree. I thought that I had messed something up. Maybe it > > got there some other way. I think I fixed it with a 'make clean' in > > the source tree. > > Ha! That's it. I wonder how those got there? > > No matter. We can probably assume that it was due to finger trouble. OK, I was thinking about this and there is a problem I have with the fat-finger, pilot-error theory. The only machine that I build current on mounts the source tree read-only as an NFS. I could not have accidently left stuff in the source tree. The other issue is that the problem occured in src/sys/modules tree. I cannot recall _ever_ building up there. I would only have ever used the buildkernel target from /usr/src or possibly a 'make' in src/sys/compile/KERNEL. All of those should be building in different object directories. Could we have Makefiles breaking occasionally and leaving droppings in the source tree and we only notice when we get breakage like this pcivar.h thing? When I presented my earlier solution, I should have mentioned that I had only cleaned the directory where I had found the '.depend' and '@' leftovers. I just did a search up my source tree and found, [104:/export/current] ls -la src/sys/modules/accf_data/ total 5 drwxr-xr-x2 cvs cvs 512 Dec 10 00:04 . drwxr-xr-x 113 cvs cvs 2048 Dec 9 13:50 .. -rw-r--r--1 cvs cvs 548 Nov 17 16:46 .depend -rw-r--r--1 cvs cvs 179 Jun 19 18:09 Makefile Anyone else have one of those? And what makes me even more suspicious is I have that exact same .depend file (same name, not same contents) in my STABLE tree. It's the only one there too with roughly the same date (two days later). -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel target breaks on pcivar.h
On Wed, Dec 13, 2000 at 10:52:10AM +0100, Yann Berthier wrote: > On Wed, 13 Dec 2000, Sheldon Hearn wrote: > > > > > > > On Tue, 12 Dec 2000 11:10:43 MST, Warner Losh wrote: > > > > > I just tried it here and it seemed to work... I also built a kernel > > > last night too. > > > > Given that I've had one "works here" and no "I see it too", it's > > probably safe to assume that I'm doing something stupid. > >Ok, so I'm afraid I'm doing the same stupid thing, because I'm bitten >by the pcivar.h thing during my kernel builds, too :( I had that problem too when I was building this weekend. IIRC there was a rogue '.depend' file in the _source_ tree. Do a 'make clean' of the source tree and see if that helps. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 01:51:25PM -0800, David O'Brien wrote: > On Sun, Dec 10, 2000 at 12:26:38PM -0800, Joe Kelsey wrote: [snip] > > To the extent that NetBSD *forces* the local administrator to use > > /usr/pkg, I find it contains the same deficiency. > > Nope. One can ``ln -s /usr/local /usr/pkg'' and get the behavior those > that like everything in one place prefers while still segregating stuff > for those that prefer it. That makes no sense. The big argument has been that packages should not go into /usr/local because /usr/local is for something else. If you symlink do the symlink trick, you only have one real location for files. If you were to do that, /usr/local or /usr/pkg would be identical. Might as well make /usr/local the "real" location and symlink /usr/pkg. What's the difference? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Highspeed serial consoles and -current
On Sat, Nov 18, 2000 at 06:38:24PM -0800, John W. De Boskey wrote: > Hi, > >I'm trying to increase the speed of the serial console > on a -current box from 9600 to 38400. I've put the following > in /etc/make.conf: > > BOOT_COMCONSOLE_SPEED=38400 # serial console speed > > >Unfortunately, it doesn't work. It still runs at 9600. > I remember seeing something about this (I thought) in one > of the mailing lists, but I can't seem to find it. You did change /etc/ttys, right? I have a serial console (null modem to a notebook PC) running at 115200 just fine, $ grep CONSOLE /etc/make.conf BOOT_COMCONSOLE_SPEED= 115200 $ grep ttyd0 /etc/ttys ttyd0 "/usr/libexec/getty std.115200" vt100 on secure And it is a CURRENT box last made mid-week. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
