PostgreService unter WindowsXP neu starten

Ich habe auf WindowsXP PostgreSQL installiert und versuche auf vom localhost zuzugreifen. Fehlermeldung: Aufgrund einer fehlerhaften Anmeldung konnte der Service nicht gestartet werden.
Weder nach Neustart des Service unter Systemsteuerung>Verwaltung noch nach einem reboot konnte ich den DBServer zum Laufen bringen.
Bitte um Unterstützung!

ics

Installation von PostgreSQL unter Windows scheitert oder funktioniert nicht

Entfernen (De-Installation) von PostgreSQL unter Windows

Installation von PostgreSQL unter Windows



Nach dem Lesen der Beiträge PostgreSQL neu installieren!





mfg

fristo

Ich bin hier ja auch Neuling.

Aber das Problem, dass die Postgre gegen die Rechteverwaltung fährt, kenne ich zur Genüge.

Versuche mal Folgendes:

In die Systemsteuerung, Verwaltung, Dienste klicken und die Postgre doppelklicken (wenn die normal hochgezogen wurde, würde sie auf “gestartet” und “automatisch” stehen - dann nicht: sie läuft). Den zweiten Reiter von links anwählen und das Kennwort ändern (sinnigerweise auf das gleiche, das bei der Installation vergeben wurde), “Übernehmen” anklicken, auf den Reiter ganz links wechseln und die Postgre “starten”,

Wenn die dann läuft, hält das mindestens bis zur nächsten Anmeldung. Sofern keiner neue Richtlinien einspielt. Darauf reagiert die pg Allergisch.

Wenn die Installation ohne Fehlermeldung durchgelaufen ist, sollte das Helfen.

Ach ja: die pg reagiert auf einen "http/localhost:8080/ NICHT. Weil der Port 5432 ist. Aber auch da gibt es keine Antwort, wenn die DB als Dienst (Voreinstellung) gestartet wurde. Aber der pg-Admin kann das…

Grüße
W.K.

Ein wenig “Feedback” wäre ja nicht schlecht.

:frowning:

Problem gelöst und nie wieder gesehen?

Ein wenig Geduld wäre auch nicht schlecht, zumal man hier im Forum einen kostenlose Unterstützung zur Lösung seiner Problemchen bekommt! Einen exclusiven 24 Stunden-Service solltest Du für den Preis nicht erwarten.

Ich habe erst mal den Bericht über Dein Performens-Problem/Lösung gelesen. Da kann man ja nur hoffen, dass Du die “Haue” auch an den richtigen verteilt hast!


Kannst ja mal am Ende des Betrages den eigenlichen Verursacher bestimmen.


Wenn ich entsprechend Deiner Beschreibung vorgehe funktioniert bei mir garnichts mehr. Allerdings verhalten sich das Betriebssystem (WinXp Pro) und auch PostgreSQL korrekt.



Der Dienst sollte normalerweise nicht mehr starten, ausser Du hast Änderungen an den Eigenschaften des Benutzers “postgres” vorgenommen. Bei der Installation werden beim Benutzers “postgres” die Eigenschaften “Benutzer kann Kennwort nicht ändern” und “Kennwort läuft nie ab” aktiviert. Das manipulieren der Dienstparameter (löschen des Kennwortes und Neueingabe) wird wohl vom Betriebssystem als Änderung des Kennwortes angesehen. Allerding kann ich (aufgrund Deiner Angaben) nicht sagen, ob es da ein Verhaltensunterschied zwischen WinXP und dem Win 2003 Server gibt.



PostgreSQL reagiert überhaupt nicht und das Betriebssystem verhält sich entsprechend den vorgegebenen Richtlinien. Die Ursache hierfür ist, dass Du PostgreSQL unter den Administrator des Win 2003 Server installiert hast und der Administrator mehr Rechte besitzt als er in einer Domäne haben sollte. Er darf nämlich neue User anlegen, diese aber nicht verwalten. Die Verwaltung erfolgt von der Domäne und dort ist der Benutzer “postgres” nicht bekannt. Der PostgreSQL-Datenbank-Server kann daher wegen fehlenden Richtlinien für den Benutzer “postgres” nicht gestartet werden. Betriebssystem und PostgreSQL verhalten sich daher auch korrekt.




Nein, die Installationsscripts sind für Workstation und Server geschrieben. Bei einer Domänverwaltung muss man da schon mitdenken.



Das ist korrekt. Nebenbei, das Format “http/localhost:8080/” ist nicht zulässig. Siehe Doku.



Was erwartest Du? Client und Datenbank-Server können nur über gleiche Portnummer kommunizieren. Ein Datenbank-Server, der nicht angesprochen wird, kann auch kein Antwort geben! Allerding sollten Deine Clients einen Verbindungsfehler melden. pgAdmin macht das auch, wenn die Portnummer nicht übereinstimmt.

Wenn Du allerdings die Portnummer ändern willst, kannst Du das in der Datei “postgresql.conf”. Diese findest Du im Verzeichnis “data”. Details zu den Parametern in der Datei “postgresql.conf” findest Du in der Doku.



Nein. Für den Verbindungaufbau hat pgAdmin einen Dialog, in dem Du die richtigen Parameter eingeben muss. Ansonsten streikt auch pgAdmin.




mfg

fristo

Soweit ich das bis jetzt überblicken kann.

Ich habe jetzt (zum Teil mehrfache, eben wegen der hier beschriebenen Probleme wiederholten versuchte) Installationen der Postgre hinter mich gebracht.

Umfeld:

  • MS - Server 2000AS
  • MS - Server 2003AS
  • MS WINDOWS - 2000 Client lokal (im Netzwerk)
  • SLES 9.3 SP 3
  • Mac OS “Leopard” mit aktuellsten Treibern
  • XP - Home SP 2 und aktuell gehalten
  • XP - Pro SP 2 und aktuell gehalten.

Immer die gleiche Installation im gleichen “Kleid”: pg 8.2.5, pg-Admin III 1.8.0 (außer SLES 9.3 - verlangt 1.6.3) JBOSS (aktuell 4.2.2.GA) und Eclipse (MyEclipse 6.0) auf einer JAVA JRE / SDK vom Dezember 2007.

Diese Installationen funktionieren bei den jeweiligen Systemen digital: Geht, geht nicht.

Aber ich habe die pg auf allen Umgebungen zum Laufen gebracht.

Mit den größten Problemen auf den WS*K - Servern. Aber diese Probleme waren nicht der pg anzulasten, sondern den eingesetzten Sicherheitsrichtlinien.

Diese Manipulation am Passwort über den Reiter “Anmelden” sollte man tunlichst nicht verwenden, wenn die pg als Dienst gestartet wurde. Wenn sie läuft - Finger weg. Dann braucht es ja auch keinen “Workaround”…

Aber die Situation gab es - Installation durchgelaufen, angeblich alles in Ordnung und beim Neustart die Fehlermeldung.

Der Fehler tritt anscheinend vorwiegend in Umgebungen mit einer zentralen Rechteverwaltung auf.

  • W2000 Server: Fehler
  • W2003 Server: Fehler
  • SLES : Fehler
  • MS WINDOWS 2K Client: Fehler.

Der “Rest” nicht: pg läuft und läuft und läuft…

Den “Schuldigen” habe ich zum Teil auch ausgemacht. Wenn mir eine Gruppenrichtinie nach dem Systemstart den Nutzer / einen der benötigten Nutzer löscht, kann der Dienst nicht starten.

Der Tipp, das Passwort neu zu setzen, funktioniert natürlich nur bei einem bestehenden Konto, dass nicht auf “gesperrt” gesetzt wurde. Oder gar gelöscht. Wobei auch hier Vorsicht angebracht ist: Der “Benutzer” muss angelegt sein. Das Anmeldekonto kann später gelöscht werden. Dann muss aber im Zweifel der Dienst wie beschrieben gestartet werden - Kollision mit dem Kerberos, vermutlich.

Bei der Installation gibt man die Passworte für die pg und den “su - pg” an. Was mir aufgefallen ist: die Installation betrachtet manche Passworte nicht als “Sicher” und würde gerne eigene setzen. Das macht anscheinend der Start als Dienst im Kerberos - Umfeld ungefragt. Manchmal scheint dabei das Passwort für den normalen Account in Verbindung mit den internen Sicherheitsrichtlinien “hinten runter” zu fallen.

Das Ergebnis ist “geht, geht nicht”, erst über den Umweg der Ereignisanzeige kann man eine ungefähre Vorstellung bekommen, weshalb es nicht geht.

Ich habe aber die pg noch jedes mal zum Laufen gebracht, wenn ich mir den Dienst im Status gestartet: “leer” und automatisch per Doppelklick geholt und unter “Anmelden” das Kennwort auf den ursprünglichen Wert gesetzt habe. Danach konnte ich über “Starten” den Dienst auch hochziehen…

Allerdings nur bis zum nächsten Einspielen der Sicherheitsrichtlinien.

Anscheinend wird da unter den MS - Systemen auf Server - Ebene tatsächlich auf Sicherheit geachtet.

Gleichfalls. und jetzt schon mal “Frohe Weihnachten” und einen (symbolischen) “Guten Rutsch” dazu.

Grüße

W.K.

Geht, geht nicht, gibt es nicht. Alles hat eine Ursache. Hier ist Betriebssystem Know-How notwendig. Das Wissen eines Tastenquälers (Otto-Normal-Anwender) reicht dazu nicht aus.



= Domänenverwaltung. Da muss man mitdenken.



Na. ja. Kein Fachman würde auf die Idee kommen, das Motoröl bei laufenden Motor zu wechseln.



= Domänenverwaltung.



= Domänenverwaltung.



Ja, auf dem Datenbankserver, und auch nur dann, wenn der Datenbankserver von einer Domäne verwaltet wird. In diesem Fall ist das Anmeldekonto auf der Domäne vorhanden. Ohne Konto läuft nichts.


Der Dienst startet auch automatisch, wenn der Benutzer auch die Angabe enthält, wo er registriert ist.



Bei einer Standard-Installation ist Kerberos überhaupt nicht aktiviert.



Das ist ein nettes Feature des Installationscripts, da es immer noch Anwender gibt, die nicht wissen wie ein sicheres Password aussieht.



Bei einer Standard-Installation ist Kerberos überhaupt nicht aktiviert.



Die speziellen Sicherheitsrichtlinien bestimmt der Admin. Wenn es dann so sein soll.



Unter UNIX sind das die LOG-Dateien, unter Windows nennt sich das Ereignisanzeige. Um Grunde das gleiche. Und nur ein Hilfsmittel. Viel wichtiger ist das Betriebssystem Know-How.




= Domänenverwaltung.



Warum denn nicht? Allerdings gibt es viele Sprücheklopfer mit Tastenquäler Know-How, die mit ihren Behauptungen nur mitteilen wollen, das sie überhaupt kein Betriebssystem Know-How haben.




Der Domänen - Admin darf auf allen von ihm verwalteten Computer Installationen vornehmen. Damit ändert sich aber nicht das Installationsscript. Das geschriebene gilt daher weiterhin.



Der größte Teil der Installation ist eine 1:1 Kopie. Bei den meisten anderen Installationsscripts wird auch nicht mehr angezeigt. Das wichtigste steht in der Doku und die sollte man eigentlich vorher lesen.



Nein. Zusätzliche Ports werden auch von anderen Betriebssystem angewandt. Beschäftige mal mit den tiefsten Grundlagen, wie eine Netzwerkverbindung aufgebaut wird. Dann wirst Du das verstehen.





mfg

fristo

Mittlerweile kann ich da ein paar zusätzliche “Fehlerquellen” anbieten:

  • das System befindet sich gerade in der Neuorganisation, was die Rechteverwaltung angeht, es werden täglich neue Sicherheitsrichtlinien eingespielt. Mehrfach. OHNE Absprache.

  • es gibt andere Domänen - Admins. Zum Beispiel solche, die den lokalen User / Dienst “Postgre” nicht kennen und ihn ohne Rückfrage löschen / deaktivieren.

  • Leute, die einen vorhandenen pg - Account von MS 2003AS (mit) auf eine SLES - Umgebung (ohne) Kerberos verlagern. Einfach so, ohne Anpassung - und sich dann beschweren, die pg läuft nicht… .

Ich wunder mich in diesem Laden über nichts mehr. Ich staune nur noch: dass er überhaupt läuft.

Damit sollte auch mein “geht / geht nicht - Erlebnis” erklärt sein: wenn da jeder mit entsprechenden Rechten rumfummeln darf, der sich für berufen hält…

Nachdem ich für “meine Server” Exclusivrechte eingefordert (und bekommen) habe, gibt es keine Probleme mehr.

Die Installation und die Konten entsprechen den Sicherheitsrichtlinienzum Zeitpunkt X, wenn die zum Zeitpunkt Y geändert wurden…

Nette Geschichten, ohne Zweifel, aber komplett OffTopic, auch ohne Zweifel. Was Du schilderst sind organisatorische Probleme. Möglicherweise gibt es auch dafür spezialisierte Foren.

Andreas

Naja wir wissen jetzt, das es an PostgreSQL liegt sondern ein internes Problem ist…

cu tb