PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Samba3 als PDC - Seltsames Verhalten und fatale Abstürze



Rennie
08.09.04, 20:06
Moin zusammen!

Da ich kurz vorm Verzweifeln stehe, wende ich mich jetzt auch mal an die Linuxforen-Gemeinde. Ich habe in den letzten Tagen/Wochen einen Samba 3 (genauer: 3.0.6) Server als PDC mit LDAP als Backend aufgesetzt. Dieser verwaltet ca 1100 Useraccounts und bedient 50 WinXP-Clients. Soweit läuft alles recht gut, aber ein paar Probleme gibt es doch:

1) ldap machine suffix wird ignoriert
Ich habe zum Füllen des LDAP die smbldap-tools von idealx genutzt und diese so konfiguriert, daß die User unter ou=users, die Gruppen unter ou=groups und die Computer unter ou=machines angelegt werden. Prompt konnte ich keinen Computer in die Domäne aufnehmen, weil das Computerkonto korrekt als uid=computername$,ou=machines,dc=bla,dc=blub angelegt wurden, Samba die Konten aber unter ou=users gesucht hat. Fazit: bei mir (sowohl Samba 3.0.4 als auch 3.0.6) scheint die Option gnadenlos ignoriert zu weden :eek: Lösung: Alle Computer kommen auch in die organizationalUnit users, dann klappt's auch mit dem Nachbarn.. öhm.. Samba. :D

2) Drucker-Share verschwindet
Der Samba läuft auf einem SuSE 9.1-System und da dort ein Skript zum PDF-Drucken über gs mitgeliefert wurde (smbprngenpdf), dachte ich, daß ich das einfach mal nutze. Das klappte dann auch nach einigem Hin und Her nur leider verschwindet das Share pdf nach einiger Zeit spurlos. Es wird über smbclient -L nicht mehr aufgelistet und ist auch von einem Windows-Client nicht mehr ansprechbar, unabhängig davon, ob der PDF-Drucker dort schon eingerichtet wurde oder nicht.

3) Nach einigen Stunden reißt Samba den LDAP in den Tod
Dieser Fehler macht mir wirklich das Leben schwer. Der Server hält als PDC für meine alte Schule her, so daß er eigentlich nonstop laufen muß. Dummerweise kommt es ca. zwei mal am Tag (bei normaler "Schulnutzung") dazu, daß ein smbd-Prozeß sich aufhängt (die Clients merken davon übrigens nix) und dann pausenlos Anfragen an den LDAP schickt. Dabei frißt der Prozeß immer weiter Speicher bis alle 512 MB der Maschine aufgebraucht sind. Der Kernel macht dann irgendwann nach einer "Out of memory"-Meldung kurzen Prozeß und killt den smbd und leider auch den slapd, also den LDAP. Dieser kommt danach nicht mehr automatisch hoch, so daß der Server stillsteht. Während dieser Aktion ist der Server voll ausgelastet, und zwar so weit, daß z.B. ein Login via SSH nicht mehr möglich ist.

Da ich mal davon ausgehe, daß der ein oder andere hier schon mal einen Samba mit LDAP aufgesetzt hat, hoffe ich, daß Ihr ein paar Tips für mich habt. Gerade dieses letzte Problem läßt mir ehrlich graue Haare wachsen, weil es den Server für den Schulbetrieb unbrauchbar macht.

Infos zum System:
SuSE 9.1 Professional
LVM (mit striping)
AMD Athlon 1800+
512 MB RAM

Ich hänge hier mal meine smb.conf an, wenn Ihr noch mehr Infos braucht, dann bitte einfach fragen.

--- schnipp ---

# Global parameters
[global]
unix charset = UTF-8
dos charset = ISO8859-1
workgroup = WORKGROUP
netbios name = A027FS01
server string = Samba Server
interfaces = 192.168.0.5/24
bind interfaces only = Yes
hosts allow = 192.168.0.0/24, localhost, 127.0.0.1
client schannel = No
server schannel = No
socket options = TCP_NODELAY
map to guest = Bad User
passdb backend = ldapsam:ldap://192.168.0.5/
passwd program = /usr/local/sbin/smbldap-passwd %u
username map = /etc/samba/smbusers
log level = 3
log file = /var/log/samba/log.smbd.%m
max log size = 10000
timestamp logs = Yes
syslog = 0
smb ports = 445 139 137
printcap cache time = 750
printing = sysv
add user script = /usr/local/sbin/smbldap-useradd -m %u
add group script = /usr/local/sbin/smbldap-groupadd -p %g
add user to group script = /usr/local/sbin/smbldap-groupmod -m %u %g
delete user from group script = /usr/local/sbin/smbldap-groupmod -x %u %g
set primary group script = /usr/local/sbin/smbldap-usermod -g %g %u
add machine script = /usr/local/sbin/smbldap-useradd -w %u
logon path = \\a027fs01\profiles\%U
logon drive = P:
logon home = \\%L\%U\.9xprofile
domain logons = Yes
os level = 65
preferred master = Yes
domain master = Yes
wins support = Yes
ldap suffix = dc=xxx,dc=xxx
ldap machine suffix = ou=users
ldap user suffix = ou=users
ldap group suffix = ou=groups
ldap idmap suffix = ou=idmaps
ldap admin dn = cn=xxx,dc=xxx,dc=xxx
ldap ssl = no
ldap delete dn = Yes
printer admin = @domadmin, root, administrator
load printers = No
map archive = No
store dos attributes = Yes
time server = Yes

[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
inherit permissions = Yes

[profiles]
comment = Network Profiles Service
path = /profiles
read only = No
create mask = 0600
directory mask = 0700
profile acls = Yes
csc policy = disable
browseable = Yes

[netlogon]
comment = NetLogon Skripts
path = /home/samba/netlogon
browseable = No
write list = @domadmin, root, administrator
guest ok = Yes
read only = No

[public]
comment = Oeffentliches lesbares Verzeichnis
path = /public
create mask = 0655
directory mask = 0755
read only = No
inherit permissions = Yes
write list = @lehrergrp, @domadmin, root, administrator

[temp]
comment = Temporaeres Verzeichnis (ACHTUNG: wird naechtlich geloescht!)
path = /temp
create mask = 0644
directory mask = 0755
read only = No

[programme]
comment = Zentrale Windows-Programme
path = /programme
follow symlinks = Yes
wide links = Yes
read only = No
write list = @domadmin, root, administrator
create mask = 0644
directory mask = 0755

[cdrom]
comment = CD-Rom in A027FS01
path = /media/cdrom
read only = Yes
valid users = @domadmin, root, administrator

[dvd]
comment = DVD-Rom in A027FS01
path = /media/dvd
read only = Yes
valid users = @domadmin, root, administrator

[users]
comment = All users
path = /home
read only = No
browseable = Yes
inherit permissions = Yes
valid users = @domadmin, @lehrergrp
veto files = /aquota.user/groups/shares/

[alles]
comment = Root-Verzeichnis des A027FS01
path = /
browseable = No
read only = No
valid users = @domadmin, root, administrator

[pdf]
comment = PDF creator
path = /var/tmp
create mask = 0600
guest ok = Yes
browseable = Yes
read only = No
printable = Yes
lpq command = /bin/true
print command = /usr/bin/smbprngenpdf -J '%J' -c %c -s %s -u '%u' -z %z

--- schnapp ---

Also bis hoffentlich bald,

Rennie

emba
08.09.04, 23:30
hi

1) hättest du die man gelesen, wäre das sicher net passiert

ldap suffix (G)

Specifies where user and machine accounts are added to the tree. Can be overriden by ldap user suffix and ldap machine suffix. It also used as the base dn for all ldap searches.

Default: ldap suffix =

=> ldap machine suffix sollte dann laut deinem beispiel ("uid=computername$,ou=machines,dc=bla,dc=blub") auf "ou=machines,dc=bla,dc=blub" stehen

3) hast du nscd am laufen?

welche pid verursacht die ganzen netzwerksockets ? (netstat -tanup)

greez

Rennie
09.09.04, 09:54
Moin emba!

Erst mal danke für die recht schnelle Antwort :)

Zu dem ersten Punkt: Ich hab natürlich nicht nur die man pages gelesen, sondern auch ca. 15 verschiedene Samba + LDAP Howtos, ein Buch über LDAP im Allgemeinen und OpenLDAP im speziellen ("LDAP verstehen - OpenLDAP einsetzen") und den Official Samba 3 Guide (so ein 5hundertirgendwas Seiten Wälzer, aus dem ich aber nur die relevanten Teile rausgesucht hab). Die Konfiguration, die ich hier gepostet habe, ist die aktuell laufende. Soll heißen, da stand vorher ldap machine suffix = ou=machines, aber dann ist genau der unter 1 beschriebene Fehler aufgetreten (Accounts wurden korrekt angelegt, aber Samba hat sie trotzdem unter ou=users gesucht).

nscd hab ich nicht installiert. Das Tool kannte ich noch garnicht, klingt aber ja recht vernünftig. Werde ich mir mal ansehen. Auf die Sockets hab ich noch nicht geachtet. Das kann ich Dir leider erst sagen, wenn der Fehler wieder auftritt und ich auch das Glück habe, gerade auf der Maschine zu sein (arbeite nich fest bei der Schule, sondern bin eigentlich Programmierer beim Kaufhof, daher kann ich das nur aus der Ferne überwachen). Die PID des smd-Prozesses wechselt natürlich ständig. Die zwei mal, wo ich das live erlebt habe, waren es zwei unterschiedliche, was mich aber auch nicht sehr wundert, da Samba ja eh für jeden user einen neuen Prozeß startet und der eben auch immer 'ne neue pid bekommen sollte. Hast Du denn 'ne Idee woran das liegen kann?

Mir ist aufgefallen, daß ich die Maschine schon mit einem einfachen 'finger username' aus dem Tritt bringen kann. Zumindest kommt finger nicht mehr zurück und der LDAP kommt aus dem Suchen nicht mehr raus. Allerdings wird dabei kein Speicher verbraucht und das scheint auch (laut diversen Postings im Internet) an der ineffektiven Art des Namensvergleichs von finger zu liegen. Ich hab das mal getestet, indem ich in den LDAP nur 'ne Hand voll User gelegt habe und siehe da, dann klappt auch der "normale" finger, auch wenn der LDAP dann dennoch viel rödeln muß. Wenn die 1100 User im LDAP stecken, dann klappt nur noch ein "finger -m", mit dem man ja den Vergleich auf den vollständigen Namen abschaltet.

Also falls noch jemand eine Idee hat, was es sein könnte: ich bin ganz Ohr :D Denn mir gehen die Ideen so langsam aber sicher aus.


Renie

emba
09.09.04, 11:32
ich hatte auf einem pdc mal den nscd fatalerweise installiert, wodurch zuhauf sockets aufgemacht wurden und die kiste nicht mehr zugreifbar war

mit den pid's meinte ich es so, dass du netstat machen sollst und schauen sollst, ob smbd prozesse viele sockets aufmachen - schon klar, dass es immer neue pids sind bei neuen prozessen


Accounts wurden korrekt angelegt, aber Samba hat sie trotzdem unter ou=users gesucht

aber hast du denn nun beim ldap machine suffixe die basedn mit angehangen?

greez

Rennie
09.09.04, 11:42
Aha, na dann laß ich wohl vorerst mal die Finger von nscd. Das mit den Sockets kann ich mal prüfen, wie gesagt leider erst, wenn der Samba wieder Probleme macht (heute is glaub ich keine Schule, daher is das unwahrscheinlich).

Ich hab die base dn nicht an das ldap machine suffix angehangen. Das wäre laut Samba-Mailingliste auch falsch, da bei konfiguriertem ldap suffix dieses (zumindest bei Samba 3) IMMER an die anderen suffixe angehangen wird. Damit würde also ein

ldap suffix = dc=bla,dc=blub
ldap user suffix = ou=users,dc=bla,dc=blub

bei der LDAP-Abfrage zu "ou=users,dc=bla,dc=blub,dc=bla,dc=blub" werden. Und es funktioniert ja wie gesagt auch beim ldap user suffix richtig.


Rennie

mamue
09.09.04, 20:06
Es ist ein bekannter Bug, dass samba nicht so recht mit verschiedenen ou für computer und user klar kommt. Die jeweiligen accounts werden gefunden, können dort aber nicht angelegt werden. Ich lege deshalb die computer accounts händisch an.
Hast Du die neuesten schema files in das schema Verzeichniss von OpenLdap gelegt? In den zu 3.0.6 gelieferten war ein kleiner Fehler.
Ich halte mittlerweile nscd eher für ein Ärgerniss und sorge dafür, dass der nicht läuft.
Im übrigen finde ich es ungewöhnlich dass sich ein slapd aufhängt. Ein smbd hieng mit alten samba-versionen schon mal gelegentlich, aber noch nie ein slapd. Hast Du schon mal daran gedacht, OpenLdap selber zu übersetzen? Das geht eigentlich problemlos.

mamue

Rennie
09.09.04, 20:16
Moin!

Das mit dem Bug hab ich vermutet und auch schon mal was in der Richtung in einer Mailinglist gesehen. Leider klappt es bei mir nicht mal, wenn ich die Accounts von Hand anlege. Ich hab das über die smbldap-tools gemacht. Das Logfile des smbd ist dann sehr interessant, denn man sieht bei mir, daß er den Account über die Tools anlegt (kann ich auch im ldap über eine einfache Suche finden), aber samba sucht den neuen Account dann tatsächlich trotz der ldap machine suffix-Option unter uo=users. Naja, letztlich ist mir das recht wurscht, denn wenn Maschinen und User unter einer ou liegen, klappt es ja. Notfalls läßt sich sowas nachträglich auch noch sehr leicht im LDAP ändern. :)

Was den Hänger angeht: Es ist auch bei mir nicht der ldap der sich weghängt. Es ist ein smbd, der hängen bleibt, nur fragt der ohne Unterbrechung irgendwas beim LDAP an. Und derjenige, der den LDAP tötet ist dann irgendwann der Kernel, wenn der smbd sämtlichen Systemspeicher gefressen hat. Momentan will mir nichts so recht einfallen, mit dem ich dem Problem auf die Spur kommen könnte. Loglevel in slapd.conf und smb.conf hat nur einen größeren Haufen an Logfiles gebracht, in denen ich aber nichts auffälliges finden konnte.

Das mit dem selbst compilieren hab ich am WE vor.. Ich werde dann sowohl Samba als auch den LDAP mal selbst erstellen. Mal sehen, ob es was bringt.


HeadCrash

emba
10.09.04, 08:05
Das wäre laut Samba-Mailingliste auch falsch
hast recht, habe bei mir gerade noch mal in der conf nachgeschaut und auch keine basedn appended - sorry, dachte die docu ist up2date

hier mal meine relevanten ldap parameter

passdb backend = ldapsam:"ldap://nevanpdc.eva.mpg.de:389 ldap://nevanbdc.eva.mpg.de:389"
ldap passwd sync = yes
ldap suffix = dc=eva,dc=mpg,dc=de
ldap admin dn = uid=sambamanager,ou=users,dc=eva,dc=mpg,dc=de
#ldap filter = (&(objectclass=sambaSamAccount)(uid=%u))
ldap machine suffix = ou=machines
ldap user suffix = ou=users
ldap group suffix = ou=groups
ldap replication sleep = 2000

# idmap backend = ldap:ldap://nevanpdc.eva.mpg.de:389 ldap:ldap://nevanbdc.eva.mpg.de:389 -> funktioniert (noch) nicht
idmap backend = ldap:ldap://nevanpdc.eva.mpg.de:389
# ldap idmap suffix = ou=users
idmap uid = 10000-50000
idmap gid = 10000-50000


bei genauer betrachtung der ML fällt auf, dass samba 3.0.6 einige bugs enthält und ich somit (gerade in produktivumgebungen) noch nicht updaten würde (von 3.0.5) - evtl. hilft also eine ältere version


Ich halte mittlerweile nscd eher für ein Ärgerniss und sorge dafür, dass der nicht läuft

auf einem DC sollte er auch nie laufen, auf einem fileserver macht dies schon eher sinn (bei einsatz von NSS)

greez

mamue
10.09.04, 08:49
Der nscd bringt mir genau dann nichts als Ärger, wenn ich ihn am dringensten benötige. Ldap ist normalerweise sehr schnell, der nscd bringt IMHO keine nennenswerten Vorteile.
Ich glaube, ich haber derzeit auf dem einen Server 3.0.6 laufen und 3.0.5 auf dem anderen. Ich übersetze stets beide selber. Allerdings gleube ich, dass ich mir das mittlerweile genausogut sparen kann. Vor zwei Jahren _musste_ man den Compiler anschmeissen, wenn mal ldap-Unterstützung haben wollte, mittlerweile nicht mehr.
OpenLDAP übesetze ich immer noch gerne selber und zwar mit allen Optimierungsflags, die "mein" System so her gibt. Ich hatte dadurch durchaus schon die Systemlast etwas verringern können. Mittlerweile ist das aber auch nicht mehr so kritisch.

Mein (stümperhaftes) perl-script zum erstellen von compi-accounts:


#! /usr/bin/perl

#passwdGen.sh verwendet: "apg -a 0 -M cn -E 0O1lI -n 1 -m 8 -x 8"
open( PASSWD, "passwdGen.sh| " );
@machines = <STDIN>;
$lastUID = 10189;
$lastUID++;
foreach $machine ( @machines ) {
chop( $machine );
print "dn: uid=$machine\$,ou=hardware,dc=bbs1-emden,dc=schule\n";
print "objectclass: posixAccount\n";
print "objectclass: account\n";
print "objectclass: sambaSamAccount\n";
print "cn: $machine\$\n";
print "uid: $machine\$\n";
print "uidNumber: $lastUID\n";
print "gidNumber: 502\n";
print "homeDirectory: /home/$machine\n";
print "loginShell: /bin/false\n";
print "description: machine\n";
print "displayName: $machine\n";
#RID = (uidNUmber * 2) + 1000
$RID = ($lastUID * 2) + 1000;
print "sambaSID: S-1-5-21-1091375802-1471697927-1951840895-$RID\n";
print "sambaPrimaryGroupSID: S-1-5-21-1091375802-1471697927-1951840895-2005\n
";
print "sambaAcctFlags: [W ]\n";
print "l: 503\n";
print "\n";
#die Syntax hat sich bei samba3.0.6 geändert, daher .old!
system( "/opt/samba3/bin/smbpasswd.old -a -m $machine \"$pass\"" ) && die "unexpected smbpasswd error";
$lastUID++;
}

Fähigere Leute bekommen das sicher besser hin.
Damit lege ich meine PC-Accounts in ou=hardware ab. Da ich ohnehin erst einmal die MAC in dhcpd.conf und IP/Namen beim Nameserver eintrage, habe ich zuerst die Liste mit den Maschinen-namen. Dann kann ich auch gleich dieses script laufen lassen. Wenn man nur mal eben schnell einen neuen PC in die Domäne einbringen möchte, ist meine Vorgehensweise fürchterlich ineffizient.

Viel Spass,
mamue

emba
10.09.04, 11:25
Der nscd bringt mir genau dann nichts als Ärger, wenn ich ihn am dringensten benötige

kann ich hier nicht bestätigen


Ldap ist normalerweise sehr schnell, der nscd bringt IMHO keine nennenswerten Vorteile

wenn ich auf ein 4TB datenverzeichnis für etwa 1000 user ein ls -al loslasse, dann bringt mir der nscd schon enorme vorteile :)

in kleineren umgebungen ist dies sicher nicht notwendig, okay
aber für jede C-get funktion, für die nss_ldap vorgesehen ist, einen socket aufzumachen verzögert die geschichte dann schon

greez

mamue
10.09.04, 11:46
wenn ich auf ein 4TB datenverzeichnis für etwa 1000 user ein ls -al loslasse, dann bringt mir der nscd schon enorme vorteile :)

in kleineren umgebungen ist dies sicher nicht notwendig, okay
aber für jede C-get funktion, für die nss_ldap vorgesehen ist, einen socket aufzumachen verzögert die geschichte dann schon

greez

Wenn ich ein ls -l loslasse, dann gibt mir nscd einen Timeout und zwar bei Dateien, die der Gruppe gehören, wo alle drin sind. Ich bin dmait nicht der einzige und alle Optimierungsversuche scheiterten. Also genau da, wo es spannend wird, geht die Sache baden.
Samba3.0.6 ist AFAIK auch etwas resourcenschonender, weil eben nicht mehr für jede Anfrage eine neue Verbindung zum LDAP aufgebaut wird. Zusammengenommen bringt der nscd IMHO wirklich nicht so ganz viel.
Zum Thema:
In den samba-release notes steht:
"This is the latest stable release of Samba. This is the version
that production Samba servers should be running for all
current bug-fixes."
"Fix stalls in smbd caused by inaccessible LDAP servers."
Sind vielleicht in der /etc/ldap.conf oder der smb.conf mehrer ldap-server konfiguriert, von denen einer nicht erreichbar ist?

HTH,
mamue

Rennie
10.09.04, 11:50
Hi!

Na hier geht ja richtig was ab, wenn auch nicht ganz zum eigentlichen Thema *g*

Zu Deiner Frage: Nein, es gibt nur einen LDAP-Server und es ist auch nur einer konfiguriert.

Gerade ist der Server wieder abgeschmiert :-(
Es scheint immer ein smbd zu sein, der im Kontext des Users nobody läuft. Ich muß mal genau nachsehen, was der da wollte.


Rennie

emba
10.09.04, 12:07
Es scheint immer ein smbd zu sein, der im Kontext des Users nobody läuft. Ich muß mal genau nachsehen, was der da wollte.

IPC$ verbindungen


Wenn ich ein ls -l loslasse, dann gibt mir nscd einen Timeout und zwar bei Dateien, die der Gruppe gehören, wo alle drin sind. Ich bin dmait nicht der einzige und alle Optimierungsversuche scheiterten. Also genau da, wo es spannend wird, geht die Sache baden.

habe dies versucht zu reproduzieren:

- habe ein ls -lR auf ein fast volles 4TB raid gemacht
- dort sind alle daten der ~1000 user drauf => viele getusername/group functions
- dort ist auch die "user" standardgruppe immer gesetzt, in der alle user drin sind

flutscht alles einwandfrei :) (noch)

läuft mit 3.0.4 und ldap 2.1 (letzters nur auf dem PDC)


"This is the latest stable release of Samba. This is the version
that production Samba servers should be running for all
current bug-fixes."
okay, lass sie das schreiben
aber ich denke, du verfolgst ebenso die ML wie ich
und da fallen mir schon gravierende bugs/änderungen auf, die es bei vorigen updates nicht gab (ok, da warens nur kleinere bugs *g)

greez

mamue
10.09.04, 16:23
Hi!

Na hier geht ja richtig was ab, wenn auch nicht ganz zum eigentlichen Thema *g*

Zu Deiner Frage: Nein, es gibt nur einen LDAP-Server und es ist auch nur einer konfiguriert.

Gerade ist der Server wieder abgeschmiert :-(
Es scheint immer ein smbd zu sein, der im Kontext des Users nobody läuft. Ich muß mal genau nachsehen, was der da wollte.


Rennie

Ich bin an dieser Stelle mit meinem Latein ziemlich am Ende.
Denkbar wäre, dass einige tdb defekt sind, hast Du schon mal tdbdump probiert?
Eventuell wäre dann noch die usermap zu prüfen, ob dort ungültige Einträge enthalten sind oder ob alle Groupmappings vorhanden sind. Ich glaube als erstes würde ich die *.tdb testen und danach samba neu übersetzen mit -O2.

HTH,
mamue

Edit: @emba: in einer Gruppe sind bei mir leider ~5000 Einträge, ein "ls -l slowFile" dauert stets 3-5 Sekunden. Wenn ich nscd starte, geht es schneller, aber ich bekomme nur die gidNumber anstelle des Bezeichners ;-)
Vielleicht ist Deine CPU aber auch einfach erheblich fixer, ich habe "nur" einen P-III mit 1GHz.

Rennie
12.09.04, 14:22
Moin!

So, ich hab mal wieder ein paar neue Infos, die mir persönlich noch nicht viel weiterhelfen, aber vielleicht hat ja jetzt noch jemand von Euch eine Idee.

Ich hab gerade eben live einen solchen "Absturz" miterlebt. Die Situation ist wie folgt:

Ein WinXP-Rechner steht unmotiviert im Anmeldebildschirm in der Gegend rum unt tut nichts. Meint man zumindest. Es gibt keine Verbindungen zum Samba. Plötzlich baut aber dieser besagte nichts tuende XP-Rechner eine (in meinem Fall gerade eben sogar 3) Verbindung zum Samba auf und versucht über IPC$ anscheinend an alle Benutzerinfos zu kommen (Suche auf die Base ou=users,dc=irmgardis,dc=de mit scope one). Der LDAP versucht nun 1161 Sätze zurückzugeben, ABER er tut dies seltsamerweise nicht auf einen Schlag, wie er das bei einem ldapsearch macht, sondern er gibt zunächst nur 1000 Einträge zurück und liefert dann die 161 nach. Leider scheint genau da das Problem aufzutreten, denn diese 161 Einträge werde in einer Endlosschleife immer und immer wieder geschickt (zumindest sieht es im Logfile so aus). Dasselbe Phänomen hatte ich schon mal bei KDE bzw. beim KDM, wenn dieser versucht, alle Userdaten für den Anmeldebildschirm zu lesen. Dabei lief die Suche auch grundsätzlich in eine Endlosschleife, was ich bisher einfach damit behoben habe, daß ich die Userliste aus dem KDM entfernt hab.

Derzeit kann ich mir nicht erklären, was da bei der Suche fehlschlägt, denn ein ldapsearch mit derselben Suchanfrage läuft problemlos durch. Die Beschränkung der Ergebnismenge habe ich per limits ausgeschaltet, so daß ich nicht mal verstehe, warum der LDAP nach 1000 Einträgen einen Schnitt macht. Ob der Client selbst ein Limit vorgegeben hat, kann ich aus dem Logfile leider nicht erkennen.

Hilft das vielleicht jemandem hier weiter? Hatte schon mal jemand so ein ähnliches Problem?

Hier mal ein Auszug aus dem Logfile, der das Verhalten zeigt:

Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 fd=25 ACCEPT from IP=192.168.0.5:33442 (IP=0.0.0.0:389)
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=312 op=6 UNBIND
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=312 fd=24 closed
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=0 BIND dn="" method=128
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=0 RESULT tag=97 err=0 text=
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=1 SRCH base="ou=groups,dc=irmgardis,dc=de" scope=1 deref=0 filter="(&(objectClass=posixGroup)(gidNumber=512))"
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=1 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=2 SRCH base="ou=users,dc=irmgardis,dc=de" scope=1 deref=0 filter="(objectClass=posixAccount)"
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=2 SEARCH RESULT tag=101 err=0 nentries=1000 text=
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=3 SRCH base="ou=users,dc=irmgardis,dc=de" scope=1 deref=0 filter="(objectClass=posixAccount)"
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=3 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=4 SRCH base="ou=users,dc=irmgardis,dc=de" scope=1 deref=0 filter="(objectClass=posixAccount)"
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=4 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=3 SEARCH RESULT tag=101 err=0 nentries=161 text=
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=5 SRCH base="ou=users,dc=irmgardis,dc=de" scope=1 deref=0 filter="(objectClass=posixAccount)"
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=5 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=4 SEARCH RESULT tag=101 err=0 nentries=161 text=
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=6 SRCH base="ou=users,dc=irmgardis,dc=de" scope=1 deref=0 filter="(objectClass=posixAccount)"
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=6 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=5 SEARCH RESULT tag=101 err=0 nentries=161 text=
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=7 SRCH base="ou=users,dc=irmgardis,dc=de" scope=1 deref=0 filter="(objectClass=posixAccount)"
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=7 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Sep 12 13:24:30 a027fs01 slapd[4190]: conn=313 op=6 SEARCH RESULT tag=101 err=0 nentries=161 text=


Ciao

Rennie

senseipetz
12.09.04, 18:32
/etc/ldap.conf

und zwar wie er bei
################################################## #############################
# Host ist wohl jedem klar.. muss übereinstimmen.. Man kann auch LINUX2.TUX-NET machen.#
# Allerdings muss Linux2.TUX-NET DNS mässig auflösbar sein.Das ist der Hacken.. #
################################################## #############################
host 10.0.0.140
################################################## ##############################
# The distinguished name of the search base. Erleutrn muss man dies nicht.. Die Base-Adresse #
# worauf der Server zuerst gesucht werden soll #
################################################## ##############################
base dc=berlin-home,dc=local
ldap_version 3
# Das Binddn muss nicht unbedingt rein. Wenn was nicht funktionieren sollte, kann man es #
# rausnehmen, da die Accesscontroll vom Server auf * steht. #
#binddn cn=nssldap,ou=DSA,dc=berlin-home,dc=local
#bindpw nssldapsecret
port 389
scope sub
pam_password md5
nss_base_passwd ou=Users,dc=berlin-home,dc=local?one
nss_base_shadow ou=Users,dc=berlin-home,dc=local?one
nss_base_group ou=Groups,dc=berlin-home,dc=local?one
ssl No

dann sucht der auch der slapd auch in der richtigen stelle.. Unter Suse ldap ist mir aber auch aufgefallen, dass nur wenn man per yast/ oder auch manuel den LDAP client sauber konfiguriert(auch in der erweiterten konfiguration(Admin DN <pfad mit cn=Manager,dc=berlin-homedc=local) setzt) kann er auch lokal die ldap konten im linux filesystem lesen.

mamue
12.09.04, 20:52
Ldap gibt standardmässig nur 1000 Einträge zurück, man kann angeblich in der /etc/openldap/ldap.conf (oder war es die slapd.conf?) die Grenze aufheben, indem man sie auf 0 setzt. Ich kenne diesen Effekt, wenn ich unter Windows im Datei-explorer die Rechte einer Datei ändern möchte und versuche, einem weiteren user zusätzliche Rechte zu geben. Dann werden ebenfalls sämtliche user aufgelistet und das dauert einige Zeit (~5min). Noch hat kein Anwender bemerkt, dass er damit zuverlässig einen DoS-Angriff durchführen könnte...
Warum versucht XP alle user auszulesen, das macht doch gar keinen Sinn? Das wäre ja fatal, wenn das jeder PC bei jedem Start versuchte.
Wie gesagt, dass ldap nur 1000 Sätze zurückgibt, ist völlig normal. Ich habe einen XP client gelegentlich in meinem Netz und so etwas ist mir bislang noch nicht aufgefallen.
Vielleicht doch die *.tdb oder die OpenLDAP-version?

mamue

Rennie
12.09.04, 23:42
Moin!

So, ich habe jetzt noch einiges rumprobiert mit Samba und LDAP.

@senseipetz:
Ich hatte bisher mit dem LDAP an sich keinerlei Probleme (außer am Anfang natürlich erst mal die Grundsätze eines solchen System zu verstehen und durch sowas wie ObjectClasses usw. durchzublicken). Er ist bei mir vollständig ins System eingebunden, und es können sich alle User lokal anmelden, so wie es sein soll (auch wenn sie das niemals tun werden).

@mamue:
Der LDAP gibt - zumindest unter SuSE - sogar nur 500 Einträge zurück. Man kann das tatsächlich in der /etc/openldap/slapd.conf mit der Option "limits" ändern. Das meinte ich ja auch mit "ich habe die Beschränkung per limits ausgeschaltet". Mein LDAP gibt also jetzt standardmäßig alles zurück, was auf den Suchfilter paßt. Wenn es tatsächlich ein solches Limit gewesen wäre, was da zugeschlagen hätte, dann hätte man das aber im Logfile sehen müssen. Der LDAP gibt nämlich dann neben der maximalen Anzahl an Einträgen auch einen Errorcode "limit exceeded" zurück. Dieser kam aber nicht (erkennt man am err=0 in "SEARCH RESULT tag=101 err=0 nentries=1000"). Daher wundert mich das etwas.

Aber wie gesagt, ich habe noch mal alles mögliche ausprobiert, noch mal Samba 3.0.2a von der SuSE-DVD installiert, was garnicht richtig wollte (der hat die Groupmappings nicht mehr gefunden, obwohl net groupmap list sie korrekt angezeigt hat). Dann habe ich noch mal ganz in Ruhe die 3.0.6er RPMs von der Samba-Seite eingespielt und das hatte zumindest schon mal einen positiven Effekt: der vorher ständig verschwindende PDF-Drucker bleibt nun bestehen. Ich geh mal davon aus, daß das ein Indiz dafür ist, daß vorher irgendwas in meinem Samba schief hing (was genau weiß der Teufel). Da ich danach mit dem besagten XP-Rechner das seltsame IPC$-Phänomen nicht mehr hinbekommen habe, hoffe ich jetzt einfach mal ganz stark, daß sich das Problem von selbst behoben hat. :cool:

Ich werde das allerdings weiter fleißig beobachten und mich ggf. noch mal melden. Jedenfalls konnte ich bisher noch keinen Anhaltspunkt dafür finden, warum der LDAP so seltsam rumsucht (oder irgendein Client so seltsam anfragt).

Ich danke Euch jedenfalls noch mal für alle Vorschläge und Ideen und melde mich ggf. noch mal, wenn das Problem weiterhin auftritt. Ich klopf jetzt jedenfalls mal auf Holz, daß es wech is.


Ciao

Rennie

mamue
13.09.04, 11:39
Das freut mich zu hören. Ich habe übrigens ebenfalls die limits aufgehoben, allerdings ebenfalls mit dem Effekt, dass max. 1000 Einträge geliefert werden. Auch ich erhalte meines Wissens keine Meldung im ldap-log. Es ist allerdings schon recht lange her, dass ich mich darum bemüht hatte.

mamue

Rennie
13.09.04, 11:58
Hi!

Also es scheint tatsächlich keine Probleme mehr zu geben. Wo Samba Ende letzter Woche noch mind. zwei mal täglich abgeschmiert ist, läuft es heute einwandfrei durch. *nochmalaufholzklopf*

Hatte sich wohl doch etwas bei der Samba-Installation verhakt. Jedenfalls bin ich noch guter Dinge, denn der Server wird ordentlich genutzt und muckt nicht.

@mamue:
Liefert Dir auch ein ldapsearch z.B. auf (objectClass=*) nur 1000 Einträge? Das fänd ich dann schon etwas seltsam. Aber solange es da keine Probleme gibt, einfach zurücklehnen und froh sein, daß es läuft ;)


Ciao

Rennie

mamue
14.09.04, 10:37
Hi!
@mamue:
Liefert Dir auch ein ldapsearch z.B. auf (objectClass=*) nur 1000 Einträge? Das fänd ich dann schon etwas seltsam. Aber solange es da keine Probleme gibt, einfach zurücklehnen und froh sein, daß es läuft ;)
Rennie

Yep, so ist es. 1000 Einträge und eine Fehlermeldung. Irgendwann schau ich mir das noch mal an, möglicherweise habe ich das in dr falschen Konfigurationsdatei geändert, da ich OPenLDAP nach /opt/openldap2 übersetzt habe, passiert so etwas leicht.

mamue

Rennie
20.09.04, 14:51
Moin!

Ich bin's noch mal. Nachdem ich ja berichtet hatte, daß ich nun keine Probleme mehr habe, trat der Fehler heute noch mal auf. Und diesmal weiß ich sogar woran es lag :D

Ich habe gestern festgestellt, daß ich das limits-Statement aus der slapd.conf genommen hatte, wodurch mein LDAP wieder nach 500 Einträgen Schluß macht. Nicht schön, hab ich mir gedacht und hab das Statement wieder eingebaut (limits * soft=-1 hard=soft). Dann natürlich Samba noch mal getestet und keine Probleme gehabt. Heute morgen klingelt mein Handy -> selbes Problem. Es hat sich wieder ein smbd im Kontext des Users nobody "aufgehangen" und den LDAP zugemüllt.

Nachdem ich jetzt das limits-Statement wieder rausgenommen habe, und damit die Anfragen wieder auf 500 Einträge beschränkt habe, klappt das mit dem Samba wieder einwandfrei.

Um mal zu testen, ob mir denn jetzt User fehlen (z.B. im Dialog zur Vergabe der Berechtigungen unter WinXP), hab ich einfach mal ein pdbedit -L gemacht und erwartet, daß er nach 500 Usern Schluß macht. Aber zu meinem Erstaunen hab ich alle 1161 User zurückbekommen.

Nunja, wie dem auch sei, es läuft nun. Falls aber jemand eine Idee hat, warum sich der Rechner so verhält wie er sich verhält, dann bitte posten! Mich würde ja schon interessieren, was da so abgeht; denn normal finde ich dieses Verhalten nicht.


Ciao

Rennie

emba
14.10.04, 12:53
nochmal zum thema samba und ou's

habe auch gerade damit zu tun gehabt, dass samba die computer accounts nicht recht finden mag, wenn man in der ldap.conf im etc die nss_base für passwd/shadow zu tief setzt

bsp:

ou=computers,dc=domain,dc=org
ou=users,dc=domain,dc=org

wird in /etc/ldap.conf zu

nss_base_passwd dc=domain,dc=org
nss_base_shadow dc=domain,dc=org

dann findet samba auch accounts, die nicht in users liegen
evtl. hilft es dem ein oder anderem

greez

senseipetz
14.10.04, 22:27
hab ich das nicht etwas früher auch schon geschrieben gahabt :D

emba
14.10.04, 23:09
@sensei

keine ahnung ;)
bin nur selbst drauf gestoßen grad, weil ich eben bei einem projekt mal auf die idealx scripten zurückgegriffen habe

und da wollt ich das nur kund tun

sorry

greez