SUSE 9.2 als LDAP client, nscd stirbt mit SIGABRT
Hi, ich bin der Sache mal ein bischen auf den Grund gegangen. Die Ursache ist, dass in den nscd Sourcen eine Funktion getaddrinfo enthalten ist (in nscd.c ganz am Ende): /* This is an ugly hack which prevents getaddrinfo from being dragged into nscd. There currently is no special getaddrinfo version for use in nscd. In case it should be necessary such a version must be created and this dummy version should be removed. */ void getaddrinfo (void) { abort (); } Vielleicht kann jemand mit mehr Einblick in nscd und glibc mal erklaeren, was das soll? Was nun passiert bei einem LDAP-Lookup ist das Folgende (gdb-Output): (gdb) run -d Starting program: /usr/sbin/nscd.debug -d [Thread debugging using libthread_db enabled] [New Thread 182899679392 (LWP 20298)] [New Thread 1075837280 (LWP 20301)] [New Thread 1077934432 (LWP 20302)] [New Thread 1080031584 (LWP 20303)] [New Thread 1082128736 (LWP 20304)] [New Thread 1084225888 (LWP 20305)] 20298: handle_request: request received (Version = 2) from PID 20332 20298: GETFDPW 20298: provide access to FD 8, for passwd 20298: handle_request: request received (Version = 2) from PID 20332 20298: GETPWBYUID (549) 20298: Haven't found "549" in password cache! Program received signal SIGABRT, Aborted. [Switching to Thread 1075837280 (LWP 20301)] 0x0000002a958c56cd in raise () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000002a958c56cd in raise () from /lib64/tls/libc.so.6 #1 0x0000002a958c6c7e in abort () from /lib64/tls/libc.so.6 #2 0x0000000000403109 in getaddrinfo () at nscd.c:489 #3 0x0000002a95cfdd0d in ldap_connect_to_host () from /usr/lib64/libldap-2.2.so.7 #4 0x0000002a95ceaf97 in ldap_int_open_connection () from /usr/lib64/libldap-2.2.so.7 #5 0x0000002a95cfc1b7 in ldap_new_connection () from /usr/lib64/libldap-2.2.so.7 #6 0x0000002a95ceadca in ldap_open_defconn () from /usr/lib64/libldap-2.2.so.7 #7 0x0000002a95cfc888 in ldap_send_initial_request () from /usr/lib64/libldap-2.2.so.7 #8 0x0000002a95cef47d in ldap_extended_operation () from /usr/lib64/libldap-2.2.so.7 #9 0x0000002a95cef60c in ldap_extended_operation_s () from /usr/lib64/libldap-2.2.so.7 #10 0x0000002a95d09339 in ldap_start_tls_s () from /usr/lib64/libldap-2.2.so.7 #11 0x0000002a95bcb15d in do_open () at ldap-nss.c:1222 #12 0x0000002a95bcb640 in _nss_ldap_search_s (args=0x401feec0, filterprot=0x2a95cdc820 "(&(objectclass=posixAccount)(uidNumber=%d))", sel=LM_PASSWD, sizelimit=1, res=0x401fee58) at ldap-nss.c:2503 #13 0x0000002a95bcbbc8 in _nss_ldap_getbyname (args=0x401feec0, result=0x401ff3c0, buffer=0x401fef70 "uucp", buflen=1024, errnop=0x401ff920, filterprot=0x2a95cdc820 "(&(objectclass=posixAccount)(uidNumber=%d))", sel=LM_PASSWD, parser=0x2a95bcc0f0 <_nss_ldap_parse_pw>) at ldap-nss.c:2873 #14 0x0000002a95bcc480 in _nss_ldap_getpwuid_r (uid=Variable "uid" is not available. ) at ldap-pwd.c:202 #15 0x00000000004060d5 in __getpwuid_r (uid=549, resbuf=0x401ff3c0, buffer=0x401fef70 "uucp", buflen=1024, result=0x401ff3b8) at getXXbyYY_r.c:207 #16 0x0000000000405b7e in addpwbyX (db=0x50e480, fd=12, req=0x401ff790, key= {v = 0x225, u = 549}, keystr=0x401ff480 "549", c_uid=4294967295, he=0x0, dh=0x0) at pwdcache.c:386 #17 0x0000000000405e2e in addpwbyuid (db=0x50e480, fd=12, req=0x401ff790, key=0x401ff480, c_uid=4294967295) at pwdcache.c:508 #18 0x00000000004041d4 in nscd_run (p=Variable "p" is not available. ) at connections.c:691 #19 0x0000002a95673649 in start_thread () from /lib64/tls/libpthread.so.0 #20 0x0000002a9594f6c3 in thread_start () from /lib64/tls/libc.so.6 Wie man sehen kann, wird diese unselige getaddrinfo-Funktion froehlich von der LDAP-Library aufgerufen und da steht eben nur "abort()" drin. Ich bin nicht sicher, was passiert, wenn ich die Dummy-getaddrinfo-Funktion in nscd einfach weglasse, werde ich mal probieren. Ein ordentlicher Fix von SUSE waere mir natuerlich viel lieber als da in den Sourcen rumzuwuehlen und das halbe glibc-Paket durchzunudeln. Karsten. -- "Nuclear war would mean abolition of most comforts, and disruption of normal routines, for children and adults alike." -- Willard F. Libby, "You *Can* Survive Atomic Attack"
Hi Karsten,
Wie man sehen kann, wird diese unselige getaddrinfo-Funktion froehlich von der LDAP-Library aufgerufen und da steht eben nur "abort()" drin. Ich bin nicht sicher, was passiert, wenn ich die Dummy-getaddrinfo-Funktion in nscd einfach weglasse, werde ich mal probieren. Ein ordentlicher Fix von SUSE waere mir natuerlich viel lieber als da in den Sourcen rumzuwuehlen und das halbe glibc-Paket durchzunudeln.
Tja ... "The power of open source". Herzlichen Dank fuer Deine Analyse. SuSE, Novell oder neu NoSE gab diesbezueglich keinen Support, weil es nicht ihr Zeugs ist und im Installationssupport ist offenbar nur Beihilfe enthalten, falls man den Karton nicht aufkriegt oder die CD falschrum ins Laufwerk legt. Wir haben nun fuer uns rausgefunden, dass das Susi 9.2.1 Package nscd-2.3.4-11.0.20050131.i686.rpm funktioniert. Name : nscd Relocations: (not relocatable) Version : 2.3.4 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 11.0.20050131 Build Date: Mon 31 Jan 2005 03:51:16 AM CET Install date: Mon 07 Feb 2005 08:37:26 AM CET Build Host: levi.suse.de Group : System/Daemons Source RPM: glibc-2.3.4-11.0.20050131.src.rpm Size : 89587 License: GPL, LGPL Signature : (none) Packager : http://www.suse.de/feedback URL : http://www.gnu.org/software/libc/libc.html Summary : Name Service Caching Daemon Description : Nscd caches name service lookups and can dramatically improve performance with NIS, NIS+, and LDAP. Distribution: SUSE LINUX 9.2.1 (i686) Die nscd-Packages von Suse 9.0 und Enterprise-Server liefen zwar, hatten aber 0% Cache-Hitrate. Mal sehen, wie es dann mit Novell Linux 10 aussieht. Danke + Gruss, Bernd
On Thursday 24 February 2005 07:59, Bernd Nies wrote:
Hi Karsten,
Wie man sehen kann, wird diese unselige getaddrinfo-Funktion froehlich von der LDAP-Library aufgerufen und da steht eben nur "abort()" drin. Ich bin nicht sicher, was passiert, wenn ich die Dummy-getaddrinfo-Funktion in nscd einfach weglasse, werde ich mal probieren. Ein ordentlicher Fix von SUSE waere mir natuerlich viel lieber als da in den Sourcen rumzuwuehlen und das halbe glibc-Paket durchzunudeln.
Tja ... "The power of open source". Herzlichen Dank fuer Deine Analyse.
SuSE, Novell oder neu NoSE gab diesbezueglich keinen Support, weil es nicht ihr Zeugs ist und im Installationssupport ist offenbar nur Beihilfe enthalten, falls man den Karton nicht aufkriegt oder die CD falschrum ins Laufwerk legt.
Das habe ich bis jetzt immer noch selbst geschafft ;-).
Wir haben nun fuer uns rausgefunden, dass das Susi 9.2.1 Package nscd-2.3.4-11.0.20050131.i686.rpm funktioniert.
Name : nscd Relocations: (not relocatable) Version : 2.3.4 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 11.0.20050131 Build Date: Mon 31 Jan 2005 03:51:16 AM CET Install date: Mon 07 Feb 2005 08:37:26 AM CET Build Host: levi.suse.de Group : System/Daemons Source RPM: glibc-2.3.4-11.0.20050131.src.rpm Size : 89587 License: GPL, LGPL Signature : (none) Packager : http://www.suse.de/feedback URL : http://www.gnu.org/software/libc/libc.html Summary : Name Service Caching Daemon Description : Nscd caches name service lookups and can dramatically improve performance with NIS, NIS+, and LDAP. Distribution: SUSE LINUX 9.2.1 (i686)
Die nscd-Packages von Suse 9.0 und Enterprise-Server liefen zwar, hatten aber 0% Cache-Hitrate. Mal sehen, wie es dann mit Novell Linux 10 aussieht.
Wo bekommt man denn SUSE 9.2.1? Auf dem SUSE-FTP-Server kann ich nichts dergleichen finden und im Update fuer 9.2 ist das Paket auch nicht enthalten. Ich hab' in der Zwischenzeit mein eigenes gepatchtes nscd-Paket gekocht, ohne die unselige getaddrinfo-Funktion. Bis jetzt haben wir auch keine Probleme damit, allerdings kann ich mir Probleme vorstellen, wenn man den nscd auch benutzt, um "hosts" zu cachen. Das ist aber in SUSE's default-Konfiguration ausgeschaltet und wir haben das auch so gelassen, da wir fuer "hosts" kein LDAP verwenden, sondern DNS. Gruss, Karsten. -- One of the rules of Busmanship, New York style, is never surrender your seat to another passenger. This may seem callous, but it is the best way, really. If one passenger were to give a seat to someone who fainted in the aisle, say, the others on the bus would become disoriented and imagine they were in Topeka, Kansas.
Hi,
Wo bekommt man denn SUSE 9.2.1? Auf dem SUSE-FTP-Server kann ich nichts dergleichen finden und im Update fuer 9.2 ist das Paket auch nicht enthalten.
http://rpm.pbone.net/ ftp://ftp.suse.com/pub/projects/glibc/2.3.4/i686/ Ich kapier die Releases von Susi auch nicht wirklich. Eigentlich sollte man annehmen, dass 9.0, 9.1, 9.2 mehr oder weniger gleich sind und sich nur in neueren Versionen der RPMs unterscheiden, so quasi 9.0 + Patches = 9.2. Denkste. Neue Kernel-Generation, neues X, neues Branding ... Mit Autoyast hab ich tagelang geuebt, bis das XML-Profil und Finishscript fuer alle Susi 9.x Releases funktioniert und wir einfach die paar 100 Clients aufsetzen koennen. Seufz. Ich wuensch mir als Sysadmin mehr Konsistenz in den Releases.
Ich hab' in der Zwischenzeit mein eigenes gepatchtes nscd-Paket gekocht, ohne die unselige getaddrinfo-Funktion. Bis jetzt haben wir auch keine Probleme damit, allerdings kann ich mir Probleme vorstellen, wenn man den nscd auch benutzt, um "hosts" zu cachen. Das ist aber in SUSE's default-Konfiguration ausgeschaltet und wir haben das auch so gelassen, da wir fuer "hosts" kein LDAP verwenden, sondern DNS.
Wir auch. DNS laeuft da viel besser als LDAP. Gruss, Bernd
Hallo Bernd, hallo Leute, Am Donnerstag, 24. Februar 2005 15:36 schrieb Bernd Nies:
Wo bekommt man denn SUSE 9.2.1? Auf dem SUSE-FTP-Server kann ich nichts dergleichen finden
Doch, die 9.2 auf dem FTP-Server ist strenggenommen die 9.2.1, da dort einige Pakete in etwas neueren Versionen als auf CD/DVD vorliegen.
Ich kapier die Releases von Susi auch nicht wirklich. Eigentlich sollte man annehmen, dass 9.0, 9.1, 9.2 mehr oder weniger gleich sind und sich nur in neueren Versionen der RPMs unterscheiden, so quasi 9.0 + Patches = 9.2. Denkste. Neue Kernel-Generation, neues X, neues Branding ...
Ja, eben "neuere Versionen der RPMs". Das schreibst Du doch selbst ;-) Wenn Du gleichbleibende Versionsnummern und nur Sicherheitsupdates haben willst, bleibe bei einer bestimmten SuSE-Version und spiele nur die YOU-Updates ein. Das kannst Du 2 Jahre lang so machen (ab Releasedatum) so machen, dann gibt es keine Sicherheitsupdates mehr. Wenn Dir diese 2 Jahre nicht reichen, steige auf ein Serverprodukt von SuSE (z. B. SLES) oder Debian um, da läuft der Support mit Sicherheitsupdates deutlich länger. Gruß Christian Boltz -- He was the same guy formatting his linux two year ago because his soundcard didn't work. After a while of consolehacking, google-ing and investigating he setup windows again (it would be the better solution ... lmao). After windows was setup the soundcard didn't work again and he plugged in the cable. [Philippe Vogel in suse-security]
participants (3)
-
Bernd Nies
-
Christian Boltz
-
Karsten Künne