- Konfigurationsverzeichnisse in die Container
- Zwei Ports über die die Kommunikation des Core Service angesprochen werden kann
- Ein Port über den der Webserver arbeiten kann.
Klangwelle Bad Neuenahr
Am Wochenende hatten wir das Vergnügen die Klangwelle Bad Neuenahr in Bad Neuenahr. zu erleben.
Ein beeindruckendes Schauspiel aus Wasser, Film, Laser, Feuer und Musik. Die Fotos bringen das nicht richtig rüber aber es war ein tolles Erlebnis. Ein kleiner Wermutstropfen. Es gibt zwischen durch immer längere Pausen die durch eine Werbepause der Sparkasse, dem Käseblatt und einigen anderen lokalen Sponsoren beendet werden.
Aber das vergisst mach recht schnell wieder. Für das nächste Wochenende gibt es noch Karten.
Das Salzmuseum in Lüneburg
Wenn man in Lüneburg ist und etwas Zeit hat sollte man sich auf jeden Fall mal das Salzmuseum ansehen. Es wird schön dargestellt erklärt mit welchen Methoden und Anlagen über die Jahrhunderte dieses wertvolle Gut produziert worden ist.
Wirklich sehenswert.
Blutspenden
Heute stand es wieder auf dem Terminkalender.
Wann geht Ihr (wieder)?
Startup Script für verschlüsseltes Debian System
Um die einzelnen Schritte für das Starten meines verschlüsselten Debian Servers zu automatisieren konnte ich auf Basis dieses Beitrags alle Schritte in ein Script zusammenfassen
#!/bin/bash
sudo wakeonlan e4:1faa:zz:yy:xx
printf "%s" "waiting for Server ..."
while ! timeout 0.2 ping -c 1 -n serveraddresse &> /dev/null
do
printf "%c" "."
done
printf "\n%s\n" "Server is back online"
ssh -i /home/hbauer/.ssh/id_rsa_initram root@192.168.xxx.yy -p 22
Das sieht dann so aus
wecken-server.sh
Sending magic packet to 255.255.255.255:9 with e4:1faa:zz:yy:xx
waiting for ServerXY ............................................................................................................................................................................................................................................................................................................................................
Server is back online
Enter passphrase for key '/home/hbauer/.ssh/id_rsa_initram':
To unlock root partition, and maybe others like swap, run `cryptroot-unlock`
BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.
~ # cryptroot-unlock
Please unlock disk sda3_crypt:
cryptsetup: sda3_crypt set up successfully
~ # packet_write_wait: Connection to 192.168.xxx.yyy port 22: Broken pipe
Debian System mit verschlüsslten Festplatten remote starten
Ich wollte einen Server im Keller mit verschlüsselten Festplatten über wakeonlan remote aufwecken und dann “aus der Ferne” die Passphrase für die Festplattenverschlüsselung eingeben. Die Anleitungen mit denen ich erfolgreich war sind die und die
Zuerst installieren wir dropbear
sudo apt install busybox dropbear-initramfs
echo 'DROPBEAR=y' >> /etc/initramfs-tools/initramfs.conf
Wie ist der Name der Netzwerkkarte?
ifconfig | grep flags
enp11s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
Was steht schon in der Konfiguration und dann den richtigen Eintrag setzten
grep DEVICE /etc/initramfs-tools/initramfs.conf
sed -i 's/DEVICE=/DEVICE=enp11s0f0/' /etc/initramfs-tools/initramfs.conf
Jetzt ist es richtig
grep DEVICE /etc/initramfs-tools/initramfs.conf
# DEVICE: ...
DEVICE=enp11s0f0
Die Netzwerkkarte soll schön über DHCP booten
echo 'IP=:::::enp11s0f0:dhcp' >> /etc/initramfs-tools/initramfs.conf
Auf einem Client habe ich einen speziellen SSH Key generiert
/.ssh$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/.ssh/id_rsa_initram_server
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa_initram_server.
Your public key has been saved in /home/user/.ssh/id_rsa_initram_server.pub.
The key fingerprint is:
SHA256:+FRsAJC4JLB29GnTnkFlasdfj..........
Dann den öffentlichen Key anschauen
more id_rsa_initram_server.pub
und auf dem Server an die richtige Stelle einkopieren
vi /etc/dropbear-initramfs/authorized_keys
...
...
Dann das Bootpaket neu bauen (um die deprecated Meldung kümmere ich mich später)
sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.9.0-8-amd64
dropbear: WARNING: Setting DROPBEAR in /etc/initramfs-tools/initramfs.conf is deprecated and will be ignored in a future release
Wenn der Server dann hochfährt kann ich mich über Port 22 mit dem SSH Key als root anmelden
ssh -i .ssh/id_rsa_initram_server root@192.168.xxx.yyy -p 22
Enter passphrase for key '.ssh/id_rsa_initram_server':
To unlock root partition, and maybe others like swap, run `cryptroot-unlock`
und lande in der kleinen Shell
BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.
Mit dem Befehl werde ich aufgefordert die Passphrase einzugeben.
cryptroot-unlock
Please unlock disk sda3_crypt:
Und wenn diese richtig ist wird im Hintergrund dann die Festplatte aufgeschlossen und der Rechner bootet. Sobald der normale SSH Dienst läuft wird meine kleine Bootshell beendet
Connection to 192.168.xxx.yyy closed by remote host.
Und ich kann mich normal an dem Server über SSH anmelden.
Echte Profis beim BSI, Oh warte mal....
Ist ja auch wirklich schwer so Webserver Zertifikate regelmässig und automatisch zu aktualisieren. Können ja nur die Leute von der NSA.
Und selbst wenn man es merkt kann das Tage dauern bis so eine Behörde wieder über das Internet erreichbar ist.
Ohne Worte
Debian: SSHD an IP Adresse binden
Auf einem internen Server wollte ich in einem Server mit verschiedenen IP Adresse den SSHD Dienst an eine bestimme IP Adresse binden. Ich wollte die andere IP Adresse einem Docker Server zuweisen.
Eigentlich ganz einfach
vi /etc/ssh/sshd_config
ListenAddress 192.168.xxx.yyy
# Default Wert: ListenAddress ::
Leider klappte es mit dem Booten danach nicht mehr. Im wesentlichen liegt es daran das die Netzwerkkonfiguration noch nicht fertig ist wenn der SSH Server startet. Es soll verschiedene Möglichkeiten geben aber am Ende konnte ich das nur mit diesem Ansatz lösen
echo 'net.ipv4.ip_nonlocal_bind = 1' > /etc/sysctl.d/99-nonlocal_bind.conf
Das ist zwar ein recht weitreichende Änderung zu sein aber für einen speziellen Server in einem abgetrennten Netzwerksegement wohl ok.
Installation Mailman auf Docker
Dies ist der zweite Beitrag über meinen Weg zu einem eigenen Mailinglisten Server auf Basis eines Docker Container. Meine ersten Erkenntnisse hatte ich hier dokumentiert. Die Installation ist an die Original Dokumentation angelehnt hat aber einige persönliche Erweiterungen.
Um den Webzugriff auf den Administrationsbereich für den Beginn erst einmal abzusichern richte in einem neuen Nginx virtual host eine Konfiguration für den späteren Proxy ein der über eine Kennwort geschützt ist
vi /etc/nginx/conf.d/host.conf>
location / {
uwsgi_pass 172.19.199.3:8080;
include uwsgi_params;
uwsgi_read_timeout 300;
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
location /static {
alias /opt/mailman/web/static;
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
Das Kennwort für diesen Proxy können wir mit htpasswd erstellen
htpasswd -c /etc/nginx/.htpasswd <yourlistadmin>
Wenn wir jetzt auf die Seite https://
Dann geht es los mit der eigentlichen Installation
cd /opt/
mkdir -p /opt/mailman/core
mkdir -p /opt/mailman/web
git clone https://github.com/maxking/docker-mailman
cd docker-mailman
Docker-Compose ist ein Werkzeug mit dem man Anwendungen auf verschiedene Docker Container verteilen kann so das sie in einen kleinen Docker Netzwerk “zusammenarbeiten”. In dieser Fall ist es so das die wichtigsten Anwendungseinstellungen für Mailman als Umgebungsvariablen gesetzt werden. Diese sind gemäß Doku einzurichten
Zuerst muss docker-compose installiert werden
pip install docker-compose
vi docker-compose.yml
HYPERKITTY_API_KEY=<ein key den ich aus keepassx genommen haben >
SECRET_KEY=<noch ein geheimer key>
SERVE_FROM_DOMAIN=www.yourdomain.de
MAILMAN_ADMIN_USER=postmaster
MAILMAN_ADMIN_EMAIL=postmaster@yourdomain.de
Dann geht es los. Docker-Compose hold sich die notwendigen Images und baut die 3 Container mit dem internen Netzwerk.
docker-compose up -d
Creating network "docker-mailman_mailman" with driver "bridge"
Pulling database (postgres:9.6-alpine)...
9.6-alpine: Pulling from library/postgres
4fe2ade4980c: Pull complete
...
...
e9f65487e6d9: Pull complete
Digest: sha256:5f243ac0a7f3057757da445ff38031e1cd24d016b91fc3bf5e747e7a15547580
Status: Downloaded newer image for postgres:9.6-alpine
Pulling mailman-core (maxking/mailman-core:0.2)...
0.2: Pulling from maxking/mailman-core
81033e7c1d6a: Pull complete
...
...
fafc78d0f4a7: Pull complete
Digest: sha256:bc874d6b48aada777fe8da61ecc1532ea3dae29064f190603ba80299527b62bf
Status: Downloaded newer image for maxking/mailman-core:0.2
Pulling mailman-web (maxking/mailman-web:0.2)...
0.2: Pulling from maxking/mailman-web
911c6d0c7995: Pull complete
...
...
1976ee7ab302: Pull complete
Digest: sha256:c534d7d8bf412ea79988fbf98730f332ba084b5fa19a6510b5d8baef57863469
Status: Downloaded newer image for maxking/mailman-web:0.2
Creating docker-mailman_database_1 ... done
Creating mailman-core ... done
Creating mailman-web ... done
Eigentlich sollte man jetzt mit diesem Befehl auf dem Server “etwas html” bekommen
curl http://172.19.199.3:8000/postorius/lists/
curl: (7) Failed to connect to 172.19.199.3 port 8000: Keine Route zum Zielrechner
Mit “docker ps” kann man sehen welche Container laufen. Wie man sieht fehlt hier einer.
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
67b5ae7fcb64 postgres:9.6-alpine "docker-entrypoint.s…" About a minute ago Up About a minute 5432/tcp docker-mailman_database_1
Im Logfile habe ich diese Zeile gefunden die auf ein Zugriffsrechteproblem hinweist.
mkdir: can't create directory '/opt/mailman-web-data/logs/': Permission denied
Warum das so ist habe ich nicht verstanden aber nach einem Wechsel des Owner ging es dann
ls -ls /opt/mailman/
insgesamt 12K
4,0K drwxr-xr-x 2 root root 4,0K Sep 15 10:33 core
4,0K drwx------ 19 952038 951968 4,0K Sep 15 10:24 database
4,0K drwxr-xr-x 2 root root 4,0K Sep 15 10:33 web
chown 951968:951968 web -R
chown 951968:951968 core -R
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e7f531a065d0 maxking/mailman-web:0.2 "docker-entrypoint.s…" 16 minutes ago Up 7 seconds 8000/tcp, 8080/tcp mailman-web
b48b8757512e maxking/mailman-core:0.2 "docker-entrypoint.s…" 16 minutes ago Up 8 seconds 8001/tcp, 8024/tcp mailman-core
67b5ae7fcb64 postgres:9.6-alpine "docker-entrypoint.s…" 16 minutes ago Up 16 minutes 5432/tcp docker-mailman_database_1
dann liefert auch dieser Befehl html zurück
curl http://172.19.199.3:8000/postorius/lists/
Ich musste dann noch etwas länger mit dem statischen Alias in der Nginx Konfiguration kämpfen aber das lag an meinen Standardeinstellungen die ich für meine Webserver im allgemeinen einrichte.
Dann bekam ich endlich die richtig formatierte Startseite.
Anbindung Postfix zu Mailman
Die Anbindung des Docker Containers an Postfix geschieht in zwei Richtungen, von “Innen” nach “Außen” und umgekehrt.
Da ich in meinem Fall einen konfigurierten Postfix Server habe der schon Mails für andere Domainen außerhalb von Mailman empfängt bin ich mit der Standardkonfiguration nicht erfolgreich gewesen. Es wurden dann nämlich alle alte Adressen als unbekannt abgewiesen.
Mit folgenden Änderungen war ich dann am Ende erfolgreich
vi /etc/postfix/main.cf
mydestination = ........, yourserver.de
mynetworks ...... 172.19.199.3
recipient_delimiter = +
unknown_local_recipient_reject_code = 550
owner_request_special = no
transport_maps = regexp:/opt/mailman/core/var/data/postfix_lmtp
local_recipient_maps = proxy:unix:passwd.byname $alias_maps regexp:/opt/mailman/core/var/data/postfix_lmtp
relay_domains = regexp:/opt/mailman/core/var/data/postfix_domains $mydestination
/etc/init.d/postfix reload
Auf die relay_domains kann man vermutlich erst einmal verzichten wenn man nicht dynamisch durch Endbenutzer neue Domainen anlegen möchte.
Anbindung Mailman zu Postfix
Damit das Mailman-Core im Container auch jemanden hat bei dem er Nachrichten abliefern kann konnte ich die Standardeinstellungen der Doku verwenden.
vi /opt/mailman/core/mailman-extra.cfg
[mta]
incoming: mailman.mta.postfix.LMTP
outgoing: mailman.mta.deliver.deliver
lmtp_host: 172.19.199.2
lmtp_port: 8024
smtp_host: 172.19.199.1
smtp_port: 25
configuration: /etc/postfix-mailman.cfg
Auch diese Datei braucht den richtigen Owner sonst knallt es später
chown 952068:952068 /opt/mailman/core/mailman-extra.cfg
Damit die Weboberfläche auch Mails versenden kann sind diese Änderungen notwendig:
vi settings_local.py
USE_SSL = False
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
EMAIL_HOST = '172.19.199.1'
EMAIL_PORT = 25
DEFAULT_FROM_EMAIL = "lists@yourserver.de"
SERVER_EMAIL = "postmaster@yourserver.de"
Dazu kam noch das Bekanntgeben der neuen Netzwerkadresse und Mail Domaine im Host Postfix
vi /etc/postfix/main.cf
mydestination = ........, yourserver.de
mynetworks ...... 172.19.199.3
/etc/init.d/postfix reload
Dann kann man sich über die Weboberfläche ein Passwordreset des “postmaster” durchführen und nachdem man die Mailadresse bestätigt hat bekommt man die Admin Oberfläche.
Als erstes richten wir eine neue Maildomaine ein:
Und dann unsere erste Maillingliste
und können uns dann direkt bei der Liste anmelden
im Hintergrund hat jetzt Mailman zwei Konfigurationsdateien für den Postfix angepasst
more /opt/mailman/core/var/data/postfix_domains
# AUTOMATICALLY GENERATED BY MAILMAN ON 2018-09-16 08:26:45
#
# This file is generated by Mailman, and is kept in sync with the binary hash
# file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what you're
# doing, and can keep the two files properly in sync. If you screw it up,
# you're on your own.
/^yourserver\.de$/ yourserver.de
more /opt/mailman/core/var/data/postfix_lmtp
# AUTOMATICALLY GENERATED BY MAILMAN ON 2018-09-16 08:26:45
# This file is generated by Mailman, and is kept in sync with the binary hash
# file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what you're
# doing, and can keep the two files properly in sync. If you screw it up,
# you're on your own.
# Aliases which are visible only in the @yourserver.de domain.
/^firstlist@yourserver\.de$/ lmtp:[172.19.199.2]:8024
/^firstlist-bounces(\+.*)?@yourserver\.de$/ lmtp:[172.19.199.2]:8024
/^firstlist-confirm(\+.*)?@yourserver\.de$/ lmtp:[172.19.199.2]:8024
/^firstlist-join@yourserver\.de$/ lmtp:[172.19.199.2]:8024
/^firstlist-leave@yourserver\.de$/ lmtp:[172.19.199.2]:8024
/^firstlist-owner@yourserver\.de$/ lmtp:[172.19.199.2]:8024
/^firstlist-request@yourserver\.de$/ lmtp:[172.19.199.2]:8024
/^firstlist-subscribe@yourserver\.de$/ lmtp:[172.19.199.2]:8024
/^firstlist-unsubscribe@yourserver\.de$/ lmtp:[172.19.199.2]:8024
Freischaltung in Rspamd
Da ich hier rspamd verwende wurde der Docker Mailversand zu Beginn enorm verzögert. Eine Freischaltung der IP Adresse hat dann geholfen
vi /etc/rspamd/local.d/ip.map
172.19.199.2
Danach konnte ich dann schön die ersten Diskussionen starten.
Das meiste wird besser
Jetzt sollten die Tagesthemen diese Nachricht nicht nur “einmal” veröffentlichen sondern vielleicht mal die Nachrichten verändern.
Jeden Tag eine gute Nachricht.
Protokoll eines Festplattenwechsels im MDM Raid
Es war mal wieder so weit. Eine Festplatte auf dem produktiven Webserver musste getauscht werden. So ein Festplattentausch in einem produktiven Web- und Mailserver ist für mich immer noch mit etwas leicht erhöhtem Blutdruck verbunden. Das letzte Mal hat es zwar ohne Probleme geklappt aber …..
Seit einiger Zeit waren recht niedrige “Gesundheitswerte” meiner ersten Festplatte gemeldet worden
smartd[626]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 63 to 64
So das ich für heute morgen ein Festplattentausch bei Hetzner beantragt habe. Sicherheitshalber habe ich auch gleich noch eine KVM Session beantragt um im Notfall direkt auf den “Bildschirm” schauen zu können. Bei der Vorgehensweise habe ich mit an diese Doku von Hetzner gehalten. Diese Dokument ist “nur” meine exakte Dokumentation für mich selber aber vielleicht hiflt was ja auch jemandem.
Der Status zu Beginn war dieser
cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdb3[1] sda3[2]
1073610560 blocks super 1.2 [2/2] [UU]
md3 : active raid1 sdb4[1] sda4[2]
1847478528 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdb1[1] sda1[2]
8384448 blocks super 1.2 [2/2] [UU]
md1 : active raid1 sdb2[1] sda2[2]
523968 blocks super 1.2 [2/2] [UU]
Zur Vorbereitung galt es zuerst die “altersmüde” Festplatte /dev/sda aus dem Raid zu nehmen
Schritt 1: markieren der Partitionen als “ausgefallen”
mdadm --manage /dev/md0 --fail /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md0
mdadm --manage /dev/md1 --fail /dev/sda2
mdadm: set /dev/sda2 faulty in /dev/md1
mdadm --manage /dev/md2 --fail /dev/sda3
mdadm: set /dev/sda3 faulty in /dev/md2
mdadm --manage /dev/md3 --fail /dev/sda4
mdadm: set /dev/sda4 faulty in /dev/md3
Schritt 2: Entfernen der Partitionen aus dem Raid
mdadm /dev/md0 -r /dev/sda1
mdadm: hot removed /dev/sda1 from /dev/md0
mdadm /dev/md1 -r /dev/sda2
mdadm: hot removed /dev/sda2 from /dev/md1
mdadm /dev/md2 -r /dev/sda3
mdadm: hot removed /dev/sda3 from /dev/md2
mdadm /dev/md3 -r /dev/sda4
mdadm: hot removed /dev/sda4 from /dev/md3
Wie schaut es jetzt aus?
more /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdb3[1]
1073610560 blocks super 1.2 [2/1] [_U]
md3 : active raid1 sdb4[1]
1847478528 blocks super 1.2 [2/1] [_U]
md0 : active raid1 sdb1[1]
8384448 blocks super 1.2 [2/1] [_U]
md1 : active raid1 sdb2[1]
523968 blocks super 1.2 [2/1] [_U]_
Pünktlich zu der vereinbarten Uhrzeit wurde mein Server gestoppt. 5 Minuten später war er wieder online.
Jetzt hat man eine leere Festplatte bei der die Partitionen von der “guten” auf die “neue” kopiert werden müssen und die Partitionen müssen dort dann neue “Nummern” bekommen
fdisk -l /dev/sda
Disk /dev/sda: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Die Partitionen werden von der guten auf die neue Platte übertragen
sgdisk -R /dev/sda /dev/sdb
The operation has completed successfully.
(Hier war dann ein Fehler. Eigentlich hätte das auf sda gemacht werden sollen.)
sgdisk -G /dev/sdb
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Wie schaut’s aus?
fdisk -l /dev/sda
Disk /dev/sda: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E6C5E876-F160-4D89-8FBF-D431C4AD1D63
Device Start End Sectors Size Type
/dev/sda1 4096 16781311 16777216 8G Linux RAID
/dev/sda2 16781312 17829887 1048576 512M Linux RAID
/dev/sda3 17829888 2165313535 2147483648 1T Linux RAID
/dev/sda4 2165313536 5860533134 3695219599 1,7T Linux RAID
/dev/sda5 2048 4095 2048 1M BIOS boot
Dann konnte ich die neuen leeren Partitionen in das Raid einfügen
mdadm --manage /dev/md0 --add /dev/sda1
mdadm: added /dev/sda1
mdadm --manage /dev/md1 --add /dev/sda2
mdadm: added /dev/sda2
mdadm --manage /dev/md2 --add /dev/sda3
mdadm: added /dev/sda3
mdadm --manage /dev/md3 --add /dev/sda4
mdadm: added /dev/sda4
Und die Synchronisation beginnt
more /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sda2[2] sdb2[1]
523968 blocks super 1.2 [2/1] [_U]
resync=DELAYED
md3 : active raid1 sda4[2] sdb4[1]
1847478528 blocks super 1.2 [2/1] [_U]
resync=DELAYED
md2 : active raid1 sda3[2] sdb3[1]
1073610560 blocks super 1.2 [2/1] [_U]
[======>..............] recovery = 32.4% (348329536/1073610560) finish=74.7min speed=161716K/sec
md0 : active raid1 sda1[2] sdb1[1]
8384448 blocks super 1.2 [2/2] [UU]_
Irgendwann ist dann alles fertig. Bei 2,7TB hat das hier um die 8 Stunden gedauert.
Leider habe ich zwischendurch bemerkt das ich den Befehl zu Neugenerierung der Partitionsnummern vergessen habe und dann habe ich ihn auch noch auf der falschen (der gesunden) Platte ausgeführt. Da es aber um das generieren von eindeutigen IDs geht habe ich das gelassen da sich ja damit eigentlich die IDs der beiden Platten unterscheiden sollten.
Anpassungen für den Bootmanager
grub-mkdevicemap -n
grub-install /dev/sda
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Wegen des angesprochenen Fehlers habe ich das auch noch mal für die alte Platte gemacht.
grub-install /dev/sdb
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Da ich mir nicht sicher war ob die IDs in der Grub Konfiguration noch stimmen habe ich das auch noch mal upgedated
update-grub
GRUB-Konfigurationsdatei wird erstellt …
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-8-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-8-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-7-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-7-amd64
erledigt
Sicherheitshalber habe ich dann noch mal eine KVM beantragt und einen Neustart getestet (Man weiß ja nie) aber der Server hat schön neu gestartet.
Mailman 3 auf Docker
Vor einiger Zeit habe ich meinen ersten Dockerserver aufgesetzt. Ziel war es die Möglichkeit zu schaffen weitere Komponenten auf dem Server zu installieren und Konflikte zwischen Softwarevoraussetzungen zu vermeiden.
GNU Mailman war damals schon mein erster Fall den ich vor Augen hatte. Ich möchte diesen Listserver verwenden um Maillinglisten für Schulklassen und Elternpflegschaften zu verwalten.
Die Installation von Mailman per Docker wird von den Entwickler befürwortet und die Dokumentation erweckt den Eindruck das der Autor weiß was er tut.
Da ich generell noch etwas misstrauisch bin wollte ich mir diese Installationsweise vorab etwas genauer ansehen.
Es gib 3 Dockercontainer die über ein eigenes internes Netz verbunden sind. Diese “sprechen” nach außen über die internen Docker IP Adressen und sollten damit nicht von extern ansprechbar sein. Es gibt 3 Schnittstellen nach außen
Damit sollte nach meinem Kenntnisstand die Installation erst einmal recht risikoarm sein da an sich der Dockercontainer abgekappselt ist.
Die eigenen Konfigurationen werden in einem Verzeichnis des Host Servers gehalten und in den Docker Container “an die richtige Stelle” gemappt. Die Daten werden in /opt/mailman/databases gehalten
Backup:
Um die Daten und Konfigurationen des Mailman Servers zu sichern sollte es ausreichen man das Verzeichnis /opt/mailman in das Backup mit aufzunehmen. Dort müssten alle Daten und eigenen Konfigurationen enthalten sein.
Installation
Die Installation müsste recht einfach sein. Aber das scheint wahrscheinlich nur so. Mal sehen.
