-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 03.03.2010 16:10, schrieb Ralf Prengel:

Geht da ggf. ein Routing pder ähnliches plötzlich durcheinder.

Das haben wir schon ausgeschlossen. Die Maschinen hängen sowieso gemeinsam an einem Switch in einer DMZ - also auch der LDAP-Master. Laut seiner eigenen Auskunft hat der Switch auch keinen Defekt, was wir aber noch selbst mittels Austausch prüfen wollen. Gruß 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/ iEYEARECAAYFAkuOgjQACgkQqdb99cbyCz4Q6wCgnIzzbnCxMwItuC2KQiqMny+E 3gcAoICrUutGc3gG+4ykh8ndt5oo5J1W =A+M1 -----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mit openLDAP in der Tat ein heikles Thema wegen der syncrepl timestamps, kann aber hier ausgeschlossen werden. Die Uhren sind sogar unter heavy-load im Toleranzbereich weniger Millisekunden synchron. Am 03.03.2010 16:15, schrieb Frank Mueller:

Hmm, nur mal so in den Raum gestellt, falls die ganze Geschichte auf Zeitstempel passiert, das die Uhren in den einzelnen VMs nicht synchron laufen, da virtualisiert..

Gruss Frank

Quoting 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

...

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

...

-- 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

- -- • 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/ iEYEARECAAYFAkuOgs0ACgkQqdb99cbyCz6N0gCfWO1h4roMHN4MW7Vw1z2BOC71 GnUAoJ7Y/Yg+w/0Fc5QD39gzBwLC+Zhj =0Vrk -----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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/ iEYEARECAAYFAkuOhfYACgkQqdb99cbyCz601gCffj4eQqxilqf3SpCzyyO9QER5 b+YAnR+DGvrdBU5JC/lHkaD0Y7ex64bp =FtQQ -----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, Am 03.03.2010 16:59, schrieb Axel Birndt:

...

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).

sind evtl priv. Firewalls auf den Knoten aktiv ??

Ein Satz, der bei uns in der Firma immer wieder gern fällt, wenn etwas nicht läuft: "Das liegt bestimmt an der Firewall!" ;-) Das tut es meist auch, nur dieses Mal ausnahmsweise leider nicht. Es sind zwar welche konfiguriert und hochgefahren, aber die benötigten Ports sind alle offen, und private Walls können aus zwei Gründen nicht laufen: 1. es sind dedizierte Server ohne Desktop und direkten User-Access 2. Nur wir haben die Macht. ;-) In diese Richtung wäre das Erscheinungsbild des Fehlers wenigstens logisch, gerade in Bezug auf den nur anteilig verschwindenden Traffic. Aber weder auf Source noch Destination wird er in einem FW-Log protokolliert. Gruß 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/ iEYEARECAAYFAkuOizcACgkQqdb99cbyCz7eAwCaAk5vMiRM8yApv+4E1JYbD87f l4EAn0B//7175PDVCFH/IVWDwpu579TK =MExe -----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

-----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 04.03.2010 09:08, schrieb Dieter Kluenter:

...

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).

Warum sollte den LDAP-Trafic sein, wenn contextCSN nicht geändert wurde, oder syncrepl refeshOnly konfiguriert wurde, das schreibt du ja nicht.

Sorry für die späte Antwort - leider erkrankt. :-( Aber es müsste ja Traffic auftreten, sobald ich bspw. eine Auth gegen LDAP versuche bzw. vielmehr versuche, eine Änderung des Passworts durchzuführen. Das Passwort wird, wie alle Änderungen auf dem Slave, per overlay chain auf den Master "ge'pushed". Im Übrigen ist auch die korrekte Replikation von diesem seltsamen Ausfall betroffen. Die Konfiguration des repl-mode hat keinen Einfluss auf das Verhalten. Gruß 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/ iEYEARECAAYFAkuWAhgACgkQqdb99cbyCz4fWgCeKtF3oYGFLy0063s0IWPWA5tk T4YAnjDoQLky3KUNgpwlgNEaQRhSnL2a =nRKl -----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.03.2010 20:14, schrieb Ralf Prengel:

Alternativ mal auf einem geeignetem System ein Citrix-Xen aufsetzten, und die Systeme kopieren/ migrieren.

Da es sich hier nicht um unser eigens System handelt, und sich auch niemand mit XEN auskennt, ist das eher weniger eine Alternative.

Dann mal schauen ob der Fehler da auch auftaucht. Wenn ja in den virtuellen Systemen suchen wenn nein ggf. ein Querschuß von ESX. Kann natürlich an fehlender geeigneter Hardware scheitern.

Die Hardware ist auch weniger der Killer. Es handelt sich um ein Produktivsystem, das nach allen von VMware gesetzten Maßstäben gebaut wurde, um Support zu gewährleisten.

Mal unter www.vmware-forum.de dein Problem geschildert. Da tummeln sich einige echte Cracks.

Das stimmt, aber da ich es bisher nicht für ein VMware-Problem gehalten habe... ich habe aber schon im offiziellen Forum gewühlt, wie ein Trüffelschwein, aber auch nichts wirklich substanzielles gefunden.

Das Arcviv der mailingliste von openldap hast du auch schon durchsucht?

Stunden lang.

Die Anwendungen selber sind nicht auch noch geclustert?

Nein, macht ja wenig Sinn. Aber selbst wenn, dürfte das eigentlich kein Problem sein, da auch das in einer Testinstallation schon funktioniert hat. Gruß 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/ iEYEARECAAYFAkuWA/sACgkQqdb99cbyCz4PtgCgnBLSYCtTdV0oHrROXMXhur5A p94An1ycHAtNqqjlgVwQi4l461vwUk8J =ENy6 -----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 04.03.2010 09:04, schrieb Dieter Kluenter:

Ein Frage vorweg, ist das Chainig-Problem in diesem Setup? Du sagst hier wenig zu OpenLDAP und Samba. Prinzipiell ist wohl die bessere Mailingliste für solche Fragen. Aber ich werde versuchen, mal hier die Fragestellung zu präzisieren.

Mein/unser Problem ist ja, dass wir dort keine Antworten erhalten haben, die uns weiter gebracht hätten; zumindest bis ich mich krank in die Kiste geschmissen habe. Du könntest das Problem aber kennen, denn meinem Kollegen Ralf hast Du, wenn ich es richtig verfolgt habe, schon eine Antwort in o.g. Liste geschrieben. Nur konnte ich dann nicht mehr verfolgen, in wie weit er sie verwerten konnte.

- welche OpenLDAP Version?

2.4.22

- Wie ist syncrepl konfiguriert

beide modes in diversen Varianten versucht - jeweils das gleiche.

- verwendet ihr smbk5pwd

*Das* weiß ich nicht genau, ich glaube aber nicht.

- ist eine password-hash Methode konfiguriert?

SHA1, wenn ich mich nicht täusche. Aktuell habe ich übrigens den Eindruck, als sei das Problem gelöst. Aber das sah zwischendurch schon einmal so aus, weshalb ich mal noch nicht davon ausgehe. Gruß 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/ iEYEARECAAYFAkuWBigACgkQqdb99cbyCz7zlgCgiMGz+ZdH8jKlUc30a9ub1s4E dkkAn0bPNOvMZxBhzVySbucGLC/s/eAZ =jA2a -----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 09.03.2010 11:31, schrieb Dieter Kluenter:

...

Mein/unser Problem ist ja, dass wir dort keine Antworten erhalten haben, die uns weiter gebracht hätten; zumindest bis ich mich krank in die Kiste geschmissen habe. Du könntest das Problem aber kennen, denn meinem Kollegen Ralf hast Du, wenn ich es richtig verfolgt habe, schon eine Antwort in o.g. Liste geschrieben. Nur konnte ich dann nicht mehr verfolgen, in wie weit er sie verwerten konnte.

Ja, mit Ralf habe ich ein Chaining- und TLS-Problem diskutiert.

Ja, ich kann mich da ganz im Groben an etwas erinnern.

...

...

- ist eine password-hash Methode konfiguriert?

SHA1, wenn ich mich nicht täusche.

Das kann Probleme geben, falls passwordPolicy benutzt wird.

Das ist sogar eine mögliche Fehlerquelle, weil wir tatsächlich die passwordPolicy benutzen müssen.

...

Aktuell habe ich übrigens den Eindruck, als sei das Problem gelöst. Aber das sah zwischendurch schon einmal so aus, weshalb ich mal noch nicht davon ausgehe.

Falls da noch einmal Probleme auftreten sollten, die darauf hindeuten, dass syncrepl nicht richtig funktioniert, einfach einen eigenen simplen syncrepl Client von mehreren Hosts laufen lassen, entweder mit Perl Net::LDAP::Control::SyncRequest oder ein kleines Shellscript mit ldapsearch, ein kleines Muster findest du hier: http://pastebin.de/4466

Den contextCSN host du mit ldapsearch -b <base> -s base contextcsn

Ich habe eben telefoniert, und tatsächlich ist seit Tagen der Fehler nicht mehr aufgetreten. Es ist nur nicht ganz sicher, ob es an einem Kernel-Boot-Parameter liegt, den ich gesetzt habe, oder an einigen Änderungen, die Ralf in der LDAP-Config gemacht hat, weil wir dummerweise ungeduldig waren - naja, uns rennt die Zeit ein wenig davon - und die Mods gleichzeitig gemacht haben. ;-) Dennoch werde ich ihm auch einmal Deine Antwort weiterleiten und ihm auch das Script-Beispiel zukommen lassen, wenn Du nichts dagegen hast. Danke sehr einstweilen. Gruß 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/ iEYEARECAAYFAkuWPN0ACgkQqdb99cbyCz5FJwCfbrrqzM6RhEUv4405Kez2SDU+ nKIAn20c81qTLSh3WZL+Fj8WF1J4aJBX =LLdB -----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Sandy, Am 09.03.2010 10:38, schrieb Sandy Drobic:

Das sieht für mich wie ein Problem mit dem Session-Management aus, sprich, ein Timeout-Problem, wo danach die Kommunikation abreisst.

Das hatten wir an sich schon ausgeschlossen, aber wie ich eben Dieter schon schrieb, haben wir zeitgleich Änderungen an LDAP und Bootparams durchgeführt, wobei letztere mit "clocksource=pit" durchaus auf ein Timing-Problem mit der virtualisierten APIC abzielt.

...

Wie gesagt, ich hoffe nicht auf *die* Lösung - auch wenn sie mich freuen würde - aber jeglicher Denkanstoß ist willkommen.

Ich habe hier ein ähnliches Problem, wo ein TSM-Client in der DMZ wochenlang im Backup lief und jetzt plötzlich keine Verbindung mehr zum Server aufbauen kann. Oder der Webserver, von dem nur 15 Minuten lang heruntergeladen werden konnte.

Das klingt wirklich ähnlich, wobei bei unserem Problem zum Glück mehrere Stunden dazwischen liegen, so dass zumindest das Arbeiten einigermaßen möglich ist.

Gibt es irgendwelche Firewalls zwischen oder auf den Rechnern, die die Kommunikation stören können?

Es gibt Firewalls direkt auf den Kisten, aber die maßgeblichen Port sind offen. Es werden auch keine Drops, Rejects oder ähnliche ge'logged. Momentan sieht es seit Tagen so aus, als habe sich das Problem durch die letzten Anpassungen erledigt; entweder meinen Kernel-Param oder die Änderungen meines Kollegen, wobei ich die leider nicht beschreiben kann, weil ich dies nicht 100%ig verfolgen konnte. Gruß 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/ iEYEARECAAYFAkuWUNUACgkQqdb99cbyCz4EmQCfWq7qjRJwIejE0+SwhEjHvoft k5AAoJOFHJw344CME+48qSAgO/iyGtqT =ydQf -----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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Ralf, Am 09.03.2010 15:58, schrieb Ralf Prengel:

...

Am 09.03.2010 10:38, schrieb Sandy Drobic:

...

Das sieht für mich wie ein Problem mit dem Session-Management aus, sprich, ein Timeout-Problem, wo danach die Kommunikation abreisst.

Das hatten wir an sich schon ausgeschlossen, aber wie ich eben Dieter schon schrieb, haben wir zeitgleich Änderungen an LDAP und Bootparams durchgeführt, wobei letztere mit "clocksource=pit" durchaus auf ein Timing-Problem mit der virtualisierten APIC abzielt.

Kann jetzt sein das ich mir vertue aber ich meine in der Vergangenheit mal Probleme mit diesem Schalter und Java-Anwendungen gehabt zu haben. Nur für ddas Archiv wenn ihr weitere Effekte habt.

Okay, danke. Ist gut archiviert! ;-) Auch wenn auf jenen Server-VMs kein Java laufen wird, könnte das auf anderen Maschinen der Infrastruktur wichtig werden; ich leite die Entwicklung einer Admin-WebGUI, die im Backend auch die LDAP-Daten jener Infrastruktur verarbeiten wird, und so werde ich dort zu gegebener Zeit einen dankbaren Extrablick auf Deinen Hinweis verwenden. Gruß 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/ iEYEARECAAYFAkuWZwAACgkQqdb99cbyCz69vgCfWMNk01KXMhsqxyncfq9QdyFY 33sAoJskYNn3jiNdwLrLK42r/slOTN8J =Kg6n -----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