6
Postgres via Batch sichern
Wir haben eine OpenSuse 9.3 VM, auf der ein Postgres v8.3.1 läuft.
Die Postgres soll nun täglich und automatisch, statt wie bisher manuell und gelegentlich gesichert werden.
Dabei tritt mit meinem Script das bekannte Problem auf, dass man gezwungen wird das Passwort zum User einzugeben.
Ich habe hier im Forum bereits Lösungsansätze gefunden, auch schon in diversen Foren, leider hat mir bisher kein Tipp geholfen.
Diese Variante hier sorgt nun immerhin schon dafür, dass ich das Passwort nur noch einmal statt 5x eingeben muss. In der einlesenden Datei steht das Passwort fünf mal drin.
Trotzdem muss ich es einmal eingeben, komme was wolle.
Auch die Variante mit dem Passwort in der /$HOME/.pgpass funkioniert nicht. Witzigerweise meckert pg_dumpall, wenn ich vorher die Attribute nicht auf 0600 gesetzt habe. Danach jedoch verlangt es nach wie vor ein Passwort.
Der dritte Lösungsansatz, den ich finden konnte mit der Option -W "passwort", der angeblich in der Version 8.x funktionieren soll scheitert bei mir mit der Ausgabe eines Fehlers.
"Die Option -w (ja, klein 'w') gibt es nicht" [sinngemäß].
Hat jemand einen Tipp für mich? - Oder anders gefragt, wie habt ihr das Problem gelöst / umgangen?
Die Postgres soll nun täglich und automatisch, statt wie bisher manuell und gelegentlich gesichert werden.
Dabei tritt mit meinem Script das bekannte Problem auf, dass man gezwungen wird das Passwort zum User einzugeben.
Ich habe hier im Forum bereits Lösungsansätze gefunden, auch schon in diversen Foren, leider hat mir bisher kein Tipp geholfen.
Diese Variante hier sorgt nun immerhin schon dafür, dass ich das Passwort nur noch einmal statt 5x eingeben muss. In der einlesenden Datei steht das Passwort fünf mal drin.
#!/bin/bash
pg_dumpall -h localhost -U "username" -l datenbank | gzip > /pfad/PostgreDB-$(date +%d-%m-%Y).gz < /pfad/bckwiki.pwd
Auch die Variante mit dem Passwort in der /$HOME/.pgpass funkioniert nicht. Witzigerweise meckert pg_dumpall, wenn ich vorher die Attribute nicht auf 0600 gesetzt habe. Danach jedoch verlangt es nach wie vor ein Passwort.
Der dritte Lösungsansatz, den ich finden konnte mit der Option -W "passwort", der angeblich in der Version 8.x funktionieren soll scheitert bei mir mit der Ausgabe eines Fehlers.
"Die Option -w (ja, klein 'w') gibt es nicht" [sinngemäß].
Hat jemand einen Tipp für mich? - Oder anders gefragt, wie habt ihr das Problem gelöst / umgangen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 122504
Url: https://administrator.de/contentid/122504
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
6 Kommentare
Neuester Kommentar
Moin Gilneas,
da müssen wir uns mal vorsichtig rantasten, weil die von Dir zusammengegoogelten Tipps unmöglich alle wahr sein können.
Mit der PostGreSQL-Referenz konform ist das von Dir beobachtete Phänomen, dass das .pgpass-File ignoriert wird, wenn Du nicht explizit world und groups ausgesperrt hast (also chmod 0600 ~/.pgpass ).
So sagt es auch das Manual auf PostgreSQL.org.
Was allerdings niemand aus meinem Bekanntenkreis behauptet haben kann, ist
Ich denke, der Fehler muss entweder im ~/.pgpass-File liegen oder aber an nicht gesetzten PGHOST/PGPORT/PGUSER-Environmentvariablen.
Kannst Du bitte mal die (anonymisierten) 5 Zeilen Deiner .pgpass-Datei posten?
Grüße
Biber
da müssen wir uns mal vorsichtig rantasten, weil die von Dir zusammengegoogelten Tipps unmöglich alle wahr sein können.
Mit der PostGreSQL-Referenz konform ist das von Dir beobachtete Phänomen, dass das .pgpass-File ignoriert wird, wenn Du nicht explizit world und groups ausgesperrt hast (also chmod 0600 ~/.pgpass ).
So sagt es auch das Manual auf PostgreSQL.org.
Was allerdings niemand aus meinem Bekanntenkreis behauptet haben kann, ist
- dass die Option [-W], die erzwingt, dass nach einem Passwort gefragt wird, nun plötzlich einen optionalen Parameter "passwort" kennen soll. Glaub ich nienich.
- und ebenfalls nicht einordnen kann ich den [-l] [minus Klein-L]-Parameter, den ich noch nie gesehen habe. Gibt es den?
Ich denke, der Fehler muss entweder im ~/.pgpass-File liegen oder aber an nicht gesetzten PGHOST/PGPORT/PGUSER-Environmentvariablen.
Kannst Du bitte mal die (anonymisierten) 5 Zeilen Deiner .pgpass-Datei posten?
Grüße
Biber
Hi Biber,
das Problem ist, dass ich ein Win-Kiddie bin und mit Suse erst jetzt zu tun bekomme. Genauso verhält es sich mit Postgres.
Woher das "-l datenbank" kommt ist schnell erklärt. Das Skript habe ich lediglich von meinem Vorgänger übernommen, weil es funkioniert hat (ich spreche von der Sicherung an sich). Ich will dabei allerdings nicht abstreiten, dass der Parameter vll. getrost ignoriert wird.
Meine ~/.pgpass-File enthält das Passwort in Klartext, mehr nicht. Oder muss ich die etwa irgendwie via Postgres verschlüsselt erzeugen lassen? (Mir kam in die Richtung noch nichts unter).
Die einlesende Datei enthält das Passwort 5 x in jeweils einer Zeile, ganz im DOS-Stil, weil ich es nicht anders kenne.
Btw. muss das PW vll. sogar die 5x in die ~/.pgpass-Datei?
das Problem ist, dass ich ein Win-Kiddie bin und mit Suse erst jetzt zu tun bekomme. Genauso verhält es sich mit Postgres.
Woher das "-l datenbank" kommt ist schnell erklärt. Das Skript habe ich lediglich von meinem Vorgänger übernommen, weil es funkioniert hat (ich spreche von der Sicherung an sich). Ich will dabei allerdings nicht abstreiten, dass der Parameter vll. getrost ignoriert wird.
Meine ~/.pgpass-File enthält das Passwort in Klartext, mehr nicht. Oder muss ich die etwa irgendwie via Postgres verschlüsselt erzeugen lassen? (Mir kam in die Richtung noch nichts unter).
Die einlesende Datei enthält das Passwort 5 x in jeweils einer Zeile, ganz im DOS-Stil, weil ich es nicht anders kenne.
Btw. muss das PW vll. sogar die 5x in die ~/.pgpass-Datei?
Moin Gilneas,
Hint: das war eine rhetorische Frage.
Ich bat doch vor wenigen Minuten darum, dass Du mal den anonymisierten Inhalt der ~./pgpass-Datei forumsöffentlich machst.
Und hatte mir etwas erhofft wie
... oder irgendetwas anderes im Format
Hattest Du diese Bitte gelesen?
Hint: das war auch eine rhetorische Frage.
Grüße
Biber
Meine ~/.pgpass-File enthält das Passwort in Klartext, mehr nicht.
Öhm.... hast Du mal meinen Link oben angetestet?Hint: das war eine rhetorische Frage.
Ich bat doch vor wenigen Minuten darum, dass Du mal den anonymisierten Inhalt der ~./pgpass-Datei forumsöffentlich machst.
Und hatte mir etwas erhofft wie
Zampano1:1530:DBMain:dbMUser:ForgetIt
Zampano1:*:*:defUser:How2ReadTFMhostname:port:database:username:password
Hattest Du diese Bitte gelesen?
Hint: das war auch eine rhetorische Frage.
Grüße
Biber
Auf die rhetorischen Fragen brauch ich kaum ncoh antworten 
.
Nein, das habe ich tatsächlich nicht... sorry, den hab ich irgendwie übergangen.
Na schön, dann werd ich mal das f*piep*k manual lesen und es morgen mit der hoffentlich richtigen pgpass ausprobieren.
Was mich trotzdem wundert ist, dass ich es mit meiner Noobhaftigkeit trotzdem geschafft habe die Abfragen von 5 auf eine zu reduzieren. Ich kann das nicht logisch nachvollziehen. Aber das soll mir auch egal sein, wenn das Manual morgen hilft.
So far danke soweit.
.Nein, das habe ich tatsächlich nicht... sorry, den hab ich irgendwie übergangen.
Na schön, dann werd ich mal das f*piep*k manual lesen und es morgen mit der hoffentlich richtigen pgpass ausprobieren.
Was mich trotzdem wundert ist, dass ich es mit meiner Noobhaftigkeit trotzdem geschafft habe die Abfragen von 5 auf eine zu reduzieren. Ich kann das nicht logisch nachvollziehen. Aber das soll mir auch egal sein, wenn das Manual morgen hilft.
So far danke soweit.
So, nun also noch einmal, nach erneutem rumspielen und diesmal haarklein, damit keiner rhetorische Fragen stellen muss.
Ich bin an unserer LinuxVM als root eingelogt. Als eben solcher habe ich folgende ~/.pgpass-Datei:
Diese Datei habe ich mit chmod auf 0600 gesetzt. Wenn ich jetzt beispielsweise das cmd
ausführe, dann kommt direkt die Abfrage nach dem Passwort. Und ich habe mit --help nachgesehen. Mein pg_dumpall kennt minus klein L als Parameter "database=DBNAME (specify an alternative default database)".
So, jetzt kam ich aber auf den Trichter simply den folgenden Befehl auszuprobieren:
Und das funktioniert und zwar auch ohne PW-Abfrage. Was mir jetzt fehlt ist das Wissen des Unterschieds zwischen den beiden Befehlen. Aber so wie ich das sehe geht pg_dumpall einfach auf alle Datenbanken los, während pg_dump nur eine spezifizierte auswählt. Dies hat zur Folge, dass bei pg_dumpall natürlich auch die Passwörter der anderen Datenbanken abgefragt werden. Und hier scheint der Hase im Pfeffer zu liegen. Die anderen DBs müssen mit einem anderen User angesprochen werden. Der hat zwar das gleiche PW, aber hier scheint die pgpass mit einem Platzhalter ' * ' für den User nicht zu greifen.
<edit>
Wenn ich fertig bin und der task als Cronjob läuft werde ich eine kleine Anleitung schreiben. Sowas hat mir nämlich wirklich gefehlt.
</edit>
Ich bin an unserer LinuxVM als root eingelogt. Als eben solcher habe ich folgende ~/.pgpass-Datei:
localhost:*:datenbank:username:passwortDiese Datei habe ich mit chmod auf 0600 gesetzt. Wenn ich jetzt beispielsweise das cmd
pg_dumpall -l datenbank -U usernameSo, jetzt kam ich aber auf den Trichter simply den folgenden Befehl auszuprobieren:
pg_dump -h localhost -U "username" datenbank Und das funktioniert und zwar auch ohne PW-Abfrage. Was mir jetzt fehlt ist das Wissen des Unterschieds zwischen den beiden Befehlen. Aber so wie ich das sehe geht pg_dumpall einfach auf alle Datenbanken los, während pg_dump nur eine spezifizierte auswählt. Dies hat zur Folge, dass bei pg_dumpall natürlich auch die Passwörter der anderen Datenbanken abgefragt werden. Und hier scheint der Hase im Pfeffer zu liegen. Die anderen DBs müssen mit einem anderen User angesprochen werden. Der hat zwar das gleiche PW, aber hier scheint die pgpass mit einem Platzhalter ' * ' für den User nicht zu greifen.
<edit>
Wenn ich fertig bin und der task als Cronjob läuft werde ich eine kleine Anleitung schreiben. Sowas hat mir nämlich wirklich gefehlt.
</edit>
Moin Gilneas,
nur noch ein Hinweis hierzu:
Die .pgpass ist aber durchaus für die Aufnahme beliebig vieler Zeilen/Autorisierungen geeignet.
Und AFAIK auch für Wildcards ("*") in den ersten 4 der 5 Items (also alles außer dem Password)
Aber selbst wenn das beim USERNAME nicht ginge, dann wäre doch eine Datei dieser Form möglich:
pg_dumpall sucht sich schon die Zeile(n) raus, die mit den übergebenen Parametern übereinstimmen.
Zweite Anmerkung zum Unterschied pg_dump und pg_dumpall.
Ja, pg_dumpall ruft seinerseits immer das pg_dump auf für jede einzelne DB.
Nein, es ist aber nicht das gleiche, ob Du nun jede vorhandene DB einzeln mit pg_dump abklapperst oder ein pg_dumpall auf alles machst.
Denn pg_dumpall sichert zusätzlich ja noch (die Supervisor-Rechte vorausgesetzt) auch die <i<globalen</i>, DB-übergreifenden DB-Objekte wie Privilegien, Benutzer, Packages etc.
Deshalb sollte ein pg_dumpall auch mit möglichst hohen Rechten (->Supervisor der DB) abgefeuert werden.
Wenn es "nur" um eine reine Sicherung der Tabelleninhalte geht-> ja hey... das kann auch sicherungsberechtiger Nicht-Supervisor.
Hat aber alles nicht unbedingt etwas mit dem Lnux-User root zu tun - es geht nur um die Datenbank-Rechte/um das, was die Datenbank kennt.
Grüße
Biber
nur noch ein Hinweis hierzu:
Die anderen DBs müssen mit einem anderen User angesprochen werden.
Der hat zwar das gleiche PW, aber hier scheint die pgpass mit einem Platzhalter ' * ' für den User nicht zu greifen
Der hat zwar das gleiche PW, aber hier scheint die pgpass mit einem Platzhalter ' * ' für den User nicht zu greifen
Die .pgpass ist aber durchaus für die Aufnahme beliebig vieler Zeilen/Autorisierungen geeignet.
Und AFAIK auch für Wildcards ("*") in den ersten 4 der 5 Items (also alles außer dem Password)
Aber selbst wenn das beim USERNAME nicht ginge, dann wäre doch eine Datei dieser Form möglich:
localhost:*:DBName1:usernameA:passwort
localhost:*:DBName1:usernameA:passwort
localhost:*:DBName1:usernameB:passwort
localhost:*:DBName2:usernameC:passwort
localhost:*:DBName3:usernameD:passwort
...Zweite Anmerkung zum Unterschied pg_dump und pg_dumpall.
Ja, pg_dumpall ruft seinerseits immer das pg_dump auf für jede einzelne DB.
Nein, es ist aber nicht das gleiche, ob Du nun jede vorhandene DB einzeln mit pg_dump abklapperst oder ein pg_dumpall auf alles machst.
Denn pg_dumpall sichert zusätzlich ja noch (die Supervisor-Rechte vorausgesetzt) auch die <i<globalen</i>, DB-übergreifenden DB-Objekte wie Privilegien, Benutzer, Packages etc.
Deshalb sollte ein pg_dumpall auch mit möglichst hohen Rechten (->Supervisor der DB) abgefeuert werden.
Wenn es "nur" um eine reine Sicherung der Tabelleninhalte geht-> ja hey... das kann auch sicherungsberechtiger Nicht-Supervisor.
Hat aber alles nicht unbedingt etwas mit dem Lnux-User root zu tun - es geht nur um die Datenbank-Rechte/um das, was die Datenbank kennt.
Grüße
Biber
