Re: FreeBSD 8.1 prerelease "security.jail.mount_allowed" is broken?
On Tuesday 25 May 2010, Pawel Jakub Dawidek wrote: > On Tue, May 25, 2010 at 12:35:19PM +0400, Eugene Mitrofanov wrote: > > Hello > > > > I try to do mount from a jail but it failed. Could you advise me where is my > > mistake? > > > > r...@ftp:eugene# uname -mrs > > FreeBSD 8.1-PRERELEASE amd64 > > r...@ftp:eugene# sysctl -a | grep -E '(jailed|mount)' > > vfs.usermount: 1 > > vfs.ffs.compute_summary_at_mount: 0 > > security.jail.mount_allowed: 1 > > security.jail.jailed: 1 > > r...@ftp:eugene# mount /dev/da2s2a /var/t > > mount: /dev/da2s2a : Operation not permitted > > r...@ftp:eugene# mount /dev/md1 /var/t > > mount: /dev/md1 : Operation not permitted > > r...@ftp:eugene# mount /dev/zvol/tank/ftp.journal /var/t > > mount: /dev/zvol/tank/ftp.journal : Operation not permitted > > You can only mount jail-friendly file systems - those with 'jail' > keyword in lsvfs(1) output. Unfortunately, it seems for me that 'zfs mount' is also broken in 8.1PRE (zpool ver 14). "zfs jail 4 tank" is executing successfully but the word 'jail' does not meet in the 'man zfs' anymore and 'zfs set jailed=on tank' is failed with the error "property 'jailed' not supported on FreeBSD: permission denied". "zfs mount" from jail also failed: r...@ftp:eugene# sysctl security.jail.jailed security.jail.jailed: 1 r...@ftp:eugene# zfs mount tank/test cannot mount 'tank/test': permission denied > What you tried can't be safe. Imagine creating corrupted file system on > da2s2a and mounting it. It will panic entire system, not only your jail. -- EMIT-RIPN, EVM7-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lzma support in `stable' has potential issues
It would be nice if "cd /usr/src/lib/liblzma && make && make install"
just worked on an existing system that didn't already have
/usr/include/lzma, but I can't find anything in the
standard BSD makefiles to support this.
I think you can use:
make hierarchy
to ensure that all the directories are present before
trying to build anything else. (This is one of the
first steps in the "installworld" target.)
As for lzmainfo, I think the attached patch fixes
it so that it pulls the lzma headers from the source
tree and not the installed system. A similar change
is probably appropriate for the other lzma and xz tools.
Tim
Garrett Cooper wrote:
Hi Martin and Tim,
I recently wiped off my Lenovo again to get a fresh install of FreeBSD
on it, and started out at 8.0-RELEASE (it's the media that I had on hand at the
time). Upgrading to 8-STABLE appears to be problematic though.
On a few different occasions I ran into issues doing the following:
make -C /usr/src/usr.bin/lzmainfo depend - fails to find the
appropriate headers
make -C /usr/src/lib/liblzma install - fails to install the headers
into /usr/include/lzma
Etc. I didn't see these issues before lzma was imported into the tree,
which makes me wonder whether or not there are some missing build or install
dependencies somewhere.
Thanks,
-Garrett
Index: Makefile
===
--- Makefile (revision 208369)
+++ Makefile (working copy)
@@ -3,7 +3,6 @@
PROG= lzmainfo
XZDIR= ${.CURDIR}/../../contrib/xz/src
-LZMALIBDIR= ${.CURDIR}/../../lib/liblzma
.PATH: ${XZDIR}/lzmainfo
SRCS+= lzmainfo.c
@@ -14,9 +13,10 @@
WARNS?= 3
-CFLAGS+= -DHAVE_CONFIG_H \
- -I${LZMALIBDIR} \
- -I${XZDIR}/common
+CFLAGS+= -DHAVE_CONFIG_H
+CFLAGS+= -I${.CURDIR}/../../lib/liblzma
+CFLAGS+= -I${.CURDIR}/../../contrib/xz/src/liblzma/api
+CFLAGS+= -I${XZDIR}/common
DPADD= ${LIBLZMA}
LDADD= -llzma
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS trouble on 7.3-STABLE i386
On Tue, 25 May 2010, Mark Morley wrote:
On Fri, 21 May 2010 11:32:33 -0400 (EDT) Rick Macklem wrote: On Fri, 21 May
2010, Mark Morley wrote:
Having an issue with a file server here (7.3-STABLE i386)
The nfsd processes are hanging. Client access to the nfs shares stops working
and the nfsd processes on the server cannot be killed by any means. There are
no errors showing up anywhere on the server. The network connection to the
server seems fine (ie: anything other than nfs traffic seems ok). Rebooting
the server fixes the problem for a while, but it doesn't reboot easily. It
times out on terminating the nfsd processes. When it finally does reboot the
file system isn't marked clean, resulting in a long wait for fsck (although it
doesn't find any problems, it's a multi terrabyte share and it takes a while).
This morning it did it again. This time I tried manually killing nfsd but
nothing I did would make them die. No errors.
Next time it happens, do a "ps axlH" to see what the nfsd threads are
waiting for. It might give you a hint as to what is happening.
Ok, it did it again. ps axlH shows all the nfsd processes stuck in the _ufs_
state. The server isn't doing anything else, no other processes seem to be
monopolizing resources or disks in any way.
rpcinfo doesn't show anything amiss as far as I can tell (ie: rpc is running)
After a reboot, one of the 32 nfsd's almost immediately goes into the "ufs"
state and never leaves it (and never racks up and CPU time either). The others are fine.
Slowly over time more and more enter this state. When I rebooted it today, all but one
were in that state. The clients were bogging down, presumably because the one and only
functioning nfsd was overworked.
You could try this patch. (It reverts the only vnode locking change that I
can see was done the the nfs server between 7.1 and 7.3.):
--- nfs_serv.c.sav 2010-05-25 19:40:29.0 -0400
+++ nfs_serv.c 2010-05-25 19:41:38.0 -0400
@@ -3236,7 +3236,7 @@
io.uio_rw = UIO_READ;
io.uio_td = NULL;
eofflag = 0;
- vn_lock(vp, LK_SHARED | LK_RETRY, td);
+ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (cookies) {
free((caddr_t)cookies, M_TEMP);
cookies = NULL;
@@ -3518,7 +3518,7 @@
io.uio_rw = UIO_READ;
io.uio_td = NULL;
eofflag = 0;
- vn_lock(vp, LK_SHARED | LK_RETRY, td);
+ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (cookies) {
free((caddr_t)cookies, M_TEMP);
cookies = NULL;
If you get a chance to try it, please let us know if it helps, rick
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
hung on ufs vnode lock, was Re: NFS trouble on 7.3-STABLE i386
On Tue, 25 May 2010, Mark Morley wrote: On Fri, 21 May 2010 11:32:33 -0400 (EDT) Rick Macklem wrote: On Fri, 21 May 2010, Mark Morley wrote: Having an issue with a file server here (7.3-STABLE i386) The nfsd processes are hanging. Client access to the nfs shares stops working and the nfsd processes on the server cannot be killed by any means. There are no errors showing up anywhere on the server. The network connection to the server seems fine (ie: anything other than nfs traffic seems ok). Rebooting the server fixes the problem for a while, but it doesn't reboot easily. It times out on terminating the nfsd processes. When it finally does reboot the file system isn't marked clean, resulting in a long wait for fsck (although it doesn't find any problems, it's a multi terrabyte share and it takes a while). This morning it did it again. This time I tried manually killing nfsd but nothing I did would make them die. No errors. Next time it happens, do a "ps axlH" to see what the nfsd threads are waiting for. It might give you a hint as to what is happening. Ok, it did it again. ps axlH shows all the nfsd processes stuck in the _ufs_ state. The server isn't doing anything else, no other processes seem to be monopolizing resources or disks in any way. If the nfsd threads are sleeping on WCHAN "ufs", I think that means that they are waiting for a ufs vnode lock. I don't know what has changed between FreeBSD7.1 and FreeBSD7.3 that might have caused this. I changed the Subject: line in the hopes that someone who might know the answer to this will take a look. rpcinfo doesn't show anything amiss as far as I can tell (ie: rpc is running) After a reboot, one of the 32 nfsd's almost immediately goes into the "ufs" state and never leaves it (and never racks up and CPU time either). The others are fine. Slowly over time more and more enter this state. When I rebooted it today, all but one were in that state. The clients were bogging down, presumably because the one and only functioning nfsd was overworked. One client is running 8.1-prerelease as a test, and that particular client only will start getting lots of timeouts accessing the nfs share (even with less load than the other clients). Just in case it's tickling something on the server I've shut it down this time and I'm leaving it off for the time being. I don't think that the 8.1-prerelease client is an issue. It's just that the FreeBSD8 krpc likes to generate the "not responding" messages more agreesively. They are pretty well meaningless, imho. rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS trouble on 7.3-STABLE i386
On Fri, 21 May 2010 11:32:33 -0400 (EDT) Rick Macklem wrote: On Fri, 21 May 2010, Mark Morley wrote: > Having an issue with a file server here (7.3-STABLE i386) > > The nfsd processes are hanging. Client access to the nfs shares stops > working and the nfsd processes on the server cannot be killed by any means. > There are no errors showing up anywhere on the server. The network > connection to the server seems fine (ie: anything other than nfs traffic > seems ok). Rebooting the server fixes the problem for a while, but it > doesn't reboot easily. It times out on terminating the nfsd processes. When > it finally does reboot the file system isn't marked clean, resulting in a > long wait for fsck (although it doesn't find any problems, it's a multi > terrabyte share and it takes a while). > > This morning it did it again. This time I tried manually killing nfsd but > nothing I did would make them die. No errors. > Next time it happens, do a "ps axlH" to see what the nfsd threads are waiting for. It might give you a hint as to what is happening. Ok, it did it again. ps axlH shows all the nfsd processes stuck in the _ufs_ state. The server isn't doing anything else, no other processes seem to be monopolizing resources or disks in any way. rpcinfo doesn't show anything amiss as far as I can tell (ie: rpc is running) After a reboot, one of the 32 nfsd's almost immediately goes into the "ufs" state and never leaves it (and never racks up and CPU time either). The others are fine. Slowly over time more and more enter this state. When I rebooted it today, all but one were in that state. The clients were bogging down, presumably because the one and only functioning nfsd was overworked. One client is running 8.1-prerelease as a test, and that particular client only will start getting lots of timeouts accessing the nfs share (even with less load than the other clients). Just in case it's tickling something on the server I've shut it down this time and I'm leaving it off for the time being. Any further thoughts? Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" X-pstn-neptune: 2/1/0.50/77 X-pstn-levels: (S:70.94084/99.9 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-pstn-settings: 4 (1.5000:1.5000) s cv gt3 gt2 gt1 r p m c X-pstn-addresses: from [294/10]
Re: Kernel panic when unpluggin AC adaptor
On Tue, May 25, 2010 at 5:52 PM, David DEMELIER wrote: > 2010/5/25 Giovanni Trematerra : >> On Mon, May 24, 2010 at 9:43 PM, David DEMELIER >> wrote: >>> 2010/5/12 Giovanni Trematerra : On Fri, May 7, 2010 at 8:33 PM, Demelier David wrote: > Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit : >> On Fri, May 7, 2010 at 2:08 PM, Demelier David >> wrote: >> > Hi, >> > I noticed that pluggin the AC adaptor when I boot without it >> > does not >> > panic. It only panic when removing it. >> > >> > Maybe that could help ? >> > >> >> Good to know. The problem lies somewhere when performance state change. >> In your case it happens when you remove AC adaptor. Let's hope someone on >> acpi@ ml comes up with a good idea. >> > > Okay so for the moment no change, I'll wait for someone with an idea > that could solve my problem. For me because the panic only happens when > changing profile from ac plugged -> ac unplugged (and not the reverse) I > would think it's a cpu related acpi issue. > I looked deeper and it seems to me that when you unplug the AC adapter, acpi_cpu_notify calls acpi_cpu_cx_cst that try to allocate a new cx_ptr->p_lvlx via acpi_PkgGas. If acpi_PkgGas set cx_ptr->p_lvlx to NULL for any reasons you'll have the panic that you reported. A solution would be to set acpi_cpu_hook to NULL so acpi_cpu_idle won't call it. I need some time to have a patch because of the possible race between acpi_cpu_notify and acpi_cpu_idle during set acpi_cpu_hook to NULL. if you have time and want panic your system you could try the attached patch, just to be sure that we catch it. >>> >>> Hi, it paniced today ! I don't know why it randomly panic but it did, >>> the backtrace didn't change. There is a picture about the panic : >>> >>> http://img541.imageshack.us/img541/2773/dsc00388xa.jpg >> >> What was you trying? acpi_idle5.diff.txt patch? >> How did it panic? Unplugging AC adapter? >> > > Hi, I tried this one : lvlx.diff.txt. Yes by unplugging the AC adapter. > This is an old one. Could you try acpi_idle5.diff.txt? I kept you in Cc when I sent to the list. If you have problems, let me know, I'll resend to you the patch. Thank you. -- Gianni ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Zpool scrub and not-root users
On Tue, 25 May 2010 16:13, Jeremy Chadwick wrote:
In Message-Id: <20100525201315.ga20...@icarus.home.lan>
On Tue, May 25, 2010 at 03:21:56PM -0400, jhell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/2010 15:04, Jeremy Chadwick wrote:
On Mon, May 24, 2010 at 05:00:03PM +0200, Mikkel Skaerris wrote:
Im wondering if there is a way of allowing non-root users to perform a disk
scrub using zpool scrub . I've been messing around with permissions,
but no luck so far. Anyone got a clue?
One question: why? Followed by one answer: sudo. :-)
Don't get me wrong I'm not shooting down sudo below.
: He does not need to add another layer of insecurity to his system such
: as sudo. Not saying that this is bad but it feels like a little overkill
: for something as simple as this.
This can be done old-school.
pw groupadd _zfsadm
pw groupmod _zfsadm -m {username}
chmod u+s,o-rx /sbin/zpool
chown :_zfsadm /sbin/zpool
: Repeat command line 2 for every user you want to have root type access
: to /sbin/zpool.
I thought I said "root type access to /sbin/zpool".
Of course you do not need the zfsadm group to do this. You could just
use the wheel group which in turn gives any member of that group su(1)
access to the root user, so you commands would turn into...
pw groupmod wheel -m {username}
chmod u+s,o-rx /sbin/zpool
Because this binary is already installed group wheel there is no need to
chown it. And this is a little more implicit that you trust anyone with
access to the zpool command will also be having access to su(1)
Pick one, and Ill leave the "how to keep these permissions through
upgrades/updates of world" up to you.
If I'm misunderstanding what the OP wants, then I welcome correction. I
read the Op to want users to be able to run "zpool scrub", so I took
that literally -- "/sbin/zpool scrub " and nothing more.
No you are not misunderstanding but I am also taking into account that the
admin said "I've been messing around with permissions" & most notably I
thought that he has tried the access control methods that are administered
through the use of zfs allow which also might be a possibility if the
admin has world/base on a zfsroot. Second thought that came to mind while
leaving the possibility open to him was your standard Unix file perms.
While thinking about the scenario in a quick sense, If this is disk
activity that the admin wants to grant to a user in the form of scrub on a
pool then the admin already must trust whoever he is planning to give
these rights and has taken into account the possibility of misuse which
has lead him here asking for advice.
sudo offers the ability for the OP to provide root-level access to
defined users and ONLY the ability to run "/sbin/zpool scrub {pool}" and
nothing more (e.g. not "/sbin/zpool remove" or similar). It could also
be used to define certain users to scrub only certain pools.
I hope so at least that's what it was designed for. Yes very well noted
just leaving the possibility open to the admin to use something other than
a third party package in case it is his policy to not have something like
that installed. It happens.
Your first and second solutions allow any user added to _zfsadm and
group wheel, respectively, the ability to use /sbin/zpool. I hear
"zpool destroy -f" is a fun command to run while the system
administrator isn't looking. :-)
Good thing in most cases you can recover a destroyed pool or at least
that's the way it was designed the last time I accidentally did that (-D).
Backups are also a good thing in the case of a angry over driven highly
motivated administrator or staff.
;)
--
jhell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Zpool scrub and not-root users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/05/2010 20:37:34, Chuck Swiger wrote:
> On May 25, 2010, at 12:21 PM, jhell wrote:
>> He does not need to add another layer of insecurity to his system such
>> as sudo. Not saying that this is bad but it feels like a little overkill
>> for something as simple as this.
>>
>> This can be done old-school.
>>
>> pw groupadd _zfsadm
>> pw groupmod _zfsadm -m {username}
>> chmod u+s,o-rx /sbin/zpool
>> chown :_zfsadm /sbin/zpool
>>
>> Repeat command line 2 for every user you want to have root type
>> access to /sbin/zpool.
> This is providing them with the ability to run any zpool command, not
> restricted to "zpool scrub" only. "zpool offline" or "zpool destroy"
> could wreak havoc upon the system if misused
>
Turning on the SUID bit on a program which wasn't designed from the
ground up to be run like that is pretty much asking for trouble too.
For instance SUID programs generally know they have enhanced privs. and
give them up right after they've done whatever they need the privileges
for. Without that level of attention to detail, SUID programs are a
root compromise waiting to happen.
sudo(8) would be my choice solution for this.
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkv8MlsACgkQ8Mjk52CukIwNYgCcCAIghZlNICwwooE5R8z/3SfQ
AGwAnRcwBWkeKNBSHz4sgmm9rLZZWaKf
=g6be
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Zpool scrub and not-root users
On Tue, May 25, 2010 at 03:21:56PM -0400, jhell wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/24/2010 15:04, Jeremy Chadwick wrote:
> > On Mon, May 24, 2010 at 05:00:03PM +0200, Mikkel Skaerris wrote:
> >> Im wondering if there is a way of allowing non-root users to perform a disk
> >> scrub using zpool scrub . I've been messing around with permissions,
> >> but no luck so far. Anyone got a clue?
> >
> > One question: why? Followed by one answer: sudo. :-)
> >
>
> He does not need to add another layer of insecurity to his system such
> as sudo. Not saying that this is bad but it feels like a little overkill
> for something as simple as this.
>
> This can be done old-school.
>
> pw groupadd _zfsadm
> pw groupmod _zfsadm -m {username}
> chmod u+s,o-rx /sbin/zpool
> chown :_zfsadm /sbin/zpool
>
> Repeat command line 2 for every user you want to have root type access
> to /sbin/zpool.
>
> Of course you do not need the zfsadm group to do this. You could just
> use the wheel group which in turn gives any member of that group su(1)
> access to the root user, so you commands would turn into...
>
> pw groupmod wheel -m {username}
> chmod u+s,o-rx /sbin/zpool
>
> Because this binary is already installed group wheel there is no need to
> chown it. And this is a little more implicit that you trust anyone with
> access to the zpool command will also be having access to su(1)
>
> Pick one, and Ill leave the "how to keep these permissions through
> upgrades/updates of world" up to you.
If I'm misunderstanding what the OP wants, then I welcome correction. I
read the Op to want users to be able to run "zpool scrub", so I took
that literally -- "/sbin/zpool scrub " and nothing more.
sudo offers the ability for the OP to provide root-level access to
defined users and ONLY the ability to run "/sbin/zpool scrub {pool}" and
nothing more (e.g. not "/sbin/zpool remove" or similar). It could also
be used to define certain users to scrub only certain pools.
Your first and second solutions allow any user added to _zfsadm and
group wheel, respectively, the ability to use /sbin/zpool. I hear
"zpool destroy -f" is a fun command to run while the system
administrator isn't looking. :-)
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Zpool scrub and not-root users
On May 25, 2010, at 12:21 PM, jhell wrote:
> He does not need to add another layer of insecurity to his system such
> as sudo. Not saying that this is bad but it feels like a little overkill
> for something as simple as this.
>
> This can be done old-school.
>
> pw groupadd _zfsadm
> pw groupmod _zfsadm -m {username}
> chmod u+s,o-rx /sbin/zpool
> chown :_zfsadm /sbin/zpool
>
> Repeat command line 2 for every user you want to have root type access to
> /sbin/zpool.
This is providing them with the ability to run any zpool command, not
restricted to "zpool scrub" only. "zpool offline" or "zpool destroy" could
wreak havoc upon the system if misused
Regards,
--
-Chuck
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Zpool scrub and not-root users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/2010 15:04, Jeremy Chadwick wrote:
> On Mon, May 24, 2010 at 05:00:03PM +0200, Mikkel Skaerris wrote:
>> Im wondering if there is a way of allowing non-root users to perform a disk
>> scrub using zpool scrub . I've been messing around with permissions,
>> but no luck so far. Anyone got a clue?
>
> One question: why? Followed by one answer: sudo. :-)
>
He does not need to add another layer of insecurity to his system such
as sudo. Not saying that this is bad but it feels like a little overkill
for something as simple as this.
This can be done old-school.
pw groupadd _zfsadm
pw groupmod _zfsadm -m {username}
chmod u+s,o-rx /sbin/zpool
chown :_zfsadm /sbin/zpool
Repeat command line 2 for every user you want to have root type access
to /sbin/zpool.
Of course you do not need the zfsadm group to do this. You could just
use the wheel group which in turn gives any member of that group su(1)
access to the root user, so you commands would turn into...
pw groupmod wheel -m {username}
chmod u+s,o-rx /sbin/zpool
Because this binary is already installed group wheel there is no need to
chown it. And this is a little more implicit that you trust anyone with
access to the zpool command will also be having access to su(1)
Pick one, and Ill leave the "how to keep these permissions through
upgrades/updates of world" up to you.
Good luck & regards,
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJL/CNUAAoJEJBXh4mJ2FR+HwcH/0vuGlIP8mU1p6FI0XiEl9K/
tpDLxED+4cd8htBTQyh0mDWrRz8dOagjggaENC2JvNpUO8Vhxx0mJNZY6pvzmAys
5VHevdYKvY6doEjoQD9muktECXruCOXgQtxeI34r+ZLJz9fUhVJIlcNDBBrhOAG5
/P6XYy5LIKEuxBBRNqosW+JVTcU4sOJhGU1YZUlUpn0z41ObM87vjD77XP6sWfhZ
Sw5dDPhNBHmmOuCEeuTnpItu1ykHUrr5jDkrtFWyIFP7ijPl7Fbd3VIRaP5nlWDU
yNd06479yKS1uqOwFeEXt3DOr8nws+uY/6WtXzlsmLdhsqwy2FQN35r7PlXaY0k=
=c/NP
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 8.1 prerelease "security.jail.mount_allowed" is broken?
On Tue, May 25, 2010 at 12:35:19PM +0400, Eugene Mitrofanov wrote: > Hello > > I try to do mount from a jail but it failed. Could you advise me where is my > mistake? > > r...@ftp:eugene# uname -mrs > FreeBSD 8.1-PRERELEASE amd64 > r...@ftp:eugene# sysctl -a | grep -E '(jailed|mount)' > vfs.usermount: 1 > vfs.ffs.compute_summary_at_mount: 0 > security.jail.mount_allowed: 1 > security.jail.jailed: 1 > r...@ftp:eugene# mount /dev/da2s2a /var/t > mount: /dev/da2s2a : Operation not permitted > r...@ftp:eugene# mount /dev/md1 /var/t > mount: /dev/md1 : Operation not permitted > r...@ftp:eugene# mount /dev/zvol/tank/ftp.journal /var/t > mount: /dev/zvol/tank/ftp.journal : Operation not permitted You can only mount jail-friendly file systems - those with 'jail' keyword in lsvfs(1) output. What you tried can't be safe. Imagine creating corrupted file system on da2s2a and mounting it. It will panic entire system, not only your jail. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp5qyFIhUszz.pgp Description: PGP signature
Re: Buzzing snd_emu10kx enabled card with r206173
On Tue, May 25, 2010 at 3:06 AM, Mark Stapper wrote: > On 18/05/2010 08:14, Mark Stapper wrote: >> On 18/05/2010 00:22, Garrett Cooper wrote: >> >>> On Mon, May 17, 2010 at 11:21 AM, Mark Stapper wrote: >>> >>> On 12/04/2010 16:29, Garrett Cooper wrote: > On Tue, Apr 6, 2010 at 3:39 AM, Garrett Cooper wrote: > > > >> On Mon, Apr 5, 2010 at 12:26 PM, Garrett Cooper >> wrote: >> >> >> >>> On Mon, Apr 5, 2010 at 11:22 AM, Garrett Cooper >>> wrote: >>> >>> >>> Hi, When I first installed FreeBSD on this machine, I had a heck of a time getting the soundcard's PCM channel to function properly. It would buzz incessantly when I played any audio on it; I disabled the onboard snd_hda enabled audio and things magically worked, until today. After a kernel upgrade and a few warm boots, I'm back to where I started from -- the PCM channel buzzes whenever I play audio; line-in works perfectly fine however. I'm not seeing anything out of the ordinary in commits over the past couple of weeks for the pcm pieces (the last successful kernel I used was 2~3 weeks old). Are there any device_printf's I should add or a debug procedure that you recommend I do to triage the situation? Thanks, -Garrett # uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206173M: Sun Apr 4 19:54:22 PDT 2010 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 # pciconf -lv | grep -A 4 emu emu10...@pci0:8:0:0: class=0x040100 card=0x10211102 chip=0x00081102 rev=0x00 hdr=0x00 vendor = 'Creative Technology LTD.' device = 'sound blaster Audigy 2 (ca0108)' class = multimedia subclass = audio # dmesg | grep 'irq 16' uhci0: port 0xa800-0xa81f irq 16 at device 26.0 on pci0 pcib7: irq 16 at device 28.1 on pci0 emu10kx0: port 0xec00-0xec3f irq 16 at device 0.0 on pci8 # dmesg | grep 'pcm' pcm0: on emu10kx0 pcm0: pcm1: on emu10kx0 pcm2: on emu10kx0 pcm3: on emu10kx0 pcm4: on emu10kx0 >>> Some more information: >>> >>> 1. snd_emu10kx and sound are both modules loaded on boot, along with >>> if_re, linux, and nvidia. >>> 2. Disabling nvidia -> no change. >>> 3. Disabling acpi -> unbootable system because many drivers can't map >>> interrupts without it (can't test unless I isolate the drivers and >>> enable them one by one -- something I'll try later on). >>> >>> I'm at a loss right now... my hunch is that it's potentially a bad >>> interaction between the snd_emu10kx driver and another driver on the >>> same PCI bus (which is just the ACPI and uhci drivers), but I can't >>> test these claims. There are other funky things about my system that >>> have changed over the past couple of kernel versions, like front USB >>> ports could charge my iPhone, and now they don't... and the fact that >>> ACPI blanking via nvidia now works again... so something may have >>> changed on the backend, but I'm not 100% sure on what I should isolate >>> as the root cause, yet. >>> >>> >>> >> Grr... it's `healed' itself again. I'll watch out for potential >> catalysts to the issue in the future. >> >> >> > Ok. Damn issue came back and here's what happened. Rebooted > several times with the same kernel and slight modifications, loading > and unloading snd_emu10kx and sound, testing out snd_emu10k1, and no > dice. The buzz was bad and it was driving me insane. Again, line-in > functioned just fine, so I didn't know what the heck was going. I was > getting desperate, so I finally broke down and booted the Gentoo Linux > livecd. PCM worked just fine. Then I got irritated enough and finally > just built the module and the sound support directly into the kernel > and everything is hunky dorey again. Does anyone have a stab in the > dark as to what's going on? Is it a potential bus or interrupt > conflict / race condition that gets alleviated when support is nailed > into the kernel? Or are other folks as stumped as I am, s.t. I should > just try emailing current@ instead to see if someone maybe knows > what's going on there :(...? > Thanks, > -Garrett > > I have the same problem. I'll try compiling the driver in the kernel. >>> FWIW I've compiled the driver into the kernel for several >>> iterations now and it works like a champ, so there's something with >>> the sound subsystem that isn't jiving properly when loading from >>> modules... >>> HTH, >>> -Garrett >>> >>> >> Thanks
Re: Kernel panic when unpluggin AC adaptor
2010/5/25 Giovanni Trematerra : > On Mon, May 24, 2010 at 9:43 PM, David DEMELIER > wrote: >> 2010/5/12 Giovanni Trematerra : >>> On Fri, May 7, 2010 at 8:33 PM, Demelier David >>> wrote: Le Vendredi 07 mai 2010 à 18:22 +0200, Giovanni Trematerra a écrit : > On Fri, May 7, 2010 at 2:08 PM, Demelier David > wrote: > > Hi, > > I noticed that pluggin the AC adaptor when I boot without it > > does not > > panic. It only panic when removing it. > > > > Maybe that could help ? > > > > Good to know. The problem lies somewhere when performance state change. > In your case it happens when you remove AC adaptor. Let's hope someone on > acpi@ ml comes up with a good idea. > Okay so for the moment no change, I'll wait for someone with an idea that could solve my problem. For me because the panic only happens when changing profile from ac plugged -> ac unplugged (and not the reverse) I would think it's a cpu related acpi issue. >>> >>> I looked deeper and it seems to me that when you unplug the AC >>> adapter, acpi_cpu_notify calls acpi_cpu_cx_cst that try to allocate a >>> new cx_ptr->p_lvlx via acpi_PkgGas. >>> If acpi_PkgGas set cx_ptr->p_lvlx to NULL for any reasons you'll have >>> the panic that you reported. >>> A solution would be to set acpi_cpu_hook to NULL so acpi_cpu_idle won't >>> call it. >>> I need some time to have a patch because of the possible race between >>> acpi_cpu_notify and >>> acpi_cpu_idle during set acpi_cpu_hook to NULL. >>> if you have time and want panic your system you could try the attached >>> patch, just to be >>> sure that we catch it. >>> >> >> Hi, it paniced today ! I don't know why it randomly panic but it did, >> the backtrace didn't change. There is a picture about the panic : >> >> http://img541.imageshack.us/img541/2773/dsc00388xa.jpg > > What was you trying? acpi_idle5.diff.txt patch? > How did it panic? Unplugging AC adapter? > Hi, I tried this one : lvlx.diff.txt. Yes by unplugging the AC adapter. -- Demelier David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: openbgpd / openospf / carp / vlan (on 7.2) trouble
Hi Bjørn! I also have had troubles with openbdpd few years ago. All troubles vanished after installing quagga instead of openbgpd. Well, maybe it's not great solution, but it's workaround. wbr. 2010/5/25 Ask Bjørn Hansen : > Hi, > > Since upgrading from openbgpd 4.5 to 4.7 (tried 4.6, too with bad results) > openbgpd doesn't work on my vlan interface. I have two routers (10.0.100.2 > and .3). That network is on vlan2; with carp2 running .1. > > Running .3 on 4.6 or 4.7 makes it immediately lose it's route to the 100.0/24 > network when bgpd starts. bgpd is announcing 10.0.100.0/24 (and understands > that it's a locally routed network, according to bgpctl show ip bgp, see > below). > > ... but somehow the routing able gets changed to have that network routed to > 10.0.100.2 (the other router, running 4.5) instead of 0.0.0.0/vlan2. I can't > even ping 10.0.100.3 (the vlan2 IP) from the box itself. If I ping that IP > from a box on a different network it works. > > Also, I can restore the route with > > route del -net 10.0.100.0/24 10.0.100.2 > route add -net 10.0.100.0/24 -interface vlan2 > > ... but as soon as bgpd reconnects it will mess it up again. > > Any ideas? Am I doing it wrong? I understand that bgpd is exchanging the > routes; but until v4.5 it'd keep the local interface as a preference. What's > the proper forum to for the FreeBSD openbgpd port? I can't even find a > changelog for the different versions... > > For what it's worth - on a non-vlan, non-carp interface in another otherwise > similar setup it's working ok with 4.6 and 4.7. > > > - ask > > gw-b.dev# bgpctl show ip bgp > flags: * = Valid, > = Selected, I = via IBGP, A = Announced > origin: i = IGP, e = EGP, ? = Incomplete > > flags destination gateway lpref med aspath origin > AI*> 10.0.100.0/24 0.0.0.0 100 0 i > *> 10.0.201.0/24 10.77.80.6 100 30 64701 i > > > gw-b.dev# netstat -rn | grep 10.0.100 > 10.0.100.0/24 10.0.100.2 UGC 5 186 vlan2 > 10.0.100.1 10.0.100.2 UGHW3 0 3 vlan2 3053 > 10.0.100.3 10.0.100.2 UGHW3 0 1 vlan2 3522 > 10.0.100.13 10.0.100.2 UGHW3 0 34 vlan2 3599 > 10.0.100.103 10.0.100.2 UGHW3 0 32 vlan2 3583 > 10.0.100.104 10.0.100.2 UGHW3 0 4 vlan2 3565 > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: openbgpd / openospf / carp / vlan (on 7.2) trouble
Dear Ask, the problem is, that freebsd only allows 1 route to 1 destination (at least at freebsd 6.3). I have a similar setup (carp and routing protocols) and use a modified ucarp with additional route add and deletes. Kind regards, ingo flaschberger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: make world fails in usr.sbin/config?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/05/2010 11:40:23, Stefan Bethke wrote: > For the record: I'm now running -stable as of last night, compiled > without issue on ZFS filesystems throughout. No idea what caused the > issue in the first place, and what made it disappear though, but > updating to the correctly built -stable made the build on ZFS work > again. (It also involved an accidential upgrade and downgrade via > -current, since I checked out the wrong tag with csup. Yikes.) I've a new machine that's been running 8-STABLE on ZFS for about a week now. Had no problems installing and then upgrading to recent 8-STABLE although I did start with installing an 8-STABLE snapshot rather than 8.0-RELEASE. (See: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror) Verb. Sap. If you're booting from ZFS, beware of updating the zpool version without due care and attention. 8.0-RELEASE was on version 13, 8-STABLE is now on version 14. (Use 'zpool update' to see what the status is on your machine -- this just gives you a report, and doesn't update anything.) Updating the zpool version is pretty smooth and simple, but *remember to immediately rebuild and reinstall gptzfsboot or zfsboot bootcode on your drives*. If you don't do that, your system won't be able to find the pool with the root filesystem and so won't be able to reboot. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv7rvYACgkQ8Mjk52CukIzoEQCeNccarvp+NUrOAvoomJIRiT+H N6MAn0UbAcoAIdrgyI8CiEvhoiY1mCLh =ZfJJ -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: make world fails in usr.sbin/config?
Am 24.05.2010 um 19:49 schrieb Jeremy Chadwick: > On Mon, May 24, 2010 at 09:24:00AM -0700, Jeremy Chadwick wrote: >> Builds are underway now (following /usr/src/Makefile method), I'll >> report back when those are done. I'm also adding "time" in front of the >> "make buildXXX" portions just to see now long things take. > > The build portions finished. Here are the numbers (quite high due to a > combination of limited memory constraints (intentional) and the fact > that VMware Workstation isn't the fastest thing on the planet. :-) ) For the record: I'm now running -stable as of last night, compiled without issue on ZFS filesystems throughout. No idea what caused the issue in the first place, and what made it disappear though, but updating to the correctly built -stable made the build on ZFS work again. (It also involved an accidential upgrade and downgrade via -current, since I checked out the wrong tag with csup. Yikes.) Thanks for all the support to all of you! Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Buzzing snd_emu10kx enabled card with r206173
On 18/05/2010 08:14, Mark Stapper wrote: > On 18/05/2010 00:22, Garrett Cooper wrote: > >> On Mon, May 17, 2010 at 11:21 AM, Mark Stapper wrote: >> >> >>> On 12/04/2010 16:29, Garrett Cooper wrote: >>> >>> On Tue, Apr 6, 2010 at 3:39 AM, Garrett Cooper wrote: > On Mon, Apr 5, 2010 at 12:26 PM, Garrett Cooper > wrote: > > > >> On Mon, Apr 5, 2010 at 11:22 AM, Garrett Cooper >> wrote: >> >> >> >>> Hi, >>>When I first installed FreeBSD on this machine, I had a heck of a >>> time getting the soundcard's PCM channel to function properly. It >>> would buzz incessantly when I played any audio on it; I disabled the >>> onboard snd_hda enabled audio and things magically worked, until >>> today. After a kernel upgrade and a few warm boots, I'm back to where >>> I started from -- the PCM channel buzzes whenever I play audio; >>> line-in works perfectly fine however. I'm not seeing anything out of >>> the ordinary in commits over the past couple of weeks for the pcm >>> pieces (the last successful kernel I used was 2~3 weeks old). >>>Are there any device_printf's I should add or a debug procedure >>> that you recommend I do to triage the situation? >>> Thanks, >>> -Garrett >>> >>> # uname -a >>> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206173M: >>> Sun Apr 4 19:54:22 PDT 2010 >>> r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 >>> # pciconf -lv | grep -A 4 emu >>> emu10...@pci0:8:0:0:class=0x040100 card=0x10211102 chip=0x00081102 >>> rev=0x00 hdr=0x00 >>>vendor = 'Creative Technology LTD.' >>>device = 'sound blaster Audigy 2 (ca0108)' >>>class = multimedia >>>subclass = audio >>> # dmesg | grep 'irq 16' >>> uhci0: port 0xa800-0xa81f >>> irq 16 at device 26.0 on pci0 >>> pcib7: irq 16 at device 28.1 on pci0 >>> emu10kx0: port 0xec00-0xec3f irq 16 at >>> device 0.0 on pci8 >>> # dmesg | grep 'pcm' >>> pcm0: on emu10kx0 >>> pcm0: >>> pcm1: on emu10kx0 >>> pcm2: on emu10kx0 >>> pcm3: on emu10kx0 >>> pcm4: on emu10kx0 >>> >>> >>> >> Some more information: >> >> 1. snd_emu10kx and sound are both modules loaded on boot, along with >> if_re, linux, and nvidia. >> 2. Disabling nvidia -> no change. >> 3. Disabling acpi -> unbootable system because many drivers can't map >> interrupts without it (can't test unless I isolate the drivers and >> enable them one by one -- something I'll try later on). >> >> I'm at a loss right now... my hunch is that it's potentially a bad >> interaction between the snd_emu10kx driver and another driver on the >> same PCI bus (which is just the ACPI and uhci drivers), but I can't >> test these claims. There are other funky things about my system that >> have changed over the past couple of kernel versions, like front USB >> ports could charge my iPhone, and now they don't... and the fact that >> ACPI blanking via nvidia now works again... so something may have >> changed on the backend, but I'm not 100% sure on what I should isolate >> as the root cause, yet. >> >> >> > Grr... it's `healed' itself again. I'll watch out for potential > catalysts to the issue in the future. > > > Ok. Damn issue came back and here's what happened. Rebooted several times with the same kernel and slight modifications, loading and unloading snd_emu10kx and sound, testing out snd_emu10k1, and no dice. The buzz was bad and it was driving me insane. Again, line-in functioned just fine, so I didn't know what the heck was going. I was getting desperate, so I finally broke down and booted the Gentoo Linux livecd. PCM worked just fine. Then I got irritated enough and finally just built the module and the sound support directly into the kernel and everything is hunky dorey again. Does anyone have a stab in the dark as to what's going on? Is it a potential bus or interrupt conflict / race condition that gets alleviated when support is nailed into the kernel? Or are other folks as stumped as I am, s.t. I should just try emailing current@ instead to see if someone maybe knows what's going on there :(...? Thanks, -Garrett >>> I have the same problem. >>> I'll try compiling the driver in the kernel. >>> >>> >> FWIW I've compiled the driver into the kernel for several >> iterations now and it works like a champ, so there's something with >> the sound subsystem that isn't jiving properly when loading from >> modules... >> HTH, >> -Garrett >> >>
openbgpd / openospf / carp / vlan (on 7.2) trouble
Hi, Since upgrading from openbgpd 4.5 to 4.7 (tried 4.6, too with bad results) openbgpd doesn't work on my vlan interface. I have two routers (10.0.100.2 and .3). That network is on vlan2; with carp2 running .1. Running .3 on 4.6 or 4.7 makes it immediately lose it's route to the 100.0/24 network when bgpd starts. bgpd is announcing 10.0.100.0/24 (and understands that it's a locally routed network, according to bgpctl show ip bgp, see below). ... but somehow the routing able gets changed to have that network routed to 10.0.100.2 (the other router, running 4.5) instead of 0.0.0.0/vlan2. I can't even ping 10.0.100.3 (the vlan2 IP) from the box itself. If I ping that IP from a box on a different network it works. Also, I can restore the route with route del -net 10.0.100.0/24 10.0.100.2 route add -net 10.0.100.0/24 -interface vlan2 ... but as soon as bgpd reconnects it will mess it up again. Any ideas? Am I doing it wrong? I understand that bgpd is exchanging the routes; but until v4.5 it'd keep the local interface as a preference. What's the proper forum to for the FreeBSD openbgpd port? I can't even find a changelog for the different versions... For what it's worth - on a non-vlan, non-carp interface in another otherwise similar setup it's working ok with 4.6 and 4.7. - ask gw-b.dev# bgpctl show ip bgp flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 10.0.100.0/240.0.0.0100 0 i *>10.0.201.0/2410.77.80.6 10030 64701 i gw-b.dev# netstat -rn | grep 10.0.100 10.0.100.0/24 10.0.100.2 UGC 5 186 vlan2 10.0.100.1 10.0.100.2 UGHW3 03 vlan2 3053 10.0.100.3 10.0.100.2 UGHW3 01 vlan2 3522 10.0.100.1310.0.100.2 UGHW3 0 34 vlan2 3599 10.0.100.103 10.0.100.2 UGHW3 0 32 vlan2 3583 10.0.100.104 10.0.100.2 UGHW3 04 vlan2 3565 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 8.1 prerelease "security.jail.mount_allowed" is broken?
Hello I try to do mount from a jail but it failed. Could you advise me where is my mistake? r...@ftp:eugene# uname -mrs FreeBSD 8.1-PRERELEASE amd64 r...@ftp:eugene# sysctl -a | grep -E '(jailed|mount)' vfs.usermount: 1 vfs.ffs.compute_summary_at_mount: 0 security.jail.mount_allowed: 1 security.jail.jailed: 1 r...@ftp:eugene# mount /dev/da2s2a /var/t mount: /dev/da2s2a : Operation not permitted r...@ftp:eugene# mount /dev/md1 /var/t mount: /dev/md1 : Operation not permitted r...@ftp:eugene# mount /dev/zvol/tank/ftp.journal /var/t mount: /dev/zvol/tank/ftp.journal : Operation not permitted Best regards -- EMIT-RIPN, EVM7-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
