comerr32.dll und andere DLLs

Hallo,

ich nutze PostgreSQL 8.2 mit den Zeos-Komponenten 6.6.1 beta unter Windows XP und Vista. Seit Neuestem muss dazu ja ein Haufen DLLs an der richtigen Stelle untergebracht werden, z.B. comerr32.dll, die früher nicht verlangt wurde. Dazu hätte ich ein paar Fragen, deren Antworten weder Google noch die PG-Hilfe findet. Situation: Wir haben Server X mit PostgreSQL und Client Y mit einer Windows-Anwendung, die auf X zugreift. (Oft ist die Anwendung sogar auch auf X oder einem anderen Server installiert, wird aber von Client Y aus gestartet.)

  • In manchen Fällen reichte es für mich aus, die DLLs ins Programmverzeichnis der Client-Anwendung zu kopieren, in anderen Fällen mussten sie auf dem Client in c:\Windows\System32, damit es lief. Woher dieser Unterschied? Was sagt man fragenden Anwendern zu diesem Problem?

  • Macht es einen Unterschied, ob das Verzeichnis zu den DLLs in der PATH-Variable des Clients oder Servers steht?

  • Was genau tun diese DLLs, und warum spielten sie früher offenbar keine Rolle?

  • Stimmt es, dass sie nur clientseitig gebraucht werden (und im PG-bin-Verzeichnis ohnehin vorhanden sind), oder muss auf dem Server auch noch irgendeine Vorbereitung bezüglich der DLLs stattfinden?

Viele Grüße und vielen Dank,
Ste_Ba

Wende Dich mal an W.K. hier im Forum, denn diese DLL hat was mit Kerberos zu tun und da kann er ganz sicher was zu sagen. Zu Vista fällt mir mir ein, daß man da UAC abschalten soll. Mehr findest Du in der von fristo gepflegten FAQ zu PG unter Windows.

Andreas

Kerberos muss mit seinen “Client - Varianten” auf allen Rechnern im Netz verfügbar sein. Das ist aber im Normalfall schon gegeben; jedes aktuelle Betriebssystem beinhaltet die nötigen Dienste und hat sie auch gestartet.

Mir ist bisher kein Fall untergekommen, dass für Kerberos benötigte ".dll"´s nicht zu finden waren.

Tut mir leid - da habe ich auch keine schnelle Hilfe im Angebot.

Wenn es nicht zeitkritisch ist: ich schau noch mal nach. Dann wird es aber ein paar Tage dauern…

Alternative: es gab da mal ein Projekt der ix , wo die Einbindung eines Kerberos in ein Netzwerk durchgespielt wurde - wenn ich mich recht erinnere in einem LINUX - Umfeld.

Oder aber: Neuinstallation. Dürfte die schnellste Lösung sein - sofern sie mit “Standardparametern” durchgeführt wird. Weil, dann ist der Kerberos dabei.

Und von wegen “Du kennst Dich damit aus”: Nö.

Kommt immer auf die Systemumgebung an. Aber die hat normalerweise mit den benötigten ".dll"´s nichts zu tun. Eher mit dem zentralen Zeitgeber. Aber das ist ein anderes Kapitel.

Grüße
W.K.

Hallo und danke!

Na ja, was heißt schon zeitkritisch? Besser spät Bescheid wissen als nie …
Wenn es PostgreSQLs Fehlermeldung, die Datei comerr32.dll nicht gefunden zu haben, nicht gegeben hätte, wäre ich auch nicht auf meine Frage gekommen, insofern scheint der Fall nicht gar so selten zu sein.
Meine Fragen haben sich genau aus dieser öfters in verschiedenen Netzwerken aufgetretenen Fehlermeldung ergeben.

Gruß,
ste_ba

Ich habe mal ganz unschuldig in meiner Dienste-Liste geschaut, finde aber keinen Dienst, der angibt, etwas mit Kerberos o.ä. zu tun zu haben, obwohl ich ja z.B. auch PostgreSQL drauf habe. Lässt sich das erklären?

Gruß,
ste_ba

Ja. Sogar relativ einfach.

Kerberos ist eigentlich ein Dienst (oder so etwas ähnliches), der auf dem für die Anmeldung benutzten Domänenserver läuft. Man kann Kerberos auch für die Autorisierung einsetzen, wird aber so gut wie nie gemacht. Dazu benutzt man in der Regel ein AD (MS) oder einen LDAP (Rest der Welt) oder eine Kombination der beiden.

Das bedeutet, dass man vom Client aus dem Kerberos nur indirekt auf die Finger schauen kann: Systemverwaltung -> Verwaltung -> Ereignisanzeige -> Sicherheit auswählen und sich dann seine Anmeldung am System herauspicken. Kleine Hilfe: “Ereignis: 540” sollte genügen. Wenn ein Kerberos im System aktiv ist, sollte man dort einen Eintrag finden wie: “Authentifizierungspaket: kerberos”.

Das ist auf Einzelplatzrechnern - auch mit Serveranwendungen - regelmäßig nicht der Fall. Bei der normalen Installation wird das Paket nicht aktiviert, wenn kein dafür “zuständiger” Server gefunden oder angegeben wird.

Im Taskmanager würde sich ein Kerberos mit einem Eintrag “krb***” bemerkbar machen - aber Vorsicht, das kann der Admin unterdrücken. Ein Kerberos kann so konfiguriert werden (von mir aus: so umgebogen), dass ein “normaler” Nutzer so gut wie nichts von der Existenz eines solchen Mitbekommt.

Genau deshalb habe ich ja auch solche Probleme mit der Anfrage wegen der .dll´s … möglicherweise habe ich zur Laufzeit die Lösung gefunden!

Bis später

W.K.

Kerberos sollte nur auf einem Server installiert werden, dieser sollte die Authentifizierung für die Clients zentral vornehmen. Man kann mehrere Instanzen des Kerberos installieren, die sollten dann aber für unterschiedliche Subnets zuständig sein - sonst gibt es Konflikte. Prinzipiell reicht ein Domänenserver mit Kerberos für mehrere tausend Clients aus. Wenn der Server ausreichend performant arbeitet.

Nun, ein Client, der vorher schon in der richtigen Domäne war, Kerberos aktiv: der findet sich natürlich wieder. Vermutlich wäre noch nicht einmal das Kopieren der .dll´s notwendig gewesen, serverseitig ein “Refresh” der Netzwerkverbindungen durchgeführt sollte reichen.

Vom Prinzip her nicht - aber es kann auch nicht schaden. Im Normalfall hat ein aktiver Kerberos seinen PATH - ob der in den Umgebungsvariablen steht oder nicht.

Dll´s tun das, was sie tun sollen: sie bieten zur Laufzeit Funktionen an, die nicht beim Systemstart “hochgezogen” werden. Und vermutlich haben sie früher keine Rolle gespielt, weil ihr eine Server - Umgebung mit einem Kerberos mal eben so auf eine andere Server - Umgebung (womöglich ohne Kerberos) gezogen habt.

Kerberos auf dem Server: kann man “sehen”. Ob nun über den Taskmanager oder über die Verwaltung -> Dienste - auf dem Server müsste da etwas in Richtung “krb***” zu sehen sein.

Die braucht der pg-Client eigentlich überhaupt nicht, aber der MS - Client. Einfach nicht mehr den Server wechseln: müsste massiv helfen.

Ach ja: die Client - Installation sollte natürlich entsprechend angepasst durchgeführt werden.

Grüße
W.K.

Ich habe mir die Sache heute noch mal etwas gründlicher angesehen.

Ich sage mal, mein Posting von Gestern traf den Kern nicht.

Dem Kerberos sind solche Umkopier- oder Verlagerungsaktionen egal, sofern er nicht selber davon betroffen ist. Kerberos wirkt auch nicht auf solche Aktionen ein und verhindert z. B. Operationen mit Dateitypen “.dll” oder so.

Zumindest nicht ohne weiteres.

Zum besseren Verständnis mal kurz die Wirkung eines Kerberos im System (keine Angst, ich mache es wirklich kurz, dafür soll mir dann aber auch keiner kommen, ich hätte diesen und jenen Aspekt weggelassen…):

Prinzipiell besteht ein Mini - Kerberos aus drei Komponenten, einem Admin - Server, einem “Key Distribution Center” (KDC) und einem Client. Admin - Server kann es nur einen geben (verwaltet die zentrale, netzwerkweite DB mit den Usern / Passwörtern), dieser kann gleichzeitig auch als KDC fungieren (in größeren Netzen hat man wegen Performance / Ausfallsicherheit mehrere aktiv, mitunter sogar in größeren Domänen) und mindestens einem Client. Ohne Client macht so etwas eigentlich keinen Sinn…

Stark vereinfacht dargestellt nimmt der Kerberos die Anmeldeinformationen des Users am System entgegen und erstellt / verwaltet für diesen User Zertifikate, mit denen dieser gegenüber Diensten und Anwendungen authentifiziert - aber nicht autorisiert - wird.

Damit braucht es nur noch eine Anmeldung am System, um andere - normalerweise passwortgeschützte - Aktionen durchführen zu können.

Soviel zum Kerberos. Wer also autorisiert ist, bestimmte Prozesse zu starten, braucht sich dafür nicht mit einem neuen Passwort anzumelden. Was der User darf, wird aber nach wie vor durch die Rechteverwaltung bestimmt. Umgekehrt kann übrigens der Kerberos so administriert werden, dass sich auch Dienste zertifizieren müssen: dafür ist die pg aber vorbereitet: sie müsste irgendwo - vermutlich im “bin - Verzeichnis” - eine Datei wie “krb5.dll” oder so haben (aktuell verbreitetste Version des Kerberos).

Damit kann der Kerberos nicht der “Schuldige” sein: wer kopieren und Server umdeklarieren darf, der kann es auch mit laufendem Kerberos…

Worauf der Kerberos allerdings ziemlich empfindlich reagiert, sind Probleme mit dem zentralen Zeitgeber. Die vom Kerberos erstellten Zertifikate haben nur eine begrenzte Lebensdauer, die bei großzügigen Einstellungen Stunden betragen, normalerweise eher weniger. Ein “Läuft nie ab” würde ja auch dem Sinn in keinster Weise entsprechen. Ist im normalfall auch kein Problem: durch die Synchronisation der Server und die Überwachung durch den Kerberos wird bei noch andauernder Nutzeraktivität rechtzeitig ein neues Zertifikat angefordert.

Dabei kann es dann passieren (ist mir passiert), dass ein unter Vollast laufender Server die Synchronisation mit dem zentralen “Zeitverteiler” einstellt und diese vor Ablauf des Zertifikates nicht wieder aufgenommen hat. Dann wird das Zertifikat nach Ablauf verworfen, wird der Nutzer von den nicht mehr von einem gültigen Zertifikat “gedeckten” Aktivitäten (Dienste / Anwendungen) abgemeldet.

Werden die Abweichungen in den “Systemzeiten” zu groß, kann davon auch mal der ganze Server betroffen sein - sofern kritische Dienste zur Zertifizierung gezwungen wurden.

Die dabei auftretenden Fehler äußern sich aber ganz anders. Ein Kopiervorgang beispielsweise bleibt “hängen” oder bricht ab, ich kann auf einen Server zwar noch über eine Laufwerksverbindung zugreifen, die Remote - Console gibt keinen Mucks mehr von sich oder so.

Eigentlich sollte es dann eine qualifizierte Fehlermeldung geben, aber… :frowning:

Ich habe mir heute die Zeit genommen, mal einen KDC zum Client und einen Client zum KDC zu machen - an den Admin - Kerberos bin ich aus gutem Grund nicht ´ran. Die Konfigurationen sind unterschiedlich, Kerberos verlangt erheblich mehr als nur ein paar dll´s, um wieder zu arbeiten. Und beeinträchtigt / beeinflusst ansonsten laufende Programme nicht.

Sorry, aber ihr müsst euch, so wie es aussieht, einen anderen “Schuldigen” suchen.

Also, manchmal ist man ja wie vernagelt…

Als ich über die “qualifizierte Fehlermeldung” :frowning: geschrieben habe, kam ich ins Grübeln…

Ja, das Problem sollte mit einem Eintrag in die Umgebungsvariablen behoben werden können.

Diese Dateien (die comerr32.dll sollte nicht die einzige sein) gehören nicht zum “Lieferumfang” der Postgre. Sondern zum Kerberos. Die pg merkt beim Start, das ihr “was fehlt” und sagt das auch.

Damit bin ich wieder beim vorletzten Post: möglicherweise auf einen Server verlagert, auf dem kein Kerberos installiert ist- dann gibt es auch keinen Eintrag in den “PATH” - die pg sucht für den Betrieb im Netzwerk - mit Kerberos - notwendige Dateien und findet sie nicht: kein Kerberos auf dieser Maschine im Pfad eingetragen.

Der einfache “Workaround”: man kopiert die Dateien in alle Verzeichnisse, die “angemeckert” werden. Dann läuft die pg wieder. Aber das ist eigentlich nicht Sinn der Sache. Das ist Datenvervielfachung - sinnlose.

Einen solchen Eintrag kann man zwar auch über eine Netzwerkverbindung realisieren, aber dann hat man das Problem, dass diese Verbindung aktiviert werden muss, bevor die lokalen Dienste gestartet werden. Geht mit einem “Startskript” (beispielsweise dem alten “Kixstart32”), aber deutlich einfacher ist die lokale Installation der Anwendung (hier: Kerberos). Dann sollten auch die Umgebungsvariablen korrekt gesetzt sein. Und hat den Vorteil, dass die Umgebung auch zur Verfügung steht, wenn man den Server und den Client als “lokale Maschinen” starten muss, weil der Rest des Netzwerkes nicht zur Verfügung steht.

Der Kerberos muss auf der Maschine übrigens nicht aktiv sein - nur vorhanden.

Kann man ja mit einer Suche nach z. B. comerr32.dll überprüfen.

Die aus meiner Sicht einfachste Lösung: falls auf der Maschine vorhanden - und zwar nicht in den Verzeichnissen, in die ihr die Dateien kopiert habt! - den Pfad händisch ergänzen.

Das ist ziemlich einfach und tut auch nicht weh. Start -> Ausführen anwählen, cmd eintippen und bestätigen (return oder “ok” anklicken).

Folgenden Befehl eingeben:

path = %path%;“gefundenes Verzeichnis, also zum Beispiel C:\programme\kerberos\bin”

eingeben. Wobei natürlich “gefundenes Verzeichnis…” für den richtigen Namen steht. Und den neuen Pfad ohne diese Zeichen:" "

Nehmen wir mal an, es wäre richtig, eine solche Zeile:

path = %path%;c:\programme\kerberos\bin

ergänzt die Umgebungsvariablen um einen Verweis auf dieses Verzeichnis. Die Angabe %path% übernimmt dabei die bestehenden Einträge.

Das kann man natürlich auch über die normale Windows - Umgebung machen - aber der traue ich nur so weit, wie ich sie werfen kann.

Ich habe ohnehin das Problem, dass ich viele der hier beschriebenen Schwierigkeiten so nicht nachvollziehen kann: privat benutze ich eine ganz andere Umgebung, “auf Arbeit” habe ich es mit einer Rechteverwaltung zu tun, die “privat” keiner laufen hat…

Grüße
W.K.

Vielen Dank für deine ausführlichen Erläuterungen. Das kommt meinem ursprünglichen, eher instinktiven Ansatz, die DLLs (also Kerberos) schlimmstenfalls ins Systemverzeichnis zu kopieren ( = lokale “Installation” mit Eintrag in PATH) ja schon recht nahe.

Was ich nach wie vor seltsam finde: dass weder PostgreSQL noch Zeos eine Erwähnung dieser Problematik in der Dokumentation für nötig halten. Nur im Zeos-Forum werden sie von einem Anwender erwähnt. Na ja, jetzt weiß ich erst mal einigermaßen Bescheid. Wenn sich noch Fragen ergeben, ist dies hier sicher das richtige Forum dafür :slight_smile:

Ach ja, natürlich ist comerr32.dll nicht die einzige, ich nannte sie nur als Beispiel, weil sie die erste ist, nach der gefragt wird.

Gruß,
ste_ba

Ich habe mich noch mal etwas genauer mit der Problematik befasst.

Zur Erläuterung: Wir haben nach den gültigen Sicherheitsrichtlinien keine pg im System, die von mir installierte Version läuft “an denen vorbei”. Was auch bei mir regelmäßig zu Problemen führt. Aber die Poste ich an anderer Stelle. Mithin: Ich kann die beschriebenen Probleme nicht am System nachvollziehen, ich muss entweder in die Dokumentation (nur mal so: Die Doku zum Kerberos liest sich teilweise so “einfach” wie ein Börsenbericht einer zur Geldwäsche gegründeten Holding…) oder eine Systemumgebung zusammenbauen, bei der solche Fehler auch auftreten. Aber das kostet Zeit, die ich im Augenblick nicht habe.

Was nun dieses Problem betrifft: Das ist ein “Kollateralschaden”.

Wie ich bereits schrieb, kann auch erzwungen werden, dass sich Dienste beim Kerberos “ausweisen” müssen.

Es ist noch besser. Automatisch gestartete Dienste müssen so etwas im Kerberos - Umfeld quasi “von selbst” können. Da sitzt ja keiner vor der Konsole und gibt das pg - Passwort beim Systemstart als Dienst ein…

Die pg startet nach Installation mit den normalen Einstellungen als Dienst automatisch…

Von daher sind das keine reinen Kerberos - Dateien, sondern mit der pg ausgelieferte Dateien, die zur automatischen Anmeldung als Dienst beim Systemstart benötigt werden. Mit dem pg - Passwort etc. . Und deshalb werden die von der pg mitgebracht. Von anderen Anwendungen, die als Dienst gestartet werden (können) und interaktiv bedient werden (können) übrigens auch.

Die als fehlend “angemeckerten” Dateien gehören in das “bin” - Verzeichnis der pg.

Vor diesem Hintergrund kann ich mir die beschriebenen Fehler nur so erklären, dass die Systemumgebung der beteiligten Rechner eben doch nicht identisch ist. So lange die Rechner alle am selben Kerberos - Admin Server hängen, sollte das ein geringes Problem sein. Von dem werden die KDC´s mit den nötigen Informationen versorgt. Natürlich nur, wenn sie auch mit dem Kerberos - Admin Verbindung aufnehmen können.

Hier könnte der Schutz der “keytab” zugeschlagen haben. In dieser Kerberos - Tabelle werden die Anmeldeinformationen der Benutzer - auch der automatisch gestarteten Dienste - abgelegt. Und da ist die Kombination aus Rechnername - Username - Passwort enthalten. Da wäre im Normalfall die Fehlermeldung aber so, dass der Nutzer nicht über die angeforderten Rechte für die Anmeldung verfügt oder dass der Benutzername für das Anmeldekonto und das Anmeldepasswort nicht übereinstimmen.

Im Normalfall. Wenn auf dem “neuen” Server mit einem aktiven Kerberos eine “keytab” nicht existiert wird sie neu angelegt. Dazu müssen die erforderlichen Informationen dann erst mal über das Netz angefordert werden. Dauert womöglich ein wenig, klappt normalerweise aber.

Wenn auf dem “neuen Server” keine Kerberos - Admin - Instanz läuft, auch kein KDC, keine Einbindung in den “alten” KDC - Bereich (Realm im Kerberos) vorhanden ist: Dann nicht.

Das sind mögliche Fehlerquellen, die einen Start der pg grundsätzlich behindern würden. Aber nichts davon würde - korrekte Installation vorausgesetzt - einen Fehler “Datei nicht gefunden” auswerfen.

Sorry - ich kann Dir auch nach Studium der mir vorliegenden Dokumentation so nicht helfen. Weil es anscheinend kein Kerberos - Problem ist.

Mit vorweihnachtlichen Grüssen

W.K.