-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 openLDAP 2.3? Um Himmels Willen. Das wäre ja quasi Steinzeit. Sorry, kleiner Spaß. ;-) Nein, im Ernst: auch hier gilt die Aussage "das aktuellste, was geht". Musste in dem Fall auch sein, weil das LDAP-Release der SLES11 einige benötigte Features noch nicht bereit stellt und, davon abgesehen, so rund läuft, wie ein Sack Nüsse. Am 03.03.2010 17:10, schrieb Markus Heinze:
Hmm, nutzt Ihr OpenLDAP <= 2.3 oder schon >=2.4 ?
Am 03.03.2010 16:53, schrieb Stefan Jurisch: Haben wir. Das Ergebis war, wie kurz erwähnt, dass kein LDAP-Traffic mehr auf dem Master ankommt (auch nicht am Interface), zeitgleich ebenfalls an diesen gerichteter I/O jedoch sehr wohl (z.B. DNS-Queries).
Am 03.03.2010 16:45, schrieb Markus Heinze:
Also mal ganz pragmatisch würd ich den Netztraffic mitsniffern und schauen ob überhaupt etwas ankommt ;)
lg max
Am 03.03.2010 16:02, schrieb Stefan Jurisch: Hallo miteinander,
seit einiger Zeit schrauben mein Kollege und ich - er zum größeren Teil - an einem bislang nicht gelösten Problem herum, das uns so langsam aber sicher den Verstand raubt - oder zumindest mich allmählich gehörig dran zweifeln lässt, dass ich jemals mit Computern zu tun hatte. ;-)
Uns gehen inzwischen echt die Ideen aus, und das trotz 2x rund 25 Jahren Hackerei und quasi Großwerdens mit Drahtköppen verschiedenster Generationen... oder wir stehen einfach nur *derart* auf dem Schlauch.................... Weil es sich um ein sehr spezielles Thema handelt, denke ich auch nicht, dass ich hier jemanden - obwohl ich es nie ausschließen würde - mit der Knaller-Lösung finde, aber selbst über eventuell frische Denkansätze und Ideen wäre ich schon froh!!!
Aber erst einmal zur Problembeschreibung, beginnend mit der vorhandenen Hardware etc.: Wir haben einen VMware-Cluster, bestehend aus drei ESX4-Hosts; dazu einen vCenter Server mit MSSQL-Express-Datenbank (reicht in der Größenordnung lange aus) und ein Infortrend Storage Array in einem Fibre Channel SAN, auf das von den Maschinen über jeweils einen 2-channel-HBA mit 4GBit zugegriffen wird. Jeder der 3 ESX-Hosts besitzt 4 NICs, je zwei on-board und 2 als Zusatzkarte (PCIe). Die Physik stammt von HP (DL360). Alles in allem absolut aktuell, bis hin zu Patches, angefangen bei der Firm- über die Software bis hin zu den OSes auf den VMs. In dieser Umgebung existieren mehrere Virtuelle Maschinen auf Basis von SLES11, auf denen jeweils ein openLDAP-Slave und SAMBA3.4.x laufen, wobei das LDAP natürlich das Backend für SAMBA stellt. Allen VMs beziehungsweise den darauf laufenden LDAP-Daemons dient eine ebenfalls aktuelle SLES11-DL360-Physik als Master zur Verfügung. Alle Maschinen, ob physisch oder virtuell kommunizieren TLS-gesichert innerhalb einer DMZ über Gigabit-Ethernet mittels IPv4.
Grundsätzlich läuft das ganze Konstrukt gut und stellt alle Funktionen, die man benötigt - wenn man so etwas aufbaut - völlig intakt bereit... allerdings nur über mehrere Stunden bis zu einem gewissen Punkt, an dem plötzlich keine Passwortänderungen auf den Slaves, und damit auch über SAMBA, mehr möglich sind! Das Kuriose an der Sache ist, dass selbst bei höchsten Debug-Stufen in openLDAP und SAMBA keine Ursache dafür angegeben wird. Die Passwortänderung wird auch scheinbar ohne Fehler abgeschlossen, aber der Traffic muss irgendwo "versanden", denn auf dem Master kommt er nicht an - nicht nur nicht im Log, sondern gar nicht erst auf dem Interface. Spannend ist, dass dazu parallel angelegter Traffic normal läuft - es ist also *keine* unterbrochene Verbindung. Startet man den LDAP-slave-daemon einmal neu, geht wieder alles ohne jegliche sonstige Maßnahme.
An sich haben wir schon alles an Standardlösungen ausprobiert, die uns irgendwie eingefallen sind. Die VMware ist schon genauestens untersucht worden, und auch die LDAP- und SAMBA Configs sind mehr als nur 10x überholt worden. Es gab einige Hinweise zu finden, dass dies ein Kernelproblem in Verbindung mit Virtualisierung sein *könnte*, aber erhärtet hat sich das nicht. Wir sind auch nicht in der Lage, mit allerletzter Überzeugung wenigstens die Hauptursache genauer zu spezifizieren. Vieles deutet auf openLDAP hin, doch auch dort konnte bis jetzt noch niemand einen genauen Hinweis geben - entweder, weil es nicht daran liegt, oder weil das Problem einfach nicht erklärbar ist (???)...
Wie gesagt, ich hoffe nicht auf *die* Lösung - auch wenn sie mich freuen würde - aber jeglicher Denkanstoß ist willkommen.
Nur bitte, fragt mich nicht nach Configs... da allein die für openLDAP mehrere 100 Zeilen ACLs umfasst, wäre das Verschleiern entsprechender vertraulicher Datenanteile ein wenig anstrengend, und das Riskio, etwas zu übersehen, ein wenig zu hoch. Dafür bitte ich um Verständnis.
Ich Bitte um Regen in meine Gedankenwüste. ;-)
Grüße Stefan
- -- • S T E F A N • J U R I S C H • ====================================== System Engineer • Department VMware® Software Development ====================================== SIEGNETZ.Informationstechnologie® GmbH Schneppenkauten 1a • DE 57076 Siegen phone +49 271 68193 -0 • facsimile -28 web www.siegnetz.de • info@siegnetz.de Geschäftsfuehrer: Oliver Seitz Amtsgericht Siegen HRB4838 Sitz der Gesellschaft ist Siegen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuOjG8ACgkQqdb99cbyCz7C/QCeN2CaFvi04zCqPht8q12G0nNd BBMAoJj3wzxA17nv7Slzq5nUx8qOGpix =mv+F -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org