Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386
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
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 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. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 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
8.1-PRERELEASE: CPU packages not detected correctly
In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 | [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz (2133.42-MHz K8-class CPU) | Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE | AMD Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBMSERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. I'm not sure if this is just a cosmetic issue, or if this is a critical thing ... I could imagine that performance might be sub-optimal if the CPU topology isn't detected correctly, but I'm not sure if FreeBSD can take advantage of the topology. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd A misleading benchmark test can accomplish in minutes what years of good engineering can never do. -- Dilbert (2009-03-02) ___ 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 Tue, 13 Jul 2010, Henrik /KaarPoSoft wrote:
Dear All,
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.
It seems that there are no package for openldap server with GSSAPI/SASL, so I
have build and installed cyrus-sasl2, openldap24-server (with sasl
configured) and openldap24-sasl-client from ports.
Those are the port versions:
# $FreeBSD: ports/security/cyrus-sasl2/Makefile,v 1.141 2009/08/02 19:35:25
mezz Exp $
# $FreeBSD: ports/net/openldap24-server/Makefile,v 1.181 2010/07/01 19:04:42
delphij Exp $
According to the distinfo files, those are the upstream versions:
openldap-2.4.23
cyrus-sasl-2.1.23
which, as far as I can see, are the latest stable.
Trying LDAP I get a segfault:
$ ldapsearch
SASL/GSSAPI authentication started
Segmentation fault (core dumped)
Here is the backtrace from gdb:
#0 0x283225c7 in free () from /lib/libc.so.7
#1 0x28654b42 in gss_release_buffer () from /usr/lib/libgssapi.so.10
#2 0x28654512 in gss_release_name () from /usr/lib/libgssapi.so.10
#3 0x28650e69 in gss_init_sec_context () from /usr/lib/libgssapi.so.10
#4 0x28648a0f in gssapi_client_mech_step () from
/usr/local/lib/sasl2/libgssapiv2.so.2
#5 0x280ef4b1 in sasl_client_step () from /usr/local/lib/libsasl2.so.2
#6 0x28440200 in ?? ()
#7 0x in ?? ()
#8 0x in ?? ()
#9 0xbfbfe208 in ?? ()
#10 0xbfbfe1f4 in ?? ()
#11 0xbfbfe204 in ?? ()
#12 0x28446860 in ?? ()
#13 0x280ef3fe in sasl_client_step () from /usr/local/lib/libsasl2.so.2
#14 0xbfbfe148 in ?? ()
#15 0x280f0135 in sasl_client_start () from /usr/local/lib/libsasl2.so.2
#16 0x in ?? ()
#17 0x in ?? ()
#18 0xbfbfe208 in ?? ()
#19 0xbfbfe1f4 in ?? ()
#20 0xbfbfe204 in ?? ()
#21 0x72408f2d in ?? ()
#22 0x283b1ad8 in ?? () from /lib/libc.so.7
#23 0x in ?? ()
#24 0x283b1730 in __stderrp () from /lib/libc.so.7
#25 0xbfbfe118 in ?? ()
#26 0x28392114 in vfprintf () from /lib/libc.so.7
Previous frame inner to this frame (corrupt stack?)
I tried valgrind ldapsearch which produces thousands of issues, ending
with:
==59479== Invalid free() / delete / delete[]
==59479==at 0x59B95: free (in
/usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
==59479==by 0x911B41: gss_release_buffer (in /usr/lib/libgssapi.so.10)
==59479==by 0x911511: ??? (in /usr/lib/libgssapi.so.10)
==59479==by 0x90DE68: gss_init_sec_context (in /usr/lib/libgssapi.so.10)
==59479==by 0x905A0E: gssapi_client_mech_step (in
/usr/local/lib/sasl2/libgssapiv2.so.2)
==59479==by 0xAF4B0: sasl_client_step (in /usr/local/lib/libsasl2.so.2)
==59479==by 0xB0134: sasl_client_start (in /usr/local/lib/libsasl2.so.2)
==59479==by 0x70C46: ldap_int_sasl_bind (in
/usr/local/lib/libldap-2.4.so.7)
==59479==by 0x73935: ldap_sasl_interactive_bind_s (in
/usr/local/lib/libldap-2.4.so.7)
==59479==by 0x80505E6: ??? (in /usr/local/bin/ldapsearch)
==59479==by 0x804D695: ??? (in /usr/local/bin/ldapsearch)
==59479==by 0x804A7D8: ??? (in /usr/local/bin/ldapsearch)
==59479== Address 0x4e2c0 is not stack'd, malloc'd or (recently) free'd
==59479==
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous
failure (see text) (unknown mech-code 2529638944 for mech unknown)
/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.
Any comments, hints or suggestions would be most appreciated!
Dear Henrik,
just a guess from my side.
You said, that you installed and configured Kerberos from packages (i
guess from ports or a prebuilt package).
Did you by any chance set HEIMDAL_HOME=/usr before building and installing
the kerberos port?
Did you set HEIMDAL_HOME to point to the place where the package/port got
installed (e.g. HEIMDAL_HOME=/usr/local) before building the cyrus-sasl2
port?
Did you set HEIMDAL_HOME to anything at all? Please take a look at
${PORTSDIR}/security/cyrus-sasl2/Makefile to see the logic behind the
kerberos selection.
The valgrind and gdb output above shows that /usr/lib/libgssapi.so.10 is
used at runtime which comes out of the FreeBSD base system not out of your
installed kerberos port/package. Maybe there is something messed up that
kerberos from ports/package was used during build of
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On 14 July 2010 18:14, Oliver Fromme o...@lurza.secnetix.de wrote: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 | [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz (2133.42-MHz K8-class CPU) | Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE | AMD Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBM SERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. Hi, can you show kern.sched.topology_spec ? It would clarify things a bit. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
pluknet pluk...@gmail.com wrote: On 14 July 2010 18:14, Oliver Fromme o...@lurza.secnetix.de wrote: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 | [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz (2133.42-MHz K8-class CPU) | Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE | AMD Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBM SERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. Hi, can you show kern.sched.topology_spec ? It would clarify things a bit. Sure: groups group level=1 cache-level=0 cpu count=8 mask=0xff0, 1, 2, 3, 4, 5, 6, 7/cpu flags/flags children group level=3 cache-level=2 cpu count=8 mask=0xff0, 1, 2, 3, 4, 5, 6, 7/cpu flags/flags /group /children /group /groups Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Blogging: Never before have so many people with so little to say said so much to so few. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Wed, Jul 14, 2010 at 04:44:05PM +0200, Oliver Fromme wrote: pluknet pluk...@gmail.com wrote: On 14 July 2010 18:14, Oliver Fromme o...@lurza.secnetix.de wrote: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 | [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz (2133.42-MHz K8-class CPU) | Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE | AMD Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBM SERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. Hi, can you show kern.sched.topology_spec ? It would clarify things a bit. Sure: groups group level=1 cache-level=0 cpu count=8 mask=0xff0, 1, 2, 3, 4, 5, 6, 7/cpu flags/flags children group level=3 cache-level=2 cpu count=8 mask=0xff0, 1, 2, 3, 4, 5, 6, 7/cpu flags/flags /group /children /group /groups Can you also provide the output of acpidump -dt? This will probably be quite long (possibly 300KB or more), so you may want to put it up on the web somewhere. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
Jeremy Chadwick wrote: Can you also provide the output of acpidump -dt? This will probably be quite long (possibly 300KB or more), so you may want to put it up on the web somewhere. http://www.secnetix.de/olli/tmp/acpidump-dt.txt Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ 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: new umass panic on 7-stable built today
On 20 July 2009 01:52, Juergen Lock n...@jelal.kn-bremen.de wrote: Hi! So I wanted to use an usb key on this freshly updated 7-stable box, and got a panic just after plugging it in: :( zsh triton# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.9 ... umass0: OCZ Technology ATV, class 0/0, rev 2.00/11.00, addr 2 on uhub5 umass0:1:0:-1: Attached to scbus1 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x290 fault code = supervisor read data, page not present instruction pointer = 0x8:0x804d67d4 stack pointer = 0x10:0xff8085487da0 frame pointer = 0x10:0xff8085487de0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 38 (usb5) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2b3 trap_pfault() at trap_pfault+0x294 trap() at trap+0x312 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x804d67d4, rsp = 0xff8085487da0, rbp = 0xff8085487de0 --- usb_transfer_complete() at usb_transfer_complete+0x1d4 bus_dmamap_load() at bus_dmamap_load+0x314 usbd_transfer() at usbd_transfer+0xee usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f usbd_do_request_flags() at usbd_do_request_flags+0x25 usbd_get_string_desc() at usbd_get_string_desc+0x9b usbd_get_string() at usbd_get_string+0x83 uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9 devaddq() at devaddq+0xd5 device_attach() at device_attach+0x13a usbd_new_device() at usbd_new_device+0x821 uhub_explore() at uhub_explore+0x1bd usb_discover() at usb_discover+0x38 usb_event_thread() at usb_event_thread+0x8a fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8085488d30, rbp = 0 --- Uptime: 1m1s Physical memory: 8176 MB Dumping 4605 MB: 4590 4574 4558 4542 4526 4510 4494 4478 4462 4446 4430 4414 4398 4382 4366 4350 4334 4318 4302 4286 4270 4254 4238 4222 4206 4190 4174 4158 4142 4126 4110 4094 4078 4062 4046 4030 4014 3998 3982 3966 3950 3934 3918 3902 3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710 3694 3678 3662 3646 3630 3614 3598 3582 3566 3550 3534 3518 3502 3486 3470 3454 3438 3422 3406 3390 3374 3358 3342 3326 3310 3294 3278 3262 3246 3230 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2254 2238 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko #0 doadump () at pcpu.h:195 195 __asm __volatile(movq %%gs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x80567248 in boot (howto=260) at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:418 #2 0x805676ac in panic (fmt=Variable fmt is not available. ) at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:574 #3 0x8082f953 in trap_fatal (frame=0xc, eva=Variable eva is not available. ) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:756 #4 0x8082fd34 in trap_pfault (frame=0xff8085487cf0, usermode=0) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:672 #5 0x808306e2 in trap (frame=0xff8085487cf0) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:443 #6 0x80819cce in calltrap () at /usr/home/nox/src72s2/src/sys/amd64/amd64/exception.S:218 #7 0x804d67d4 in usb_transfer_complete (xfer=0xff00046b1000) at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:949 #8 0x80815bf4 in bus_dmamap_load (dmat=0xff0004499880, map=0xff000478ec00, buf=0xff8085487fe0, buflen=0, callback=0x804d68b0 usbd_start_transfer, callback_arg=0xff00046b1000, flags=0) at
Re: 8.1-PRERELEASE: CPU packages not detected correctly
on 14/07/2010 17:14 Oliver Fromme said the following: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 | [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz (2133.42-MHz K8-class CPU) | Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE | AMD Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBMSERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. I'm not sure if this is just a cosmetic issue, or if this is a critical thing ... I could imagine that performance might be sub-optimal if the CPU topology isn't detected correctly, but I'm not sure if FreeBSD can take advantage of the topology. Could you please try to do the following? 1. Fetch topo-12212009.tar from the top of this page: http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ 2. Untar it and apply this patch to the code: http://people.freebsd.org/~avg/cpu-topology.diff 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) 4. Run cpu_topology64.out and report back its output. Thanks! -- Andriy Gapon ___ 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: new umass panic on 7-stable built today
On Wed, Jul 14, 2010 at 08:49:10PM +0400, pluknet wrote: On 20 July 2009 01:52, Juergen Lock n...@jelal.kn-bremen.de wrote: Hi! So I wanted to use an usb key on this freshly updated 7-stable box, and got a panic just after plugging it in: :( zsh triton# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.9 ... umass0: OCZ Technology ATV, class 0/0, rev 2.00/11.00, addr 2 on uhub5 umass0:1:0:-1: Attached to scbus1 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x290 fault code = supervisor read data, page not present instruction pointer = 0x8:0x804d67d4 stack pointer = 0x10:0xff8085487da0 frame pointer = 0x10:0xff8085487de0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 38 (usb5) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2b3 trap_pfault() at trap_pfault+0x294 trap() at trap+0x312 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x804d67d4, rsp = 0xff8085487da0, rbp = 0xff8085487de0 --- usb_transfer_complete() at usb_transfer_complete+0x1d4 bus_dmamap_load() at bus_dmamap_load+0x314 usbd_transfer() at usbd_transfer+0xee usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f usbd_do_request_flags() at usbd_do_request_flags+0x25 usbd_get_string_desc() at usbd_get_string_desc+0x9b usbd_get_string() at usbd_get_string+0x83 uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9 devaddq() at devaddq+0xd5 device_attach() at device_attach+0x13a usbd_new_device() at usbd_new_device+0x821 uhub_explore() at uhub_explore+0x1bd usb_discover() at usb_discover+0x38 usb_event_thread() at usb_event_thread+0x8a fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8085488d30, rbp = 0 --- Uptime: 1m1s Physical memory: 8176 MB Dumping 4605 MB: 4590 4574 4558 4542 4526 4510 4494 4478 4462 4446 4430 4414 4398 4382 4366 4350 4334 4318 4302 4286 4270 4254 4238 4222 4206 4190 4174 4158 4142 4126 4110 4094 4078 4062 4046 4030 4014 3998 3982 3966 3950 3934 3918 3902 3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710 3694 3678 3662 3646 3630 3614 3598 3582 3566 3550 3534 3518 3502 3486 3470 3454 3438 3422 3406 3390 3374 3358 3342 3326 3310 3294 3278 3262 3246 3230 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2254 2238 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko #0 doadump () at pcpu.h:195 195 __asm __volatile(movq %%gs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x80567248 in boot (howto=260) at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:418 #2 0x805676ac in panic (fmt=Variable fmt is not available. ) at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:574 #3 0x8082f953 in trap_fatal (frame=0xc, eva=Variable eva is not available. ) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:756 #4 0x8082fd34 in trap_pfault (frame=0xff8085487cf0, usermode=0) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:672 #5 0x808306e2 in trap (frame=0xff8085487cf0) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:443 #6 0x80819cce in calltrap () at /usr/home/nox/src72s2/src/sys/amd64/amd64/exception.S:218 #7 0x804d67d4 in usb_transfer_complete (xfer=0xff00046b1000) at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:949 #8 0x80815bf4 in bus_dmamap_load (dmat=0xff0004499880, map=0xff000478ec00, buf=0xff8085487fe0, buflen=0,
Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386
On Tue, Jul 13, 2010 at 10:10:25PM +0200, Henrik /KaarPoSoft wrote: I have a problem: ldapsearch results in Segmentation fault under openldap-2.4.23 with cyrus-sasl-2.1.23. [...] Jeremy Chadwick wrote: 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. Jeremy, I would really appreciate your going through this! Thank you very much in advance. Here is what I did: FreeBSD 8.0 vanilla install hostname: srv02.example.lan freebsd-update fetch freebsd-update install Create self-signed CA cert, and create SSL cert for LDAP signed by this. References: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/openssl.html http://forums.freebsd.org/showthread.php?t=6490 http://www.freebsdmadeeasy.com/tutorials/freebsd/create-a-ca-with-openssl.php pkg_add -r heimdal cat /etc/rc.conf kerberos5_server_enable=YES kadmind5_server_enable=YES cat /etc/krb5.conf [libdefaults] default_realm = EXAMPLE.LAN kstash kadmin -l kadmin init EXAMPLE.LAN kadmin add TestOne kadmin list * /etc/rc.d/kerberos start /etc/rc.d/kadmind start Add to nameserver: kerberos.example.lan CNAME srv02.example.lan ldap.example.lan CNAME srv02.example.lan _kerberos IN TXT kerberos.example.lan _kerberos._udp.example.lan. IN SRV 0 0 88 kerberos.example.lan. _kerberos._tcp.example.lan. IN SRV 0 0 88 kerberos.example.lan. _kerberos-adm._tcp.example.lan. IN SRV 0 0 749 kerberos.example.lan. _kpasswd._udp.example.lan. IN SRV 0 0 464 kerberos.example.lan. cd /usr/ports portsnap fetch portsnap extract (and subsequently portsnap fetch update) cd /usr/ports/security/cyrus-sasl2 make config [X] Berkeley DB [X] /dev/urandom make make install cd /usr/ports/net/openldap24-sasl-client make make install cd /usr/ports/net/openldap24-server make config [x] SASL make cat /etc/rc.conf slapd_enable=YES slapd_flags=-h ldaps:/// touch /var/db/openldap-data/DB_CONFIG srv02# diff /usr/local/etc/openldap/slapd.conf.ORIG /usr/local/etc/openldap/slapd.conf 48a50,80 ### # EXAMPLE ### #=# Shemas we need include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema #=# Logging loglevel stats stats2 shell parse ACL config filter BER conns #=# GSSAPI mapping #=# http://www.openldap.org/doc/admin24/sasl.html#GSSAPI #=# http://www.openldap.org/doc/admin24/sasl.html#Mapping Authentication Identities authz-regexp uid=([^,]*),cn=example.lan,cn=gssapi,cn=auth uid=$1,ou=Users,dc=example,dc=lan #=# LDAP over TSL (SSL) #=# http://www.openldap.org/doc/admin24/tls.html security ssf=128 TLSCertificateFile /etc/exampleCA/certs/ldap.pem TLSCertificateKeyFile /etc/exampleCA/private/ldap.pem TLSCACertificateFile /etc/exampleCA/certs/example.pem 54,55c86,93 suffix dc=my-domain,dc=com rootdn cn=Manager,dc=my-domain,dc=com --- #=# The example Network suffix dc=example,dc=lan #=# The rootdn user, authenticated by Kerberos #=# http://www.openldap.org/doc/admin24/sasl.html#GSSAPI rootdn uid=LDAProot,cn=example.lan,cn=gssapi,cn=auth 59c97,99 rootpw secret --- #=# Since rootdn is authenticated by Kerberos, we do not need rootpw #rootpw secret 65a106 Add domain and a few users with slapadd cat /usr/local/etc/openldap/ldap.conf base dc=example,dc=lan uri ldaps://ldap.example.lan/ tls_cacert /etc/exampleCA/cacert.pem ___ 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
Joerg Pulz wrote:
On Tue, 13 Jul 2010, Henrik /KaarPoSoft wrote:
Dear All,
I have a problem: ldapsearch results in Segmentation fault under
openldap-2.4.23 with cyrus-sasl-2.1.23.
[...]
Dear Henrik,
just a guess from my side.
You said, that you installed and configured Kerberos from packages (i
guess from ports or a prebuilt package).
Did you by any chance set HEIMDAL_HOME=/usr before building and
installing the kerberos port?
Did you set HEIMDAL_HOME to point to the place where the package/port
got installed (e.g. HEIMDAL_HOME=/usr/local) before building the
cyrus-sasl2 port?
Did you set HEIMDAL_HOME to anything at all? Please take a look at
${PORTSDIR}/security/cyrus-sasl2/Makefile to see the logic behind the
kerberos selection.
The valgrind and gdb output above shows that /usr/lib/libgssapi.so.10
is used at runtime which comes out of the FreeBSD base system not out
of your installed kerberos port/package. Maybe there is something
messed up that kerberos from ports/package was used during build of
cyrus-sasl2 but the base kerberos libs are used at runtime or vice versa.
In any case, this is just one thing i would double check before deeper
debugging.
Joerg, thank you very much for your input - most appreciated!
I simply installed heimdal with
pkg_add -r heimdal
I did not set HEIMDAL_HOME at any point.
env shows that HEIMDAL_HOME is not set.
So according to /usr/ports/security/cyrus-sasl2/Makefile I guess we
would have CONFIGURE_ARGS+=--enable-gssapi but no --with-gss_impl=heimdal
To be on the safe side, I tried
cd /usr/ports/security/cyrus-sasl2/
make clean
export HEIMDAL_HOME=/usr
make
(during make I noticed a few cc ... -DKRB5_HEIMDAL ...)
ldapsarch still coredumps with gss_init_sec_context () from
/usr/lib/libgssapi.so.10
I noticed that I have libgssapi's - no clue why:
srv02# ls /usr/lib/libgss*
/usr/lib/libgssapi.a /usr/lib/libgssapi_krb5.a
/usr/lib/libgssapi_krb5_p.a /usr/lib/libgssapi_ntlm.so.10
/usr/lib/libgssapi_spnego.a /usr/lib/libgssapi_spnego_p.a
/usr/lib/libgssapi.so /usr/lib/libgssapi_krb5.so
/usr/lib/libgssapi_ntlm.a /usr/lib/libgssapi_ntlm_p.a
/usr/lib/libgssapi_spnego.so
/usr/lib/libgssapi.so.10 /usr/lib/libgssapi_krb5.so.10
/usr/lib/libgssapi_ntlm.so /usr/lib/libgssapi_p.a
/usr/lib/libgssapi_spnego.so.10
srv02# ls /usr/local/lib/libgss*
/usr/local/lib/libgssapi.a /usr/local/lib/libgssapi.la
/usr/local/lib/libgssapi.so /usr/local/lib/libgssapi.so.2
Next I tried pkg_delete heimdal-1.0.1_1
and then
srv02# ls /usr/local/bin/k*
ls: No match.
srv02# ls /usr/bin/k*
/usr/bin/kadmin /usr/bin/kdump /usr/bin/keylogout /usr/bin/killall
/usr/bin/klist /usr/bin/krb5-config /usr/bin/ktrace
/usr/bin/kdestroy /usr/bin/keylogin /usr/bin/kgdb /usr/bin/kinit
/usr/bin/kpasswd /usr/bin/ksu /usr/bin/ktrdump
srv02# ls /usr/lib/libgss*
/usr/lib/libgssapi.a /usr/lib/libgssapi_krb5.a
/usr/lib/libgssapi_krb5_p.a /usr/lib/libgssapi_ntlm.so.10
/usr/lib/libgssapi_spnego.a /usr/lib/libgssapi_spnego_p.a
/usr/lib/libgssapi.so /usr/lib/libgssapi_krb5.so
/usr/lib/libgssapi_ntlm.a /usr/lib/libgssapi_ntlm_p.a
/usr/lib/libgssapi_spnego.so
/usr/lib/libgssapi.so.10 /usr/lib/libgssapi_krb5.so.10
/usr/lib/libgssapi_ntlm.so /usr/lib/libgssapi_p.a
/usr/lib/libgssapi_spnego.so.10
srv02# ls /usr/local/lib/libgss*
ls: No match.
so it would seem that the /usr/local heimdal is now gone, but some
heimdal is still left in /usr ?
looking at a different partition with a vanilla FreeBSD install I find
the same files in /usr/lib and /usr/bin.
maybe I did not have to install kerberos package at all ?
I will play a bit more with this, but any more input would still be
appreciated...
/Henrik
___
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
George Mamalakis wrote: 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). That would be most appreciated! - Looking forward to the weekend ((-; /Henrik ___ 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 fbsd8stablei386
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. After building perl, cyrus-sasl2 and userland/kernel with debug symbols I was able to get the following backtrace. #0 free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889 3889arena_dalloc(chunk-arena, chunk, ptr); [New Thread 286ae140 (LWP 100273)] (gdb) bt #0 free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889 #1 0x2899ed32 in gss_release_buffer (minor_status=0xbfbfe4b8, buffer=0x280871cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41 #2 0x2899e6e2 in _gss_mg_error (m=0x28a86480, maj=851968, min=2) at /usr/src/lib/libgssapi/gss_display_status.c:240 #3 0x2899afd9 in gss_init_sec_context (minor_status=0xbfbfe5a4, initiator_cred_handle=0x0, context_handle=0x28630164, target_name=0x2861b380, input_mech_type=0x0, req_flags=58, time_req=0, input_chan_bindings=0x0, input_token=0x0, actual_mech_type=0x0, output_token=0xbfbfe5a8, ret_flags=0xbfbfe594, time_rec=0x0) at /usr/src/lib/libgssapi/gss_init_sec_context.c:156 #4 0x289936c9 in gssapi_client_mech_step (conn_context=0x28630160, params=0x28a97080, serverin=0x0, serverinlen=0, prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, oparams=0x28a95860) at gssapi.c:1418 #5 0x285810f6 in sasl_client_step (conn=0x28a95000, serverin=0x0, serverinlen=0, prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8) at client.c:655 #6 0x28580ef7 in sasl_client_start (conn=0x28a95000, mechlist=0x2861b360 GSSAPI DIGEST-MD5 CRAM-MD5 , prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, mech=0xbfbfe8b8) at client.c:603 #7 0x2856a94c in imclient_authenticate () from /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so #8 0x28566f5e in XS_Cyrus__IMAP__authenticate () from /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so #9 0x281d8f30 in Perl_pp_entersub () at pp_hot.c:2888 #10 0x281878bc in Perl_runops_debug () at dump.c:1968 #11 0x280d80a9 in S_run_body (oldscope=1) at perl.c:2431 #12 0x280d7535 in perl_run (my_perl=0x28601100) at perl.c:2349 #13 0x08048930 in main (argc=6, argv=0xbfbfec44, env=0xbfbfec60) at perlmain.c:117 I'm complete GDB-idjit though so any help in getting usable information from the following trace would be appreciated - I have the dump etc. stored away for further digging of course. -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
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: on 14/07/2010 17:14 Oliver Fromme said the following: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC | 2010 [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz | (2133.42-MHz K8-class CPU) Origin = GenuineIntel Id = | 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SE |P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE |2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,C |X16,xTPR,PDCM,DCA,SSE4.1,XSAVE AMD | Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBMSERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. I'm not sure if this is just a cosmetic issue, or if this is a critical thing ... I could imagine that performance might be sub-optimal if the CPU topology isn't detected correctly, but I'm not sure if FreeBSD can take advantage of the topology. Could you please try to do the following? 1. Fetch topo-12212009.tar from the top of this page: http://software.intel.com/en-us/articles/intel-64-architecture-proc essor-topology-enumeration/ 2. Untar it and apply this patch to the code: http://people.freebsd.org/~avg/cpu-topology.diff 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) 4. Run cpu_topology64.out and report back its output. It's funny that I actually wrote a convenience script (and cleaned up today): http://people.freebsd.org/~jkim/cpu_topology-12212009.sh BTW, current topology detection code is not optimal for some Intel processors if my memory serves. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
on 15/07/2010 00:40 Jung-uk Kim said the following: It's funny that I actually wrote a convenience script (and cleaned up today): http://people.freebsd.org/~jkim/cpu_topology-12212009.sh BTW, current topology detection code is not optimal for some Intel processors if my memory serves. Indeed. Your patch looks so much cleaner too. Thanks! -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote: On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: on 14/07/2010 17:14 Oliver Fromme said the following: In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC | 2010 [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz | (2133.42-MHz K8-class CPU) Origin = GenuineIntel Id = | 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC, |SE | P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE, |SSE 2,SS,HTT,TM,PBE | Features2=0x40ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3 |,C X16,xTPR,PDCM,DCA,SSE4.1,XSAVE AMD | Features=0x2800SYSCALL,LM | AMD Features2=0x1LAHF | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: IBMSERBLADE | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | cpu0 (BSP): APIC ID: 0 | cpu1 (AP): APIC ID: 1 | cpu2 (AP): APIC ID: 2 | cpu3 (AP): APIC ID: 3 | cpu4 (AP): APIC ID: 4 | cpu5 (AP): APIC ID: 5 | cpu6 (AP): APIC ID: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 Version 2.0 irqs 24-47 on motherboard | ioapic0 Version 2.0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. I'm not sure if this is just a cosmetic issue, or if this is a critical thing ... I could imagine that performance might be sub-optimal if the CPU topology isn't detected correctly, but I'm not sure if FreeBSD can take advantage of the topology. Could you please try to do the following? 1. Fetch topo-12212009.tar from the top of this page: http://software.intel.com/en-us/articles/intel-64-architecture-pr oc essor-topology-enumeration/ 2. Untar it and apply this patch to the code: http://people.freebsd.org/~avg/cpu-topology.diff 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) 4. Run cpu_topology64.out and report back its output. It's funny that I actually wrote a convenience script (and cleaned up today): http://people.freebsd.org/~jkim/cpu_topology-12212009.sh BTW, current topology detection code is not optimal for some Intel processors if my memory serves. Surprisingly, I found a patch I wrote last year from /tmp of my desktop and it is still applied cleanly. 8-) Just in case, it is available from here: http://people.freebsd.org/~jkim/mp_machdep.diff It is applicable to both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. I have to warn you, though, it hasn't been used for more than a year, so it may not work at all. ;-) Jung-uk Kim ___ 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
