Kerberized NFSv3 incorrect behavior
Dear all,
I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My
configuration is based on
http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My
goal is to share filesystems securely through kerberos authentication.
Everything works fine, until I try to kdestroy my tickets or kinit to
some other user, where the system insists to think that I am the user
that initially obtained their ticket. To be more extensive, my story is
as follows:
nfs server:
/etc/rc.conf:
rpcbind_enable="YES"
mountd_flags="-e"
nfs_server_enable="YES"
nfs_client_enable="YES"
gssd_enable="YES"
and the kernel is compiled with:
options KGSSAPI
device crypto
my /etc/exports contains:
/exports-alldirs -sec=krb5
nfs client:
/etc/rc.conf:
rpcbind_enable="YES"
nfs_client_enable="YES"
gssd_enable="YES"
on both client and server the /etc/krb5.conf contains:
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc.example.com
admin_server = kdc.example.com
kpasswd_server = kdc.example.com
}
[domain_realm]
kdc.example.com= EXAMPLE.COM
.kdc.example.com = EXAMPLE.COM
.example.com= EXAMPLE.COM
example.com = EXAMPLE.COM
and both client and server have the correct entries about each other
(and themselves) in their /etc/hosts, so heimdal works just fine.
Both client and server have their respective keytabs stored in
/etc/krb5.keytab, and I use two users in my example (that both exist in
both systems with the same uid,gid): mamalos and testakis.
So, when I mount the exported filesystem on the client giving:
# mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt
# mount
/dev/da0s1a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
server.example.com:/exports on /mnt (nfs)
and try to access the share:
# ls /mnt
ls: mnt: Permission denied
I get the error I am expecting, since root does not have any kerberos
tickets assigned, yet. Let's see what happens when I kinit as mamalos:
# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: mama...@example.com
Issued Expires Principal
Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/exapmle@example.com
# ls -la /mnt/
total 8
drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./
drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../
drwx-- 2 mamalos wheel - 512 5 Feb 11:11 mamalos/
drwx-- 2 testakis wheel - 512 4 Feb 19:06 testakis/
# touch /mnt/mamalos/myfile
# ls -la /mnt/mamalos/myfile
rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile
Which is the exact behavior that is expected. Now when I kdestroy:
# kdestroy
# klist
klist: No ticket file: /tmp/krb5cc_0
# touch /mnt/mamalos/myfilethatshouldnotbe
# ls -la /mnt/mamalos/myfilethatshouldnotbe
-rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24
/mnt/mamalos/myfilethatshouldnotbe
And I can do everything in that share as if I were still mamalos, even
though I kdestroyed my kerberos ticket. The same thing will happen even
if I kinit to testakis after that. klist shows testakis' ticket this
time, but I am not allowed to access (rwx) tetakis' files/folders, and I
still have full control over mamalos' files and folders.
In order to be able to do something as testakis, I have to unmount the
share and remount it while having testakis' ticket (or having no ticket
at all, and giving kinit testakis after mounting the share).
I am not an NFS expert, but I suppose that this behavior is not the one
to be expected, except if I am missing some fundamental information
about kerberized NFS that explains it. Even so, it would be quite unwise
to behave so, since even if the users kdestroys their tickets, they have
still all permissions as when they obtained their ticket.
Thank you all in advance,
looking forward to an answer,
kind regards,
mamalos
--
George Mamalakis
IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)
Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki
phone number : +30 (2310) 994379
___
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: Inmutable bit in some binaries
It's possible installworld will break (fail/exit) when trying to overwrite some of these binaries. However... install(1) supports the -f flags to specify what the destination file should have its file flags (chflags) set to, and from looking at the code (src/usr.bin/xinstall/xinstall.c), there are some places which indicate before copying/installing a file the software may attempt to unset file flags first. I'm not 100% familiar with this code, but it appears as if use of the -S flag to install(1) would cause it to behave like described. It should be easy enough for you to test. Otherwise, my recommendation is to build a test system / virtual box of some sort (VMware, etc.) and try it. See what happens. Ok. It's exactly what I've supposed. Opinion below: What you're attempting to solve, ultimately, is security through obscurity and gets you a very large headache. :-) Your schg idea would only work if you planned on using kern.securelevel=1 or higher. This sounds great in concept, but many a time on this list have people posted problems with system administrative tasks (re: upgrading) when this sysctl is set to non-default (-1). Mm... I don't undestand this like secuiryt by obscurity; anyway you've the reason: kern.securelevel should be the correct path to follow. If you plan on using this, I would advocate *all* installation/work be done in single-user mode. I know quite a few people who completely ignore the "boot into single user" step of src/Makefile and instead do it in multi-user mode -- only to be found later screaming/crying when binaries don't work or behave oddly because, say, /libexec/ld-elf.so was supposed to be updated yet wasn't due to their choosing to not follow the proper procedure. If your system doesn't have an out-of-band method of getting to it (ex. serial console), then I wouldn't bother trying any of the above. Otherwise, I'm pretty sure others here have made use of read-only environments, such as read-only NFS root filesystems (sometimes accomplished via PXE) and/or /usr, or CD-based OS (good luck changing any files there). I can't help in that regard. Thanks for comments. ;) -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: ionice in FreeBSD?
Great aclarations. Thanks. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ 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: ionice in FreeBSD?
Great work Luigi ;) That's amazing... anyway ¿is it production-ready? -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE -> -STABLE and size of /
Hi Randi, On 02/03/10 02:43, Randi Harper wrote: This is going to happen. It's been on my to-do list for a while, as I find it increasingly annoying. The default sizes of all mount points need to be tweaked a bit. Be patient, there will be some new changes going into sysinstall very soon. Great! Thank you! my next machine I again installed ZFS only, so there I didn't run into the topic :-) - Olli ___ 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.0 stable amd64/x86 needs ~9min to bootup
2010/1/28 Zavam, Vinícius : > 2010/1/28 Bruce Simpson : >> Try GRUB4DOS. I use this so on boxes where I have Windows installed, I can >> keep GRUB in the NTFS partition. >> >> I haven't seen this issue and am tracking -STABLE on an ASUS V-series >> machine. >> > > Simpson, > I forgot to mention... but I tested it using boot0 (freebsd's > bootmanager) with no success ;< > > had no shots with grub4dos, gag, lilo or grub2; I assume it may not be > a bootmanager issue, but freebsd's btx bootstrap loader. > my gentoo and windows o.s. can be loaded using grub or boot0. > > > -- > Zavam, Vinícius gentlemen, morning. I just did new fresh installs using 80-STABLE/amd64 and 90-CURRENT/amd64 snapshots. unfortunately, no success. when tryied the 90-CURRENT I've created a slice to /boot (d) at the beginning of the partition (ad4s4) and grub returned error code 18 [1]. strange. even installing in another slice, at the beginning of the disk (ad4s1), the bootup process was slow too. [1] http://wiki.linuxquestions.org/wiki/GRUB#Error_18 -- Zavam, Vinícius ___ 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"
8.0-RELEASE hangs with lighttpd, unionfs related? Some traces included
Hello, when I start lighttpd at boot time, the system half-locks in a way, that any process, which accesses /usr/local/etc stalls. It's also impossible to shut down. /usr/local/etc is unionfs mounted. I compiled a kernel with debug options. When mounting unionfs at boot time, here's the firt LOR with trace: lock order reversal: 1st 0xff00018b47f8 unionfs (unionfs) @ /usr/src/sys/fs/unionfs/union_subr.c:356 2nd 0xff00018d9d80 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2188 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 vrele() at vrele+0x120 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0xf1 vrecycle() at vrecycle+0x58 unionfs_inactive() at uniougen2.2: at usbus2 nfs_inactive+ukbd0: 01.10/1.01, addr 2> on usbus2 x20 vinactive() at vinactive+0x6b vput() at vput+0x216 kern_statatkbd1 at ukbd0 _vnhook() at kern_statat_vnhook+0xe9 kern_statat() at kern_statat+0x15 stat() at stat+0x22 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- suhid0: yaddr 2> on usbus2 scall (188, FreeBSD ELF64, stat), rip = 0x8009a055c, rsp = 0x7fffe5b8, rbp = 0x800b312c0 --- KDB: enter: witness_checkorder [thread pid 27 tid 100068 ] Stopped at kdb_enter+0x3d: movq$0,0x4c04dc(%rip) Tracing pid 27 tid 100068 td 0xff00016fe720 kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 vrele() at vrele+0x120 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0xf1 vrecycle() at vrecycle+0x58 unionfs_inactive() at unionfs_inactive+0x20 vinactive() at vinactive+0x6b vput() at vput+0x216 kern_statat_vnhook() at kern_statat_vnhook+0xe9 kern_statat() at kern_statat+0x15 stat() at stat+0x22 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (188, FreeBSD ELF64, stat), rip = 0x8009a055c, rsp = 0x7fffe5b8, rbp = 0x800b312c0 - Like mentioned, there is that strange problem with lighttpd started at boot time. Other /urs/local/etc/rc.d startups don't lead to a /usr/local/etc deadlock. Unfortunately I don't get any panic or anything else when the hang happens. How can I aquire more information? It's no problem to log in and to do everything else outside /usr/local/etc... == Here's a LOR at shutdown with trace: lock order reversal: 1st 0xff0001bc2098 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1200 2nd 0xff0001bc1ba8 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1194 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_flushfiles() at ffs_flushfiles+0x93 ffs_unmount() at ffs_unmount+0x48 dounmount() at dounmount+0x2ac vfs_unmountall() at vfs_unmountall+0x54 boot() at boot+0x814 mkdumpheader() at mkdumpheader syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x40829c, rsp = 0x7fffe738, rbp = 0x402290 --- KDB: enter: witness_checkorder [thread pid 1 tid 12 ] Stopped at kdb_enter+0x3d: movq$0,0x4c04dc(%rip) Tracing pid 1 tid 12 td 0xff0001310ab0 kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_flushfiles() at ffs_flushfiles+0x93 ffs_unmount() at ffs_unmount+0x48 dounmount() at dounmount+0x2ac vfs_unmountall() at vfs_unmountall+0x54 boot() at boot+0x814 mkdumpheader() at mkdumpheader syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x40829c, rsp = 0x7fffe738, rbp = 0x402290 --- Any Help highly appreciated! Thanks, -Harry signature.asc Description: OpenPGP digital signature
Reboot Loop: ffs_snapshot/bufwait LORs [Was: Re: 8.0-RELEASE hangs with lighttpd, unionfs related? Some traces included]
Harald Schmalzbauer schrieb am 05.02.2010 12:31 (localtime): Hello, when I start lighttpd at boot time, the system half-locks in a way, that any process, which accesses /usr/local/etc stalls. It's also impossible to shut down. /usr/local/etc is unionfs mounted. I compiled a kernel with debug options. When mounting unionfs at boot time, here's the firt LOR with trace: lock order reversal: 1st 0xff00018b47f8 unionfs (unionfs) @ /usr/src/sys/fs/unionfs/union_subr.c:356 2nd 0xff00018d9d80 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2188 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 vrele() at vrele+0x120 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0xf1 vrecycle() at vrecycle+0x58 unionfs_inactive() at uniougen2.2: at usbus2 nfs_inactive+ukbd0: 01.10/1.01, addr 2> on usbus2 x20 vinactive() at vinactive+0x6b vput() at vput+0x216 kern_statatkbd1 at ukbd0 _vnhook() at kern_statat_vnhook+0xe9 kern_statat() at kern_statat+0x15 stat() at stat+0x22 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- suhid0: yaddr 2> on usbus2 scall (188, FreeBSD ELF64, stat), rip = 0x8009a055c, rsp = 0x7fffe5b8, rbp = 0x800b312c0 --- KDB: enter: witness_checkorder [thread pid 27 tid 100068 ] Stopped at kdb_enter+0x3d: movq$0,0x4c04dc(%rip) Tracing pid 27 tid 100068 td 0xff00016fe720 kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 vrele() at vrele+0x120 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0xf1 vrecycle() at vrecycle+0x58 unionfs_inactive() at unionfs_inactive+0x20 vinactive() at vinactive+0x6b vput() at vput+0x216 kern_statat_vnhook() at kern_statat_vnhook+0xe9 kern_statat() at kern_statat+0x15 stat() at stat+0x22 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (188, FreeBSD ELF64, stat), rip = 0x8009a055c, rsp = 0x7fffe5b8, rbp = 0x800b312c0 - Like mentioned, there is that strange problem with lighttpd started at boot time. Other /urs/local/etc/rc.d startups don't lead to a /usr/local/etc deadlock. Unfortunately I don't get any panic or anything else when the hang happens. How can I aquire more information? It's no problem to log in and to do everything else outside /usr/local/etc... == Here's a LOR at shutdown with trace: lock order reversal: 1st 0xff0001bc2098 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1200 2nd 0xff0001bc1ba8 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1194 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_flushfiles() at ffs_flushfiles+0x93 ffs_unmount() at ffs_unmount+0x48 dounmount() at dounmount+0x2ac vfs_unmountall() at vfs_unmountall+0x54 boot() at boot+0x814 mkdumpheader() at mkdumpheader syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x40829c, rsp = 0x7fffe738, rbp = 0x402290 --- KDB: enter: witness_checkorder [thread pid 1 tid 12 ] Stopped at kdb_enter+0x3d: movq$0,0x4c04dc(%rip) Tracing pid 1 tid 12 td 0xff0001310ab0 kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_flushfiles() at ffs_flushfiles+0x93 ffs_unmount() at ffs_unmount+0x48 dounmount() at dounmount+0x2ac vfs_unmountall() at vfs_unmountall+0x54 boot() at boot+0x814 mkdumpheader() at mkdumpheader syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x40829c, rsp = 0x7fffe738, rbp = 0x402290 --- Any Help highly appreciated! Thanks, -Harry Additional LORs while regular machine operation (background fsck) which leads to reboot! I have access over the serail console, but the machine is unresponsive after that. So I'm now in a endelss reboot loop with the debug kernel... lock order reversal: 1st 0xff0001b899d0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xff802970fc28 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 3rd 0xff00018b4448 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack ba
Re: Reboot Loop: ffs_snapshot/bufwait LORs [Was: Re: 8.0-RELEASE hangs with lighttpd, unionfs related? Some traces included]
Harald Schmalzbauer schrieb am 05.02.2010 12:39 (localtime): Harald Schmalzbauer schrieb am 05.02.2010 12:31 (localtime): ... Additional LORs while regular machine operation (background fsck) which leads to reboot! I have access over the serail console, but the machine is unresponsive after that. So I'm now in a endelss reboot loop with the debug kernel... lock order reversal: 1st 0xff0001b899d0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xff802970fc28 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 3rd 0xff00018b4448 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_snapshot() at ffs_snapshot+0x1b70 ffs_mount() at ffs_mount+0x651 vfs_donmount() at vfs_donmount+0xcd4 nmount() at nmount+0x74 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007acfec, rsp = 0x7fffe988, rbp = 0x800a028e- KDB: enter: witness_checkorder [thread pid 947 tid 100073 ] Stopped at kdb_enter+0x3d: movq$0,0x4c04dc(%rip) db> lock order reversal: 1st 0xff00018b4470 vnode interlock (vnode interlock) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:523 2nd 0xff8000422028 uhci2 (uhci2) @ /usr/src/sys/dev/usb/controller/uhci.c:1551 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea _mtx_lock_flags() at _mtx_lock_flags+0x68 uhci_do_poll() at uhci_do_poll+0x2e usbd_transfer_poll() at usbd_transfer_poll+0x18d ukbd_do_poll() at ukbd_do_poll+0x63 ukbd_get_key() at ukbd_get_key+0xa8 ukbd_read_char() at ukbd_read_char+0xaa scgetc() at scgetc+0x5b sc_cngetc() at sc_cngetc+0xf2 cncheckc() at cncheckc+0x65 cngetc() at cngetc+0x1c db_readline() at db_readline+0x79 db_read_line() at db_read_line+0x15 db_command_loop() at db_command_loop+0x38 db_trap() at db_trap+0x87 kdb_trap() at kdb_trap+0x82 trap() at trap+0x18f calltrap() at calltrap+0x8 --- trap 0x3, rip = 0x80381141, rsp = 0xff803e959000, rbp = 0xff803e959020 --- kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_snapshot() at ffs_snapshot+0x1b70 ffs_mount() at ffs_mount+0x651 vfs_donmount() at vfs_donmount+0xcd4 nmount() at nmount+0x74 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007acfec, rsp = 0x7fffe988, rbp = 0x800a028e- lock order reversal: 1st 0xff00018b4470 vnode interlock (vnode interlock) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:523 2nd 0xff0001747890 USB device mutex (USB device mutex) @ /usr/src/sys/dev/usb/usb_device.c:1410 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea _mtx_lock_flags() at _mtx_lock_flags+0x68 usbd_clear_stall_proc() at usbd_clear_stall_proc+0x49 usbd_transfer_poll() at usbd_transfer_poll+0x1c0 ukbd_do_poll() at ukbd_do_poll+0x63 ukbd_get_key() at ukbd_get_key+0xa8 ukbd_read_char() at ukbd_read_char+0xaa scgetc() at scgetc+0x5b sc_cngetc() at sc_cngetc+0xf2 cncheckc() at cncheckc+0x65 cngetc() at cngetc+0x1c db_readline() at db_readline+0x79 db_read_line() at db_read_line+0x15 db_command_loop() at db_command_loop+0x38 db_trap() at db_trap+0x87 kdb_trap() at kdb_trap+0x82 trap() at trap+0x18f calltrap() at calltrap+0x8 --- trap 0x3, rip = 0x80381141, rsp = 0xff803e959000, rbp = 0xff803e959020 --- kdb_enter() at kdb_enter+0x3d witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xcbd ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 ffs_snapshot() at ffs_snapshot+0x1b70 ffs_mount() at ffs_mount+0x651 vfs_donmount() at vfs_donmount+0xcd4 nmount() at nmount+0x74 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007acfec, rsp = 0x7fffe988, rbp = 0x800a028e- lock order reversal: (Giant after non-sleepable) 1st 0xff00018b4470 vnode interlock (vnode interlock) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:523 2nd 0x80820780 Giant (Giant) @ /usr/src/sys/dev/usb/usb_transfer.c:1952 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea _mtx_lock_flags() at _mtx_lock_flags+0x68 usb_callback_proc() at usb_callback_proc+0x48 usbd_transfer_poll() at usbd_tra
amdtemp(4) oddities, Athlon 64 X2 (8-stable)
This is a RELENG_8 box, csupped on 2010-01-22, kernel built with amdtemp(4). It's a dual-core Athlon 64, running i386 (32bit) SMP. Excerpt from dmesg: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.28-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f [...] FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) [...] amdtemp0: on hostb3 sysctl displays the following values (idle system): dev.cpu.0.temperature: 14.0C dev.cpu.1.temperature: 14.0C dev.amdtemp.0.sensor0.core0: 14.0C dev.amdtemp.0.sensor0.core1: 22.0C dev.amdtemp.0.sensor1.core0: -49.0C dev.amdtemp.0.sensor1.core1: -49.0C hw.acpi.thermal.tz0.temperature: 40.0C Upon consecutive calls, the first three vary from 13.0C to 16.0C, which is below room temperature, so it can't be true. The fourth one varies from 22.0C to 23.0C, which might be correct, although it still seems a bit low, even on an idle system. Under load (buildworld -j4), it looks like this: dev.cpu.0.temperature: 38.0C dev.cpu.1.temperature: 39.0C dev.amdtemp.0.sensor0.core0: 38.0C dev.amdtemp.0.sensor0.core1: 44.0C dev.amdtemp.0.sensor1.core0: -49.0C dev.amdtemp.0.sensor1.core1: -49.0C hw.acpi.thermal.tz0.temperature: 40.0C That's the maximum readings I've seen: The first three go up to 39.0C, the fourth one reaches 44.0C (I've never seen values higher than this). The first three are always about the same (+/-1), and the fourth is always 4 to 6 more. When buildworld -j4 is finished, the values quickly go down and reach the ones given for the idle system above after a few minutes. BTW, the machine is running powerd(8) which reduces the CPU clock from 2000 to 1000 when it is idle. The sensor1.* values are always fixed at -49.0C, and the ACPI temperature stays at exactly 40.0C. These three don't seem to be connected to any actual sensors. I'm not too worried about those. I've got two questions: First, I'm wondering why sensor0.core1 is different from all the other values. I think it should be the same as the dev.cpu.1.temperature value. This smells like a bug. According to the description in the manual page, I would expect it to be the same. Second, the temperature readings on the idle system are too low. I don't think they can realistically be below room temperature. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. ___ 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: Recent MFC to 7 causes crash on VMware ESXi
On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs > on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk > controller the VM just shuts off. The workaround is to change the disk > controller to the BusLogic type. Still, it used to work up until last > week. The change was made around January 26th and based on the commits > that day I'm guessing it's either r203047 or r203073 > > I have the same issue with both amd64 and i386 VMs. This affects HEAD > and 8-STABLE as well and first affected HEAD over the summer. (I just > worked around it and went about my business at the time. :-/) I've > attached a dmesg from a kernel before the problem and one from after it > started. What if you set 'hw.clfush_disable=1' from the loader? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE -> -STABLE and size of /
Randi Harper wrote: > Marian Hettwer wrote: > > +1 vote for making / bigger. > > At least a size where a make installkernel runs through. > > This is going to happen. It's been on my to-do list for a while, as I > find it increasingly annoying. The default sizes of all mount points > need to be tweaked a bit. Be patient, there will be some new changes > going into sysinstall very soon. Revisiting sysinstall's default partition sizes is certainly a good idea. However, I think it makes a lot of sense to *not* install symbol files in /boot/kernel by default. I can't think of a good reason why they need to be there by default, and they're what causes the space problems for the root FS in the first place. Please change the default. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal ___ 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: amdtemp(4) oddities, Athlon 64 X2 (8-stable)
05.02.2010 15:34, Oliver Fromme написав(ла): This is a RELENG_8 box, csupped on 2010-01-22, kernel built with amdtemp(4). It's a dual-core Athlon 64, running i386 (32bit) SMP. Excerpt from dmesg: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.28-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f [...] FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) [...] amdtemp0: on hostb3 sysctl displays the following values (idle system): dev.cpu.0.temperature: 14.0C dev.cpu.1.temperature: 14.0C dev.amdtemp.0.sensor0.core0: 14.0C dev.amdtemp.0.sensor0.core1: 22.0C dev.amdtemp.0.sensor1.core0: -49.0C dev.amdtemp.0.sensor1.core1: -49.0C hw.acpi.thermal.tz0.temperature: 40.0C It's not Freebsd, it's cpu issuses. For brisbane core cpus CoreTemp author reported many times than the internal sensor seems to be defective because it reads ilogical temperatures. ___ 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-Stable with Samba too slow
Hi all, I have just installed FreeBSD 8.0-STABLE-201001 to work as a file server running samba 3.3.9 installed by ports. But, I don't know why, when I try to access the share by Windows or by Linux, it is so slow. I takes a long time to give the authentication window and when I manage authenticate It keeps so slow to browse directories and files. And the interesting thing is that when I reach the share with my files (*.iso for tests) after a long time and start a copy, the transfer goes so good, in a normal gigabit speed. I tried compiling and installing samba 3.4.5 and had the same behaviour . Maybe it's not a samba issue. I already have two freebsd file servers both with the 8-RELEASE version and they're running ok! In this case, I need to use the 8-STABLE version because of my disk controller. So I don't know what could be happening. Thanks in advance! -- Danilo Mussolini Candido danilomussol...@gmail.com MSN: danilomussol...@gmail.com Home: http://mussolini.no-ip.org:3 ___ 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-Stable with Samba too slow
>Hi all, >I have just installed FreeBSD 8.0-STABLE-201001 to work as a file server >running samba 3.3.9 installed by ports. >But, I don't know why, when I try to access the share by Windows or by >Linux, it is so slow. I takes a long time to give the authentication window >and when I manage authenticate It keeps so slow to browse directories and >files. And the interesting thing is that when I reach the share with my >files (*.iso for tests) after a long time and start a copy, the transfer >goes so good, in a normal gigabit speed. >I tried compiling and installing samba 3.4.5 and had the same behaviour . >Maybe it's not a samba issue. >I already have two freebsd file servers both with the 8-RELEASE version and >they're running ok! >In this case, I need to use the 8-STABLE version because of my disk >controller. So I don't know what could be happening. >Thanks in advance! Just a me too! I had a 8.0 RELEASE server running on a HP Proliant ML110. The server responded quick wit no issues at all. I just upgraded the server to 8-Stable (No reason, just test) and the samba speed drops significant. Normally little files did not show the copy box, but after the update all copy's to the XP desktop shows me the copy window in windows. Same kernel file and settings. Samba version is 3.3.9 Regards, Johan ___ 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"
Kerberized NFSv3 incorrect behavior (revisited)
What's more, if I obtain (as root for example) a ticket for user mamalos and kdestroy it, and then login as user root in a new terminal, the root user in the new terminal has still all privileges of mamalos in the share. Klist, of course, shows no tickets. This could be also a security threat, in case different kerberos principals (users in this setup) use a shared machine account to logon, and then access their resources by kiniting to their respective principals. I assume that this must have to do with kernel's KGSSAPI support, which "forgets" to delete or renew its kerberos' cache. Thank you all, again, for your time. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ 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-Stable with Samba too slow
On Fri, Feb 05, 2010 at 03:41:42PM +0100, Johan Hendriks wrote: > >Hi all, > > >I have just installed FreeBSD 8.0-STABLE-201001 to work as a file > server > >running samba 3.3.9 installed by ports. > >But, I don't know why, when I try to access the share by Windows or by > >Linux, it is so slow. I takes a long time to give the authentication > window > >and when I manage authenticate It keeps so slow to browse directories > and > >files. And the interesting thing is that when I reach the share with my > >files (*.iso for tests) after a long time and start a copy, the > transfer > >goes so good, in a normal gigabit speed. > > >I tried compiling and installing samba 3.4.5 and had the same behaviour > . > >Maybe it's not a samba issue. > > >I already have two freebsd file servers both with the 8-RELEASE version > and > >they're running ok! > >In this case, I need to use the 8-STABLE version because of my disk > >controller. So I don't know what could be happening. > > > >Thanks in advance! > > Just a me too! > > I had a 8.0 RELEASE server running on a HP Proliant ML110. > The server responded quick wit no issues at all. > I just upgraded the server to 8-Stable (No reason, just test) and the > samba speed drops significant. > Normally little files did not show the copy box, but after the update > all copy's to the XP desktop shows me the copy window in windows. > > Same kernel file and settings. > Samba version is 3.3.9 I'm using Samba at home on FreeBSD 8.0-STABLE for personal use (user-level shares, and the guest OS is Windows XP). I've spent quite some time tuning both FreeBSD sysctls as well as smb.conf to try and get the most overall throughput. What I ended up with is this: sysctl.conf -- net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 smb.conf -- socket options = TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536 read raw = yes use sendfile = yes I tried adjusting many of the above parameters to try and find a "sweet spot" for reading/writing data to a 2-disk ZFS mirror (2x1TB disks, 7200rpm, SATA2 connected via ICH9 with AHCI enabled, and using ataahci(4) (not ahci(4)). The above is what works best. "Worked best" means I can push about 40-50MBytes/sec reading/writing to/from a Samba SMB/CIFS share. Comparatively, FTP gets around 75-85MByte/sec with the same sysctl.conf configuration. This is using Samba 3.3.10, though I can guarantee I saw the same speed/throughout as a result of the above tuning going back to 3.3.7. -- | 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: amdtemp(4) oddities, Athlon 64 X2 (8-stable)
Vasyl Samoilov wrote: > Oliver Fromme wrote: > > dev.cpu.0.temperature: 14.0C > > dev.cpu.1.temperature: 14.0C > > dev.amdtemp.0.sensor0.core0: 14.0C > > dev.amdtemp.0.sensor0.core1: 22.0C > > dev.amdtemp.0.sensor1.core0: -49.0C > > dev.amdtemp.0.sensor1.core1: -49.0C > > hw.acpi.thermal.tz0.temperature: 40.0C > > It's not Freebsd, it's cpu issuses. For brisbane core cpus CoreTemp > author reported many times than the internal sensor seems to be > defective because it reads ilogical temperatures. That doesn't explain the difference between the second and the fourth line: dev.cpu.1.temperature: 14.0C dev.amdtemp.0.sensor0.core1: 22.0C They should come from the same sensor (at least the manual page implies this), so why are they different? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton ___ 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: ionice in FreeBSD?
On Fri, Feb 05, 2010 at 12:07:36PM +0100, Jordi Espasa Clofent wrote: > Great work Luigi ;) > That's amazing... anyway ?is it production-ready? i would say it is pretty solid. I used it on my main workstation and desktop for a few months last year without a glitch. cheers luigi > -- > I must not fear. Fear is the mind-killer. Fear is the little-death that > brings total obliteration. I will face my fear. I will permit it to pass > over me and through me. And when it has gone past I will turn the inner > eye to see its path. Where the fear has gone there will be nothing. Only > I will remain. > > Bene Gesserit Litany Against Fear. > ___ > 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: ionice in FreeBSD?
On Fri, Feb 05, 2010 at 06:06:22PM +0100, Luigi Rizzo wrote: > On Fri, Feb 05, 2010 at 12:07:36PM +0100, Jordi Espasa Clofent wrote: > > Great work Luigi ;) > > That's amazing... anyway ?is it production-ready? > > i would say it is pretty solid. I used it on my main workstation > and desktop for a few months last year without a glitch. I appreciate your work on this -- truly I do -- but the above statement is incredible. This is not meant as a flame-inducer, but there's really no other way to phrase it: This IS NOT what "production-ready" means to the rest of us, particularly those of us in the server world. A single developer running such code on their workstation for a few months is in no way identical to that of a heavily I/O-bound server. I thought freebsd.org (or maybe ISC?) offered some test/development boxes on the 'net available to developers who could test such code + perform stress tests over long periods of time? I'm probably mistaken, but I was under that impression. -- | 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: Kerberized NFSv3 incorrect behavior
On Fri, 5 Feb 2010, George Mamalakis wrote: Dear all, I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My configuration is based on http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My goal is to share filesystems securely through kerberos authentication. Everything works fine, until I try to kdestroy my tickets or kinit to some other user, where the system insists to think that I am the user that initially obtained their ticket. To be more extensive, my story is as follows: [good stuff snipped] and both client and server have the correct entries about each other (and themselves) in their /etc/hosts, so heimdal works just fine. Both client and server have their respective keytabs stored in /etc/krb5.keytab, and I use two users in my example (that both exist in both systems with the same uid,gid): mamalos and testakis. Unless you have applied the experimental patch, a keytab entry is meaningless in the client. Without that, it was assumed that "root" would never "kinit" as anyone. Basically, it was assumed that "root" would only do the mount and a user, like "mamalos" or "testakis" would be logged in and kinit'd as that user. The short answer is that any principal with TGT in the credentials cache for uid==N will be used to authenticate that user. Once authenticated, that "handle" for the user can be used until it expires (up to the server, but usually set to when the TGT that it found in the credential cache is due to expire). So, when I mount the exported filesystem on the client giving: # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server.example.com:/exports on /mnt (nfs) and try to access the share: # ls /mnt ls: mnt: Permission denied I get the error I am expecting, since root does not have any kerberos tickets assigned, yet. Let's see what happens when I kinit as mamalos: Yep, as expected. # klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: mama...@example.com Issued Expires Principal Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/exapmle@example.com # ls -la /mnt/ total 8 drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ drwx-- 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ drwx-- 2 testakis wheel - 512 4 Feb 19:06 testakis/ # touch /mnt/mamalos/myfile # ls -la /mnt/mamalos/myfile rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile Which is the exact behavior that is expected. Now when I kdestroy: # kdestroy # klist klist: No ticket file: /tmp/krb5cc_0 # touch /mnt/mamalos/myfilethatshouldnotbe # ls -la /mnt/mamalos/myfilethatshouldnotbe -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 /mnt/mamalos/myfilethatshouldnotbe Yes, this is a "bug/limitation" in the current implementation. I believe that "kdestroy" should do some sort of system call to inform the NFS client that "credentials for uid==N" should be invalidated. This is not implemented in FreeBSD8 (or Linux for that matter, last I checked). I don't know if dfr@ was planning on doing this and whether or not he thinks it is appropriate to do so? Without that implemented, the "handle" continues to work until the server expires it, normally when the TGT for "mamalos" would have expired if you hadn't kdestroy'd it. And I can do everything in that share as if I were still mamalos, even though I kdestroyed my kerberos ticket. The same thing will happen even if I kinit to testakis after that. klist shows testakis' ticket this time, but I am not allowed to access (rwx) tetakis' files/folders, and I still have full control over mamalos' files and folders. In order to be able to do something as testakis, I have to unmount the share and remount it while having testakis' ticket (or having no ticket at all, and giving kinit testakis after mounting the share). Actually, logging in as "testakis" should allow that user to access the mount as "testakis" once kinit'd as "testakis". The trick is that the credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the uid assigned to "testakis"). Same would apply to "mamalos" if that user were logged in with a non-0 uid. I am not an NFS expert, but I suppose that this behavior is not the one to be expected, except if I am missing some fundamental information about kerberized NFS that explains it. Even so, it would be quite unwise to behave so, since even if the users kdestroys their tickets, they have still all permissions as when they obtained their ticket. Yes, as noted above, I believe that "kdestroy" should get rid of the Kerberized NFS "handles" for the corresponding "uid". It's on my "to discuss with dfr and maybe do" list, but unfortunately not near the top of it. (I'd also like to come up with a good way to do initiator credentials from a keytab entry. The experimental patch is con
Re: ionice in FreeBSD?
On Fri, Feb 05, 2010 at 09:25:55AM -0800, Jeremy Chadwick wrote: > On Fri, Feb 05, 2010 at 06:06:22PM +0100, Luigi Rizzo wrote: > > On Fri, Feb 05, 2010 at 12:07:36PM +0100, Jordi Espasa Clofent wrote: > > > Great work Luigi ;) > > > That's amazing... anyway ?is it production-ready? > > > > i would say it is pretty solid. I used it on my main workstation > > and desktop for a few months last year without a glitch. > > I appreciate your work on this -- truly I do -- but the above statement > is incredible. This is not meant as a flame-inducer, but there's really > no other way to phrase it: > > This IS NOT what "production-ready" means to the rest of us, > particularly those of us in the server world. A single developer > running such code on their workstation for a few months is in no way > identical to that of a heavily I/O-bound server. exactly - i said "pretty robust" and not "production ready". There are known issues with multiple disks arrangements (gvinum etc.) due to a reuse of a field in a structure. These are solved in 8.x. cheers luigi > > I thought freebsd.org (or maybe ISC?) offered some test/development > boxes on the 'net available to developers who could test such code + > perform stress tests over long periods of time? I'm probably mistaken, > but I was under that impression. > > -- > | 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" ___ 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: ionice in FreeBSD?
On Fri, 5 Feb 2010 09:25:55 -0800 Jeremy Chadwick wrote: > I appreciate your work on this -- truly I do -- but the above > statement is incredible. This is not meant as a flame-inducer, but > there's really no other way to phrase it: > > This IS NOT what "production-ready" means to the rest of us, > particularly those of us in the server world. A single developer > running such code on their workstation for a few months is in no way > identical to that of a heavily I/O-bound server. > > I thought freebsd.org (or maybe ISC?) offered some test/development > boxes on the 'net available to developers who could test such code + > perform stress tests over long periods of time? I'm probably > mistaken, but I was under that impression. > Luigi wrote: > i would say it is pretty solid. I used it on my main workstation > and desktop for a few months last year without a glitch. In what twilight zone does that mean 'Yes, it is production ready' to warrant such a nice diatribe? -- Alexander Kabaev signature.asc Description: PGP signature
PF Traffic Redirection issues
Hello, I am trying to perform traffic redirection with PF on 7.2-RELEASE. The traffic is in the same subnet and I try doing that by using just one interface em0. Mu current setup of pf is as follows: No ALTQ support in kernel ALTQ related functions disabled TRANSLATION RULES: rdr pass on em0 inet proto tcp from any os "NMAP" to any port 1:65535 -> 192.168.128.170 port 22 rdr pass on em0 inet proto tcp from 192.168.128.126 to any port = http -> 192.168.128.103 port 83 rdr pass on em0 inet proto tcp from 192.168.128.126 to any port = rdp -> 192.168.128.102 port 3389 rdr pass on em0 inet proto tcp from any to any port = ctf -> 192.168.128.102 port 83 FILTER RULES: scrub in all fragment reassemble block drop log all block drop in on ! em0 inet from 192.168.128.0/24 to any block drop in inet from 192.168.128.170 to any pass in on em0 inet proto tcp from any to 192.168.128.170 port = ssh flags S/SA keep state pass in on em0 inet proto tcp from any to 192.168.128.102 port = ctf flags S/SA synproxy state pass in on em0 inet proto tcp from any to 192.168.128.103 port = mit-ml-dev flags S/SA synproxy state pass out all flags S/SA keep state When I try to perform request they get the state of *SYN_SENT:CLOSED* : No ALTQ support in kernel ALTQ related functions disabled all tcp 192.168.128.170:22 <- 192.168.128.126:53162 ESTABLISHED:ESTABLISHED all tcp 192.168.128.102:83 <- 192.168.128.170:84 <- 192.168.128.104:8351 CLOSED:SYN_SENT all tcp 192.168.128.104:8351 -> 192.168.128.102:83 *SYN_SENT:CLOSED* Any advice is much appreciated. KR, Spas ___ 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: PF Traffic Redirection issues
On Fri, Feb 5, 2010 at 9:41 AM, Spas Karabelov wrote: > Hello, > > I am trying to perform traffic redirection with PF on 7.2-RELEASE. > The traffic is in the same subnet and I try doing that by using just one > interface em0. PF cannot redirect packets back out the interface they originated on. >From pf.conf(5)... "Redirections cannot reflect packets back through the interface they arrive on, they can only be redirected to hosts connected to different interfaces or to the firewall itself." ___ 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: Recent MFC to 7 causes crash on VMware ESXi
On 02/05/10 07:27, John Baldwin wrote: > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk >> controller the VM just shuts off. The workaround is to change the disk >> controller to the BusLogic type. Still, it used to work up until last >> week. The change was made around January 26th and based on the commits >> that day I'm guessing it's either r203047 or r203073 >> >> I have the same issue with both amd64 and i386 VMs. This affects HEAD >> and 8-STABLE as well and first affected HEAD over the summer. (I just >> worked around it and went about my business at the time. :-/) I've >> attached a dmesg from a kernel before the problem and one from after it >> started. > > What if you set 'hw.clfush_disable=1' from the loader? > For what it's worth, I have two machines running ESXi 4.0 and haven't encountered this problem. It's possible this issue affects 3.5 only. -- Thanks, Josh Paetzel FreeBSD -- The power to serve ___ 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: Kerberized NFSv3 incorrect behavior (revisited)
On Fri, 5 Feb 2010, George Mamalakis wrote: shows no tickets. This could be also a security threat, in case different kerberos principals (users in this setup) use a shared machine account to logon, and then access their resources by kiniting to their respective principals. The kernel only knows the effective uid and the current gssd assumes that there will be "one" user principal with a TGT in /tmp/krb5cc_N (where 'N' is that uid#). Having multiple principals sharing the same login/uid (which I'm guessing is what you refer to as a "shared machine account", isn't going to work. I suppose that the gssd could do a "uid"->"username"->"principal name" mapping and then use that "principal name", but it is still going to be unique (ie only one) per uid. 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: Kerberized NFSv3 incorrect behavior (revisited)
On Fri, 5 Feb 2010, George Mamalakis wrote: I assume that this must have to do with kernel's KGSSAPI support, which "forgets" to delete or renew its kerberos' cache. Oops, missed this on the last reply. It is actually a cache of "handles" for RPCSEC_GSS credentials allocated by the server (one per uid). It is normally the server that decides to expire them (they no longer really have anything to do with Kerberos, except that they were acquired via a Kerberos ticket and it uses the session key created by Kerberos). As noted before, I believe that kdestroy should somehow invalidate these handles (it's an RPC to the NFS server + flushing the cached entry in the client). A quick and dirty hack that has kdestroy do a system call to do this could be implemented fairly easily. A key management subsystem (aka key ring) that deals with all types of authentication and not just Kerberos would be much more work. 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"
samba recplacement
hail, I've installed a recent 8-stable with gnome installed. I needed samba and noticed I have samba4-devel installed. but I can't manage to make it a simple file server as I need. so how to change samba package at minimum harm ? do I need to reinstall all ? a simple make fetch in samba33 says I can't as it conflicts with samba4 and some tbd-something (not in the machine right now). is there easy way ? I'd really like to choose samba version ... I've found a thread in gnome@ about this change (from late december). not a solution though. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em(4) + ALTQ broken
I applied drbr_altq.diff to the e1000 driver (sys/dev/e1000) from HEAD on top of 8.0-RELEASE kernel sources. It appears to have fixed the immediate problem where queues simply don't work on em interfaces. Thanks a bunch. I suppose further review and testing by others would be greatly appreciated from my point of view. I am trying to decide on a relatively stable 8.0 kernel with working em(4) + ALTQ to put into production on 100 or so installations. Are you guys more comfortable with the HEAD sys/dev/e1000 + this patch on top of 8.0-RELEASE, or e1000 from 7.2 on top of 8.0-RELEASE? So far I am having good luck with the later. Thanks again for your contributions! On Thu, Feb 4, 2010 at 6:51 PM, Max Laier wrote: > Okay ... attached is a patch to fix this for em(4) (and lay the groundwork > to > fix it for other drbr_* consumer as well). I have tested it in VirtualBox, > but don't have real hardware to check for non-ALTQ performance or other > regressions. > > Test, comments and review appreciated. > > -- > Max > ___ 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"
