Articles tagged "linux"

systemd-resolvd (v250) broken in testing

Every other distribution/version works but not systemd 250...

Debian 12

root@lxc-local-debian12:/# resolvectl
Global
       Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Debian 11

root@lxc-local-debian11:/# resolvectl
Global
       Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
     Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
   DNS Servers: 172.22.240.1

Docker-Gitea-Postgres Part 5: Posgres MD5- und SCRAM-Passwörter

Teil 5 einer Reihe über Gitea & Postgres im Docker-Container: Postgres MD5- und SCRAM-Passwörter

Hintergrund dieser Reihe ist das notwendige Update einer Docker-Gitea-Instanz und in diesem Rahmen auch das Major-Version-Upgrade der zugehörigen Postgres-Datenbank.

Postgres MD5- und SCRAM-Passwörter

Mit Version 10 hat Postgres Abschied von den alten und potentiell unsicheren MD5-Passwort-Hashes genommen. Ersatz dafür sind die sog. "SCRAM secrets". Das bedeutet aber auch, dass bei einem Major-Upgrade von 9 auf 10 (oder danach) alle Benutzer keine "passend" verschlüsselten Passwörter mehr haben.

Vorgeschichte

Nachdem Gitea nicht mehr starten bzw. dauerhauft laufen wollte, bin ich auf einigen Umwegen auf folgenden Log-Eintrag gestoßen:

root@docker:~ # docker logs gitea_db
[...]
FATAL:  password authentication failed for user "gitea"
DETAIL:  User "gitea" does not have a valid SCRAM secret.
    Connection matched pg_hba.conf line 100: "host all all all scram-sha-256"
[...]

Wenn man dies direkt im Container ausprobiert, kommt auch nur eine (wenig sagende) Fehlermeldung:

root@docker:~ # docker exec -it gitea_db bash
root@bash-5.1# psql -U gitea -h 172.31.3.2
  psql: error: connection to server at "172.31.3.2", port 5432 failed: FATAL:  password authentication failed for user "gitea"

SCRAM als Ersatz für MD5

Wenn man sich im Container umsieht, findet man auch die entsprechenden Stellen, an denen die Postgres-Instanz auf SCRAM konfiguriert wird;

root@bash-5.1# grep password_encryption /var/lib/postgresql/data/postgresql.conf 
#password_encryption = scram-sha-256    # scram-sha-256 or md5

root@bash-5.1# grep -v "^#\|^$" /var/lib/postgresql/data/pg_hba.conf 
local   all             all                                     trust
host    all             all             127.0.0.1/32            trust
host    all             all             ::1/128                 trust
local   replication     all                                     trust
host    replication     all             127.0.0.1/32            trust
host    replication     all             ::1/128                 trust
host all all all scram-sha-256

Natürlich ist das Ersetzen von MD5 durch einen stärkeren Algorithmus notwendig und zu begrüßen, letztendlich war es aber der Aufhänger für diese ganze Reihe von Artikeln ;)

Um jetzt zu sehen, welche Benutzer bereits ein SCRAM-Passwort haben, verbindet man sich mit der Datenbank und stellt eine Anfrage:

root@bash-5.1# psql -U gitea
psql (14.2)
Type "help" for help.

gitea=# SELECT rolname, rolpassword ~ '^SCRAM-SHA-256\$' AS scram_pw FROM pg_authid WHERE rolcanlogin;
 rolname | scram_pw 
---------+--------------
 gitea   | f
(1 row)

Man sieht, der Benutzer "gitea" hat offensichtlich noch kein SCRAM-Passwort ("f"alse).

Da es in diesem (Gitea-Docker-)Fall nur ein Benutzer ist, kann man das Passwort auch schnell von Hand setzen - wie es im .env, Ansible-Playbook, ... gesetzt wurde:

gitea=# \password gitea
Enter new password for user "gitea": 
Enter it again: 

Im Erfolgsfall gibt es keine weitere Ausgabe, stimmen die beiden Versuche nicht überein, kommentiert Postgres dies mit einem Passwords didn't match.. Die Datenbank-Commandline kann man per exit verlassen. Dann kann man auch nochmals kurz an der Commandline kontrollieren, ob der Benutzer nun ein SCRAM-Passwort hat:

root@bash-5.1# echo "SELECT rolname, rolpassword ~ '^SCRAM-SHA-256\$' AS scram_pw FROM pg_authid WHERE rolcanlogin;" | psql -U gitea
 rolname | scram_pw 
---------+--------------
 gitea   | t
(1 row)

Schluss

Nach dem Setzen des Passworts als SCRAM secret konnte sich der Gitea-Container wieder ohne Probleme an die neue Postgres-Instanz verbinden. Seit dem läuft Gitea und Postgres also wieder in aktueller Version!

Docker-Gitea-Postgres Part 4: Gitea startet nicht

Teil 4 einer Reihe über Gitea & Postgres im Docker-Container: Gitea startet nicht

Hintergrund dieser Reihe ist das notwendige Update einer Docker-Gitea-Instanz und in diesem Rahmen auch das Major-Version-Upgrade der zugehörigen Postgres-Datenbank.

Docker und Debugging - zwei Welten treffen aufeinander

Vorlauf

Bis zu diesem Schritt lief soweit alles problemlos ab:

  • Backup von Gitea - und auch dessen Restore auf einer anderen Maschine!
  • Backup der alten Postgres-9-Instanz
  • Testweiser Restore des Postgres-Backups auf einem Postgres-9 und Postgres-14

Gitea startet nicht mehr - oder doch?

Ein Versuch auf das Web-Frontend zuzugreifen, brachte verschiedene Fehler des Reverse-Proxys zu Tage. Ein Zugriff auf Gitea war aber nicht möglich.

Erst nach einiger Zeit und einigen docker ps -a fiel mir auf, dass der Gitea-Container sich offensichtlich immer wieder beendete - aber eben nicht sofort, sondern nach ca. einer Minuten. Er wurde dann wieder neu gestartet und nach einer weiteren Minute begann das Spiel von vorne. Von einem Blick in die Logs erhofft man sich ja Aufschluss, was da gerade vor sich geht:

root@docker:~ # docker logs gitea
Server listening on :: port 22.
Server listening on 0.0.0.0 port 22.
cmd/web.go:102:runWeb() [I] Starting Gitea on PID: 15
cmd/web.go:150:runWeb() [I] Global init
routers/init.go:107:GlobalInitInstalled() [I] Git Version: 2.30.3, Wire Protocol Version 2 Enabled
routers/init.go:110:GlobalInitInstalled() [I] AppPath: /usr/local/bin/gitea
routers/init.go:111:GlobalInitInstalled() [I] AppWorkPath: /app/gitea
routers/init.go:112:GlobalInitInstalled() [I] Custom path: /data/gitea
routers/init.go:113:GlobalInitInstalled() [I] Log path: /data/gitea/log
routers/init.go:114:GlobalInitInstalled() [I] Configuration file: /data/gitea/conf/app.ini
routers/init.go:115:GlobalInitInstalled() [I] Run Mode: Prod
Received signal 15; terminating.

Und das wiederholte sich immer und immer wieder. Die ersten beiden Zeilen kommen BTW vom OpenSSH-Server, welcher auch im Gitea-Container läuft.

Nach einiger Zeit (und Frust) bin ich dann wieder mal in den Container gegangen und hab dort nach weiteren Informationen gesucht. Und siehe da, im Gitea-Log-File stehen Informationen, die es - warum ich immer - nicht ins docker logs geschafft haben:

root@bash-5.1# cat /data/gitea/logs/gitea.log
[...]
routers/common/db.go:27:InitDBEngine() [I] ORM engine initialization attempt #8/10...
cmd/web.go:153:runWeb() [I] PING DATABASE postgres
routers/common/db.go:33:InitDBEngine() [E] ORM engine initialization attempt #8/10 failed. Error: pq: password authentication failed for user "gitea"
routers/common/db.go:34:InitDBEngine() [I] Backing off for 3 seconds
[...]

Warum zum Geier schafft es eine solch essentielle Fehlermeldung nicht in die docker logs?! Warum auch immer ich die Idee hat, mir im Container die Logs anzusehen - ohne diese Zeilen hätte ich vermutlich bald aufgegeben und wäre wieder auf die alte Postgres-Version zurückgegangen.

Was sagt denn die Datenbank dazu?

Mit diesem Hinweis schaute ich dann natürlich auch noch in die docker logs der Datenbank. Und siehe da:

root@bash-5.1# docker logs gitea_db
[...]
FATAL:  password authentication failed for user "gitea"
DETAIL:  User "gitea" does not have a valid SCRAM secret.
    Connection matched pg_hba.conf line 100: "host all all all scram-sha-256"
[...]

Der Fehler ist also weniger bei Gitea- als in der Postgres-Datenbank zu suchen - wobei "Fehler" hier natürlich auch nicht korrekt ist. Der alte, aus dem Backup stammende, gitea-Benutzer der Postgres-Datenbank hat einfach kein passend verschlüsseltes Passwort!

Das Setzen eines neue Passworts wird im Teil 5: Postgres MD5- und SCRAM-Passwörter beschrieben.

Fazit

Solche Dinge begegnen mir im Docker-Umfeld immer und immer wieder. Gar keine Logs, Logs nicht an der vermuteten/offiziellen Stelle, zu schnell rotiert Logs - Gründe dafür gibt's viele. Aber genau das sorgt dafür, dass man ohne tiefes Wissen gar keine Chance mehr hat, selbständig aus dieser Situation wieder herauszukommen. Docker wurde eingeführt, damit sich Admins mit gewissen Themen nicht mehr beschäftigen müss(t)en - aber dann eben einfach an einer Wand zerschellen, weil sie keine Ahnung (in diesem Fall rund um die Logs) haben...

Docker-Gitea-Postgres Part 3: Postgres Upgrade

Teil 3 einer Reihe über Gitea & Postgres im Docker-Container: Postgres Upgrade

Hintergrund dieser Reihe ist das notwendige Update einer Docker-Gitea-Instanz und in diesem Rahmen auch das Major-Version-Upgrade der zugehörigen Postgres-Datenbank.

Postgres

Major-Versionen, interne Struktur

Bis einschließlich zur Version 9 waren die zweistelligen Versionsnummern (die letzte Version war 9.6) die Haupt- oder "Major"-Versionen von Postgres. Dass die zweite Stelle im Allgemeinen bzw. bei vielen Projekten als "Minor"-Version bezeichnet wird, lief dem entgegen. Trotzdem war beim Sprung 9.5 auf 9.6 ein entsprechendes Vorgehen notwendig, da sich die interne Datenstruktur geändert hat (bzw. ändern hätte können) und die neuen Version nicht mit den alten Dateien auf der Platte umgehen konnte.

Ab der Version 10 sind jetzt auch bei Postgres Major-Versionssprünge an der ersten Stelle erkennbar, z.B. von 10 auf 11.

Die letzten Sprünge, an denen ein Upgrade nicht einfach durchgeführt werden konnte, waren folglich: 9.4 → 9.5 → 9.6 → 10 → 11 → 12 → 13 → 14

Welche Postgres-Versionen noch supported werden, kann man auf der "Versioning Policy"-Seite der Postgres-Dokumentation nachsehen.

Upgrade mit "pg_upgrade"

Seit einiger Zeit bringt Postgres ein Tool namens pg_upgrade mit, welches den alten und etwas aufwändigen Weg nicht mehr notwendig macht. Dieses Command ist allerdings auf einen Betrieb des Postgres-Servers auf einer "normalen" Linux-Installation (Host, VM, OS-Container, ...) ausgelegt und kann hier nicht helfen.

Als Alternative stehen allerdings mehrere Scripte, Tools und Docker-Container zur Verfügung, welche dieses Upgrade automagisch durchführen sollen (können). Da ich aber sowieso ein Backup der Datenbank machen möchte, bediene ich mich aus dem Skript des zweiten Teils dieser Reihe

Klassisches Upgrade

Das klassische Upgrade entspricht einem Backup, einem Upgrade des Postgres-Server und dem Restore. Die entsprechenden Schritte sind im zweiten Teil dieser Reihe (Postgres Backup) beschrieben.

Upgrade mit Docker

Ich habe mich inzwischen aus Sicherheitsgründen entschieden, das "alte" Daten-Docker-Volume erstmal aufzuheben und für die neue Postgres-Version ein neues Docker-Volume anzulegen. Erinnerung: Die neue Postgres-Version kann mit dem on-disk-format der alten Version leider nichts anfangen bzw. sie öffnen.

Folgende Schritte sind dann notwendig:

  • Den Gitea-Container stoppen, damit keine Schreibzugriffe (und später auch Lesezugriffe) auf die Datenbank kommen
  • Ein neues Volume (hier: gitea_db_14data, die 14 kommt von der Postgres-Major-Version) anlegen (lassen) - z.B. durch Anpassung im docker-compose.yml oder Ansible-Playbook oder wie auch immer die Container(-Volumes) angelegt werden/wurden.
  • Den Postgres-Container bzw. den Tag/Version im docker-compose.yml, Ansible-Playbook, ... entsprechend ändern und anlegen (lassen). In einem Fall habe ich ein Upgrade von 9-alpine auf 14-alpine durchgeführt und es hat problemlos funktioniert.
  • Den Datenbank-Container (und nur diesen) starten. Im Zweifelsfall beide Container starten und gitea wieder stoppen.
  • Anhand des zweiten Teiles dieser Reihe, Abschnitt "Restore im Docker" die Backup-Datei in den Container kopieren und wieder in die Postgres einspielen.
  • Den Gitea-Container wieder starten
  • Wen man sicher ist, dass es nicht mehr braucht wird, das Volume gitea_db_data (das alte Volume! Ohne "14"!) löschen.

Docker-Gitea-Postgres Part 2: Postgres Backup

Teil 2 einer Reihe über Gitea & Postgres im Docker-Container: Postgres Backup

Hintergrund dieser Reihe ist das notwendige Update einer Docker-Gitea-Instanz und in diesem Rahmen auch das Major-Version-Upgrade der zugehörigen Postgres-Datenbank.

Postgres

Backup allgemein

Um aus einer laufenden Postgres-Instanz (nahezu) alle Daten zu sichern, gibt es den Befehl pg_dumpall. Da das entstehende Backup reiner Text ist, wird es gleich in einem Rutsch mit xz komprimiert, damit es kleiner wird.

postgres@db:~ # pg_dumpall | xz >pg-backup.xz
[...]

Umgekehrt kann man auch einen Dump in eine (leere) Datenbank wieder einspielen :

postgres@db:~ # xzcat pg-backup.xz | psql -U <USERNAME> -d <DATABASE>

Backup im Docker

Da in den meisten Docker-Umgebungen nicht nur eine Postgres-Datenbank laufen wird, habe ich mir im Laufe der Zeit ein Script geschrieben, welches bei Übergabe des Container-Namens sich ein Backup auf den Host (konkret: ins aktuelle Verzeichnis) zieht:

root@docker:~ # .../postgres-backup.sh gitea_db
-rw-r--r-- 1 root root   115320 Apr 17 09:59 gitea_db_2022-04-17_09:59:23_postgres:9-alpine_9.6.24.xz

Im Backup-Dateinamen sind nacheinander Container-Name, Zeitstempel, Image-Name und Posgres-Version hinterlegt. So kann man auch z.B. im Rahmen eines Upgrades ;) nachvollziehen, mit bzw. auf Basis welcher Version das Backup angelegt wurde.

Das Script macht folgende Schritte:

  • (Zeile 3-13) Basierend auf dem übergebenen Namen wird die Container-ID ermittelt
  • (Zeile 14-19) Beginnt der zu Grunde liegende Image-Name nicht mit "postgres" wird das Script abgebrochen - es ist vermutlich kein Postgres-Container
  • (Zeile 21-29) Der Postgres-Username und -Version werden aus den Container-Umgebungsvariablen extrahiert
  • (Zeile 31-36) Der Backup-Dateinamen wird generiert und sichergestellt, dass es nicht bereits existiert
  • (Zeile 37-39) pg_dumpall wird aufgerufen, das Ergebnis durch xz komprimiert und ein ls -l auf die Datei angezeigt
#!/bin/ash

PGCONTAINER=$1
PGCONTID=$(docker ps -qf "name=^${PGCONTAINER}$")

if [ -z "$PGCONTID" ]; then
    echo "Container '${PGCONTAINER}' not found"
    exit 1
elif [ $(echo ${PGCONTID}| wc -m) -ne 13 ]; then
    echo "Unknown container id: ${PGCONTID}"
    exit 1
fi

DIMAGE=$(docker inspect ${PGCONTID} | jq '.[].Config.Image' | tr -d '"')
PGIMAGE=$(basename $DIMAGE | grep '\(^\|/\)postgres:')
if [ -z "${PGIMAGE}" ]; then
    echo "Not a Posgres image '${DIMAGE}'"
    exit 1
fi

export $(docker inspect ${PGCONTID} | jq '.[].Config.Env' | grep '"POSTGRES_USER\|"PG_VERSION' | tr -d '"' | sed -e 's/,$//')

if [ -z "${POSTGRES_USER}" ]; then
    echo "No Posgres user found"
    exit 1
elif [ -z "${PG_VERSION}" ]; then
    echo "No Postgres version number found"
    exit 1
fi

BACKUPFILE=${PGCONTAINER}_$(date +%F_%T)_${PGIMAGE}_${PG_VERSION}
if [ -f "${BACKUPFILE}.xz" ]; then
    echo "Backupfile exists"
    exit 1
fi

docker exec -it -w /tmp ${PGCONTID} sh -c "pg_dumpall -U ${POSTGRES_USER}" | xz >${BACKUPFILE}.xz

ls -l ${BACKUPFILE}.xz

Restore im Docker

Ich habe es nicht geschafft, die Backup-Datei vom Host aus direkt an einen psql in einen Container per Pipe zu übergeben. Falls hier jemand einen Tipp hat, gerne per Mail an mich ;)

Um also die Daten in den neu angelegten (oder umgezogenen oder...) Container zu bringen, kopiert man die Backup-Datei in den Container:

root@docker:~ # docker cp $BACKUPFILE gitea_db:/tmp/

Der zweite Schritt besteht dann darin, im Container das Backup wieder an Postgres zu verfüttern:

root@docker:~ # docker exec -it gitea_db bash
root@bash-5.1# psql -U gitea -d gitea < /tmp/gitea_db_2022-04-17_09:59:23_postgres:9-alpine_9.6.24.xz
root@bash-5.1# rm /tmp/gitea_db_2022-04-17_09:59:23_postgres:9-alpine_9.6.24.xz

Es macht natürlich keinen Sinn, das Backup im Container liegen zu lassen, es ist schließlich nur eine Kopie, daher wird es auch gleich wieder gelöscht.

Anmerkungen:

  • Meine Docker-Installationen laufen im Allgemeinen auf einem btrfs-Dateisystem. Daher ist Kopieren und Löschen ein Vorgang, der keinerlei Speicher benötigt. Läuft Docker allerdings mit irgendeiner Art von Images, dann ist dieser HD-/SSD-Speicherplatz bis zum nächsten Container-Anlegen und anschließendem "purge" verloren! Hier geht's nur um ca. 100kB, also wirklich nicht viel. Bei einer Multi-GiByte-Datenbank sieht das dann vielleicht anders aus!
  • Natürlich könnte man die Backup-Datei in ein temporäres Docker-Volume kopieren, dieses in den neuen Datenbank-Container einhängen und von dort das Restore machen. Der Aufwand war/ist mir aber zu groß.
  • Wer sofort seinen Speicher zurück möchte, der kann natürlich nach dem Restore den Container zerstören und neu anlegen. Dann ist der Speicher nach der nächsten Maintainance auch wieder frei.

Docker-Gitea-Postgres Part 1: Gitea Backup

Teil 1 einer Reihe über Gitea & Postgres im Docker-Container: Gitea Backup

Hintergrund dieser Reihe ist das notwendige Update einer Docker-Gitea-Instanz und in diesem Rahmen auch das Major-Version-Upgrade der zugehörigen Postgres-Datenbank.

Gitea

Backup allgemein

Gitea hat eine integrierte Backup-Funktion, welche man sehr einfach über die Command-Line aufrufen kann. Ergebnis ist dann eine ZIP-Datei, welche später oder wo anders wieder eingespielt werden kann:

gitea@gitea:~ # gitea dump -c .../app.ini --file /tmp/gitea-dump.zip

Backup im Docker

Wenn Gitea im Docker läuft, muss man natürlich auf die laufende Gitea-Instanz im Container zugreifen und anschließend die Sicherung aus dem Container holen. Dies kann mit dem folgenden Script passieren, welches der Sicherung am Schluss auch noch einen Zeitstempel verpasst:

#!/bin/ash

CONT_NAME=gitea
CONT_ID=$(docker ps -qf "name=^${CONT_NAME}$")
docker exec -u git -it -w /tmp ${CONT_ID} bash -c '/app/gitea/gitea dump -c /data/gitea/conf/app.ini --file /tmp/gitea-dump.zip'
docker cp ${CONT_ID}:/tmp/gitea-dump.zip .
docker exec -u git -it -w /tmp ${CONT_ID} bash -c 'rm /tmp/gitea-dump.zip'
BACKUPFILE=gitea-dump-$(date +"%Y%m%d%H%M").zip
mv ./gitea-dump.zip $BACKUPFILE

Da ich aktuell nur eine Gitea-Instanz am Laufen habe, ist der Container-Name im Script in Zeile 3 fest auf gitea gesetzt - natürlich kann man das Script an dieser Stelle erweitern und z.B. den Container-Namen an der Command-Line übergeben. Oder über ein Konstrukt eine Schleife bauen, welche gleich alle Gitea-Instanzen sichert.

Apropos Anpassungen: Meine Docker-Hosts nutzen AlpineLinux, daher ruft das Script in Zeile 1 eine ash auf - dies muss ggf. noch auf sh oder bash korrigiert werden.

Restore

Leider gibt es aktuell kein Restore-Command für Gitea. Die notwendigen Schritte sind jedoch IMHO ausreichend in der - nicht immer sehr ausführlichen - Dokumentation von Gitea unter Usage: Backup and Restore beschrieben. Bei mir haben die Schritte funktioniert - sowohl beim Restore als auch beim Umzug auf einen anderen Rechner/Host. Falls der Link nicht mehr gehen sollte, hier die Schritte:

# open bash session in container
root@docker:~ # docker exec --user git -it 2a83b293548e bash
# unzip your backup file within the container
root@bash-5.1# unzip gitea-dump-1610949662.zip
root@bash-5.1# cd gitea-dump-1610949662
# restore the gitea data
root@bash-5.1# mv data/* /data/gitea
# restore the repositories itself
root@bash-5.1# mv repos/* /data/git/repositories/
# adjust file permissions
root@bash-5.1# chown -R git:git /data
# Regenerate Git Hooks
root@bash-5.1# /usr/local/bin/gitea -c '/data/gitea/conf/app.ini' admin regenerate hooks

systemd is enterprise grade software...

systemd does not like to run with newer kernels if there are new capabilities...

root@buster:~ # systemctl show dnsmasq >/dev/null; echo $?
Failed to parse bus message: Invalid argument
1

I really like that software. NOT.

This breaks many software packages which (have to) use systemd, e.g. Ansible - see Github Ansible Issue #71528

Quick fix for Debian Buster/Backport's /usr/lib/python3/dist-packages/ansible/modules/system/systemd.py (Ansible 2.9.6)

Fixes should go into Ansible 2.10.4 and 2.9.16.

12. Chemnitzer Linux Tage

Samstag

  • R. Richter: Git ist MacGyver - Kernelsourcen mit Git verwalten
    Es ist ja schön, wenn man Leute findet, die @kernel.org-E-Mail-Adressen haben und dann auch noch über ein Kernel-nahes Projekt vortragen. Nur leider zeigte sich hier, dass nicht jeder Techniker dafür geschaffen ist, Vorträge zu halten. Vom Git-Einsteiger bis -Profi sollten alle bedient werden. Und das geht einfach in 45 Minuten nicht. Hätte er sich auf seine "Cool stuff"- und "Git and Linux"-Folien beschränkt (und die ausführlich gemacht), hätte es wirklich gut werden können. Aber so: Guter Vorsatz, schlecht umgesetzt.
  • H. Schlittermann: DNSSEC - Sichere Namensauflösung im Internet
    TSIG, DNSSEC, KSK, ZSK - viele Begrifflichkeiten, wenig Verwirrung, viel "so läuft der Hase". Meiner Meinung nach ein sehr guter Vortrag, um einmal den Einstieg in die Tiefen von DNS (hier: die Sicherheit der Daten) zu bekommen. Für mich als Techie hätte das sicherlich noch technischer sein dürfen, aber im Großen und Ganzen bin ich mit dem Überblick und Einstieg sehr zufrieden.
    Folien: DNSSec-Vortrag.pdf
  • P. Dickten: Einführung in CouchDB
    Das Grundkonzept der CouchDB war mir aus einem Tutorial geläufig, ich erhoffte mir hier wohl etwas zu viel. Die absoluten Basics wurden breit und ausführlich erklärt, als es dann aber interessant wurde (Replikation, Views, Map&Reduce;) musste der Referent sich bereits sputen. Aus seiner Anspielung ("... damit ich nicht wieder mit Gewalt aus dem Raum bzw. von der Bühne gezogen werden muss...") war zu entnehmen, dass er schon bei anderen Vorträgen in Zeitprobleme kam. Schade, denn genau das, was letztendlich durchgehetzt wurde, wäre das wirklich interessante gewesen und hätte vielleicht (auch mir) mal aufzeigen können, wo CouchDB besser geeignet ist als eine SQL-Datenbank
  • S. Schwarzer: Robustere Python-Programme
    Für jemanden, der gelegentlich Python programmiert, sicher ein sehr interessanter Vortrag von Anfang bis zum Ende. Für mich waren manche Folien weder neu, noch die Vorschläge "robust", doch da auch dies interessant und mit einer Prise Witz vorgestellt wurde, ein durchgängig nett anzuhörender Vortrag.

(Persönliches) Fazit des Samstag Vormittag: Ich sollte häufiger Abstracts der Vorträge lesen ;-)

  • A. Wirt: Single-Sign-On mit Kerberos
    Was passiert laut Murphey, wenn man in seinem Vortrag auf Netz angewiesen ist? Richtig! Es geht natürlich genau dann nicht ;-) War ein wenig doof, weil sich so einiges an Zeit, welche für den praktischen Vortrag gedacht war, leider nicht mehr zur Verfügung stand. Positiv ist, dass alle Informationen dieses Vortrags und auch die Vorgehensweise in ein Wiki überführt werden sollen, damit auch andere ihre Erfahrung einbringen können
  • P. Heinlein: Dovecot: Warum man keinen anderen IMAP-Server haben will
    Langsam sollte ich aufhören, in Vorträge von Peer zu gehen ;-) Eine unterhaltsame Zeit ist zwar garantiert, aber viele seiner Aussagen, Meinungen und Aufstellungen kenn ich nun halt doch schon. Letztendlich war's eine unterhaltsame Marketing-Veranstaltung für Dovecot - inkl. praktischem Anteil, sprich eine "Live-Installtion" des selben.

Sonntag

  • S. Andres: Einführung in die Virtualisierung mit kvm, qemu und libvirt
    Klassischer Fall von "Guter Vortrag, aber nicht für mich". Dass ich den Titel des Vortrags nicht vollständig wahrgenommen habe ("Einführung..."), schieb ich jetzt mal auf noch fehlenden Kaffee ;-)

XFS gegen Ext4

Im Rahmen eines "Festplatten-Upgrades" habe ich auch gleich mal auf neue Filesysteme umgestellt. Dabei ist meine Root-Partition nun mit Ext4 formatiert, genauso wie meine Home-Partition.

Der erste Eindruck von Ext4: WOW!

Die Geschwindigkeit im Gegensatz zu XFS ist beeindruckend. Der Start von Iceweasel/Firefox geht gefühlt 10x so schnell wie vorher.

Allerdings dürfte ich die Zeit jetzt beim Backup-Erstellen wieder aufbrauchen, so ganz traue ich dem Frieden hier noch nicht ;-)

Chemnitzer Linux Tage 2009

Samstag

  • Sören Sprenger - GPL Telefonanlage Gemeinschaft
    Nette Übersicht über die Features, die das Projekt bietet und ein paar Screenshots, was man alles mit der Web-Oberfläche machen kann. Ich hätte mir etwas mehr Technik bzw. Abgrenzungen zu anderen Lösungen, die auch Asterisk einsetzten, gewünscht.
  • Gerhard Galsterer - Ethernet und Mobilfunk, zwei Welten begegnen sich
    Kompakter Überblick über Probleme und Möglichkeiten, die beim Verbinden zweier Ethernet-Segmente via Mobilfunk existieren. Für mich zu wenig Linux-Verbindung, mich hätte schon interessiert, was an Software auf den Boxen läuft - und natürlich, was für Hardware da überhaupt drin steckt.
  • Ralf Spenneberg - Praktische SELinux Anwendung: Kiosk-Modus für Gäste
    Super Start, um mal ein bisschen in SELinux reinzuschnuppern! Guter Vortrag, guter Inhalt, viel rübergebracht! TOP! Und es war wohl auch der Startschuss, dass ich mich wirklich mal etwas da einlese/einarbeite. Sinngemäßes Zitat: "Sie denken, Sie können SELinux nicht einsetzten, weil Sie es nicht verstehen? Aber den Linux-Kernel verstehen Sie, ja? ;-) SELinux verbietet nur Dinge, die bisher erlaubt waren - nicht andersrum -, es wird also nur 'besser'."
  • Prof Dr. Peter Trommler - OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE
    Im Linux-Magazin war vor kurzem schon ein Artikel dazu und gerade die Tatsache, dass man eben nichts am Server installieren muss, macht dieses Offline-FS so interessant. Bisher ist wohl eher ein Prototyp entwickelt worden, aber trotzdem werde ich das demnächst mal austesten ;-)
  • Martin Schütte - Syslog nach RFC
    Klingt irgendwie interessant, wie das ganze funktionieren soll, nur ob man das wirklich will, sei mal dahingestellt. Wenn mir jemand in den Syslog-Server "spucken" kann, ist er eh schon in meinem Netz (evtl. sogar auf dem Rechner) und wieso sollte er dann nicht mit den Möglichkeiten, die man so auf einer UNIX-Büchse hat, Log-Meldungen verschicken?!?
  • David Roetzel: Systemkonfiguration managen mit Puppet
    Ui, heftiges Thema. Die Config-Files sehen halbwegs brauchbar aus, auch wenn es definitv schöner gehen würde. Ist wohl der Tatsache geschuldet, dass es in Ruby programmiert ist ;-). Naja, ich denke man muss das System mal antesten, sich selbst am Riemen reißen, dass man es so macht, wie es Puppet will und dann darf man urteilen. Was mich allerdings nachdenklich stimmt ist die CPU-Zeit, die der Master wohl so zum "Client-Config-Compiliere" braucht - wenn ich das richtig verstanden habe.
  • Karl Uwe Lockhoff: Einsatz von NetBSD auf minimaler Hardware
    Ziemlich theoretischer Vortrag, wie man NetBSD kleiner machen kann um es eben auf kleiner/alter Hardware als Mini-Server laufen lassen kann. Ich hätte das ganze etwas praktischer, bzw. mit "echten" Configs, besser gefunden.

Sonntag

  • Peter Eisentraut - Spaß mit PostgreSQL
    Hmm, was soll ich sagen? Inhalt gut, am Vortragsstil fand ich noch Optimierungspotential. Die Sachen, die man mit PostgreSQL machen kann, sollte man auf jeden Fall mal austesten, schließlich ist es fast egal, was z.B. die eingebundenen "Funktionen" machen
  • David Kastrup - Lua, eine kompakte Erweiterungssprache
    Eigentlich bin ich von David ja echt gute Vorträge gewohnt. Leider hat er sich wohl letzte Nacht etwas... "überhoben" und ist zu spät in's Bett bzw. den Schlafsack gekommen. Letztendlich gleiches Fazit wie beim PostgreSQL-Vortrag: Inhalt top, Vortrag flop :-(
  • Hans-Jürgen Schönig - PostgreSQL: Aktuelle Entwicklungen
    Schade, leider zu spät gekommen und so eine echt gute Show (und auch guten Inhalt!) teilweise verpasst! Schön zu sehen, dass man auch solche Vorträge nicht nur bierernst rüberbringen kann, sondern dass auch hier der Spaß ganz weit vorne stehen kann. Der unüberhörbare österreicher Akzent tat dann sein übriges ;-)

CeBIT 2009 - mit mir

Dieses Jahr hat's mich auch mal erwischt. Ich bin auf der CeBIT 2009.

Wer Lust hat, kann mich ja in Halle 6, Stand G41 (rechter Teil von Heinlein) mal besuchen. Teamix stellt u.a. Nagios aus und ich halte auch täglich einen Vortrag darüber.

Wer uns nicht findet, einfach nach den roten oder türkis Shirts ausschau halten ;-)

NFSv4 verringert Latenzen gegenüber NFSv3 (insbesondere über WLAN)

Kurz zu meiner Motivation:

Weil ich es lieben und schätzen gelernt habe, auf vielen/allen Rechner das gleiche Home-Verzeichnis zu haben, liegt bei mir zu Hause /home auf meinem Server. Dies wird dann von den diversen anderen Rechner per NFS (bisher V3) gemountet.

Meine Workstation ist aufgrund der Lage in der Wohnung per WLAN mit dem Server verbunden, was an sich kein Problem ist (die Geschwindigkeit reicht vollkommen aus, vielleicht mal beim DVD brennen nervt's - wenn das Image auf dem Server liegt).

Allerdings gibt es ein paar Programme, die IMHO viel zu häufig auf das Dateisystem zugreifen, dazu gehört eben Firefox/Iceweasel. Das Ergebnis war, dass man bis zu 3 Sekunden warten musste, bis sich ein neues Tag geöffnet hat - grausam! Versuche mit lokalem Home-Verzeichnis und Firefox/Iceweasel bzw. NFS-Home und Opera haben gezeigt, dass es eindeutig an dieser Kombination lag.

Da ich mich vor längerer Zeit auch schon mal beruflich mit NFSv4/NFS4 auseinander gesetzt habe und daher wusste, dass genau diese vielen Round-Trips zwischen Server und Client reduziert wurden, dachte ich mir, probier's doch "mal einfach schnell aus". Pustekuchen! Leider gibt's zu viele Anleitungen, die auf alten Ständen aufsetzen und nicht funktionieren. Deswegen hier eine Lösung für Debian/Lenny (NFS-Tools 1.1.2).

    1.

Vorbereitung IDMAP - Server & Client
NFSv4/NFS4 arbeitet auf der Leitung nicht mehr mit User-IDs, sondern mit "User-Strings", welche wie E-Mail-Adressen aussehen. Dazu gibt's den (rpc.)idmapd, welcher die Umsetzung auf beiden Seiten vornimmt.

% cat >/etc/idmapd.conf <<EOF
[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = homenfs.domainname.local

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

    2.

Server einrichten
Benötigte Pakete installieren:

root@server% aptitude install nfs-kernel-server

Anlegen der neuen Export-Struktur:

root@server% mkdir -p /exports/{home,data}

Dauerhafter Bind-Mount der zu exportierenden Verzeichnisse:

root@server% cat >>/etc/fstab <<EOF
/home /exports/home none bind 0 0
/data /exports/data none bind 0 0
EOF

Exportieren der neuen Struktur:

root@server% cat >>/etc/exports <<EOF
/exports 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash,fsid=0,crossmnt)
/exports/home 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
/exports/data 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
EOF

Starten der NFS- und IDMAP-Dienste:

root@server% /etc/init.d/nfs-common restart
root@server% /etc/init.d/nfs-kernel-server restart

    3.

Client einrichten
Benötigte Pakete installieren:

root@server% aptitude install nfs-common

Dauerhaftes Mounten der Verzeichnisse:

root@client% cat >>/etc/fstab <<EOF
server:/home /home/ nfs4 defaults 0 0
server:/data /data/ nfs4 defaults 0 0
EOF
root@client% mount -a

    4.

Glücklich sein
Man merkt zwar immernoch einen kleinen Unterschied zwischen lokalem und NFS-Home-Verzeichnis, aber das nur gelegentlich. Auf jeden Fall kann man nun auch wieder mit Firefox/Iceweasel gut arbeiten ;-)

cat ~/.gitconfig

[alias]
br = branch
st = status
log1 = log --pretty=oneline --abbrev-commit
rlog = log --pretty=format:\"%h %Cblue%cr%Creset %an %Cgreen%s%Creset\"
[color]
ui = auto
[color "branch"]
current = "yellow bold"
local = cyan
remote = "red bold"
[color "diff"]
new = cyan
old = magenta
frag = yellow
meta = green
commit = normal
whitespace = "white reverse"
[color "status"]
changed = yellow
added = magenta
untracked = "blue bold"
nobranch = "red bold"

Asus WL500g Premium, DD-WRT, Linux - Teil 2

mkdir /jffs/etc
mkdir /jffs/etc/config
cd /jffs/etc/config

cat usb.startup

chmod +x usb.startup

wget http://www.wlan-sat.com/boleo/optware/optware-install-ddwrt.sh -O - | tr -d '\r' > /tmp/optware-install.sh
cd /tmp
sh ./optware-install.sh

Asus WL500g Premium, DD-WRT, Linux - Teil 1

Bereits einige Zeit liegt bei mir ein Asus WL500g Premium (oder WL500gP), der eigentlich nur darauf wartet, seine Aufgabe zu übernehmen. Jetzt habe ich mir dann mal vorgenommen, das originale Firmware-Image "kaputt" zu machen, damit ich mich endlich mal mit dem Kistchen genauer beschäftigen muss ;-)

Schritt 1: DD-WRT einspielen
Nach einigem hin und her habe ich für meinen Router-Liebling DD-WRT entschieden. Nachdem ein Kollege auf dem selben Modell einfach ein Debian installiert hat, wäre das wohl die zweite Alternative. Allerdings wollte ich schon länger etwas ausprobieren, was sich OptWare nennt. Das Prinzip ist einfach: Software für das NSLU2 von Linksys compiliert, aber so, dass es unterhalb von /opt liegt. Und angeblich soll das auch mit DD-WRT funktionieren.

Man findet im Netz mehr oder minder haarsträubende Beschreibungen, was man alles tun muss, um auf das weiße Kästchen initial ein DD-WRT draufzubekommen. Aber es geht auch einfach:

    * Download der aktuellen Software von [der Downloadseite von DD-WRT](http://www.dd-wrt.com/dd-wrtv3/dd-wrt/downloads.html). Ich hab als erstes ein [Mini-Image (v24sp1)](http://www.dd-wrt.com/dd-wrtv2/downloads/v24-sp1/Consumer/Asus/WL500g-Premium/dd-wrt.v24_mini_generic.bin) draufgeflasht, bei anderen Routern wird das empfohlen und bei manchen hat es anders auch nicht funktioniert

Wenn man aber schon auf der Seite ist, kann man sich auch gleich noch das Standard-Image (v24sp1) oder sogar das Mega-Image (v24-sp1) herunterladen. Ich nutze aktuell das Mega-Image, da ist alles (fast) drin, was ich brauche und noch mehr (siehe auch den Vergleich der verschiedenen Images)

    * `aptitude install tftp` installiert die notwendige Software zum Flashen


    * Network-Manager und ähnliche Dinge auf dem Rechner ausschalten. Die automatische Konfiguration spuckt immer wieder dazwischen, deswegen macht man das von Hand:

root@linux:/tmp> ifconfig eth0 192.168.1.23/24 dev eth0 up
root@linux:/tmp> ifconfig eth0 192.168.1.23/24 dev eth0 up # Zur Sicherheit nochmal...
root@linux:/tmp> tftp 192.168.1.1
tftp> verbose
tftp> trace
tftp> binary
tftp> put dd-wrt.v24_mini_generic.bin # noch NICHT ENTER drücken!

    * Strom aus dem Asus ziehen, mit einem Stift den Reset-Taster (das ist der versenkte, NICHT der der raussteht!) gedrückt HALTEN(!) und Strom wieder anstecken.

Nach ca. 10 Sekunden hat bei mir die Power-LED geblinkt. In div. Mailings liest man allerdings, dass es auch mal 20 oder 30 Sekunden dauern kann (oder nur 5...)

    * Jetzt im tftp-Client Return drücken, man sollte sehen, wie viele Pakete Richtung Asus geschickt werden.

Wenn er fertig ist, Ruhe bewahren... lasst den Router zur Sicherheit einfach 2-3 Minuten stehen.
Dann allerdings sollte ein ping 192.168.1.1 zeigen, dass der Router wieder erreichbar ist.

    * Mit einem Web-Browser geht man dann auf das Web-Interface http://192.168.1.1, ändert das Passwort und... Willkommen bei DD-WRT ;-)


    * Unter "Administration" -> "Firmware Upgrade" kann man nun bequem das oben heruntergeladenen Standard- oder Mega-Image einspielen>br />

Da der Asus ja etwas mehr Flash besitzt, kann man diesen unter "Administration" -> "Management" -> "JFFS2" mit "JFFS2: Enable" und "Clean JFFS2: Enable" (einmalig!) mit anschließendem Reboot benutzbar machen.

    * Da ich eine 2,5"-USB-HD an das Gerät packen möchte, habe ich auch noch unter "Services" -> "Services" die Einstellungen für "Core USB support", "USB2.0 support", "USB storage support" und "ext2/ext3 FS support" eingeschalten. Das geht Out-of-the-Box nur mit dem Mega-Image, sonst muss [man selbst Hand anlegen.](http://www.dd-wrt.com/wiki/index.php/USB#USB_drivers)

Update!
Nachdem ich es selbst nicht beachtet habe und beinahe einen Router gebrickt hätte, nochmal der Hinweis: Nach dem Flashen lasst den Router ein paar Minuten einfach in Ruhe stehen! NICHT Strom abziehen oder ähnliches! Warten!

  1 2 3 »