On 03.03.2010 16:02, Stefan Jurisch wrote:
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.
Das sieht für mich wie ein Problem mit dem Session-Management aus, sprich, ein Timeout-Problem, wo danach die Kommunikation abreisst.
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. Gibt es irgendwelche Firewalls zwischen oder auf den Rechnern, die die Kommunikation stören können? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@)drobic (.) de -- 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