Der Export von Rollen bei PostgreSQL auf AWS RDS – leider ohne Passwort-Hashes

Schreibe eine Antwort

Ich hatte mir zum Ziel gesetzt, die Daten einer PostgreSQL-RDS zu einer anderen RDS migrieren zu wollen – und das via SQL. Daher habe ich versucht, die Metadaten für die Rollen zu generieren. Normalerweise würde ich das folgendermaßen machen:

$ pg_dumpall -h myrds.eu-central-1.rds.amazonaws.com -U rdsmaster
 -r -f dumpall_roles.sql

Leider klappte das nicht so, weil:

pg_dumpall: error: query failed: ERROR:  permission denied for table pg_authid
pg_dumpall: error: query was: SELECT oid, rolname, rolsuper, rolinherit, rolcreaterole, rolcreatedb, rolcanlogin, rolconnlimit, rolpassword, rolvaliduntil, rolreplication, rolbypassrls, pg_catalog.shobj_description(oid, 'pg_authid') as rolcomment, rolname = current_user AS is_current_user FROM pg_authid WHERE rolname !~ '^pg_' ORDER BY 2

AWS sperrt also den Zugriff auf die Tabelle pg_authid im Catalog. Auch eine Nachfrage beim AWS Support hat mir nur eingeschränkt geholfen.

I would like to kindly inform you that RDS PostgreSQL doesn’t support access on ‘pg_authid’ table. Since RDS is a managed service, for platform stability, RDS don’t support full permission for all system relations. […] The workaround is to supply “–no-role-passwords” to pg_dumpall command.

Na danke. Somit muss ich nun alle Passwörter nachträglich manuell setzen. Klappt natürlich nur, wenn man selbst die Hoheit über die Passwörter hat.

Pimp my HP Microserver Gen8 / Austausch SSD ODD-Bay

Schreibe eine Antwort

Da ich auf meinem HP Microserver gerade wieder mehr mit Datenbank-VMs experimentieren möchte, hatte ich mir vorgenommen, die SSD durch eine größere zu ersetzen. Generell habe ich bei meinem HP Microserver Gen9 schon alles gefühlt ersetzt. In der Basiskonfiguration hatte er mal einen Intel Celeron-Prozessor und 2GB ECC RAM. Mittlerweile hat er einen Intel Xeon E3-1225 V2, 16GB ECC RAM und eine 256GB SSD. Da ich leider bei Recherchen keinen schönen Adapter von 2,5 Zoll SSDs auf 3,5 Zoll-Slots für HDDs zu finden, habe ich (wie auch viele andere), die SSD im ODD-Bay platziert.

Die 256GB SSD reichte mir jetzt nicht mehr aus und ich habe mich für eine Samsung 860 PRO 1TB entschieden. Da ich mir viel IO-Last arbeiten möchte, war es mir wichtig, auf eine MLC-SSD zu setzen und somit den Verschleiß gegenüber einer TLC-SSD zu reduzieren. Aber es ist dennoch Wahnsinn, was für Mehrkosten das verursacht.

Vergleich:
Samsung 860 EVO 1TB – 148 EUR bei Amazon
Samsung 860 PRO 1TB – 226 EUR bei Amazon

Ursprünglich hätte ich eine 2TB SSD bevorzugt, die hätte allerdings gleich 482 EUR bei Amazon gekostet und somit mein Budget gesprengt. Ich finde es überraschend, dass bei Consumer-SSDs kaum ein Hersteller MLC SSDs produziert. Daher bin ich irgendwie bei Samsung hängen geblieben.

Austausch

Auf der Rückseite die beiden blauen Schrauben lösen und den oberen Gehäuseteil wegschieben.

Dort befindet sich bei mir die SSD, die ich mit einfachen Mitteln via Panzerband befestigt habe. Einfach Klebeband gelöst und die SSD mit der neuen ersetzt.

Kopie des Betriebssystems

Zuerst habe ich versucht, mithilfe des Bootimages von Acronis True Image die SSD zu klonen, bin jedoch gescheitert, da beim Booten nach dem Klon eine Windows-Fehlermeldung kam. Glücklicherweise habe ich bei Thomas-Krenn einen Artikel gefunden, wie man Festplatten mithilfe von CloneZilla klonen kann. Das hat dann funktioniert. Kurzzusammenfassung: device-device-Kopie mit Übernahme der Partitionstabelle (Parameter -e1 -e2 -j2 -r -v). Das ISO hatte ich über ILO angesteuert und die alte SSD hatte ich über ein USB-SATA-Interface angeschlossen.

Update 03.06.2020:

Die Idee des Titels und die grundlegende Anleitung zum Prozessoraustausch kommt hierher – vielen Dank daher noch einmal in diese Richtung.

Funktionen, die man bei AWS RDS nicht einsetzen kann – Teil 1

Schreibe eine Antwort

Ich darf in den letzten Monaten beruflich häufiger Datenbanken aus Rechenzentren nach AWS RDS migrieren. Ich gebe gerne zu, dass RDS ein großartiges Framework ist, durch das man sich nicht mehr um Installation, Konfiguration, Backup, Restore und Patching einer Datenbank kümmern muss und es dadurch bedeutend einfacher ist, Software einzusetzen, die man nicht so sehr im Detail kennt. Damit RDS so nutzbar ist, hat AWS eine eigene Konfektionierung entwickelt. Einige Funktionen sind somit leider nicht verfügbar. Da ich während meiner Arbeit immer wieder mal auf derartige Hürden stoße, möchte ich gerne über diese berichten.

Oracle

Oracle ist meiner persönlichen Meinung nach das beste relationale Datenbankmanagementsystem – jedoch auch das teuerste. Daher sollte man meiner Meinung nach auch wirklich nur Oracle einsetzen, wenn man einige Besonderheiten davon nutzen möchte.

Dateisystemschnittstellen

In eine Oracle-RDS kann man leider keine NFS-Shares von EFS oder anderen Storage mounten. Dadurch gibt es nur zwei Wege in die RDS herein und heraus:

  1. Nutzung eines S3-Buckets als Intermediate-Storage
    Upload nach S3, Download in RDS / Upload nach S3, Download nach App-Server, Schnittstellensystem, etc.
  2. Direktkopie via Datenbanklink und DBMS_FILETRANSFER. Dazu muss jedoch die andere Quelle eine Oracle-Datenbank haben und ist daher nicht zwingend geeignet.

Ich arbeite mit Schnittstellensystemen, die Dateien von oder zur Datenbank über NFS oder SMB direkt übertragen möchten. Das ist hier leider nicht möglich.

PostgreSQL

Authentifizierung mit Zertifikaten

Bei einem Projekt wollten wir eine Authentifizierung über Zertifikate mit der Datenbank einrichten. Dies entfällt leider, da man bei RDS weder die pg_hba.conf direkt bearbeiten, noch die SSL-Zertifikate mit eigenen ersetzen kann.

Was soll ich tun, wenn ich auf derartige Probleme stoße?

Tja, schwierig. Wenn man auf derartige Probleme stößt, ist die eingesetzte Software eigentlich nicht “cloud-ready”. Als Alternative kann man bspw. Oracle oder PostgreSQL manuell auf einer EC2 installieren. Dadurch gehen jedoch die Automatisierungseffekte verloren, die einem die Administration so signifikant vereinfachen.

Besonderheit bei der Rollenadministration beim Einsatz von Oracle bei AWS RDS

Schreibe eine Antwort

Bei einem Import eines Datapump-Dumps in eine Oracle-RDS-Umgebung fiel neulich folgende Problematik auf:

Ich hatte eine Rolle, die ich nicht granten konnte und das, obwohl ich mit dem RDS-Master-User arbeite. Es zeigte sich, dass ich keine GRANTs verteilen konnte, weil mir die ADMIN OPTION für diese Rolle fehlte. Leider habe ich die genaue Fehlermeldung nicht mehr parat. Da ich bei RDS auch keine SYS-Privilegien besaß, konnte ich nicht die ADMIN OPTION nachträglich setzen.

Zur Validierung habe ich erneut eine Rolle angelegt und gesehen, dass ich auch automatisch die ADMIN OPTION bei Erstellung erhalte.

CREATE ROLE TESTROLE_A NOT IDENTIFIED;

-- Grantees of TESTROLE_A
GRANT TESTROLE_A TO DB_ADMIN WITH ADMIN OPTION;

Somit bin ich zum Ergebnis gekommen, dass die Rolle von Datapump leider allgemein ohne einen einzigen Administrator importiert wurde und somit zwar allgemein nutzbar, aber nicht mehr administrierbar ist. Da man bei AWS nicht an die SYS-Privilegien herankommt und zur Modifizierung der Rolle die rdsadmin.rdsadmin_util.grant_sys_object-Prozedur nicht hilfreich ist, blieb mir nichts übrig, als manuell die Rolle zu löschen und erneut anzulegen.