Re: mod_auth_kerb2 broken in 8-STABLE? Or is it heimdal to blame?
On 19/10/2012 02:19 πμ, John Marshall wrote:
On 02/10/2012 02:08, George Mamalakis wrote:
On 04/07/11 14:08, George Mamalakis wrote:
On 06/04/2011 18:29, George Mamalakis wrote:
Dear all,
I installed mod_auth_kerb2 on my FreeBSD 8-STABLE machine and tried
to use it. After the installation (which was successful(?!?)), the
server refused to start giving the error:
# /usr/local/etc/rc.d/apache22 start
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 103 of
/usr/local/etc/apache22/httpd.conf: Cannot load
/usr/local/libexec/apache22/mod_auth_kerb.so into server:
/usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol
gsskrb5_register_acceptor_identity
Starting apache22.
httpd: Syntax error on line 103 of
/usr/local/etc/apache22/httpd.conf: Cannot load
/usr/local/libexec/apache22/mod_auth_kerb.so into server:
/usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol
gsskrb5_register_acceptor_identity
/usr/local/etc/rc.d/apache22: WARNING: failed to start apache22
but ldd showed:
# ldd /usr/local/libexec/apache22/mod_auth_kerb.so
/usr/local/libexec/apache22/mod_auth_kerb.so:
libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x800c0)
libheimntlm.so.10 = /usr/lib/libheimntlm.so.10 (0x800d0a000)
libkrb5.so.10 = /usr/lib/libkrb5.so.10 (0x800e0f000)
libhx509.so.10 = /usr/lib/libhx509.so.10 (0x800f7e000)
libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x8010be000)
libcrypto.so.6 = /lib/libcrypto.so.6 (0x8011c)
libasn1.so.10 = /usr/lib/libasn1.so.10 (0x801461000)
libroken.so.10 = /usr/lib/libroken.so.10 (0x8015e3000)
libcrypt.so.5 = /lib/libcrypt.so.5 (0x8016f5000)
libc.so.7 = /lib/libc.so.7 (0x800647000)
which showed that everything should have been fine. I googled it a
bit and found this thread regarding my error message:
http://forum.nginx.org/read.php?23,88476 , which started on May 2010,
and pointed to this PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=147454 , which started on
June 2010. What is stated, is that heimdal-1.1 was broken in FreeBSD,
and that it should be fixed at some moment in the future. (I tested
mod_auth_kerb2 on another machine running heimdal from ports (1.4_1)
and I had exactly the same problem).
I searched to find where this notorious function
(gsskrb5_register_acceptor_identity) was located, and I found its
declaration in: /usr/include/gssapi/gssapi_krb5.h, and its definition
in: /usr/lib/libgssapi_krb5.so.
So, I added -lgssapi_krb5 in KRB5_LDFLAGS variable of
/usr/ports/www/mod_auth_kerb2/work/mod_auth_kerb-5.4/Makefile , since
this where the location of gsskrb5_register_acceptor_identity
originally seemed to be, and reinstalled the port using gmake this
time (inside the port's work directory). After that, the module works
just fine. The initial content of this line was:
KRB5_LDFLAGS = -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509
-lcom_err -lcrypto -lasn1 -lroken -lcrypt
I've sent an analogous email to the port maintainer, but I am not
sure if it is their fault. Hence, I decided to send this email to
the stable list for two reasons: First, someone else may be having a
similar problem and wants to find a rough solution. Secondly, there
are people reading this list that know heimdal's code, so somebody
may know another (much more elegant) way to fix this bug.
Thank you all for your time in advance,
Regards,
mamalos.
OK,
I spoke with the maintainer who confirmed the problem. He also
suggested to change line 96 of /usb/bin/krb5-config to include
gssapi_krb5 among its libraries. He also gave me the relevant patch,
and asked me to send a PR to FreeBSD. The patch is as follows:
--- /usr/bin/krb5-config.orig 2011-02-17 03:18:57.0 +0100
+++ /usr/bin/krb5-config2011-04-06 23:41:31.0 +0200
@@ -93,7 +93,7 @@
lib_flags=-L${libdir}
case $library in
gssapi)
- lib_flags=$lib_flags -lgssapi -lheimntlm
+ lib_flags=$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm
;;
kadm-client)
lib_flags=$lib_flags -lkadm5clnt
And the relevant PR is:
http://www.freebsd.org/cgi/query-pr.cgi?pr=156245
Thank you all for your time,
mamalos
Hi all,
I am bringing this matter back again because the same things hold for my
current system too (/usr/bin/krb5-config does not seem to link
gssapi-things properly):
# uname -a
FreeBSD example.com 9.0-STABLE FreeBSD 9.0-STABLE #0: Mon Jun 18
21:04:14 EEST 2012 r...@example.com:/usr/obj/usr/src/sys/FILESRV amd64
# pkg_info -Ix apache kerb
ap22-mod_auth_kerb-5.4_3 An Apache module for authenticating users with
Kerberos v5
apache22-2.2.22_8 Version 2.2.x of Apache web server with prefork MPM.
Should I send a PR or is there something that I've done wrong?
I've seen the same thing on 8.3-RELEASE, 9.1-RC1 and 9.1-RC2. In all
cases, applying your patch (thank you!) to /usr/bin/krb5-config resolved
the issue. I did not need to patch krb5-config for other GSSAPI servers
to work (dovecot and sendmail
Re: mod_auth_kerb2 broken in 8-STABLE? Or is it heimdal to blame?
On 04/07/11 14:08, George Mamalakis wrote:
On 06/04/2011 18:29, George Mamalakis wrote:
Dear all,
I installed mod_auth_kerb2 on my FreeBSD 8-STABLE machine and tried
to use it. After the installation (which was successful(?!?)), the
server refused to start giving the error:
# /usr/local/etc/rc.d/apache22 start
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 103 of
/usr/local/etc/apache22/httpd.conf: Cannot load
/usr/local/libexec/apache22/mod_auth_kerb.so into server:
/usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol
gsskrb5_register_acceptor_identity
Starting apache22.
httpd: Syntax error on line 103 of
/usr/local/etc/apache22/httpd.conf: Cannot load
/usr/local/libexec/apache22/mod_auth_kerb.so into server:
/usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol
gsskrb5_register_acceptor_identity
/usr/local/etc/rc.d/apache22: WARNING: failed to start apache22
but ldd showed:
# ldd /usr/local/libexec/apache22/mod_auth_kerb.so
/usr/local/libexec/apache22/mod_auth_kerb.so:
libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x800c0)
libheimntlm.so.10 = /usr/lib/libheimntlm.so.10 (0x800d0a000)
libkrb5.so.10 = /usr/lib/libkrb5.so.10 (0x800e0f000)
libhx509.so.10 = /usr/lib/libhx509.so.10 (0x800f7e000)
libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x8010be000)
libcrypto.so.6 = /lib/libcrypto.so.6 (0x8011c)
libasn1.so.10 = /usr/lib/libasn1.so.10 (0x801461000)
libroken.so.10 = /usr/lib/libroken.so.10 (0x8015e3000)
libcrypt.so.5 = /lib/libcrypt.so.5 (0x8016f5000)
libc.so.7 = /lib/libc.so.7 (0x800647000)
which showed that everything should have been fine. I googled it a
bit and found this thread regarding my error message:
http://forum.nginx.org/read.php?23,88476 , which started on May 2010,
and pointed to this PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=147454 , which started on
June 2010. What is stated, is that heimdal-1.1 was broken in FreeBSD,
and that it should be fixed at some moment in the future. (I tested
mod_auth_kerb2 on another machine running heimdal from ports (1.4_1)
and I had exactly the same problem).
I searched to find where this notorious function
(gsskrb5_register_acceptor_identity) was located, and I found its
declaration in: /usr/include/gssapi/gssapi_krb5.h, and its definition
in: /usr/lib/libgssapi_krb5.so.
So, I added -lgssapi_krb5 in KRB5_LDFLAGS variable of
/usr/ports/www/mod_auth_kerb2/work/mod_auth_kerb-5.4/Makefile , since
this where the location of gsskrb5_register_acceptor_identity
originally seemed to be, and reinstalled the port using gmake this
time (inside the port's work directory). After that, the module works
just fine. The initial content of this line was:
KRB5_LDFLAGS = -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509
-lcom_err -lcrypto -lasn1 -lroken -lcrypt
I've sent an analogous email to the port maintainer, but I am not
sure if it is their fault. Hence, I decided to send this email to
the stable list for two reasons: First, someone else may be having a
similar problem and wants to find a rough solution. Secondly, there
are people reading this list that know heimdal's code, so somebody
may know another (much more elegant) way to fix this bug.
Thank you all for your time in advance,
Regards,
mamalos.
OK,
I spoke with the maintainer who confirmed the problem. He also
suggested to change line 96 of /usb/bin/krb5-config to include
gssapi_krb5 among its libraries. He also gave me the relevant patch,
and asked me to send a PR to FreeBSD. The patch is as follows:
--- /usr/bin/krb5-config.orig 2011-02-17 03:18:57.0 +0100
+++ /usr/bin/krb5-config2011-04-06 23:41:31.0 +0200
@@ -93,7 +93,7 @@
lib_flags=-L${libdir}
case $library in
gssapi)
- lib_flags=$lib_flags -lgssapi -lheimntlm
+ lib_flags=$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm
;;
kadm-client)
lib_flags=$lib_flags -lkadm5clnt
And the relevant PR is:
http://www.freebsd.org/cgi/query-pr.cgi?pr=156245
Thank you all for your time,
mamalos
Hi all,
I am bringing this matter back again because the same things hold for my
current system too (/usr/bin/krb5-config does not seem to link
gssapi-things properly):
# uname -a
FreeBSD example.com 9.0-STABLE FreeBSD 9.0-STABLE #0: Mon Jun 18
21:04:14 EEST 2012 r...@example.com:/usr/obj/usr/src/sys/FILESRV amd64
# pkg_info -Ix apache kerb
ap22-mod_auth_kerb-5.4_3 An Apache module for authenticating users with
Kerberos v5
apache22-2.2.22_8 Version 2.2.x of Apache web server with prefork MPM.
Should I send a PR or is there something that I've done wrong?
Thanx all in advance.
--
George Mamalakis
IT and Security 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
Re: pf nat fails on msk0 from packets deriving from a jail interface
On 08/09/12 20:00, YongHyeon PYUN wrote: On Wed, Aug 08, 2012 at 02:33:25PM +0300, George Mamalakis wrote: Hi all, Suddenly I am facing a problem on a new PC, using a configuration that I have been using on more than 10 servers for the last few years. The only thing that I find that differs from my other configuratinos is the NIC of the PC. If not, I must be missing something very trivial. I have built a jail on this PC, following the handbook's guidelines (section: application of jails). The PC has one NIC, msk0, where I run pf on (built on my kernel; I have already tried using the module). My pf.conf is as simple as possible: # cat /etc/pf.conf nat on msk0 from any to any - 10.0.3.6 pass quick all when I jexec inside the jail, and pf is running, I am unable to reach any machine except my jail (not even the host). If pf is off, the network works just fine (of course my router knows where to find my jail's subnet). What is strange is that if I tcpdump on msk0, then after a few seconds that I request something from within the jail, I see the packets going and coming on msk0 using the correct IP (the NAT IP), but it seems that the machine fails to route them back inside the jail. I guess this is the same issue reported in kern/170081. Some msk(4) controllers lack full hardware checksum offloading capability such that pseudo checksum should be computed by upper layer. It seems pf(4) NAT was broken for controllers that lack pseudo checksumming. This indicates the following ethernet controller do not work with pf(4) NAT. sk(4), msk(4), fxp(4), hme(4) and gem(4) Try disabling RX checksum offloading as a work-around. #ifconfig msk0 -rxcsum You were absolutely right! Once I disabled RX checksum offloading -as you suggested- everything started working just fine. Since this issue has been reported already, I will not send a bug report. Thanx again! -- George Mamalakis IT and Security 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
pf nat fails on msk0 from packets deriving from a jail interface
Hi all, Suddenly I am facing a problem on a new PC, using a configuration that I have been using on more than 10 servers for the last few years. The only thing that I find that differs from my other configuratinos is the NIC of the PC. If not, I must be missing something very trivial. I have built a jail on this PC, following the handbook's guidelines (section: application of jails). The PC has one NIC, msk0, where I run pf on (built on my kernel; I have already tried using the module). My pf.conf is as simple as possible: # cat /etc/pf.conf nat on msk0 from any to any - 10.0.3.6 pass quick all when I jexec inside the jail, and pf is running, I am unable to reach any machine except my jail (not even the host). If pf is off, the network works just fine (of course my router knows where to find my jail's subnet). What is strange is that if I tcpdump on msk0, then after a few seconds that I request something from within the jail, I see the packets going and coming on msk0 using the correct IP (the NAT IP), but it seems that the machine fails to route them back inside the jail. My configuration is as follows: #uname -a FreeBSD filesrv.svr.noca 9.0-STABLE FreeBSD 9.0-STABLE #1: Fri Jul 27 15:40:48 EEST 2012 r...@filesrv.svr.noca:/usr/obj/usr/src/sys/MAMALOPYRINO amd64 #ifconfig -a msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE ether 80:ee:73:10:a3:58 inet 10.0.3.6 netmask 0xff00 broadcast 10.0.3.255 inet6 fe80::82ee:73ff:fe10:a358%msk0 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active pflog0: flags=0 metric 0 mtu 33152 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL pfsync0: flags=0 metric 0 mtu 1500 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL syncpeer: 0.0.0.0 maxupd: 128 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x9 inet 127.0.0.1 netmask 0xff00 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL lo1: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 10.3.2.1 netmask 0xff00 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL tap1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8LINKSTATE ether 00:bd:7b:c3:0c:01 inet6 fe80::2bd:7bff:fec3:c01%tap1 prefixlen 64 scopeid 0xb inet 10.3.2.2 netmask 0xff00 broadcast 10.3.2.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL tap2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8LINKSTATE ether 00:bd:7f:c3:0c:02 inet6 fe80::2bd:7fff:fec3:c02%tap2 prefixlen 64 scopeid 0xc nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL lo3: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 10.3.2.3 netmask 0xff00 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL lo3 is used as my jail interface, msk0 is my lan interface. # pciconf -v mskc0@pci0:3:0:0: class=0x02 card=0x40011297 chip=0x438011ab rev=0x10 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88E8057 PCI-E Gigabit Ethernet Controller' class = network subclass = ethernet excerpt of /etc/rc.conf: jail_test_hostname=test.svr.noca jail_test_rootdir=/jails/j/test jail_test_devfs_enable=YES jail_test_ip=10.3.2.3/24 jail_test_interface=lo3 I have even enabled forwarding and fast forwarding (just in case that this had been the case) with non results. # netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.0.3.1 UGS 0 290 msk0 10.0.3.0/24link#1 U 018825 msk0 10.0.3.6 link#1 UHS 01lo0 10.3.2.0/24link#11U 00 tap1 10.3.2.1 link#10UH 00lo1 10.3.2.2 link#11UHS 0 61lo0 10.3.2.3 link#13UH 00lo3 127.0.0.1 link#9 UH 0 64lo0 Since I don't need NAT on my configuration, I will use simple routing instead, so there won't be a problem for me. I am just sending this info in case this is a bug with pf-msk driver (for the specific card?) and before I send a bug report, I'd like a second opinion in case I am missing something fundamental. Thanx all in advance. -- George Mamalakis IT and Security Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering
grow zpool on a mirror setup
Hello everybody, I have asked the same question in the freebsd forums, but had no luck. Apart of this, there might be a bug somewhere, so I re-ask the question to this list. Here how it goes (three posts): post 1: I am experimenting with one installation of FreeBSD-9-STABLE/amd64 on a VirtualBox that is using gptzfsboot on a raid-1 (mirrored) zfs pool. My problem is that I need to grow the filesystem size of zfs partitions. I followed this guide http://support.freenas.org/ticket/342(http://support.freenas.org/ticket/342), which is for FreeNAS, and encountered a few problems. # gpart show = 34 40959933 ada0 GPT (19G) 34 128 1 freebsd-boot (64k) 162 35651584 2 freebsd-zfs (17G) 35651746 5308221 3 freebsd-swap (2.5G) = 34 40959933 ada1 GPT (19G) 34 128 1 freebsd-boot (64k) 162 35651584 2 freebsd-zfs (17G) 35651746 5308221 3 freebsd-swap (2.5G) # zpool status pool: zroot state: ONLINE scan: resilvered 912M in 1h3m with 0 errors on Sat Mar 10 14:01:17 2012 config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p2 ONLINE 0 0 0 ada1p2 ONLINE 0 0 0 errors: No known data errors # zpool list NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT zroot 5.97G 3.69G 2.28G61% 1.00x ONLINE - Let me give you a few info with regard to my setup, before explaining my problems: As you can see, *gpart* shows that my ada0p2 and ada1p2 partitions (used in zroot) are of size 17G, while *zfs list* shows that zroot has a size of 5.97G (which is the initial size of the virtual machine's disks, before I resized them). The problem I encountered when following the aforementioned procedure, was that I was unable to export zroot (the procedure says to export the pool, resize the paritions with *gparted*, and then import the pool), because I was receiving a message of some of my filesystems being busy (in single user mode, / was busy). Thus, in order to resolve this issue, I booted with a CDROM of FreeBSD 9 RELEASE, I then imported (*-f*) my zpool, and followed the procedure of resizing my filesystems. Does anyone have a better idea as to what I should do in order to make *zpool* see all the available space of the partitions it is using? Thank you all for your time in advance, mamalos post 2: Ah, and not to forget: I have enabled the autoexpand property of *zpool* (to be honest I've enabled, disabled, reenabled, and so forth many times, because somewhere I read that it might be needed, sometimes...), with no luck. post 3: Since nobody has an answer that far, let me ask another thing. Instead of deleting ada0p2 and ada1p2, and then recreating them from the same starting block but with a grater size, could I have just created two new filesystems (ada0p3 and ada1p3), and having them added in the pool as a new mirror? Because if that's the case, then I could try that out, since it seems to have the same result. Not that this answers to my question, but at least it's a workaround. As stated in these posts, it's really strange that zpool list doesn't seem to react even if I set the expand flag (or autoexpand which is the same), hence my concern whether this could be a bug. Thank you all for your time, -- George Mamalakis IT and Security 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: grow zpool on a mirror setup
Trond, thank you for your reply. Now to my questions: On 03/15/12 14:45, Trond Endrestøl wrote: On Thu, 15 Mar 2012 14:00+0200, George Mamalakis wrote: I am experimenting with one installation of FreeBSD-9-STABLE/amd64 on a VirtualBox that is using gptzfsboot on a raid-1 (mirrored) zfs pool. My problem is that I need to grow the filesystem size of zfs partitions. I followed this guide http://support.freenas.org/ticket/342(http://support.freenas.org/ticket/342), which is for FreeNAS, and encountered a few problems. # gpart show = 34 40959933 ada0 GPT (19G) 34 128 1 freebsd-boot (64k) 162 35651584 2 freebsd-zfs (17G) 35651746 5308221 3 freebsd-swap (2.5G) = 34 40959933 ada1 GPT (19G) 34 128 1 freebsd-boot (64k) 162 35651584 2 freebsd-zfs (17G) 35651746 5308221 3 freebsd-swap (2.5G) There's one mistake I'd point out. Your ZFS partitions are followed by your swap partitions. It would be a lot easier if the ZFS partitions were the last one on each drive. Why is this a mistake? Shouldn't ZFS grow up to the size of its underlying partition, regardless of its position? Is this restriction documented somewhere? Since your are using VirtualBox, I would simply create a new pair of virtual drives with the desired sizes and attach these to your VM. Next, create new boot, swap, and ZFS partitions, in this particular order, on the new drives. Create a ZFS pool using the new ZFS partitions on the new drives, and transfer the old system from the old drives to the new drives, using a recursive snapshot and the zfs send/receive commands. Remember to set the bootfs property on the newly created ZFS pool prior to reboot. I understand that there are quite a few alternatives on how I could migrate my system to one with larger disks, but I hoped that the method that was supposed to work with zpool and gpart, would have worked indeed (It was the simple, and required less space than the one that you propose). Thanks again for your answer! -- George Mamalakis IT and Security 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: grow zpool on a mirror setup
On 03/15/12 18:25, Marco van Tol wrote: On Thu, Mar 15, 2012 at 02:00:48PM +0200, George Mamalakis wrote: Hello everybody, I have asked the same question in the freebsd forums, but had no luck. Apart of this, there might be a bug somewhere, so I re-ask the question to this list. Here how it goes (three posts): post 1: I am experimenting with one installation of FreeBSD-9-STABLE/amd64 on a VirtualBox that is using gptzfsboot on a raid-1 (mirrored) zfs pool. My problem is that I need to grow the filesystem size of zfs partitions. I followed this guide http://support.freenas.org/ticket/342(http://support.freenas.org/ticket/342), which is for FreeNAS, and encountered a few problems. # gpart show = 34 40959933 ada0 GPT (19G) 34 128 1 freebsd-boot (64k) 162 35651584 2 freebsd-zfs (17G) 35651746 5308221 3 freebsd-swap (2.5G) = 34 40959933 ada1 GPT (19G) 34 128 1 freebsd-boot (64k) 162 35651584 2 freebsd-zfs (17G) 35651746 5308221 3 freebsd-swap (2.5G) # zpool status pool: zroot state: ONLINE scan: resilvered 912M in 1h3m with 0 errors on Sat Mar 10 14:01:17 2012 config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p2 ONLINE 0 0 0 ada1p2 ONLINE 0 0 0 errors: No known data errors # zpool list NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT zroot 5.97G 3.69G 2.28G61% 1.00x ONLINE - Let me give you a few info with regard to my setup, before explaining my problems: As you can see, *gpart* shows that my ada0p2 and ada1p2 partitions (used in zroot) are of size 17G, while *zfs list* shows that zroot has a size of 5.97G (which is the initial size of the virtual machine's disks, before I resized them). The problem I encountered when following the aforementioned procedure, was that I was unable to export zroot (the procedure says to export the pool, resize the paritions with *gparted*, and then import the pool), because I was receiving a message of some of my filesystems being busy (in single user mode, / was busy). Thus, in order to resolve this issue, I booted with a CDROM of FreeBSD 9 RELEASE, I then imported (*-f*) my zpool, and followed the procedure of resizing my filesystems. Does anyone have a better idea as to what I should do in order to make *zpool* see all the available space of the partitions it is using? Thank you all for your time in advance, mamalos post 2: Ah, and not to forget: I have enabled the autoexpand property of *zpool* (to be honest I've enabled, disabled, reenabled, and so forth many times, because somewhere I read that it might be needed, sometimes...), with no luck. post 3: Since nobody has an answer that far, let me ask another thing. Instead of deleting ada0p2 and ada1p2, and then recreating them from the same starting block but with a grater size, could I have just created two new filesystems (ada0p3 and ada1p3), and having them added in the pool as a new mirror? Because if that's the case, then I could try that out, since it seems to have the same result. Not that this answers to my question, but at least it's a workaround. As stated in these posts, it's really strange that zpool list doesn't seem to react even if I set the expand flag (or autoexpand which is the same), hence my concern whether this could be a bug. Thank you all for your time, Hi, Have you tried offline, online -e yet? I have done what you are trying succesfully with physical larger drives. When I understand your layout right, you should be able to do the following: (as root) zpool offline zroot ada0p2 zpool online -e zroot ada0p2 # Wait till everything settles and looks okay again, monitoring zpool # status # After all is okay again: zpool offline zroot ada1p2 zpool online -e zroot ada1p2 At this point your zpool should have grown to the size of its underlying partitions. It worked for me, my system was 8-STABLE at the time. The very same system has been upgrade to 9.0-RELEASE in the mean time, without any problems. Marco Marco thank you, it worked like a charm! -- George Mamalakis IT and Security 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
audit in jail
Hello everybody, has anyone started auditd inside a jail successfully? I allowed audit and auditpipe from devfs inside the jails (I have confirmed their existence in the jails as well...:-) ), but when I run auditd I am getting this message in my logs: Mar 2 15:20:29 myhost auditd[89494]: auditd_prevent_audit() could not set active audit session state: Function not implemented Mar 2 15:20:29 myhost mamalos: audit warning: nostart I googled it, but didn't find much. I checked the code and after some searching, I found that the problem was occurring when the setaudit system call is being called. I checked the code of audit_syscalls and found that: 584: if (jailed(td-td_ucred)) 585: return (ENOSYS); in the sys_setaudit() context...which is somewhat clear as to what it means :-). Is there anything I have omitted, or is it that clear that audit does not run in jails? And if so, are there any thoughts on implementing in the near future? Thank you all for your help and time in advance. -- George Mamalakis IT and Security 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: audit in jail
Ah! And one more thing with respect to this issue. Since I realized that probably I won't be able to run audit within a jail, I tried to continue with my work from outside the jail. What I need is to audit some system users (like www) inside my jails and do stuff with their audit trails. In order to be able to audit www's actions, I downloaded setaudit from http://www.freebsd.org/~csjp/setaudit.c which allows this functionality. setaudit works fine from outside my jails, but when I run it from within a jail, I get the following error again: [root@in-jail] # setaudit -awww -mfr /bin/ls setaudit: setaudit_addr: Function not implemented Is there, at least, some easy/secure/not-whole-system-configuration-changing way to start apache from within a jail to be able to audit his actions from outside the jail? Thank you all in advance, once more. -- George Mamalakis IT and Security 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: audit in jail
On 03/02/12 18:17, George Mamalakis wrote: Ah! And one more thing with respect to this issue. Since I realized that probably I won't be able to run audit within a jail, I tried to continue with my work from outside the jail. What I need is to audit some system users (like www) inside my jails and do stuff with their audit trails. In order to be able to audit www's actions, I downloaded setaudit from http://www.freebsd.org/~csjp/setaudit.c which allows this functionality. setaudit works fine from outside my jails, but when I run it from within a jail, I get the following error again: [root@in-jail] # setaudit -awww -mfr /bin/ls setaudit: setaudit_addr: Function not implemented Is there, at least, some easy/secure/not-whole-system-configuration-changing way to start apache from within a jail to be able to audit his actions from outside the jail? Thank you all in advance, once more. OK, found it! I am running: [root@out-of-jail] setaudit -awww -m fr,fw,fa,fm,fc,fd,cl jexec 6 /usr/local/bin/sudo -u www /usr/local/sbin/apachectl startssl from outside the jails and it works like a charm! Nasty, but at least it's working... Thank you all anyway! -- George Mamalakis IT and Security 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: mod_auth_kerb2 broken in 8-STABLE? Or is it heimdal to blame?
On 06/04/2011 18:29, George Mamalakis wrote:
Dear all,
I installed mod_auth_kerb2 on my FreeBSD 8-STABLE machine and tried to
use it. After the installation (which was successful(?!?)), the server
refused to start giving the error:
# /usr/local/etc/rc.d/apache22 start
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 103 of /usr/local/etc/apache22/httpd.conf:
Cannot load /usr/local/libexec/apache22/mod_auth_kerb.so into server:
/usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol
gsskrb5_register_acceptor_identity
Starting apache22.
httpd: Syntax error on line 103 of /usr/local/etc/apache22/httpd.conf:
Cannot load /usr/local/libexec/apache22/mod_auth_kerb.so into server:
/usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol
gsskrb5_register_acceptor_identity
/usr/local/etc/rc.d/apache22: WARNING: failed to start apache22
but ldd showed:
# ldd /usr/local/libexec/apache22/mod_auth_kerb.so
/usr/local/libexec/apache22/mod_auth_kerb.so:
libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x800c0)
libheimntlm.so.10 = /usr/lib/libheimntlm.so.10 (0x800d0a000)
libkrb5.so.10 = /usr/lib/libkrb5.so.10 (0x800e0f000)
libhx509.so.10 = /usr/lib/libhx509.so.10 (0x800f7e000)
libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x8010be000)
libcrypto.so.6 = /lib/libcrypto.so.6 (0x8011c)
libasn1.so.10 = /usr/lib/libasn1.so.10 (0x801461000)
libroken.so.10 = /usr/lib/libroken.so.10 (0x8015e3000)
libcrypt.so.5 = /lib/libcrypt.so.5 (0x8016f5000)
libc.so.7 = /lib/libc.so.7 (0x800647000)
which showed that everything should have been fine. I googled it a bit
and found this thread regarding my error message:
http://forum.nginx.org/read.php?23,88476 , which started on May 2010,
and pointed to this PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=147454 , which started on
June 2010. What is stated, is that heimdal-1.1 was broken in FreeBSD,
and that it should be fixed at some moment in the future. (I tested
mod_auth_kerb2 on another machine running heimdal from ports (1.4_1)
and I had exactly the same problem).
I searched to find where this notorious function
(gsskrb5_register_acceptor_identity) was located, and I found its
declaration in: /usr/include/gssapi/gssapi_krb5.h, and its definition
in: /usr/lib/libgssapi_krb5.so.
So, I added -lgssapi_krb5 in KRB5_LDFLAGS variable of
/usr/ports/www/mod_auth_kerb2/work/mod_auth_kerb-5.4/Makefile , since
this where the location of gsskrb5_register_acceptor_identity
originally seemed to be, and reinstalled the port using gmake this
time (inside the port's work directory). After that, the module works
just fine. The initial content of this line was:
KRB5_LDFLAGS = -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err
-lcrypto -lasn1 -lroken -lcrypt
I've sent an analogous email to the port maintainer, but I am not sure
if it is their fault. Hence, I decided to send this email to the
stable list for two reasons: First, someone else may be having a
similar problem and wants to find a rough solution. Secondly, there
are people reading this list that know heimdal's code, so somebody may
know another (much more elegant) way to fix this bug.
Thank you all for your time in advance,
Regards,
mamalos.
OK,
I spoke with the maintainer who confirmed the problem. He also suggested
to change line 96 of /usb/bin/krb5-config to include gssapi_krb5 among
its libraries. He also gave me the relevant patch, and asked me to send
a PR to FreeBSD. The patch is as follows:
--- /usr/bin/krb5-config.orig 2011-02-17 03:18:57.0 +0100
+++ /usr/bin/krb5-config2011-04-06 23:41:31.0 +0200
@@ -93,7 +93,7 @@
lib_flags=-L${libdir}
case $library in
gssapi)
- lib_flags=$lib_flags -lgssapi -lheimntlm
+ lib_flags=$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm
;;
kadm-client)
lib_flags=$lib_flags -lkadm5clnt
And the relevant PR is:
http://www.freebsd.org/cgi/query-pr.cgi?pr=156245
Thank you all for your time,
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
mod_auth_kerb2 broken in 8-STABLE? Or is it heimdal to blame?
Dear all, I installed mod_auth_kerb2 on my FreeBSD 8-STABLE machine and tried to use it. After the installation (which was successful(?!?)), the server refused to start giving the error: # /usr/local/etc/rc.d/apache22 start Performing sanity check on apache22 configuration: httpd: Syntax error on line 103 of /usr/local/etc/apache22/httpd.conf: Cannot load /usr/local/libexec/apache22/mod_auth_kerb.so into server: /usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol gsskrb5_register_acceptor_identity Starting apache22. httpd: Syntax error on line 103 of /usr/local/etc/apache22/httpd.conf: Cannot load /usr/local/libexec/apache22/mod_auth_kerb.so into server: /usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol gsskrb5_register_acceptor_identity /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22 but ldd showed: # ldd /usr/local/libexec/apache22/mod_auth_kerb.so /usr/local/libexec/apache22/mod_auth_kerb.so: libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x800c0) libheimntlm.so.10 = /usr/lib/libheimntlm.so.10 (0x800d0a000) libkrb5.so.10 = /usr/lib/libkrb5.so.10 (0x800e0f000) libhx509.so.10 = /usr/lib/libhx509.so.10 (0x800f7e000) libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x8010be000) libcrypto.so.6 = /lib/libcrypto.so.6 (0x8011c) libasn1.so.10 = /usr/lib/libasn1.so.10 (0x801461000) libroken.so.10 = /usr/lib/libroken.so.10 (0x8015e3000) libcrypt.so.5 = /lib/libcrypt.so.5 (0x8016f5000) libc.so.7 = /lib/libc.so.7 (0x800647000) which showed that everything should have been fine. I googled it a bit and found this thread regarding my error message: http://forum.nginx.org/read.php?23,88476 , which started on May 2010, and pointed to this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=147454 , which started on June 2010. What is stated, is that heimdal-1.1 was broken in FreeBSD, and that it should be fixed at some moment in the future. (I tested mod_auth_kerb2 on another machine running heimdal from ports (1.4_1) and I had exactly the same problem). I searched to find where this notorious function (gsskrb5_register_acceptor_identity) was located, and I found its declaration in: /usr/include/gssapi/gssapi_krb5.h, and its definition in: /usr/lib/libgssapi_krb5.so. So, I added -lgssapi_krb5 in KRB5_LDFLAGS variable of /usr/ports/www/mod_auth_kerb2/work/mod_auth_kerb-5.4/Makefile , since this where the location of gsskrb5_register_acceptor_identity originally seemed to be, and reinstalled the port using gmake this time (inside the port's work directory). After that, the module works just fine. The initial content of this line was: KRB5_LDFLAGS = -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -lroken -lcrypt I've sent an analogous email to the port maintainer, but I am not sure if it is their fault. Hence, I decided to send this email to the stable list for two reasons: First, someone else may be having a similar problem and wants to find a rough solution. Secondly, there are people reading this list that know heimdal's code, so somebody may know another (much more elegant) way to fix this bug. Thank you all for your time in advance, 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
NFS tuning over ZFS
Hi everybody, I want to use a setup of nfsv3,krb5i mountpoints for my users' homefolders. The clients are linux (Ubuntu) and the server is FreeBSD-8-STABLE. The clients use autofs for mounting the users' homefolders. Once a user logs in, their folder is mounted, and the user has access to their homefolder via nfs. When I run ls(1), the system sometimes stalls before it responds. At the moment I am in the pilot phase, so there is no load on the server or client to cause this stall, since I am the only user using this setup. The delay in this ls(1) command is present even if I mount the homefolder without the use of kerberos. Hence, I started reading about NFS tuning both for linux and FreeBSD. What I found in a few resources regarding linux, was to enable async mounts on the client if I was willing to take the risk of compromising data integrity. I've tried mounting the share with the async option set, just for the sake of experimentation, but with no luck (mount(8) doesn't show 'async' among the mount options). I didn't look into it more deeply, so I moved on. As far as my next tuning candidate is concerned -the server- the shares are stored on a ufs partition of an esxi FreeBSD-image, for the moment. Once my proof-of-concept period is completed, the setup will be migrated to a real system and the homefolders are meant to be stored on a ZFS zraid partition. The server uses a 6-disk raid on an IBM 8k raid controller with memory and battery backup. I will create a 15GB volume (raid6) for the root filesystem, and will export the remaining space of each disk as a separate, equal-size volume. This way, I will be able to create the ZFS raid over these 6 volumes and then I will export the filesystem using NFS. From what I've read so far, both on this list and on http://wiki.freebsd.org/ZFSTuningGuide, it is stated that if ZIL is disabled or put on a SSD separate disk, NFS over ZFS performance is enhanced. On some mails of this list, specifically those with the subject zfs, nfs and zil started by Claus Guttesen, it is mentioned that ZIL 'may' be disabled if the underlying system uses an analogous data integrity mechanism. So, after all this intro, here are my two simple questions: 1) If I enable this mechanism on my controller, will my filesystem be safe in a case of power outage? 2) Is there a good, up-to-date guide for NFS performance for FreeBSD? Thank you all for your time in advance, 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: nsswitch problems
On 24/03/2011 16:28, George Mamalakis wrote: Hello everybody, In short: nsswitch seems not to honor (fully) the criteria and actions of nsswitch.conf. A detailed analysis of my problem can be found on this thread (it's on freebsd forums, and it hasn't been answered yet): http://forums.freebsd.org/showthread.php?t=22716 Thank you all for your time and help in advance, I hope that somebody will help me realize how nsswitch works, so as to see if and how caching may help me on an nss_ldap authenticated configuration, regards, mamalos Anybody having an idea on what might be wrong with the nsswitch mechanism? Have I used the wrong mailing list? Should I have used freebsd-questions instead? Thank you all for your time in advance. 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: nsswitch problems
On 28/03/2011 11:43, George Mamalakis wrote: On 24/03/2011 16:28, George Mamalakis wrote: Hello everybody, In short: nsswitch seems not to honor (fully) the criteria and actions of nsswitch.conf. A detailed analysis of my problem can be found on this thread (it's on freebsd forums, and it hasn't been answered yet): http://forums.freebsd.org/showthread.php?t=22716 Thank you all for your time and help in advance, I hope that somebody will help me realize how nsswitch works, so as to see if and how caching may help me on an nss_ldap authenticated configuration, regards, mamalos Anybody having an idea on what might be wrong with the nsswitch mechanism? Have I used the wrong mailing list? Should I have used freebsd-questions instead? Thank you all for your time in advance. mamalos Hmm, I found two more problems with nsswitch, regarding su(1) this time: 1) If I use SASL authentication in nss_ldap, then when I try to: $ su - Password: # On /var/log/messages I get the error: Mar 28 18:17:03 mamalacation su: GSSAPI Error: Miscellaneous failure (see text) (open(/tmp/krb5cc_1001): No such file or directory^B) Mar 28 18:17:03 mamalacation su: nss_ldap: could not search LDAP server - Server is unavailable which is a bit peculiar, since 1001 is my default user (mamalos), and it seems that su(1) tries to find a principal with a uid=1001 when it tries to access nsswitch information, instead of using the sasl_authid user from /usr/local/etc/nss_ldap.conf. If I use binddn=blabla, then everything works just fine. 2) When my /etc/nsswitch.conf reads: hosts: ldap files group: ldap files and I run: $ id mamalos uid=1001(mamalos) gid=513(Domain Users) groups=513(Domain Users),512(Domain Admins),0(wheel),814(puppet) we see that mamalos is a member of the wheel group. But when I try to su(1) to root I get a BAD SU mamalos to root in /var/log/messages. When my /etc/nsswitch.conf reads: hosts: files ldap group: files ldap and I run: $ id mamalos uid=1001(mamalos) gid=1001(mamalos) groups=1001(mamalos),0(wheel),814(puppet),512(Domain Admins) then, suing to root works just fine. The same holds when I run id(1) (with no arguments); in that case, the system replies with the information it finds in the first resource (ldap on the first example, file on the second) and stops. That said, I come into two separate conclusions: 1) SASL authentication in nss_ldap doesn't seem to be fully functional. 2) It seems that some commands call functions that honor the criteria/actions fields of /etc/nsswitch.conf, while other commands call functions that don't (like the id and getent). Any comments on these issues are welcome, 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
nsswitch problems
Hello everybody, In short: nsswitch seems not to honor (fully) the criteria and actions of nsswitch.conf. A detailed analysis of my problem can be found on this thread (it's on freebsd forums, and it hasn't been answered yet): http://forums.freebsd.org/showthread.php?t=22716 Thank you all for your time and help in advance, I hope that somebody will help me realize how nsswitch works, so as to see if and how caching may help me on an nss_ldap authenticated configuration, 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: vm.swap_reserved toooooo large?
On 19/12/2010 00:17, Ronald Klop wrote: On Sat, 18 Dec 2010 12:52:10 +0100, George Mamalakis mama...@eng.auth.gr wrote: Oliver, I am sending you this email outside the list, because I think that That didn't work out as you intended. :-) replying on emails and cooking on the same time may result in peculiar outcomes :)...sorry guys. -- 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: vm.swap_reserved toooooo large?
Oliver, I am sending you this email outside the list, because I think that enough emails have been sent regarding my message. Now to your statements: On 18/12/2010 11:47 πμ, Oliver Fromme wrote: George Mamalakis wrote: Oliver, thanx for your comments. I know it is difficult to choose which process to kill and how to be fair during such a killing procedure. Nevertheless, I would assume that all non-root processes would have higher priority to get killed, and that root's processes would get killed last. The owner of the process is not taken into consideration, because the run-away process causing the memory shortage may as well be a root-owned process. In such a situation, if root processes were exempt from killing, the system would deadlock and require a hard reboot. Killing the root-owned process is the lesser of two evils. As I explained in one of my previous emails, I expected that root processes would have *lower priority* than non-root processes; I never implied that root processes shouldn't get killed, it would be irrational to say so. As I already explained, there is a process flag that root- owned processes can set for themselves, preventing the kernel from killing them in low-memory situations. See the description of the MADV_PROTECT flag in the madvise(2) manual page. For example, cron(8) and sshd(8) make use of this, so they will not be killed. This is a better way than simply excluding all root processes. I understand your comments completely, but I was just so surprised when I realized how easy it was for me to kill root processes on my system. Only because you didn't configure resource limits. ;-) When you're the only user on a machine, such as a desktop box, this is usually not a big deal. But in all other cases it's strongly recommended to set resource limits, in particular for shell users and for server processes. Without any resource limits, a normal user can starve the system and take it down. This is an old and well-known problem for all UNIX systems (and most non-UNIX systems, too, I guess). You certainly didn't discover any new problem. If you're concerned, configure resource limits. Period. As I stated in my first message (if I recall correctly), all this happened because I didn't configure my rlimits (it's my laptop). Of course I am aware of resource limits, and I configure them on most of the servers I administer for the last 12 years (I've seen my vmstat showing 500+ processes in blocked-by-io state, and the system wouldn't hang..:)). I never implied to have discovered anything new, and especially something regarding resource limits. All my enthusiasm was caused firstly due to fbsd's memory allocation algorithm (I never knew the system would assume that it could allocate 500+GB of memory, and the replies on this issue where very enlightening for me), and secondly due to fbsd's algorithm on process killing when memory has been starved. Certainly, I was not surprised by the fact that my system was out of memory...exceeding my system's memory limits was my experiment in the first place! Anyway, thanx again for your answer and all your pointers (MADV_PROTECT, etc), and I think there is no need to get angry about my emails. As I initially stated, my questions where rhetorical, and no answers where needed. I trusted that there should be a good reason behind this behavior...Some of you answered on the list and I just replied with my opinion. Nothing more, nothing less. Have a nice day and 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: vm.swap_reserved toooooo large?
On 16/12/2010 18:56, Oliver Fromme wrote: George Mamalakismama...@eng.auth.gr wrote: My dmesg shows: pid 1732 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) pid 2227 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) swap zone exhausted, increase kern.maxswzone pid 1544 (console-kit-daemon), uid 0, was killed: out of swap space swap zone exhausted, increase kern.maxswzone pid 2864 (memory), uid 1001, was killed: out of swap space swap zone exhausted, increase kern.maxswzone pid 1676 (gconf-helper), uid 1001, was killed: out of swap space where one can see that pid 1544 was killed before 2864, which is the process that caused all this mess. Yes, I know that I should use limits so as not to allow such things to happen, but on the other hand, if a malicious user causes such a situation he/she may gain access to information through core-dumps on root processes, AND cause DoS attacks. No. First, when the kernel kills processes because it runs out of swap space, it uses SIGKILL which does _not_ cause a core dump to be written. Second, core dumps are always created with permissions 0600, i.e. they are only readable by the owner of the process. Of course, any user who can run a machine out of memory can cause a DoS attack by doing this. That's the reason why resource limits exist. If it were for me, I would sort all processes based on their memory consumption, and start by killing those that have the highest value (top-bottom) that are NOT owned by root (just a thought, without thinking about it too much), so as to prevent such situations from happening. It is very non-trivial to find a generic algorithm that kills the right process in such a situation. For example, an attacker could start a lot of small processes that allocate memory. That's the reason why an admin should always configure resource limits approprately. The kernel's killing feature should only be regarded as the very last emergency break, which basically exists only to prevent a reboot. If you're interested, you can find the selection algorithm for processes to kill in the vm_pageout_oom() function in src/sys/vm/vm_pageout.c. Basically, it selects the process that consumes the most physical memory (RAM + swap), not counting the virtual size of the process. Also, some processes are excluded, such as system processes and protected processes (cron and sshd, for example). Best regards Oliver Oliver, thanx for your comments. I know it is difficult to choose which process to kill and how to be fair during such a killing procedure. Nevertheless, I would assume that all non-root processes would have higher priority to get killed, and that root's processes would get killed last. I understand your comments completely, but I was just so surprised when I realized how easy it was for me to kill root processes on my system. Thanx again and best 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
vm.swap_reserved toooooo large?
Dear all, I was testing a program that would exhaust all my memory (in C++), and when this would happen, it would call set_new_handler() along with one of my functions that would inform the user about the lack of memory and then it would exit the program. Instead, the program was force-killed by the kernel (signal 9) and I was informed that: swap zone exhausted, increase kern.maxswzone on my main console. So far so good. In two other consoles I was running top -P, and vmvstat 5, and their output was: # top -P last pid: 1776; load averages: 1.71, 0.72, 0.40up 0+00:24:29 12:24:39 34 processes: 2 running, 32 sleeping CPU 0: 2.6% user, 0.0% nice, 88.3% system, 0.0% interrupt, 9.0% idle CPU 1: 0.0% user, 0.0% nice, 39.1% system, 0.0% interrupt, 60.9% idle CPU 2: 0.0% user, 0.0% nice, 2.6% system, 1.5% interrupt, 95.9% idle CPU 3: 0.4% user, 0.0% nice, 89.8% system, 0.0% interrupt, 9.8% idle Mem: 2629M Active, 221M Inact, 966M Wired, 82M Cache, 7280K Buf, 16M Free Swap: 4096M Total, 1821M Used, 2275M Free, 44% Inuse, 196K In, 30M Out FreeBSD/amd64 (example.com) (ttyv2)ATE C TIME WCPU COMMAND 1771 mamalos 1 1170 573G 3566M CPU11 1:48 94.38% memory login: oot 1 440 11544K 1176K select 0 0:17 0.29% hald-addon 1535 root 1 440 16552K 1436K swread 2 0:03 0.20% hald-addon 1772 mamalos 1 440 9364K 2032K CPU30 0:02 0.00% top 790 root 1 460 8068K 812K select 3 0:01 0.00% moused 1514 root 1 440 21696K 1596K wait0 0:00 0.00% login 1711 mamalos 1 450 10148K 0K wait1 0:00 0.00% bash 1021 root 1 440 7044K 864K zio-i 2 0:00 0.00% syslogd 829 root 1 640 3204K16K select 2 0:00 0.00% devd 1568 root 1 470 10148K 964K ttyin 1 0:00 0.00% bash 1530 root 1 440 17872K 1108K swread 2 0:00 0.00% hald-runne 1513 root 1 440 21696K 0K wait0 0:00 0.00% login 1680 mamalos 1 440 10148K 0K wait3 0:00 0.00% bash 1512 root 1 440 21696K 0K wait0 0:00 0.00% login 1511 root 1 440 21696K 0K wait0 0:00 0.00% login and: # vmstat 5 procs memory pagedisks faults cpu r b w avmfre flt re pi pofr sr ad4 cd0 in sy cs us sy id 1 0 9565G 133M 1761 3 4 156 901 13078 0 0 173 1693 1581 0 7i 92 when the program was shut. As you can see (in vmstat's output) avm equals to 565G of memory(?!?!?!), and top shows that the first process (it's called memory) has a size of 573G! moreover, on another terminal I run: # sysctl -a | grep -i swap vm.swap_enabled: 1 vm.nswapdev: 1 vm.swap_async_max: 4 vm.swap_reserved: 544762376192 vm.swap_total: 4294967296 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.stats.vm.v_swappgsout: 795224 vm.stats.vm.v_swappgsin: 1188 vm.stats.vm.v_swapout: 200045 vm.stats.vm.v_swapin: 606 vm.disable_swapspace_pageouts: 0 vm.defer_swapspace_pageouts: 0 vm.swap_idle_enabled: 0 where one can see that vm.swap_reserved is equal to 507G whereas the total size (vm.swap_total) is 4G.(?!?!?) As far as my system is concerned: $ uname -a FreeBSD example.com 8.1-STABLE FreeBSD 8.1-STABLE #1: Fri Nov 5 17:27:37 EET 2010 root@:/mnt/obj/mnt/src/sys/GENERIC amd64 and I use zfs on one of my filesystems. So: $ cat /boot/loader.conf zfs_load=YES vfs.zfs.prefetch_disable=0 nvidia_load=YES kern.maxfiles=35000 kern.ipc.shmall=65536 atapicam_load=YES snd_hda_load=YES I had noticed in the past that at some moments vmstat would show more memory than what my total memory was, but never sooo much. Is this a bug or am I missing something very fundamental? Thank you all for your time in advance. -- 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: vm.swap_reserved toooooo large?
On 15/12/2010 13:26, Trond Endrestøl wrote: On Wed, 15 Dec 2010 13:04+0200, George Mamalakis wrote: I was testing a program that would exhaust all my memory (in C++), and when this would happen, it would call set_new_handler() along with one of my functions that would inform the user about the lack of memory and then it would exit the program. Instead, the program was force-killed by the kernel (signal 9) and I was informed that: If all your process' memory is exhausted, then there is no memory left for the runtime system for doing I/O and the other stuff you want. Next, unless I'm on drugs, maybe you should call set_new_handler() before you actually run out of memory. Just my $0.02. Trond. ___ 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 Trond, My problem was not that the program was force-killed, my problem was that the system reserved 500G+ of swap, even though the total size is 4G. -- 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: vm.swap_reserved toooooo large?
On 15/12/2010 15:51, Kostik Belousov wrote: On Wed, Dec 15, 2010 at 03:43:56PM +0200, George Mamalakis wrote: On 15/12/2010 13:26, Trond Endrest??l wrote: On Wed, 15 Dec 2010 13:04+0200, George Mamalakis wrote: I was testing a program that would exhaust all my memory (in C++), and when this would happen, it would call set_new_handler() along with one of my functions that would inform the user about the lack of memory and then it would exit the program. Instead, the program was force-killed by the kernel (signal 9) and I was informed that: If all your process' memory is exhausted, then there is no memory left for the runtime system for doing I/O and the other stuff you want. Next, unless I'm on drugs, maybe you should call set_new_handler() before you actually run out of memory. Just my $0.02. Trond. ___ 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 Trond, My problem was not that the program was force-killed, my problem was that the system reserved 500G+ of swap, even though the total size is 4G. Read tuning(7), in particular, the description of vm.overcommit sysctl. Thank you Kostik, it proves that I was missing something fundamental after all :) On the other hand, what I noticed was that during the process of allocating the huge amount of memory, root processes got killed, which at first seems rational, on the other hand it is a bit strange. My dmesg shows: pid 1732 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) pid 2227 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) swap zone exhausted, increase kern.maxswzone pid 1544 (console-kit-daemon), uid 0, was killed: out of swap space swap zone exhausted, increase kern.maxswzone pid 2864 (memory), uid 1001, was killed: out of swap space swap zone exhausted, increase kern.maxswzone pid 1676 (gconf-helper), uid 1001, was killed: out of swap space where one can see that pid 1544 was killed before 2864, which is the process that caused all this mess. Yes, I know that I should use limits so as not to allow such things to happen, but on the other hand, if a malicious user causes such a situation he/she may gain access to information through core-dumps on root processes, AND cause DoS attacks. If it were for me, I would sort all processes based on their memory consumption, and start by killing those that have the highest value (top-bottom) that are NOT owned by root (just a thought, without thinking about it too much), so as to prevent such situations from happening. No need to answer my questions, they are rhetorical. I assume that there must be some good reason behind this behavior. Thanx again for all the help. -- 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: chflags on zfs (sappnd)
On 17/11/2010 21:25, Markus Gebert wrote: On 17.11.2010, at 20:00, Andriy Gapon wrote: on 17/11/2010 18:38 Markus Gebert said the following: On 17.11.2010, at 11:49, George Mamalakis wrote: Hi everbody, from http://wiki.freebsd.org/ZFS I understand that chflags are supported by zfs. But if I have a file with sappnd on a zfs filesystem, I am unable to execute a command like this: # touch lili # chflags sappnd lili # ls -lrto lili -rw-r--r-- 1 root wheel sappnd 5 Nov 17 12:38 lili # echo lala lili # echo lala lili -su: echo: write error: Operation not permitted So, the first time it worked, but it stops working on any consequent time (when the file is no more empty). I found a bug report on: http://www.freebsd.org/cgi/query-pr.cgi?pr=149495 And: http://www.freebsd.org/cgi/query-pr.cgi?pr=151082cat=kern where a patch is suggested. Nevertheless, even though my sources are newer than the suggested patch, my source tree does not contain it. Do we know anything more about it? The fix was committed to CURRENT on Oct 8th (r213634). The commit message talks about MFC after a week, however to me it looks like the fix hasn't made it to 8-STABLE yet. Also, there seems to be a related commit r213673 which essentially reverts r213634 and has a more general approach to handling ioflags with zfs. This commit was on Oct 10th, again 1 week MFC grace period, again not in 8-STABLE yet, at least to my knowlegde. Maybe MFC was simply forgotten, maybe there's a good reason to delay it, I don't know. We're using my patch (the one mentioned in the PRs) for now and append-only works as intended. Applying the changes in r213673 to 8-STABLE might be an option too, if you're considering patching to get the append flag working. Anyway, hopefully one of these fixes gets MFCd to 8-STABLE soon. Good analysis, but did you forget to CC the committer(s)? It is known that sometimes the committers do need a gentle (or not so) nudging :-) Right :-) mm@ and pjd@ now CCed. Markus cheers guys :-) -- 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
chflags on zfs (sappnd)
Hi everbody, from http://wiki.freebsd.org/ZFS I understand that chflags are supported by zfs. But if I have a file with sappnd on a zfs filesystem, I am unable to execute a command like this: # touch lili # chflags sappnd lili # ls -lrto lili -rw-r--r-- 1 root wheel sappnd 5 Nov 17 12:38 lili # echo lala lili # echo lala lili -su: echo: write error: Operation not permitted So, the first time it worked, but it stops working on any consequent time (when the file is no more empty). I found a bug report on: http://www.freebsd.org/cgi/query-pr.cgi?pr=149495 where a patch is suggested. Nevertheless, even though my sources are newer than the suggested patch, my source tree does not contain it. Do we know anything more about it? # uname -a FreeBSD myhost 8.1-STABLE FreeBSD 8.1-STABLE #1: Fri Nov 5 17:27:37 EET 2010 root@:/mnt/obj/mnt/src/sys/GENERIC amd64 Thank you all for your time in advance, 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: fbsd8_stable nfsv3 sys=krb5 issue [resolved]
On 16/09/2010 16:44, George Mamalakis wrote: Hi all, I re-decided to move my nfs server from solaris to fbsd. So I am using test machines to see if it works. I have my kerberos realm configured, and seems to work fine, both nfsserver and nfsclient have their host and nfs keytabs stored in /etc/krb5.keytab files, and I am following the configuration instructions from http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup that rick was kind enough to write (thanx rick!). Before analyzing my problem and configuration steps further, let me state the reason for this email: I am not able to access an nfsv3 mounted filesystem when mounted with sys=krb5 (or krb5i, krb5p whatsoever) by following rick's instructions, whereas in the past I had no such problem. To be more specific: Last time I was playing with the configuration most things worked fine (Feb 2010), but now things seem a bit different, and I am not sure whether I have forgotten something fundamental on my configuration or something has changed since I updated both my machines (client and server) to the latest sources: nfs-server: # uname -a FreeBSD fbsdclient.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #1: Wed Sep 15 17:07:13 EEST 2010 r...@fbsdclient.ee.auth.gr:/usr/obj/usr/src/sys/SERVER i386 nfs-client: # uname -a FreeBSD filesrv.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #0: Fri Sep 10 13:08:06 EEST 2010 r...@filesrv.ee.auth.gr:/usr/obj/usr/src/sys/CLIENT amd64 I have my two usual test-users on my test-machines, mamalos and testakis, who both exist as kerberos principals too; their uids and gids are the same on all machines. I am able to kinit to any of them on my machines and acquire a valid kerberos ticket, which makes me assume that kdc runs nicely. fbsd-client's /etc/rc.conf reads: rpcbind_enable=YES mountd_enable=YES mountd_flags=-e nfs_server_enable=YES nfs_client_enable=YES nfsv4_server_enable=YES nfsuserd_enable=YES gssd_enable=YES and fbsd-server's /etc/rc.conf reads: rpcbind_enable=YES nfs_client_flags=-n 4 rpc_statd_enable=YES rpc_lockd_enable=YES #nfsd_flags=-e gssd_enable=YES nfsuserd_enable=YES nfsclient_enable=YES # nfs server nfs_server_enable=YES mountd_enable=YES #mountd_flags=-e Don't get confused that both machines have nfsd enabled (the client is used as an experimental nfsv4 server too), and I think that this should not be an issue with regard to my problem (on the other hand, nobody knows...). the server's kernel-config reads: options KGSSAPI device crypto options NFSCL and the client's kernel-config reads: options NFSD #(don't forget that the client works as an nfsv4 server too) options KGSSAPI device crypto Lastly, the server's /etc/exports reads: /exports-alldirs -sec=krb5 on the server: # ls -la /exports total 10 drwxr-xr-x 5 root wheel - 512 17 Feb 2010 ./ drwxr-xr-x 22 root wheel - 512 15 Sep 19:33 ../ drwxr-xr-x 3 root wheel - 512 5 Feb 2010 m/ drwxr-xr-x 2 mamalos wheel - 512 16 Sep 15:43 mamalos/ drwx-- 2 testakis wheel - 512 4 Feb 2010 testakis/ on the client: # klist klist: No ticket file: /tmp/krb5cc_0 # mount mount_nfs -onfsv3,sec=krb5 server:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server:/exports on /mnt (nfs) # ls -la /mnt total 0 ls: /mnt: Permission denied # exit $ id uid=1001(mamalos) gid=1001(mamalos) groups=1001(mamalos),0(wheel) $ klist klist: No ticket file: /tmp/krb5cc_1001 $ ls -la /mnt total 0 ls: /mnt: Permission denied $ kinit mamalos mama...@example's Password: $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example $ ls -la /mnt total 0 ls: /mnt: Permission denied ... (dooea?!?!?!!?) ... $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example Sep 16 16:27:51 Sep 17 02:26:49 nfs/ser...@example And this is where I don't understand what I have done wrong... If I use sec=krb5:sys in my /etc/exports, and type mount_nfs -onsfsv3,sec=krb5 ...blabla... on the client, everything seems to work ok, but then again no kerberos protection is applicable (I am able to rw in /mnt/mamalos folders as mamalos without having obtained any ticket). I assume that I must have forgotten to include something very fundamental in my configs, but my head is stuck, so if someone has an idea... Thank you all for your time in advance, regards, mamalos Rick, I found the problem once I followed your suggestion to kinit -k fbsdclient.ee.auth.gr on the server; the output was wrong password or something like that. On both server and client I have two keys stored in their /etc/krb5.keytab files: one nfs/blabla and one host
fbsd8_stable nfsv3 sys=krb5 issue
Hi all, I re-decided to move my nfs server from solaris to fbsd. So I am using test machines to see if it works. I have my kerberos realm configured, and seems to work fine, both nfsserver and nfsclient have their host and nfs keytabs stored in /etc/krb5.keytab files, and I am following the configuration instructions from http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup that rick was kind enough to write (thanx rick!). Before analyzing my problem and configuration steps further, let me state the reason for this email: I am not able to access an nfsv3 mounted filesystem when mounted with sys=krb5 (or krb5i, krb5p whatsoever) by following rick's instructions, whereas in the past I had no such problem. To be more specific: Last time I was playing with the configuration most things worked fine (Feb 2010), but now things seem a bit different, and I am not sure whether I have forgotten something fundamental on my configuration or something has changed since I updated both my machines (client and server) to the latest sources: nfs-server: # uname -a FreeBSD fbsdclient.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #1: Wed Sep 15 17:07:13 EEST 2010 r...@fbsdclient.ee.auth.gr:/usr/obj/usr/src/sys/SERVER i386 nfs-client: # uname -a FreeBSD filesrv.ee.auth.gr 8.1-STABLE FreeBSD 8.1-STABLE #0: Fri Sep 10 13:08:06 EEST 2010 r...@filesrv.ee.auth.gr:/usr/obj/usr/src/sys/CLIENT amd64 I have my two usual test-users on my test-machines, mamalos and testakis, who both exist as kerberos principals too; their uids and gids are the same on all machines. I am able to kinit to any of them on my machines and acquire a valid kerberos ticket, which makes me assume that kdc runs nicely. fbsd-client's /etc/rc.conf reads: rpcbind_enable=YES mountd_enable=YES mountd_flags=-e nfs_server_enable=YES nfs_client_enable=YES nfsv4_server_enable=YES nfsuserd_enable=YES gssd_enable=YES and fbsd-server's /etc/rc.conf reads: rpcbind_enable=YES nfs_client_flags=-n 4 rpc_statd_enable=YES rpc_lockd_enable=YES #nfsd_flags=-e gssd_enable=YES nfsuserd_enable=YES nfsclient_enable=YES # nfs server nfs_server_enable=YES mountd_enable=YES #mountd_flags=-e Don't get confused that both machines have nfsd enabled (the client is used as an experimental nfsv4 server too), and I think that this should not be an issue with regard to my problem (on the other hand, nobody knows...). the server's kernel-config reads: options KGSSAPI device crypto options NFSCL and the client's kernel-config reads: options NFSD #(don't forget that the client works as an nfsv4 server too) options KGSSAPI device crypto Lastly, the server's /etc/exports reads: /exports-alldirs -sec=krb5 on the server: # ls -la /exports total 10 drwxr-xr-x 5 root wheel - 512 17 Feb 2010 ./ drwxr-xr-x 22 root wheel - 512 15 Sep 19:33 ../ drwxr-xr-x 3 root wheel - 512 5 Feb 2010 m/ drwxr-xr-x 2 mamalos wheel - 512 16 Sep 15:43 mamalos/ drwx-- 2 testakis wheel - 512 4 Feb 2010 testakis/ on the client: # klist klist: No ticket file: /tmp/krb5cc_0 # mount mount_nfs -onfsv3,sec=krb5 server:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server:/exports on /mnt (nfs) # ls -la /mnt total 0 ls: /mnt: Permission denied # exit $ id uid=1001(mamalos) gid=1001(mamalos) groups=1001(mamalos),0(wheel) $ klist klist: No ticket file: /tmp/krb5cc_1001 $ ls -la /mnt total 0 ls: /mnt: Permission denied $ kinit mamalos mama...@example's Password: $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example $ ls -la /mnt total 0 ls: /mnt: Permission denied ... (dooea?!?!?!!?) ... $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: mama...@example Issued Expires Principal Sep 16 16:26:49 Sep 17 02:26:49 krbtgt/exam...@example Sep 16 16:27:51 Sep 17 02:26:49 nfs/ser...@example And this is where I don't understand what I have done wrong... If I use sec=krb5:sys in my /etc/exports, and type mount_nfs -onsfsv3,sec=krb5 ...blabla... on the client, everything seems to work ok, but then again no kerberos protection is applicable (I am able to rw in /mnt/mamalos folders as mamalos without having obtained any ticket). I assume that I must have forgotten to include something very fundamental in my configs, but my head is stuck, so if someone has an idea... Thank you all for your time in advance, 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
Re: fbsd8_stable nfsv3 sys=krb5 issue
Hi Rick, glad to hearing from you, since we had a few relevant discussions in the past. On 16/9/2010 6:30 μμ, Rick Macklem wrote: Normally the server will have a keytab entry for its fully qualified domain name like: nfs/fbsdclient.ee.auth...@example and if that is the case, the client is expected to use fbsdclient.ee.auth.gr as the server's name in the mount and not server (which I assume is an alias for the above). I'm definitely no kerberos wizard, but I'd guess that's where the problem is? (try kinit -k nfs/fbsdclient.ee.auth...@example on the server, to see that the keytab works.) The aliases were written by me after copying the console's output on the email. I missed out the one you are stating in your email, and this is why I caused this confusion. All names mentioned in my email are in real called by their fqdn. The real machine names are fbsdclient.ee.auth.gr and filesrv.ee.auth.gr (but server and client are used the other way around) and my realm is EE.AUTH.GR. My /var/heimdal/kdc.log shows that all requests are handled without any problems (this is why I didn't mention it at all), and the configuration is the same as the one I was trying on Feb (subject: Kerberized NFSv3 incorrect behavior sent on Feb 5 2010) where everything seemed to work OK...or this is what I think it is, since probably I must be overseeing something important... The fully qualified domain name is used so that the keytab can't be moved to a different client and made to work easily, although a keytab entry is obviously weaker that a password based ccache entry. Beyond that, I'd suggest that you look in your KDC's logs to see what it thinks is going on when you try to access the mount point. rick ktutil -k /etc/krb5.keytab shows both keys on both servers. I haven't kinit'ed to the keytabs on the server, but when I do so I will inform you about my output (sadly I don't have access on my machines at the moment). The thing is that kdc.log shows that all keys are exchanged correctly and no exceptions are thrown... Hence, I am afraid that kerberos-config is not the problem for my case, but if you or anybody else cannot see anything wrong with the rest of my config, I will have to reconfigure both server and client from scratch, step-by-step to make it work again (I hoped to avoid this step through sending this email on the list) ps: Btw, I haven't forgotten about the issue w.r.t. kdestroy not invalidating the handle in the client so that access continues to work until the handle times out, but I haven't gotten around to fixing it. No problem!! I understand that everybody's time is precious. It is more than enough that you even remember it (I had forgotten it myself:-) ) Thanx again for the time and help. 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: AoE driver for FBSD8 or later?
On 13/09/2010 16:20, Max Khon wrote: George, On Mon, Sep 13, 2010 at 7:53 PM, Max Khon f...@samodelkin.net mailto:f...@samodelkin.net wrote: Have you tried to contact coraid on this matter? Can you try this port version? http://people.freebsd.org/~fjoe/aoe-2.tar.gz http://people.freebsd.org/%7Efjoe/aoe-2.tar.gz Max Max, thank you very much for your help. The driver works fine; I am able to see all 13T. In case something goes wrong I will inform you. For the time being, everything is OK. 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: AoE driver for FBSD8 or later?
On 14/9/2010 4:35 ??, Max Khon wrote: George, On Tue, Sep 14, 2010 at 5:01 PM, George Mamalakis mama...@eng.auth.gr mailto:mama...@eng.auth.gr wrote: On Mon, Sep 13, 2010 at 7:53 PM, Max Khon f...@samodelkin.net mailto:f...@samodelkin.net mailto:f...@samodelkin.net mailto:f...@samodelkin.net wrote: Have you tried to contact coraid on this matter? Can you try this port version? http://people.freebsd.org/~fjoe/aoe-2.tar.gz http://people.freebsd.org/%7Efjoe/aoe-2.tar.gz http://people.freebsd.org/%7Efjoe/aoe-2.tar.gz Max, thank you very much for your help. The driver works fine; I am able to see all 13T. In case something goes wrong I will inform you. For the time being, everything is OK. I committed the port to the FreeBSD ports tree: ports/net/aoe. I also committed ports/net/vblade (user-space AoE target) -- I used it for testing. I am not sure that it can be used in production due to possible performance problems. Max Max, good job! I will benchmark both drivers (fbsd and linux) to compare results. Thank you once more for your immediate actions and answers! Your have been profoundly quick and well targeted on your answers, no matter how easy it may have been for you to alter the existing code. Thumbs up to the fbsd community! great job man! 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: AoE driver for FBSD8 or later?
On 13/09/2010 08:41, Max Khon wrote: George, On Sat, Sep 11, 2010 at 12:12 AM, George Mamalakis mama...@eng.auth.gr mailto:mama...@eng.auth.gr wrote: On 10/09/2010 19:05, pluknet wrote: On 10 September 2010 17:32, George Mamalakismama...@eng.auth.gr mailto:mama...@eng.auth.gr wrote: Hi everybody, we have a coraid device with 15x1GB disks on it, and would like to use it with fbsd8 (zfs, etc). The http://support.coraid.com/support/freebsd/ is really outdated, and the port that creates the kernel module does not compile on FBSD8 (obviously!). Is there any effort on migrating the driver onto fbsd8 or should I plug the coraid on a linux system and use it from there? This change below looks obvious to me. Not sure if this is enough to make it work though. There are also might be issues with those interfaces which announce itself as IFT_ETHER, but have NULL if_input. # cat files/patch-dev-aoe-aoenet.c --- aoenet.c.orig 2006-05-25 16:10:11.0 + +++ aoenet.c2010-09-10 15:03:01.0 + @@ -77,8 +77,11 @@ #define NECODES (sizeof(aoe_errlist) / sizeof(char *) - 1) #if (__FreeBSD_version 60) #define IFPADDR(ifp) (((struct arpcom *) (ifp))-ac_enaddr) +#elif (__FreeBSD_version 70) +#define IFPADDR(ifp) IFP2ENADDR(ifp) #else -#define IFPADDR(ifp) IFP2ENADDR(ifp) +#includenet/if_dl.h +#define IFPADDR(ifp) IF_LLADDR(ifp) #endif #define IFLISTSZ 1024 @@ -223,7 +226,11 @@ m1-m_ext.ref_cnt = NULL; MEXTADD(m1, f-f_data, len, nilfn, +#if (__FreeBSD_version 80) NULL, 0, EXT_NET_DRV); +#else + f-f_data, NULL, 0, EXT_NET_DRV); +#endif m1-m_len = len; m1-m_next = NULL; } Hi, and thanx for your quick reply. I patched my workdir on /usr/ports/net/aoe/work/dev/aoe but got the following output, which probably suggests that we may be talking about a different version you and me: [root]# patch -p0 patch-dev-aoe-aoenet.c Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- aoenet.c.orig 2006-05-25 16:10:11.0 + |+++ aoenet.c2010-09-10 15:03:01.0 + -- Patching file aoenet.c using Plan A... Hunk #1 failed at 77. Hunk #2 failed at 226. 2 out of 2 hunks failed--saving rejects to aoenet.c.rej Hmm... Ignoring the trailing garbage. done After cd'ing into /usr/ports/net/aoe and giving make I got: [root]# make === Configuring for aoe-1.2.0_1 === Building for aoe-1.2.0_1 . . aoenet.c:226:24: error: macro MEXTADD requires 8 arguments, but only 7 given aoenet.c: In function 'frame_mbufinit': aoenet.c:225: error: 'MEXTADD' undeclared (first use in this function) aoenet.c:225: error: (Each undeclared identifier is reported only once aoenet.c:225: error: for each function it appears in.) cc1: warnings being treated as errors aoenet.c: In function 'aoenet_xmitbcast': aoenet.c:278: warning: implicit declaration of function 'IFP2ENADDR' aoenet.c:278: warning: nested extern declaration of 'IFP2ENADDR' aoenet.c:278: warning: passing argument 2 of 'memcpy' makes pointer from integer without a cast aoenet.c: In function 'aoenet_enaddr': aoenet.c:294: warning: return makes pointer from integer without a cast *** Error code 1 Stop in /usr/ports/net/aoe/work/dev/aoe. *** Error code 1 Stop in /usr/ports/net/aoe. Which was pretty obvious, since not much had been patched... I didn't include the whole output; the missing part is correct compilation parts. Thanx again for your help, and if you could point me into the right source code (or port, whatsoever), I could try your patch and see whether the driver would be built. You need to put that patch to ports/net/aoe/files. You can try to use this version of the port (unpack it to /usr/ports/net): http://people.freebsd.org/~fjoe/aoe.tar.gz http://people.freebsd.org/%7Efjoe/aoe.tar.gz Max Your patch worked fine, the driver compiled seamlessly, but I am unable to see more than 2T on my coraid device, even though it's size is 13T. I don't know whether this is a driver issue or fbsd issue. uname -a on my machine: [r...@~]# uname -a FreeBSD lala 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Aug 31 13:54:36 EEST 2010 r...@lala:/usr/obj/usr/src/sys/CUSTOM i386 Thanx again for your help, and since
AoE driver for FBSD8 or later?
Hi everybody, we have a coraid device with 15x1GB disks on it, and would like to use it with fbsd8 (zfs, etc). The http://support.coraid.com/support/freebsd/ is really outdated, and the port that creates the kernel module does not compile on FBSD8 (obviously!). Is there any effort on migrating the driver onto fbsd8 or should I plug the coraid on a linux system and use it from there? Thank you all in advance. -- 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: AoE driver for FBSD8 or later?
On 10/09/2010 19:05, pluknet wrote: On 10 September 2010 17:32, George Mamalakismama...@eng.auth.gr wrote: Hi everybody, we have a coraid device with 15x1GB disks on it, and would like to use it with fbsd8 (zfs, etc). The http://support.coraid.com/support/freebsd/ is really outdated, and the port that creates the kernel module does not compile on FBSD8 (obviously!). Is there any effort on migrating the driver onto fbsd8 or should I plug the coraid on a linux system and use it from there? This change below looks obvious to me. Not sure if this is enough to make it work though. There are also might be issues with those interfaces which announce itself as IFT_ETHER, but have NULL if_input. # cat files/patch-dev-aoe-aoenet.c --- aoenet.c.orig 2006-05-25 16:10:11.0 + +++ aoenet.c2010-09-10 15:03:01.0 + @@ -77,8 +77,11 @@ #define NECODES (sizeof(aoe_errlist) / sizeof(char *) - 1) #if (__FreeBSD_version 60) #define IFPADDR(ifp) (((struct arpcom *) (ifp))-ac_enaddr) +#elif (__FreeBSD_version 70) +#define IFPADDR(ifp) IFP2ENADDR(ifp) #else -#define IFPADDR(ifp) IFP2ENADDR(ifp) +#includenet/if_dl.h +#define IFPADDR(ifp) IF_LLADDR(ifp) #endif #define IFLISTSZ 1024 @@ -223,7 +226,11 @@ m1-m_ext.ref_cnt = NULL; MEXTADD(m1, f-f_data, len, nilfn, +#if (__FreeBSD_version 80) NULL, 0, EXT_NET_DRV); +#else + f-f_data, NULL, 0, EXT_NET_DRV); +#endif m1-m_len = len; m1-m_next = NULL; } Hi, and thanx for your quick reply. I patched my workdir on /usr/ports/net/aoe/work/dev/aoe but got the following output, which probably suggests that we may be talking about a different version you and me: [root]# patch -p0 patch-dev-aoe-aoenet.c Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- aoenet.c.orig 2006-05-25 16:10:11.0 + |+++ aoenet.c2010-09-10 15:03:01.0 + -- Patching file aoenet.c using Plan A... Hunk #1 failed at 77. Hunk #2 failed at 226. 2 out of 2 hunks failed--saving rejects to aoenet.c.rej Hmm... Ignoring the trailing garbage. done After cd'ing into /usr/ports/net/aoe and giving make I got: [root]# make === Configuring for aoe-1.2.0_1 === Building for aoe-1.2.0_1 . . aoenet.c:226:24: error: macro MEXTADD requires 8 arguments, but only 7 given aoenet.c: In function 'frame_mbufinit': aoenet.c:225: error: 'MEXTADD' undeclared (first use in this function) aoenet.c:225: error: (Each undeclared identifier is reported only once aoenet.c:225: error: for each function it appears in.) cc1: warnings being treated as errors aoenet.c: In function 'aoenet_xmitbcast': aoenet.c:278: warning: implicit declaration of function 'IFP2ENADDR' aoenet.c:278: warning: nested extern declaration of 'IFP2ENADDR' aoenet.c:278: warning: passing argument 2 of 'memcpy' makes pointer from integer without a cast aoenet.c: In function 'aoenet_enaddr': aoenet.c:294: warning: return makes pointer from integer without a cast *** Error code 1 Stop in /usr/ports/net/aoe/work/dev/aoe. *** Error code 1 Stop in /usr/ports/net/aoe. Which was pretty obvious, since not much had been patched... I didn't include the whole output; the missing part is correct compilation parts. Thanx again for your help, and if you could point me into the right source code (or port, whatsoever), I could try your patch and see whether the driver would be built. cheers, 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: openldap client GSSAPI authentication segfaults in fbsd8stable i386
On 14/7/2010 11:42 πμ, Reko Turja wrote: I have a problem: ldapsearch results in Segmentation fault under openldap-2.4.23 with cyrus-sasl-2.1.23 A thread for similar issues was started by George Mamalakis back in february: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html but I find no solution / conclusion from this thread, hence I post here... I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with freebsd-update, and ports updated with portsnap fetch update. Kerberos installed from packages, configured, and seems to work OK. I had similar issue with 8-RELEASE and cyrus-sasl2 with cyrus-saslauthd linked against system kerberos. (uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: Sat Jun 12 00:39:22 EEST 2010 r...@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386) The problem manifested itself with pretty much the same backtrace when using cyradm tool for administering cyrus mailboxes and due time constraints I solved my issue by removing all the gssapi plugin libs from /usr/local/lib/sasl2, so my solution isn't really applicable in your case. my /etc/hosts file for the server in question contains only localhost entry + entry for one IP so George's solution didnt help with my problem. /var/log/messages has: slapd[1146]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core dumped) The first message is from the LDAP server. Even if it has some problem, it should not lead the client to segfault. I agree. If I was to build a test box from scratch, can you tell me how to set up all the necessary software/etc. to mimic your environment so that I could try to reproduce this? Reviewing the source isn't enough, I'd have to actually build a debug version of libgssapi to track it down. Alternatively I can try to step you through how to debug this using gdb, but again, lack of debugging symbols makes this annoying. I'd say that based on present evidence there is something broken in gssapi/sasl interaction, but due my need of getting the server functional quickly I didn't dig much further in the issue myself, although I really don't know how to enable generating debugging symbols for ports either - Which was another reason for not digging deeper in the problem. I wonder if using dovecot-sasl would work with ldap and if it has the same issue as cyrus-sasl - athough it doesn't seem to be available as separate port. -Reko ___ 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 Hello guys, I am glad that somebody brought this issue back, since despite my last email regarding the same issue on 25/02/2010 saying that there must be something wrong with the function gss_release_buffer(void *a, void *b), the issue got forgotten. The problem would not persist in amd64, so I stopped looking it further myself. Whoever wants to see more information on this issue, search the subject field of this list for: openldap client GSSAPI authentication segfaults in fbsd8stable i386 I hope that a remedy to this issue will be yielded this 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: openldap client GSSAPI authentication segfaults in fbsd8stable i386
On 14/7/2010 12:32 μμ, Jeremy Chadwick wrote: On Wed, Jul 14, 2010 at 11:56:57AM +0300, George Mamalakis wrote: On 14/7/2010 11:42 πμ, Reko Turja wrote: I have a problem: ldapsearch results in Segmentation fault under openldap-2.4.23 with cyrus-sasl-2.1.23 A thread for similar issues was started by George Mamalakis back in february: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html but I find no solution / conclusion from this thread, hence I post here... I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with freebsd-update, and ports updated with portsnap fetch update. Kerberos installed from packages, configured, and seems to work OK. I had similar issue with 8-RELEASE and cyrus-sasl2 with cyrus-saslauthd linked against system kerberos. (uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: Sat Jun 12 00:39:22 EEST 2010 r...@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386) The problem manifested itself with pretty much the same backtrace when using cyradm tool for administering cyrus mailboxes and due time constraints I solved my issue by removing all the gssapi plugin libs from /usr/local/lib/sasl2, so my solution isn't really applicable in your case. my /etc/hosts file for the server in question contains only localhost entry + entry for one IP so George's solution didnt help with my problem. /var/log/messages has: slapd[1146]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core dumped) The first message is from the LDAP server. Even if it has some problem, it should not lead the client to segfault. I agree. If I was to build a test box from scratch, can you tell me how to set up all the necessary software/etc. to mimic your environment so that I could try to reproduce this? Reviewing the source isn't enough, I'd have to actually build a debug version of libgssapi to track it down. Alternatively I can try to step you through how to debug this using gdb, but again, lack of debugging symbols makes this annoying. I'd say that based on present evidence there is something broken in gssapi/sasl interaction, but due my need of getting the server functional quickly I didn't dig much further in the issue myself, although I really don't know how to enable generating debugging symbols for ports either - Which was another reason for not digging deeper in the problem. I wonder if using dovecot-sasl would work with ldap and if it has the same issue as cyrus-sasl - athough it doesn't seem to be available as separate port. -Reko Hello guys, I am glad that somebody brought this issue back, since despite my last email regarding the same issue on 25/02/2010 saying that there must be something wrong with the function gss_release_buffer(void *a, void *b), the issue got forgotten. The problem would not persist in amd64, so I stopped looking it further myself. Whoever wants to see more information on this issue, search the subject field of this list for: openldap client GSSAPI authentication segfaults in fbsd8stable i386 I hope that a remedy to this issue will be yielded this time. Like I said -- if someone can step me through setting everything up (configurations, whatever ports/packages need to be installed, etc.) to mimic their setup so that I can reproduce the problem, I'll put in the time to track it down. This would be on a dedicated/freshly installed machine (RELENG_8 running under VMware Workstation) to rule out any other oddities. It's the LDAP + any quirky GSSAPI or Cyrus stuff that I don't have experience with. Unfortunately I have no time this week. I will be able to look at it and send you a quick howto for openldap/cyrus/heimdal on Saturday. If somebody else is able to do it sooner, it would be great. Please, install it on i386 image, since amd64 didn't seem to have any problems on my installation (at least on February). Thank you for your time and effort. -- 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
mount_newnfs mount_nullfs problem.
Dear all, In short: If I export the filesystem /export/homes, and mount it through nfsv4 on a fbsd8-stable box in the folder /mnt, and then use mount_nullfs /mnt/ /path1/path2/path3, then I have the following-wrong behaviour. If I use vi /path1/path2/path3/mamalos/newfile to write a file, the file is saved in /path1/path2, instead (!!?!). Which is on my local filesystem tree. If I echo mytestfile /path1/path2/path3/mamalos/one, then the file is correctly written in /path1/path2/path3/mamalos/one. In my jail environment, I use a similar approach to that of freebsd-handbook for application jails (paragraph 15.6). So in my setup, mount command shows: solaris:/export/homes on /mnt (newnfs) /jails/j/mroot on /jails/j/postfix (nullfs, local, read-only) /jails/s/postfix on /jails/j/postfix/s (nullfs, local, read-only) /jails/t/postfix on /jails/j/postfix/t (nullfs, local) /mnt on /jails/j/postfix/t/home (nullfs) where we see my imported filesystem, the path where my postfix jail starts (/jails/j/postfix) along with two other filesystems mounted on it (/jails/j/postfix/s and /jails/j/postfix/t). On top of the latter's folder home I mount /mnt. If I jexec to that jail, and try to create a file using vi, then vi /home/mamalos/myfile is written in /jails/t/postfix (which is the same as /jails/j/postfix/t) What I suspect is that there must be a problem with nfs4 root-directory (which is two subfolders deep - /export/homes) and mount_nullfs. The thing is that information is finally stored in my local filesystem instead of the imported one, which is very strange... I will look to it more thoroughly, so as to provide more feedback about the issue. Hopefully, someone with more knowledge on the source code will find an answer. FBSD-box: # uname -a FreeBSD fbsd 8.0-STABLE FreeBSD 8.0-STABLE #2: Fri Feb 19 19:30:00 EET 2010 r...@filesrv.ee.auth.gr:/usr/obj/usr/src/sys/MYKERNEL amd64 # mount_newnfs -o nfsv4,rw solaris:/export/homes /mnt/ OpenSolaris: # uname -a SunOS opensolaris 5.11 snv_111b i86pc i386 i86pc Solaris # share -F nfs -o sec=sys,rw,ro...@192.168.100.12 /export/homes 192.168.100.12 where 192.168.100.12 is fbsd-box's IP. Thank you all. -- 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: openldap client GSSAPI authentication segfaults in fbsd8stable i386
On 11/02/2010 20:45, George Mamalakis wrote: 4: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2529638919 for mech unknown) which is very strange, since mech-code seems unnaturally large. This problem has been resolved. I had an issue with my /etc/hosts file, where the name of the ldap server could not be resolved correctly (via the gssapi library I assume), and openldap client gave me this reply (both ldap server and heimdal server had the same IP (two jails on the same host)). After changing the order in which the host and its IP appeared in /etc/hosts the problem stopped (which is still strange, since ldapwhoami -D 'blabla' -W worked ok, even with the old /etc/hosts). -- 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: openldap client GSSAPI authentication segfaults in fbsd8stable i386
To sum things up.
By fixing my /etc/hosts to read as it should (this needs some work too,
the behavior with the 'wrong' /etc/hosts is unexpected), ldapwhoami
works fine IF (AND ONLY IF) someone kinits to a user principal;
otherwise it segfaults. My default binding method is GSSAPI, hence the
segfault. If I use simple bind (ldapwhoami -W -D 'blabla') it works
fine. If I LD_PRELOAD the hacked library lala.so, which is created
like this:
lala.c:
int gss_release_buffer(void *a, void *b) {
return 0;
}
# gcc -c -fPIC -shared lala.c -o lala.so
and if I haven't obtained any kerberos tickets, then
# ldapwhoami
SASL/GSSAPI authentication started
Segmentation fault: 11 (core dumped)
once I ldpreload the above fake-library, then:
# LD_PRELOAD=./lala.so ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:
Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown)
which is what is expected.
This, maybe implies that something is freed by gss_release_buffer that
normally shouldn't.
amd64 won't hang in the same test (so no need to ld_preload anything),
but shares the same problem with i386 when /etc/hosts is not as expected
(to recreate the /etc/hosts problem, place in your /etc/hosts file two
fqdns for the ldap server's IP, but write the ldap server's fqdn second
in turn).
Thank you all and have a nice evening.
--
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: openldap client GSSAPI authentication segfaults in fbsd8stable i386
On 17/02/2010 12:39, George Mamalakis wrote: On 13/02/2010 00:23, George Mamalakis wrote: On 12/2/2010 8:48 πμ, jhell wrote: This is a lot of information to consume. Lets start with this: All of the machines in question are of some form of FreeBSD 8. You enter gdb and very clearly it starts whining about a segfault libc.so.7 Did you happen to upgrade these clients server from FreeBSD 7 ? AFAIK the libc version on FreeBSD 8 was bumped to libc.so.8 If you upgraded and from source did you run make delete-old and make delete-old-libs after your make install and after your mergemaster ? Will wait here for results. Best wishes. Guys(?!), anybody having taken a look at the issue or has an opinion/workaround whatsoever? Thanks again. mamalos I've setup a linux client with the latest arch linux, I installed openldap 2.4.21-2, cyrus-sasl 2.1.23-3 and cyrus-sasl-plugins 2.1.23-1 using pacman, I configured /etc/krb5.conf and /etc/openldap/ldap.conf to read the same as in my other boxes, and tested ldapwhoami before and after kiniting to mamalos, and everything worked alright. -- 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
mountd segfaults in NFSv4 if -alldirs is present in exports
Hi all, the title explains it all... But ok, let's be a bit more extensive. If I have one line in /etc/exports reading: V4: / -alldirs and try to start mountd, it segfaults with signal 11. From the manpage I read that -alldirs is the second method used to export a filesystem and V4 is the third, maybe implying that they are mutually exclusive. Nevertheless, I suppose that mountd shouldn't segfault in my case, it could just refuse to start giving an error message or something. I've tried a different /etc/exports containing a dummy option -dummy instead of -alldirs and mountd won't segfault, hence there's no problem with its parser. -- 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: mountd segfaults in NFSv4 if -alldirs is present in exports
On 19/02/2010 17:44, George Mamalakis wrote: Hi all, the title explains it all... But ok, let's be a bit more extensive. If I have one line in /etc/exports reading: V4: / -alldirs and try to start mountd, it segfaults with signal 11. From the manpage I read that -alldirs is the second method used to export a filesystem and V4 is the third, maybe implying that they are mutually exclusive. Nevertheless, I suppose that mountd shouldn't segfault in my case, it could just refuse to start giving an error message or something. I've tried a different /etc/exports containing a dummy option -dummy instead of -alldirs and mountd won't segfault, hence there's no problem with its parser. oops, forgotten system info: # uname -a FreeBSD lala 8.0-STABLE FreeBSD 8.0-STABLE #0: Fri Feb 19 11:45:56 EET 2010 r...@lala:/usr/obj/usr/src/sys/MAMALOPYRINO-NFS4 i386 my custom kernel has the follwoing differences from GENERIC: # diff GENERIC MAMALOPYRINO-NFS4 21,22c21,22 cpuI486_CPU cpuI586_CPU --- #cpuI486_CPU #cpuI586_CPU 24c24 identGENERIC --- identMAMALOPYRINO-NFS4 49c49,50 options NFSSERVER# Network Filesystem Server --- options NFSD# Network Filesystem Server #options NFSSERVER# Network Filesystem Server 332c333 devicefirewire# FireWire bus code --- #devicefirewire# FireWire bus code 334,337c335,338 devicefwe# Ethernet over FireWire (non-standard!) devicefwip# IP over FireWire (RFC 2734,3146) devicedcons# Dumb console driver devicedcons_crom# Configuration ROM for dcons --- #devicefwe# Ethernet over FireWire (non-standard!) #devicefwip# IP over FireWire (RFC 2734,3146) #devicedcons# Dumb console driver #devicedcons_crom# Configuration ROM for dcons Which means that I have all firewire commented out (since fbsd8 kernel panics on my msi gt627 otherwise, but that's another issue), and I have NFSD instead of NFSSERVER as an option. Cheers all. -- 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: mountd segfaults in NFSv4 if -alldirs is present in exports
On 19/02/2010 18:24, Rick Macklem wrote: On Fri, 19 Feb 2010, George Mamalakis wrote: Hi all, the title explains it all... But ok, let's be a bit more extensive. If I have one line in /etc/exports reading: V4: / -alldirs and try to start mountd, it segfaults with signal 11. From the manpage I read that -alldirs is the second method used to export a filesystem and V4 is the third, maybe implying that they are mutually exclusive. Nevertheless, I suppose that mountd shouldn't segfault in my case, it could just refuse to start giving an error message or something. I've tried a different /etc/exports containing a dummy option -dummy instead of -alldirs and mountd won't segfault, hence there's no problem with its parser. The V4: line does not export a file system. It only specifies where the root is for NFSv4 and what clients/security flavours are supported for the NFSv4 lock state Ops that aren't associated with any file handle is. (There can be multiple V4: lines for different hosts, but they should differ in their -sec specification and only that.) The file systems must still be exported by separate lines, just like NFSv2,3. It happens that -alldirs always applies to NFSv4, since it does not use the Mount protocol and can mount anything under the root that has been exported. As such, -sec plus the ones related to specifying host(s) -network, -mask are the only ones that should be in the V4: line(s). But, of course it shouldn't segfault. I'll put that on my to do list. Thanks for reporting it, rick Yes Rick, I understood that there was something wrong with my syntax but I wouldn't expect a segfault, as you already have stated :). Moreover, this is the problem that I was facing in one of my previous emails with the title Kerberized NFSv3 incorrect behavior. In my last email to you I was claiming that mountd segfaults when both NFSD and KGSSAPI (along with device crypto) exist in the kernel config file. You replied to me that you would have it fixed. Now I understood that the problem had nothing to do with KGSSAPI, my problem was my /etc/exports file that contained -alldirs in V4 line. So no need to check if there's a conflict with KGSSAPI, there isn't :). Now, two last questions. question 1) I want to export my /export directory with -sec=krb5 to my clients, and the configuration of my server and client is respectively as follows: - server: /etc/exports: V4: / -sec=krb5 /export /etc/rc.conf rpcbind_enable=YES mountd_flags=-e nfs_server_enable=YES nfsv4_server_enable=YES nfsuserd_enable=YES gssd_enable=YES KERNEL: options NFSD options KGSSAPI device crypto -client: rc.conf: gssd_enable=YES nfsuserd_enable=YES nfsclient_enable=YES rpcbind_enable=YES nfs_client_flags=-n 4 rpc_statd_enable=YES rpc_lockd_enable=YES KERNEL: options KGSSAPI device crypto As I said, heimdal seems to work fine, all keytabs are where they should be, and I don't know how to mount the partition to my client. When I run: [r...@fbsdclient ~]# mount_newnfs -onfsv4,sec=krb5 filesrv.ee.auth.gr:/export /mnt nfsv4 err=10016 mount_newnfs: /mnt, : Input/output error An I/O error I receive if I use opensolaris as a client. The kdc.log shows that the clients request the nfs server's ticket (2010-02-19T19:56:29 TGS-REQ mama...@ee.auth.gr from IPv4:192.168.100.11 for nfs/filesrv.ee.auth...@ee.auth.gr), so things should be working that far, but then they refuse to mount the partition. If I export the partition with sec=sys and try to mount it with sec=sys, it works fine. question 2) At the end of nfsv4(4) man page (in the BUGS session) it states: At this time, there is no recall of delegations for local file system operations. As such, delegations should only be enabled for file systems that are being used soley as NFS export volumes and are not being accessed via local system calls nor services such as Samba. Does this mean that if I manage to export my /home filesystem eventually, and my mailserver copies the emails to my users' maildirs (located in their home folder), or through another nfs mount, or a user is connected to his/her account both through nfsv4 and samba, then there will be a serious problem? Should I setup the nfs server in solaris and use bsd/linux nfs4 clients instead, to be sure that I will have no corrupted filesystems, etc? Have you tried mounting solaris-nfsv4 exported filesystems with the fbsd nfsclient and sec=krb5? Thanx again for your help and attention. 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
Re: mountd segfaults in NFSv4 if -alldirs is present in exports
On 19/02/2010 20:11, George Mamalakis wrote: [r...@fbsdclient ~]# mount_newnfs -onfsv4,sec=krb5 filesrv.ee.auth.gr:/export /mnt nfsv4 err=10016 mount_newnfs: /mnt, : Input/output error I performed some more test on this setup and I can shed a bit more light to the issue. My /etc/export on my server (filesrv.ee.auth.gr) reads: V4: / -sec=krb5 /home If I run: # mount_newnfs -onfsv4,sec=krb5 filesrv.ee.auth.gr:/home /mnt as root, without having kinited to some principal, the partition gets mounted in /mnt and I can perform operations on it. Once I kinit to some user I get the error: nfsv4 err=10016 Then, I read the article on http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup a bit more thoroughly (with regard to nfsv4), and changed /etc/fstab to read: V4: / -sec=krb5 /home -sec=krb5 I restarted nfsd and mountd, switched to a simple user (mamalos), kinited as mamalos principal, and typed: [mama...@fbsdclient ~]$ mount_newnfs -onfsv4,sec=krb5 filesrv.ee.auth.gr:/home mnt where mnt is a directory in mamalos' homefolder owned by that user. Of course, one has to run sysctl vfs.usermount=1 in order to allow simple users to mount filesystems (as was already suggested by the aforementioned article). This time the mount worked! I ls'd the directory, cd'd to a folder owned by mamalos (permissions 700), even touched a file in it. The only problem was that the first time I touched a file, it took a few seconds for the touch command to complete. After that, all subsequent touch commands were executed immediately. So, for the time being, mounting nfsv4 partitions with sec=krb5 has been established, but with a few limitations. I'll test now what can be done with solaris and linux clients. Good night everybody (~GMT+2). -- 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: openldap client GSSAPI authentication segfaults in fbsd8stable i386
On 13/02/2010 00:23, George Mamalakis wrote: On 12/2/2010 8:48 πμ, jhell wrote: This is a lot of information to consume. Lets start with this: All of the machines in question are of some form of FreeBSD 8. You enter gdb and very clearly it starts whining about a segfault libc.so.7 Did you happen to upgrade these clients server from FreeBSD 7 ? AFAIK the libc version on FreeBSD 8 was bumped to libc.so.8 If you upgraded and from source did you run make delete-old and make delete-old-libs after your make install and after your mergemaster ? Will wait here for results. Best wishes. Guys(?!), anybody having taken a look at the issue or has an opinion/workaround whatsoever? Thanks again. 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: openldap client GSSAPI authentication segfaults in fbsd8stable i386
On 12/2/2010 8:48 πμ, jhell wrote: This is a lot of information to consume. Lets start with this: All of the machines in question are of some form of FreeBSD 8. You enter gdb and very clearly it starts whining about a segfault libc.so.7 Did you happen to upgrade these clients server from FreeBSD 7 ? AFAIK the libc version on FreeBSD 8 was bumped to libc.so.8 If you upgraded and from source did you run make delete-old and make delete-old-libs after your make install and after your mergemaster ? Will wait here for results. Best wishes. jhel, None of my machines is upgraded from fbsd7. As I stated in my previous email, two of them are built from January's snapshot (no updates/upgrades); My gdb example is running on one of these machines. Nevertheless, on all machines that segfault, the outcome of gdb is the same. The rest machines are built either from fbsd8-release and upgraded to the latest stable sources, except from my laptop which was installed from fbsd8-beta1 and has been upgraded frequently since then. Its current binaries are built from January's 25 sources. Either way, since you asked, I always use make delete-old and make delete-old-libs when upgrading. Lastly, to make a long story short, what I want everybody to keep from my latest email is that 32bit and 64bit behave differently. 32bit segfaults, but not always..and it definately behaves differently when built on vmware esxi4 then when built on virtual box. Then again, amd64, on the same esxi host works correctly in only one of the two machines. Lastly, I want someone who knows more about the sources in question than I do, to see what gdb shows, and that after the little hack we made, instead of a segfault we got the same strange behavior as that of the brokent amd64 box. Cheers once more. mamalos ___ 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
openldap client GSSAPI authentication segfaults in fbsd8stable i386
)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...SASL/GSSAPI authentication started
Program received signal SIGSEGV, Segmentation fault.
0x2831e187 in free () from /lib/libc.so.7
(gdb) where
#0 0x2831e187 in free () from /lib/libc.so.7
#1 0x2850fb82 in gss_release_buffer () from /usr/lib/libgssapi.so.10
#2 0x2850f552 in gss_release_name () from /usr/lib/libgssapi.so.10
#3 0x2850bea9 in gss_init_sec_context () from /usr/lib/libgssapi.so.10
#4 0x283f9abf in gssapi_client_mech_step () from
/usr/local/lib/sasl2/libgssapiv2.so.2
#5 0x280e84b1 in sasl_client_step () from /usr/local/lib/libsasl2.so.2
#6 0x28443100 in ?? ()
#7 0x in ?? ()
#8 0x in ?? ()
#9 0xbfbfe968 in ?? ()
#10 0xbfbfe954 in ?? ()
#11 0xbfbfe964 in ?? ()
#12 0x28445860 in ?? ()
#13 0x280e83fe in sasl_client_step () from /usr/local/lib/libsasl2.so.2
#14 0xbfbfe8a8 in ?? ()
#15 0x280e9135 in sasl_client_start () from /usr/local/lib/libsasl2.so.2
#16 0x in ?? ()
#17 0x in ?? ()
#18 0xbfbfe968 in ?? ()
#19 0xbfbfe954 in ?? ()
#20 0xbfbfe964 in ?? ()
#21 0xd7a3b2da in ?? ()
#22 0x283abad8 in ?? () from /lib/libc.so.7
#23 0x in ?? ()
#24 0x283ab730 in __stderrp () from /lib/libc.so.7
#25 0xbfbfe878 in ?? ()
#26 0x2838c764 in vfprintf () from /lib/libc.so.7
Previous frame inner to this frame (corrupt stack?)
I built openldap and cyrus-sasl on this machine from sources (not
ports), and (after a long time of trying to find out how to run
configure successfully in both installations) the outcome was exactly
the same (meaning segfaults). So, one of my admins wrote a c program
that overrides gss_release_buffer returning always 0 (what is expected
after normal operation) and compiled it as a library. The program code
is nothing more than just:
int gss_release_buffer(void *a, void *b) {
return 0;
}
we ld_preloaded the library, and when we ran ldapwhoami the outcome was:
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:
Miscellaneous failure (see text) (unknown mech-code 2529638919 for mech
unknown)
When we ran it with no kerberos tickets, we got:
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:
Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown)
The exact same errors as the aforementioned client 4 (esxi,
amd64)!
What on earth is happening?!?!!?!?!
Now one can easily see that there is a definite problem regarding memory
freeing, and after overcoming that the mech-code 2529638919 implies that
some segment in memory is overwritten by some random value, so
mech-code returns the number 2529638919 instead of a number of
marginality 1.
What is more definite, is that openldap doesn't work out-of-the-box if
gssapi support is required, and behaves randomly in different
architectures/virtualHosts/platforms.
The problem may have been something related to line 96 in
/usr/bin/krb5-config... I don't know.
What is sure, is that I am having second thoughts on using fbsd as my
openldap/heimdal server for my setup, which would be quite disappointing
for me, since I am using fbsd for the last many-many years, on all my
laptops and servers. The only good part is that the only machine that
works seamlessly (until now, at least) is the heimdal/ldap server.
Thank you all in advance and I hope that we will find an answer to all this.
--
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
A more secure approach of jail establishment. It could be included in jail chapter of fbsd handbook
In my setup I have three jails: ldap, heimdal and bind. mroot is monted in each jail's root folder, and the s and t directories of each jail are null_mounted on each jail's s and t folder respectively. I introduced another folder, /jails/manage which has the analogous usage to /jails/j folder, only this folder's subfolders are not used as jails. I chroot to each folder when I want to have write access on it's corresponding jail, and I can perform all my administrative operations (if you notice, even mroot is mounted rw in this chroot, so changes in base disto can be performed - eg when installing perl where you are asked to change /usr/bin/perl). This is the reason why I mount devfs on these chroots. As a result, with this setup, only /var and /tmp are mounted rw in each jail, and all other filesystems are mounted ro. Management (meaning jobs that require write access, not starting and/or stopping services) is achieved by chrooting to each jail's corresponding chroot. I am working with this setup for more than 4 months without having any problems; I thought that I could propose it as another paragraph in chapter 15.6 of freebsd handbook, as an even more secure jail setup, instead of just publishing it to some blog,forum,etc. Thank you all 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: A more secure approach of jail establishment. It could be included in jail chapter of fbsd handbook
On 10/02/2010 15:10, Igor Mozolevsky wrote: alling a full blown OS inside their jails? You do know that it is possible to have a jail with a single program inside and not much els Yes I do, but still in my configs I may need much more than just one program running in my jails, so I prefer the almost-full-OS option. Moreover, I find it also easier to maintain and troubleshoot, no matter how peculiar this may sound, since I don't have to chose only the files needed in each jail when I upgrade them, and I am able to run terminals in the jail, along with other which makes troubleshooting the jail easier. Of course, this is just my opinion and I think it is more of a matter of taste on how someone would want to setup their jails. Thank you for your answer. -- 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: Kerberized NFSv3 incorrect behavior
On 08/02/2010 00:34, Rick Macklem wrote: On Sat, 6 Feb 2010, George Mamalakis wrote: thank you for all your answers. I am planning on setting up the computer labs of my department using kerberized nfsv3 (since v4 seems to be more experimental) with a FreeBSD nfs server and Linux nfs clients. I was wondering how stable such an implementation would be; meaning that I wouldn't want to end up with an unstsable setup when receiving requests from 50-60 simultaneous clients, because that would be my everyday scenario. I believe that the above should be stable, but your mileage may vary, as they say. The main issue will be what your TGT lifetime will be, since client access to the server will normally stop when the TGT expires. Some systems (Mac OS X) will automagically renew the TGT before it expires, if your KDC allows that. I don't think most/all Linux systems do this by default, but there are some utilities out there (try a search for krenew) that will do so. I think that this I can be overcome with a default timeout option in my shell variables (at least for the 'pilot phase'). Basically, I think you'll want to avoid TGTs expiring before the user logs out. You also need a unique uid-user principal mapping for all users logging in. I am planning on using LDAP as my backend with kerberos attributes (I have already setup my ldap like that). To be honest, I have done something funny. My heimdal's backend is openldap; this LDAP is only for heimdal access (inside a jail). Then, I have another jail which serves its openldap instance to all my clients. This ldap (which stores a totally different DIT then heimdal's LDAP) is kerberized (it uses gssapi authentication via cyrus-sasl), using the heimdal jail. It's a bit dramatic, but it seems to work fine-until now-, it seems quite secure, and allows me to synchronize the heimdal backend easily through openldap replication. Moreover, keeping the user credentials in ldap helps for having a generic user/password store for other services I use (like samba, (for my windows hosts)). So, I use a different ldap attribute for samba-semantics and another ldap attribute for kerberos. Lastly, openldap caters for storing uids,gids,home_folder_locations,etc for my users, where my clients have access to this information via their respective nsswitch.conf files. I think that this answers your question regarding uid-user principal mapping, unless I misunderstood something. You definitely want to do some testing with whatever Linux system you are using for the client. Good luck with it, rick ps: Choosing nfsv3 vs nfsv4 is basically independent of using RPCSEC_GSS except for the host based initiator credential needed by some clients (Linux and Solaris10 are among those) for NFSv4. To tell you the truth, when I recompiled my kernel with: options NFSD options KGSSAPI device crypto to setup an nvsv4 server, nfsd refused to start because mountd was segfaulting. I didn't play much with this setup, because I was in a hurry, so I commented out NFSD and put back NFSSERVER, to be able to test my server. Now a last question: Does gssapi/nfs setup work with the automounter (bsd/linux nfs-client)? Thanx again for your answer. -- 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: Kerberized NFSv3 incorrect behavior
Rick Macklem wrote: 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 considered unacceptable for FreeBSD-current etc.) Hope that clarifies things, rick
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
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: MSI GT 627 unsuccessful installation in 7-STABLE and 8-BETA4
Manolis Kiagias wrote: George Mamalakis wrote: Dear all, My question should maybe have be sent to some other fbsd list; if so, please someone instruct me where, and excuse me for my potential mistake. Now to my question: I just bought the MSI GT 627 Laptop, and I tried to install FreeBSD on it. First I tried with 8-BETA4 amd, then with 8-BETA4 i386, and lastly with 7.2 latest snapshot. All attempts have been unsuccessful, so I tried NetBSD 5.0.1 to see if it would install, and it did! The kernel messages I got on all FOUR attempts (even in NetBSD, although it worked finally) was something like that (in the beginning) (NetBSD excerpt, since it is the only that booted, so I could copy-paste it from dmesg, but FreeBSD gave the exact same Error messages (a few numbers differ)): Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 00:08:07 UTC 2009 bui...@b7.netbsd.org:/home/builds/ab/netbsd-5-0-1-RELEASE/amd64/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/amd64/compile/GENERIC total memory = 4095 MB avail memory = 3954 MB timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter i8254 frequency 1193182 Hz quality 100 SMBIOS rev. 2.5 @ 0x9a400 (45 entries) Micro-Star International GT627 (Ver 1.000) mainbus0 (root) cpu0 at mainbus0 apid 0: Intel 686-class, 2394MHz, id 0x1067a cpu1 at mainbus0 apid 1: Intel 686-class, 2394MHz, id 0x1067a cpu2 at mainbus0 apid 2: Intel 686-class, 2394MHz, id 0x1067a cpu3 at mainbus0 apid 3: Intel 686-class, 2394MHz, id 0x1067a ioapic0 at mainbus0 apid 4: pa 0xfec0, version 20, 24 pins acpi0 at mainbus0: Intel ACPICA 20080321 acpi0: X/RSDT: OemId MSI_NB,MEGABOOK,20090407, AslId MSFT,0097 ACPI Error (evregion-0427): No handler for Region [EC__] (0x87e20400) [EmbeddedControl] [20080321] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20080321] ACPI Error (psparse-0627): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0x87e23760), AE_NOT_EXIST ACPI Error (uteval-0306): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0x87e23760), AE_NOT_EXIST acpi0: SCI interrupting at int 9 acpi0: fixed-feature power button present timecounter: Timecounter ACPI-Fast frequency 3579545 Hz quality 1000 ACPI-Fast 24-bit timer ACPI Error (evregion-0427): No handler for Region [EC__] (0x87e20400) [EmbeddedControl] [20080321] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20080321] ACPI Error (psparse-0627): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0x87e23760), AE_NOT_EXIST ACPI Error (uteval-0306): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0x87e23760), AE_NOT_EXIST WMI1 (pnp0c14) at acpi0 not configured where fbsd differed, was somewhere after identifying ad4 (the disk, which is WDC WD5000BEVT-22ZAT0 01.01A1), where it stated: acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config and after that it kept on repeating the last message, only increasing the seconds to wait, until nothing more happened. Does anyone know if this is something that will be fixed soon? I guess it has to do with MSI's ACPI or something like that. Thank you all for your interest. Regards, mamalos. Is the laptop equipped with a firewire port? I have a few Gigabyte 8IPE1000-G motherboards at school that exhibit the exact same behaviour. (Using 7.X, have not tried with 8.0 yet). Although the motherboard does not in fact have a firewire chip soldered on, the BIOS presents a firewire device (in Windows it shows in the device manager as a non-working, unknown problem device) and I believe this confuses the FreeBSD boot sequence. Other people on the lists have also suggested disabling device sbp in a custom kernel configuration file (or even removing the entire firewire section if you don't need it). One possible first step would be to try disabling firewire in the BIOS (Sadly I don't have this option at all in my case) and see if the boot continues. If you install successfully you may then try building a custom kernel and re-enabling the BIOS option. ___ 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 Manoli, I built current in another machine's folder, addressed my laptop to boot from lan having this folder as it's nfsroot, and even then I kept having the problem. Then I compiled a kernel without firewire
Base system's Heimdal with Openldap support?
Hi all, I was wondering if there is a way to build fbsd's basesystem heimdal with openldap support. I saw that /usr/src/kerberos5/Makefile.inc has a section starting with .if defined(WITH_OPENLDAP), so I built the world with the flag -DWITH_OPENLDAP. What I managed was to link the kdc binary with my system's openldap libraries, but no openldap code was compiled in the binary. ( kdc --builtin-hdb didn't return ldap) How could I achieve this with the base system's heimdal, without *hacking* the /usr/src/crypt/heimdal/configure* files? (the port's heimdal distribution gets configured with openldap backend) In case I have sent this question in the wrong list, please somebody inform me so. Thank you all in advance. -- 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: SASL problems with spnego on 8.0-BETA4
John Marshall wrote: On Sat, 19 Sep 2009, 09:31 +1000, John Marshall wrote: On Fri, 18 Sep 2009, 17:38 -0400, Rick Macklem wrote: When cyrus-sasl2 builds, it uses the little shell script /usr/bin/krb5-config with the args. --libs gssapi to get the list of libraries to link against. This doesn't return -lgssapi_spnego in the list. (The list can be changed by editting line #96 of /usr/bin/krb5-config.) I think this sounds promising! It makes sense. Thanks for pointing us in this direction. This morning, on my 8.0-RC1 system, I did the following to confirm that GSSAPI authentication to the LDAP server via SASL2 using the base Heimdal was still broken: - removed the heimdal-1.2.1 port - rebuilt the cyrus-sasl-2.1.23 port (against the base heimdal) - started the openldap-sasl-server-2.4.18_1 - queried the LDAP server from a separate client using ldapsearch: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) - and noted that the ldap server died at that point. I edited line 96 of /usr/bin/krb5-config to include -lgssapi_krb5 in the libraries list: lib_flags=$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm and then did the following: - rebuilt the cyrus-sasl-2.1.23 port (against the base heimdal) - started the openldap-sasl-server-2.4.18_1 - queried the LDAP server from a separate client using ldapsearch SASL/GSSAPI authentication started SASL username: j...@example.com SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 SUCCESS! So, this fix obviates THAT reason for installing the Heimdal port. If George meets with similar success adding -lgssapi_spnego for his spnego problem, I suggest that both libraries be added to the list in line 96 of /usr/bin/krb5-config prior to release of FreeBSD 8.0. It doesn't look like this fix is as simple as submitting a patch to krb5-config. It looks like magic needs to happen somewhere in the base kerberos build system. I notice that the Heimdal port doesn't build the separate libraries and everything seems to be included in libgssapi (which explains why sasl2 works when linked against the Heimdal port). Guys, I changed my /usr/bin/krb5-config's line 96 to include -lgssapi_spnego and -lgssapi_krb5, and ever since both client and server work correctly!! Of course I get some other error, but at least this must be a configuration error :). So, to sum up: Still running on fbsd.8-BETA4, changed krb5-config to include the missing libraries, recompiled cyrus-sasl-2.1.23 after I changed the krb5-config, restarted openldap-sasl-server-2.4.18_1 and after performing an ldapsearch, the client does not complain (and exits) about missing libraries, NOR does the server crash on sasl authentication. Great job guys, thank you all very very much for your help! I posted my query on the 17th of Sep. and in four days (weekend inclusive!) someone came up with an answer that resolves my issue! Great job, once more, and thank you all again! -- 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
SASL problems with spnego, heimdal, AND openldap on 8.0-BETA4
Dear all,
I changed the subject of my email, due to today's results on my
configurations, regarding SASL authentication on
openldap-sasl-server-2.4.18_1, with cyrus-sasl-2.1.23, and fbsd's
8-BETA4 heimdal. When I try to ldapsearch from another machine to the
openldap server, slapd hangs!
The client goes like that:
(
client-host$ ldapsearch -d 255 -H ldap://ldap.example.com -b
'dc=example,dc=com'
ldap_url_parse_ext(ldap://ldap.example.com)
ldap_create
ldap_url_parse_ext(ldap://ldap.example.com:389/??base)
ldap_sasl_interactive_bind_s: user selected: GSSAPI
ldap_int_sasl_bind: GSSAPI
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.example.com:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 1.2.3.4:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_int_sasl_open: host=ldap.example.com
SASL/GSSAPI authentication started
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x34142000 ptr=0x34142000 end=0x341422b4 len=692
: 30 82 02 b0 02 01 01 60 82 02 a9 02 01 03 04 00
0..`
0010: a3 82 02 a0 04 06 47 53 53 41 50 49 04 82 02 94
..GSSAPI
0020: 60 82 02 90 06 09 2a 86 48 86 f7 12 01 02 02 01
`.*.H...
0030: 00 6e 82 02 7f 30 82 02 7b a0 03 02 01 05 a1 03
.n...0..{...
. packet infrormation.
ber_scanf fmt ({i) ber:
ber_dump: buf=0x34142000 ptr=0x34142007 end=0x341422b4 len=685
: 60 82 02 a9 02 01 03 04 00 a3 82 02 a0 04 06 47
`..G
0010: 53 53 41 50 49 04 82 02 94 60 82 02 90 06 09 2a
SSAPI`.*
0020: 86 48 86 f7 12 01 02 02 01 00 6e 82 02 7f 30 82
.Hn...0.
. more packet infrormation.
ber_flush2: 692 bytes to sd 3
: 30 82 02 b0 02 01 01 60 82 02 a9 02 01 03 04 00
0..`
0010: a3 82 02 a0 04 06 47 53 53 41 50 49 04 82 02 94
..GSSAPI
0020: 60 82 02 90 06 09 2a 86 48 86 f7 12 01 02 02 01
`.*.H...
. even more packet infrormation.
ldap_write: want=692, written=692
: 30 82 02 b0 02 01 01 60 82 02 a9 02 01 03 04 00
0..`
0010: a3 82 02 a0 04 06 47 53 53 41 50 49 04 82 02 94
..GSSAPI
. even even more packet infrormation
ldap_result ld 0x34124040 msgid 1
wait4msg ld 0x34124040 msgid 1 (infinite timeout)
wait4msg continue ld 0x34124040 msgid 1 all 1
** ld 0x34124040 Connections:
* host: ldap.example.com port: 389 (default)
refcnt: 2 status: Connected
last used: Fri Sep 18 11:02:10 2009
** ld 0x34124040 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x34124040 request count 1 (abandoned 0)
** ld 0x34124040 Response Queue:
Empty
ld 0x34124040 response count 0
ldap_chkResponseList ld 0x34124040 msgid 1 all 1
ldap_chkResponseList returns ld 0x34124040 NULL
ldap_int_select
read1msg: ld 0x34124040 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=0
ber_get_next failed.
ldap_free_connection 1 0
ldap_free_connection: actually freed
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
)
And this is where it loses connection. From the server's point of view,
the only thing I get from the logs (loglevel args config stats) is:
Sep 18 11:02:08 ldap slapd[2257]: conn=1 fd=13 ACCEPT from
IP=1.2.3.5:50345 (IP=0.0.0.0:389)
Sep 18 11:02:08 ldap slapd[2257]: connection_get(13)
Sep 18 11:02:08 ldap slapd[2257]: conn=1 op=0 BIND dn= method=163
Sep 18 11:02:08 ldap slapd[2257]: == sasl_bind: dn= mech=GSSAPI
datalen=660
And after that the server is down..
I don't know what to do, I'll try to update heimdal to version 1.2.1, as
John Marshall advised me in his last email..
If anyone knows anything more, I would be delighted if he could share it
on this list.
Thanx again for reading.
--
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: SASL problems with spnego on 8.0-BETA4
John Marshall wrote: On Thu, 17 Sep 2009, 21:28 +0300, George Mamalakis wrote: Dear all, I am trying to setup ldap with heimdal on my fbsd 8.0-BETA4 and when I run ldapsearch to see if I can authenticate via GSSAPI I keep getting the following error: [r...@ldap root]# ldapsearch -H ldap://ldap.example.com/; -b dc=example,dc=com SASL/GSSAPI authentication started dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol GSS_C_NT_HOSTBASED_SERVICE ldap_sasl_interactive_bind_s: Local error (-2) in ldap.conf (loglevel args stats) I am getting: Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 ACCEPT from IP=192.168.35.10:32598 (IP=0.0.0.0:389) Sep 17 21:24:46 ldap slapd[44607]: connection_get(13) Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 closed (connection lost) The ports I installed are: cyrus-sasl-2.1.23 openldap-sasl-client-2.4.18 openldap-sasl-server-2.4.18_1 I cannot resolve this issue, so if anyone knows anything, I would be grateful if I could have a hint. Thank you all for your time in advance. I don't remember if the symptoms I saw were identical, but I couldn't use GSSAPI to authenticate to OpenLDAP on 8.0-BETA2. I solved my problem by installing a newer Heimdal as a port and then rebuilding SASL2 against the newer Heimdal. NB. To build security/cyrus-sasl2 against the Heimdal port, I added the following line to my /usr/local/etc/ports.conf (see: ports-mgmt/portconf) security/cyrus-sasl2: HEIMDAL_HOME=/usr/local FreeBSD 8.0 includes Heimdal 1.1.0 in the base system. The Heimdal port is older (1.0.1). The heimdal-1.2.1 port patch I used was submitted to GNATS a couple of hours ago. No response from GNATS yet but it should be available there sometime soon. John, thank you for your answer, first of all. Now to your email: Could you please send me the location from where you downloaded the heimdal-1.2.1 ? I would really appreciate it if you could send it to me to test it on my machine so as to proceed with my configuration. Thank you for your time in advance. -- 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
SASL problems with spnego on 8.0-BETA4
Dear all, I am trying to setup ldap with heimdal on my fbsd 8.0-BETA4 and when I run ldapsearch to see if I can authenticate via GSSAPI I keep getting the following error: [r...@ldap root]# ldapsearch -H ldap://ldap.example.com/; -b dc=example,dc=com SASL/GSSAPI authentication started dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol GSS_C_NT_HOSTBASED_SERVICE ldap_sasl_interactive_bind_s: Local error (-2) in ldap.conf (loglevel args stats) I am getting: Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 ACCEPT from IP=192.168.35.10:32598 (IP=0.0.0.0:389) Sep 17 21:24:46 ldap slapd[44607]: connection_get(13) Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 closed (connection lost) The ports I installed are: cyrus-sasl-2.1.23 openldap-sasl-client-2.4.18 openldap-sasl-server-2.4.18_1 I cannot resolve this issue, so if anyone knows anything, I would be grateful if I could have a hint. Thank you all for your time in advance. -- 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.0-BETA4 IBM ServerRaid 8k issues
Artis, and the rest of the guys, thank you all for your answers. Ivan, I was thinking of using one of the techniques you mention (create two volumes, install fbsd on one of them, and use GTP on the second drive), but I was wondering if there would be any incompatibility issues with tools like df, etc. Artis, let me get to your comments now: Same problem here, thought we got timeouts also on idle boxes. IBM support told to switch controller channel speed from auto(3Gbps) to 1.5Gbps and update ServeRaid firmware. We are currently running 5.2.0-15429 (flashing them almost monthly :) ). You can change speed in raid bios, in Ctrl-A menu. But this issue is only with sata disks, sas works perfectly. In case I do this (since I only have sata drives), will I end up with degraded disk performance? Theoretically I assume not, since 1.5 Gbps is adequate for *each* disk (it calculates to something like ~178MBps); but have you tried it on your disks, and everything works OK since (along with performance)? Thank you all again for your answers, you've been truly helpful! -- 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
MSI GT 627 unsuccessful installation in 7-STABLE and 8-BETA4
Dear all, My question should maybe have be sent to some other fbsd list; if so, please someone instruct me where, and excuse me for my potential mistake. Now to my question: I just bought the MSI GT 627 Laptop, and I tried to install FreeBSD on it. First I tried with 8-BETA4 amd, then with 8-BETA4 i386, and lastly with 7.2 latest snapshot. All attempts have been unsuccessful, so I tried NetBSD 5.0.1 to see if it would install, and it did! The kernel messages I got on all FOUR attempts (even in NetBSD, although it worked finally) was something like that (in the beginning) (NetBSD excerpt, since it is the only that booted, so I could copy-paste it from dmesg, but FreeBSD gave the exact same Error messages (a few numbers differ)): Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 00:08:07 UTC 2009 bui...@b7.netbsd.org:/home/builds/ab/netbsd-5-0-1-RELEASE/amd64/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/amd64/compile/GENERIC total memory = 4095 MB avail memory = 3954 MB timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter i8254 frequency 1193182 Hz quality 100 SMBIOS rev. 2.5 @ 0x9a400 (45 entries) Micro-Star International GT627 (Ver 1.000) mainbus0 (root) cpu0 at mainbus0 apid 0: Intel 686-class, 2394MHz, id 0x1067a cpu1 at mainbus0 apid 1: Intel 686-class, 2394MHz, id 0x1067a cpu2 at mainbus0 apid 2: Intel 686-class, 2394MHz, id 0x1067a cpu3 at mainbus0 apid 3: Intel 686-class, 2394MHz, id 0x1067a ioapic0 at mainbus0 apid 4: pa 0xfec0, version 20, 24 pins acpi0 at mainbus0: Intel ACPICA 20080321 acpi0: X/RSDT: OemId MSI_NB,MEGABOOK,20090407, AslId MSFT,0097 ACPI Error (evregion-0427): No handler for Region [EC__] (0x87e20400) [EmbeddedControl] [20080321] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20080321] ACPI Error (psparse-0627): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0x87e23760), AE_NOT_EXIST ACPI Error (uteval-0306): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0x87e23760), AE_NOT_EXIST acpi0: SCI interrupting at int 9 acpi0: fixed-feature power button present timecounter: Timecounter ACPI-Fast frequency 3579545 Hz quality 1000 ACPI-Fast 24-bit timer ACPI Error (evregion-0427): No handler for Region [EC__] (0x87e20400) [EmbeddedControl] [20080321] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20080321] ACPI Error (psparse-0627): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0x87e23760), AE_NOT_EXIST ACPI Error (uteval-0306): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0x87e23760), AE_NOT_EXIST WMI1 (pnp0c14) at acpi0 not configured where fbsd differed, was somewhere after identifying ad4 (the disk, which is WDC WD5000BEVT-22ZAT0 01.01A1), where it stated: acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config and after that it kept on repeating the last message, only increasing the seconds to wait, until nothing more happened. Does anyone know if this is something that will be fixed soon? I guess it has to do with MSI's ACPI or something like that. Thank you all for your interest. 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
FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
Hello everybody, Yesterday I installed FreeBSD 8.0-BETA4 on an IBM 3650, having a ServerRaid 8k adapter, and 6 sata disks on raid-6. The raid-6 volume was synchronizing for a day, so this syncing process was happening while I was installing fbsd on the server. During the installation I was understanding that (writing) performance was low, but this was rational, considering the fact that the raid controller had to synchronize its disks. After the system got installed, and while the controller was still syncing, I ran portsnap fetch extract to get the latest ports. During this process, all my terminals kept lagging when I was opening files, browsing directories, etc, and the following kernel message appeared in dmesg: lock order reversal: 1st 0xff807c133540 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 2nd 0xff0003deb200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_makeinode() at ufs_makeinode+0x2a7 VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x468 kern_openat() at kern_openat+0x179 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp = 0x7fffe688, rbp = 0x1a4 --- lock order reversal: 1st 0xff00352cbd80 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 2nd 0xff807c133540 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6177 3rd 0xff00352cbba8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b vfs_hash_get() at vfs_hash_get+0xd5 ffs_vgetf() at ffs_vgetf+0x48 softdep_sync_metadata() at softdep_sync_metadata+0x456 ffs_syncvnode() at ffs_syncvnode+0x210 ffs_fsync() at ffs_fsync+0x43 ufs_direnter() at ufs_direnter+0x315 ufs_makeinode() at ufs_makeinode+0x2a7 VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x468 kern_openat() at kern_openat+0x179 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp = 0x7fffe688, rbp = 0x1a4 --- aac0: COMMAND 0xff80003e08a0 TIMEOUT AFTER 40 SECONDS aac0: COMMAND 0xff80003d5070 TIMEOUT AFTER 40 SECONDS aac0: COMMAND 0xff80003e0d00 TIMEOUT AFTER 40 SECONDS aac0: COMMAND 0xff80003d9440 TIMEOUT AFTER 40 SECONDS ...and kept on like that, for many many lines, with decreasing timeouts. Once the syncing process stopped, everything came back to normal (not that I have stress-tested the machine, to be honest...). But since it happened once, during this specific procedure, then maybe it could also happen when the raid controller is reconstructing its volumes; and this would be very annoying, as far as the server's efficiency (and/or maybe stability) is concerned. The kernel is GENERIC-amd64 and untouched, if someone may need more information (eg, dmesg output) please do not hesitate to say so. Thank you all for your time in advance, 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: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
Ivan, thank you very much for answering; and now to your comments: 3650 M1 or M2? On the box it writes x3650 (I forgot the initial 'x' before, sorry). You have received this message because you are running a debug kernel; a normal kernel with debugging disabled would not have shown it. So far, I understood :) It looks like the controller was too busy rebuilding to take any new requests. It is possible you have filled the controller's write cache and that is why the lag happened at this point. You can easily test this theory. This is the exact reason why I am asking this question. If this behavior is normal, then there is no problem with me. But I couldn't be sure whether it was a driver's problem or a controller's problem. If you determine rebuild/resync is problematic, you might consider using a RAID mode that doesn't require it to be so extensive, like RAID 10 with 4+ drives, or software RAID with ZFS. I was thinking of using other raid modes, along with ZFS (although still labeled 'experimental', and this is going to be our department's main file server, so I still have my second thoughts about it...), since FreeBSD does not recognize my 2.8T volume during installation. This means that I 'll have to break it into more volumes in order for FreeBSD to see it. Thank you for your answer again, and (now that you mentioned it:) ) in case anyone knows whether we'll be able to see partitions 2T in the future (or now?!), please say how :). -- 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
FREEBSD 7.1-STABLE crashes when trying to mount USB device of solaris UFS filesystem
symbols from /boot/kernel/libiconv.ko...Reading symbols from /boot/kernel/libiconv.ko.symbols...done. done. Loaded symbols for /boot/kernel/libiconv.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from /boot/kernel/if_vlan.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_vlan.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /boot/kernel/daemon_saver.ko...Reading symbols from /boot/kernel/daemon_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/daemon_saver.ko Reading symbols from /usr/local/modules/rtc.ko...done. Loaded symbols for /usr/local/modules/rtc.ko #0 doadump () at pcpu.h:196 196pcpu.h: No such file or directory. in pcpu.h (kgdb) I will csup my box to the latest freebsd-stable and see if the problems persist. If not, I hope this message will help somebody to find some solution. Thank you all for your help in advance, regards, George Mamalakis -- 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: jails and mac_seeotheruids problems in 6-STABLE
Robert Watson wrote: On Tue, 30 Sep 2008, George Mamalakis wrote: It works like a charm! Thank you very much for your time and help, No problem -- I've gone ahead and committed that change to stable/6. If you're able to test 6.4RC1 when it comes out to confirm that the fix works there as desired, that would be most helpful. I will csup to 6.4RC1 when available, and will inform you of the outcome. Thanks again. Thanks, Robert N M Watson Computer Laboratory University of Cambridge regards, Robert Watson wrote: On Tue, 30 Sep 2008, George Mamalakis wrote: I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them is running 7-STABLE. All three have services running in jails. I noticed a very peculiar behavior in 6-STABLE when I set the sysctl security.mac.seeotheruids.enabled=1. The root user in my jails was not able to see processes and sockets owned by other users of the same jail, whereas the root user of the host system could see every process (thank the Almighty). The same behavior does not apply on the server running 7-STABLE. In one sense it is more secure, since the root user in a jail is not as strong as the root user should be in a UNIX system. On the other hand, the root user looses its purpose of existence, which I suppose is a bug. Below are the security.mac sysctl settings of both 6 and 7-STABLE: Could you try modifying src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree so that the call to suser_cred() in mac_seeotheruids_check() passes the SUSER_ALLOWJAIL flag rather than 0? This may correct the problem you're experiencing. Let me know and I can merge that change to 6.x. Robert N M Watson Computer Laboratory University of Cambridge 6-STABLE: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 security.mac.portacl.port_high: 1023 security.mac.portacl.autoport_exempt: 1 security.mac.portacl.suser_exempt: 1 security.mac.portacl.enabled: 1 7-STABLE: security.mac.max_slots: 4 security.mac.version: 3 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.suser_privileged: 1 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 I would be very glad if someone could inform me whether I am doing something wrong; if not I think I should inform FreeBSD about this bug. Thank you guys in advance, -- 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 [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED]
jails and mac_seeotheruids problems in 6-STABLE
Hallo everyone, I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them is running 7-STABLE. All three have services running in jails. I noticed a very peculiar behavior in 6-STABLE when I set the sysctl security.mac.seeotheruids.enabled=1. The root user in my jails was not able to see processes and sockets owned by other users of the same jail, whereas the root user of the host system could see every process (thank the Almighty). The same behavior does not apply on the server running 7-STABLE. In one sense it is more secure, since the root user in a jail is not as strong as the root user should be in a UNIX system. On the other hand, the root user looses its purpose of existence, which I suppose is a bug. Below are the security.mac sysctl settings of both 6 and 7-STABLE: 6-STABLE: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 security.mac.portacl.port_high: 1023 security.mac.portacl.autoport_exempt: 1 security.mac.portacl.suser_exempt: 1 security.mac.portacl.enabled: 1 7-STABLE: security.mac.max_slots: 4 security.mac.version: 3 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.suser_privileged: 1 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 I would be very glad if someone could inform me whether I am doing something wrong; if not I think I should inform FreeBSD about this bug. Thank you guys in advance, -- 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 [EMAIL PROTECTED]
Re: jails and mac_seeotheruids problems in 6-STABLE
It works like a charm! Thank you very much for your time and help, regards, Robert Watson wrote: On Tue, 30 Sep 2008, George Mamalakis wrote: I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them is running 7-STABLE. All three have services running in jails. I noticed a very peculiar behavior in 6-STABLE when I set the sysctl security.mac.seeotheruids.enabled=1. The root user in my jails was not able to see processes and sockets owned by other users of the same jail, whereas the root user of the host system could see every process (thank the Almighty). The same behavior does not apply on the server running 7-STABLE. In one sense it is more secure, since the root user in a jail is not as strong as the root user should be in a UNIX system. On the other hand, the root user looses its purpose of existence, which I suppose is a bug. Below are the security.mac sysctl settings of both 6 and 7-STABLE: Could you try modifying src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree so that the call to suser_cred() in mac_seeotheruids_check() passes the SUSER_ALLOWJAIL flag rather than 0? This may correct the problem you're experiencing. Let me know and I can merge that change to 6.x. Robert N M Watson Computer Laboratory University of Cambridge 6-STABLE: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 security.mac.portacl.port_high: 1023 security.mac.portacl.autoport_exempt: 1 security.mac.portacl.suser_exempt: 1 security.mac.portacl.enabled: 1 7-STABLE: security.mac.max_slots: 4 security.mac.version: 3 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.suser_privileged: 1 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 I would be very glad if someone could inform me whether I am doing something wrong; if not I think I should inform FreeBSD about this bug. Thank you guys in advance, -- 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 [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED]
