Bananenkiste als Homeserver
Aus BraLUG-Wiki
(→Motivation) |
(→Printserver) |
||
(41 dazwischenliegende Versionen von einem Benutzer werden nicht angezeigt) | |||
Zeile 7: | Zeile 7: | ||
"Mit der Zeit gehen..." heißt natürlich aktuelle, ressourcen-seitig ausreichende und, vor allem, stromsparende Hardware zu verwenden, denn immerhin soll der Server ja 24 Stunden, 7 Tage in der Woche arbeiten. Heutzutage ist es kein Problem ein geeignetes Board, welches mit dem Betriebssystem Linux läuft, zu finden. Meine Wahl fiel auf einen [http://www.lemaker.org/ Banana Pro]. An die, auf dem Board vorhandene, SATA-Schnittstelle wurde eine [http://www.wdc.com/de/products/products.aspx?id=810 2,5"-"WD Red"-Festplatte] angeschlossen. Alles in einem entsprechenden Gehäuse eingebaut, ergibt es ein recht kompaktes Gerät, welches überall Platz finden sollte. | "Mit der Zeit gehen..." heißt natürlich aktuelle, ressourcen-seitig ausreichende und, vor allem, stromsparende Hardware zu verwenden, denn immerhin soll der Server ja 24 Stunden, 7 Tage in der Woche arbeiten. Heutzutage ist es kein Problem ein geeignetes Board, welches mit dem Betriebssystem Linux läuft, zu finden. Meine Wahl fiel auf einen [http://www.lemaker.org/ Banana Pro]. An die, auf dem Board vorhandene, SATA-Schnittstelle wurde eine [http://www.wdc.com/de/products/products.aspx?id=810 2,5"-"WD Red"-Festplatte] angeschlossen. Alles in einem entsprechenden Gehäuse eingebaut, ergibt es ein recht kompaktes Gerät, welches überall Platz finden sollte. | ||
− | = | + | =Linux-Betriebssystem installieren und konfigurieren= |
==Installation== | ==Installation== | ||
+ | Als Linux-Distribution wird [https://www.bananian.org/ Bananian] verwendet, was eigentlich ein Debian 7 ist, welche aber speziell für den Banana Pi/Pro angepasst wurde. | ||
+ | |||
+ | Die Installation gestaltet sich recht einfach. Nach dem [https://www.bananian.org/download Download] des gepackten Images, ist es zu entpacken und auf eine passende SD-Karte zu kopieren (Beispiel für Linux :-)): | ||
+ | <pre> | ||
+ | > dd if=bananian-1504.img of=/dev/<your-sd-card> bs=1M | ||
+ | > sync | ||
+ | </pre> | ||
+ | |||
+ | Danach ist die SD-Karte nur noch in den entsprechenden Slot des Banana Pi zu stecken, Netzwerk dran und Strom an! Das System sollte booten und eine IP-Adresse über DHCP beziehen. Zugriff auf das System hat man dann entweder lokal über die/den angeschlossene/n Tastatur/Monitor oder auch remote via ssh. Das root-Passwort lautet initial ''pi'' und sollte natürlich sofort geändert werden... | ||
+ | |||
==Konfiguration== | ==Konfiguration== | ||
Eine erste Konfiguration des Systems, kann man mit folgenden Tool erledigen: | Eine erste Konfiguration des Systems, kann man mit folgenden Tool erledigen: | ||
<pre> | <pre> | ||
− | bananian-config | + | > bananian-config |
</pre> | </pre> | ||
Folgende Einstellungen können verändert werden: | Folgende Einstellungen können verändert werden: | ||
Zeile 22: | Zeile 32: | ||
Danach sollte das System einmal durchgestartet werden. | Danach sollte das System einmal durchgestartet werden. | ||
− | |||
==Feste IP-Adresse== | ==Feste IP-Adresse== | ||
Zeile 49: | Zeile 58: | ||
Hat man eine SATA-Festplatte an seinen Banana Pi angeschlossen, ist es sinnvoll von dieser auch zu booten. Um dies so einzurichten, sind z.B. folgende Schritte zielführend (angenommen, ''/dev/sda'' ist die angeschlossene Festplatte): | Hat man eine SATA-Festplatte an seinen Banana Pi angeschlossen, ist es sinnvoll von dieser auch zu booten. Um dies so einzurichten, sind z.B. folgende Schritte zielführend (angenommen, ''/dev/sda'' ist die angeschlossene Festplatte): | ||
<pre> | <pre> | ||
− | fdisk /dev/sda | + | > fdisk /dev/sda |
</pre> | </pre> | ||
...RTFM --> Partionierung der Festplatte. | ...RTFM --> Partionierung der Festplatte. | ||
Zeile 55: | Zeile 64: | ||
<pre> | <pre> | ||
− | mkfs.ext4 /dev/sda1 | + | > mkfs.ext4 /dev/sda1 |
</pre> | </pre> | ||
...Formatierung der (ersten eingerichteten) Partition der Festplatte mit [https://de.wikipedia.org/wiki/Ext4 ext4]. | ...Formatierung der (ersten eingerichteten) Partition der Festplatte mit [https://de.wikipedia.org/wiki/Ext4 ext4]. | ||
Zeile 61: | Zeile 70: | ||
Das root-Filesystem der SD-Karte muss auf die Festplatte kopiert werden (Annahme, es wurde nur die Partition ''/dev/sda1'' auf der Festplatte angelegt; der Swap-Bereich befindet sich in der Datei ''/swapfile1'' (Default bei [https://www.bananian.org/ Bananian])): | Das root-Filesystem der SD-Karte muss auf die Festplatte kopiert werden (Annahme, es wurde nur die Partition ''/dev/sda1'' auf der Festplatte angelegt; der Swap-Bereich befindet sich in der Datei ''/swapfile1'' (Default bei [https://www.bananian.org/ Bananian])): | ||
<pre> | <pre> | ||
− | mount /dev/sda1 /mnt/ | + | > mount /dev/sda1 /mnt/ |
− | rsync -ax / /mnt/ | + | > rsync -ax / /mnt/ |
</pre> | </pre> | ||
Zeile 68: | Zeile 77: | ||
Danach müssen noch die entsprechenden Boot-Parameter in der Datei ''/uEnv.txt'' eingestellt werden (der Editor ''joe'' ist installiert): | Danach müssen noch die entsprechenden Boot-Parameter in der Datei ''/uEnv.txt'' eingestellt werden (der Editor ''joe'' ist installiert): | ||
<pre> | <pre> | ||
− | umount /mnt/ | + | > umount /mnt/ |
− | mount /dev/mmcblk0p1 /mnt/ | + | > mount /dev/mmcblk0p1 /mnt/ |
− | joe /mnt/uEnv.txt | + | > joe /mnt/uEnv.txt |
</pre> | </pre> | ||
Die Zeichenfolge 'root=/dev/mmcblk0p2' ist durch 'root=/dev/sda1' auszutauschen. Nach einem | Die Zeichenfolge 'root=/dev/mmcblk0p2' ist durch 'root=/dev/sda1' auszutauschen. Nach einem | ||
<pre> | <pre> | ||
− | reboot | + | > reboot |
</pre> | </pre> | ||
sollte von der angeschlossenen Festplatte gebootet werden...! Die SD-Karte muss natürlich im entsprechenden Slot bleiben, da sich darauf der Bootloader befindet. Bei einem Festplattendefekt hat man damit auch gleich ein funktionsfähiges Basissystem zur Verfügung (uEnv.txt entsprechend angepasst...). | sollte von der angeschlossenen Festplatte gebootet werden...! Die SD-Karte muss natürlich im entsprechenden Slot bleiben, da sich darauf der Bootloader befindet. Bei einem Festplattendefekt hat man damit auch gleich ein funktionsfähiges Basissystem zur Verfügung (uEnv.txt entsprechend angepasst...). | ||
=="Heartbeat" ausschalten== | =="Heartbeat" ausschalten== | ||
− | Um die nervig blinkende grüne LED auf dem Board auszuschalten, ist folgender Befehl (als root auszuführen) erfolgreich: | + | Um die nervig blinkende grüne LED auf dem Banana-Board auszuschalten, ist folgender Befehl (als root auszuführen) erfolgreich: |
<pre> | <pre> | ||
− | echo none > /sys/class/leds/green\:ph24\:led1/trigger | + | > echo none > /sys/class/leds/green\:ph24\:led1/trigger |
</pre> | </pre> | ||
Zeile 88: | Zeile 97: | ||
=Server-Dienste= | =Server-Dienste= | ||
==Printserver== | ==Printserver== | ||
− | + | Als Druck-Server wird [http://www.cups.org/ CUPS] verwendet. Die Installation gestaltet sich recht entspannt: | |
− | CUPS | + | |
<pre> | <pre> | ||
− | apt-get install cups cups-bsd foo2zjs | + | > sudo apt-get install cups cups-bsd printer-driver-foo2zjs-common printer-driver-foo2zjs |
</pre> | </pre> | ||
Zeile 99: | Zeile 107: | ||
* die automatische Druckervermittlung aktivieren | * die automatische Druckervermittlung aktivieren | ||
<pre> | <pre> | ||
− | cupsctl --share-printers --remote-admin --remote-printers | + | > sudo cupsctl --share-printers --remote-admin --remote-printers |
</pre> | </pre> | ||
− | Danach kann CUPS z.B. über einen Webbrowser administriert werden. URL: ''https://dein_server:631'' | + | Ein User auf dem Server sollte CUPS administrieren dürfen (z.B. Drucker hinzufügen): |
+ | <pre> | ||
+ | > sudo usermod -aG lpadmin <user> | ||
+ | </pre> | ||
+ | |||
+ | Danach kann CUPS z.B. über einen Webbrowser administriert werden. URL: ''https://dein_server:631''. Wie man Drucker einrichtet und administriert, kann der [https://www.cups.org/documentation.php CUPS-Dokumentation] entnommen werden bzw. die Web-Oberfläche ist auch recht selbsterklärend... | ||
Ich besitze einen HP Laserjet 1018, es muss die Firmware aus dem Internet geholt und installiert werden, damit diese automatisch beim Einschalten des Druckers in selbigen kopiert wird: | Ich besitze einen HP Laserjet 1018, es muss die Firmware aus dem Internet geholt und installiert werden, damit diese automatisch beim Einschalten des Druckers in selbigen kopiert wird: | ||
<pre> | <pre> | ||
− | getweb 1018 | + | > sudo getweb 1018 |
... | ... | ||
</pre> | </pre> | ||
+ | Das Tool ''getweb'' ist Bestandteil des Paketes ''foo2zjs''. Als Parameter wird die Typ-Nummer des Druckers angegeben. Das Tool richtet dann alles notwendige automatisch ein. | ||
+ | |||
Danach empfiehlt sich ein Reboot des Systems. | Danach empfiehlt sich ein Reboot des Systems. | ||
+ | |||
+ | ==autofs== | ||
+ | Spätestens beim [[Bananenkiste_als_Homeserver#Backup|Backup]] benötigt man sinnvoller Weise einen Datenträger, welcher nur während des Schreiben/Lesens in den Verzeichnisbaum eingebunden und sonst vom System jeder Zeit gefahrlos entfernbar ist. Es wird also ein Dienst benötigt, welcher z.B. eine bestimmte USB-Festplatte automatisch, vor dem ersten Zugriff, einbindet, wenn diese im System verfügbar ist und auch wieder selbstständig, nach einer einstellbaren Zeit der Inaktivität, entfernt. Ein solcher Dienst ist u.a. [https://wiki.ubuntuusers.de/autofs ''autofs'']. | ||
+ | |||
+ | Installation: | ||
+ | <pre> | ||
+ | sudo apt-get install autofs | ||
+ | </pre> | ||
+ | |||
+ | Festlegung des Verzeichnisses, unter dem der dynamische Datenträger eingebunden werden soll (alle Aktionen als Benutzer ''root''): | ||
+ | <pre> | ||
+ | > mkdir /autofs | ||
+ | |||
+ | > cat /etx/auto.master | ||
+ | /autofs /etc/auto.autofs --timeout=300 --ghost | ||
+ | |||
+ | > cat /etc/auto.autofs | ||
+ | usb-backup -fstype=ext3,sync :/dev/disk/by-uuid/0d5ef4bb-6f06-4814-95fe-7aa5acf09f4f | ||
+ | </pre> | ||
+ | Also: | ||
+ | * ein Verzeichnis (''/autofs'') anlegen, unter dem die Datenträger eingebunden werden sollen | ||
+ | * auto.master --> alle Datenträger, welche unter diesem Verzeichnis (''autofs'') eingebunden werden sollen (mehrere möglich), sind in ''/etc/auto.autofs'' konfiguriert, werden nach 300 Sekunden ausgehangen (timeout) --> RTFM! | ||
+ | * im Unterverzeichnis ''usb-backup'' wird eine USB-Festplatte, formatiert mit ext3, (vor dem ersten Lesen oder Schreiben) eingebunden, wenn sie die angegebene UUID hat... | ||
+ | |||
+ | |||
+ | UUID ermitteln: | ||
+ | <pre> | ||
+ | sudo blkid -o list -w /dev/null | ||
+ | ... | ||
+ | /dev/sdb1 ext3 (not mounted) 0d5ef4bb-6f06-4814-95fe-7aa5acf09f4f | ||
+ | </pre> | ||
+ | |||
+ | Nach einer Änderung der ''autofs''-Konfiguration ist der entsprechende Dienst neu zu starten: | ||
+ | <pre> | ||
+ | < service autofs restart | ||
+ | </pre> | ||
==Fileserver== | ==Fileserver== | ||
+ | ===sshfs=== | ||
+ | Die einfachste Methode ein Server-Verzeichnis in den Verzeichnisbaum des Clients einzubinden, bietet [http://fuse.sourceforge.net/sshfs.html sshfs], vorausgesetzt: | ||
+ | * auf der Server-Seite ist ein ssh-Server (sollte eigentlich Standard sein...) und | ||
+ | * auf der Client-Seite ist sshfs (siehe z.B. folgende [https://wiki.ubuntuusers.de/fuse/sshfs Dokumentation]) | ||
+ | installiert. | ||
+ | |||
+ | Das Einbinden eines Server-Verzeichnisses via sshfs erfolgt (interaktiv) über folgendes Kommando: | ||
+ | <pre> | ||
+ | > sshfs serveruser@server:/serververzeichnis /clientverzeichnis | ||
+ | </pre> | ||
+ | Man wird nach dem Passwort des angegebenen Server-Benutzers gefragt... | ||
+ | |||
+ | Natürlich kann man auch alles automatisieren und z.B. das Einbinden eines Server-Verzeichnisses via sshfs über einen [http://superuser.com/questions/669287/automount-sshfs-using-fstab-without-mount-a Eintrag in der Datei /etc/fstab] erledigen. Eine weitere interessante Methode über den [https://wiki.ubuntuusers.de/NetworkManager/Dispatcher NetworkManager-Dispatcher] ist z.B. [https://wiki.ubuntuusers.de/fuse/sshfs#per-Dispatcher hier] beschrieben. | ||
+ | |||
+ | Ein, über sshfs eingebundenes Server-Verzeichnis, wird man mit folgenden Kommando wieder los: | ||
+ | <pre> | ||
+ | > fusermount -u /clientverzeichnis | ||
+ | </pre> | ||
+ | |||
+ | |||
+ | ===NFS=== | ||
+ | ...kommt (vielleicht) noch. | ||
+ | |||
+ | ===Samba=== | ||
+ | [https://www.samba.org/ Samba] ist auch eine recht nette Möglichkeit, Zugriff auf Verzeichnisse des Servers zu bekommen. Vorteil ist, dass man damit auch Windows-Clients versorgen kann... | ||
+ | |||
+ | Installation Samba-Server plus einiger Tools: | ||
+ | <pre> | ||
+ | > sudo apt-get install samba-common samba-common-bin samba samba-doc samba-doc-pdf tdb-tools | ||
+ | </pre> | ||
+ | |||
+ | Samba verwaltet seine Benutzer in einer eigenen Datenbank (wenn nichts anderes konfiguriert): | ||
+ | <pre> | ||
+ | > sudo smbpasswd -a <user> # Benutzer <user> in der Samba-DB anlegen/aktivieren | ||
+ | > sudo smbpasswd -x <user> # Benutzer <user> aus der Samba-DB entfernen | ||
+ | > sudo smbpasswd -d <user> # Benutzer <user> in der Samba-DB deaktivieren | ||
+ | > sudo smbpasswd -e <user> # Benutzer <user> in der Samba-DB wieder aktivieren | ||
+ | </pre> | ||
+ | Beim Anlegen eines Samba-Benutzers (erstes Kommando) kann man auch gleich ein Passwort vergeben. Mit dem gleichen Befehl kann dieses Passwort für den angegeben Benutzer auch geändert werden. | ||
+ | |||
+ | |||
+ | Die Konfiguration des Samba-Servers erfolgt über die Datei ''/etc/samba/smb.conf''. Über die vielfälltigen Einstellungsmöglichkeiten sind diverse [https://wiki.ubuntuusers.de/Samba_Server/smb.conf Beschreibungen] im Internet zu finden. Um beispielsweise ein Verzeichnis auf dem Server im Netzwerk freizugeben, ist die Datei ''/etc/samba/smd.conf'' um folgende Zeilen zu ergänzen: | ||
+ | <pre> | ||
+ | # Bilder | ||
+ | [Bilder] | ||
+ | path = /medien/bilder | ||
+ | public = no | ||
+ | writeable = yes | ||
+ | </pre> | ||
+ | Erläuterung: Das Verzeichnis /medien/bilder auf dem Server wird als Share "Bilder" freigegeben, kann allerdings nur von Benutzern aus der Samba-DB (siehe oben) geöffnet werden und ist auch beschreibbar. (Nicht angegebene Optionen wirken mit ihrem Default-Wert (RTFM...)). | ||
+ | |||
+ | |||
+ | Bevor man die Samba-Dienst mit der veränderten Konfiguration durchstartet, sollte man deren Syntax überprüfen, um eventuelle Fehler auszuspüren: | ||
+ | <pre> | ||
+ | > testparm | ||
+ | </pre> | ||
+ | |||
+ | Das Durchstarten der Samba-Dienste kann z.B. mit folgenden Kommando erfolgen: | ||
+ | <pre> | ||
+ | > service samba restart | ||
+ | </pre> | ||
+ | |||
+ | |||
+ | ToDo: | ||
+ | * Client-Zugriff auf freigegebene Shares | ||
+ | * Zugriff auf "Server-Drucker" von Windows-Clients aus | ||
+ | * ? | ||
+ | |||
==Backup== | ==Backup== | ||
+ | ===Allgemeines zu rdiff-backup=== | ||
+ | Ein recht komfortables Backuptool zur Sicherung entfernter Rechner bzw. auch lokaler Serververzeichnisse auf einen externen Datenträger ist [http://www.nongnu.org/rdiff-backup/ rdiff-backup]. Das Tool ermöglicht eine einfache und platzsparende Sicherung (und natürliche auch Rücksicherung) von Daten. Nach einer initialen Vollsicherung werden in der Folge nur noch Änderungen versioniert in einer speziellen Verzeichnisstruktur gesichert (RTFM). Die Backups können auch über das Netzwerk gesichert via ssh erfolgen. | ||
+ | |||
+ | rdiff-backup ist ein Kommandozeilentool. Es gibt aber eine Reihe von GUIs, die u.U. die Bedienung vereinfachen. Ich selbst verwende zur Überprüfung/Sichtung der Backups auf dem Homeserver [http://www.patrikdufresne.com/en/rdiffweb/ rdiffweb], eine kleine WEB-basierte Oberfläche. | ||
+ | |||
+ | ===Verwendung von rdiff-backup=== | ||
+ | |||
+ | '''Backup:''' | ||
+ | <pre> | ||
+ | rdiff-backup /home/user /backup/home/user | ||
+ | </pre> | ||
+ | Es wird hier das Verzeichnis /home/user (mit allen Unterverzeichnissen) in das Backup-Verzeichnis /backup/home/user gesichert. Selbstverständlich können die Verzeichnisse jeweils auch Netzlaufwerke sein. Mit ein wenig Konfigurationsaufwand kann der Anstoß auch remote via ssh auf dem zu sichernden Rechner erfolgen. Weiterhin können, über entsprechende Aufrufparameter, die zu sichernden Verzeichnisse/Dateien über Include-/Exclude-Listen feiner spezifiziert werden. Hilfreich ist dazu die Dokumentation von [http://www.nongnu.org/rdiff-backup/docs.html rdiff-backup]. | ||
+ | |||
+ | |||
+ | '''Restore:''' | ||
+ | Wenn einfach nur die aktuellste Sicherung einer Datei oder eines Verzeichnisses aus dem Backup zurückgeholt werden soll, reicht ein ein einfaches Kopieren vom Backup-Verzeichnis an den gewünschten Zielort. | ||
+ | Soll eine ältere Version aus dem Backup zurückgesichert werden kann dies z.B. mit folgendem Befehl erfolgen: | ||
+ | <pre> | ||
+ | rdiff-backup -r 10D /backup/home/user/datei.txt /home/user/datei.txt | ||
+ | </pre> | ||
+ | In diesem Beispiel wird die Version von vor 10 Tagen der Datei /home/user/datei.txt aus dem Backup an ihren Ursprungsort zurückgesichert. Natürlich kann auch ein anderes Rücksicherungsziel angegeben werden. Weitere Rücksicherungsoptionen sind der Dokumentation von [http://www.nongnu.org/rdiff-backup/docs.html rdiff-backup] zu entnehmen. | ||
+ | |||
+ | |||
+ | '''Alte Sicherungen löschen:''' | ||
+ | |||
+ | Mit der Zeit sammeln sich einige Sicherungen an. Wenn man nicht alle aufheben möchte, bietet rdiff-backup eine Reihe von Befehlen an, um ältere bzw. bestimmte Backups aus dem Sicherungsverzeichnis zu eleminieren: | ||
+ | <pre> | ||
+ | rdiff-backup --remove-older-than 180D /backup/home/user | ||
+ | </pre> | ||
+ | Mit diesem Befehl werden z.B. alle Sicherungen gelöscht, welche älter als 180 Tage sind. Weitere Möglichkeiten sind der Dokumentation von [http://www.nongnu.org/rdiff-backup/docs.html rdiff-backup] zu finden. | ||
+ | |||
+ | |||
+ | '''Status der Sicherungen abfragen:''' | ||
+ | |||
+ | Ab und zu sollte man auch mal überprüfen, ob das Backup überhabt noch funktioniert. Mit folgendem Befehl kann z.B. eine Liste alle Backups erzeugt werden: | ||
+ | <pre> | ||
+ | rdiff-backup -l /backup/home/user | ||
+ | </pre> | ||
+ | |||
+ | |||
+ | Möchte man sich auch die Mengen der gesicherten Daten innerhalb der einzelnen Backups ansehen, ist dieser Befehl hilfreich: | ||
+ | <pre> | ||
+ | rdiff-backup --list-increment-sizes /backup/home/user | ||
+ | </pre> | ||
+ | |||
+ | ===Weitere Informationsquellen (zu rdiff-backup)=== | ||
+ | * http://www.nongnu.org/rdiff-backup/ | ||
+ | * https://www.thomas-krenn.com/de/wiki/Backup_unter_Linux_mit_rdiff-backup | ||
+ | * https://www.howtoforge.com/linux_rdiff_backup | ||
+ | * http://arctic.org/~dean/rdiff-backup/unattended.html | ||
+ | * http://www.patrikdufresne.com/en/rdiffweb/ | ||
+ | |||
==Mail== | ==Mail== | ||
− | == | + | ===Allgemeines=== |
+ | Auf meinem alten Homeserver hatte ich einen Mailserver betrieben. Diverse Scripte, regelmäßig via Cron gestartet, holten meine E-Mails von den diversen Mail-Servern in Internet ab und verteilten diese in lokale Mailboxen bzw. -ordner, damit sie im lokalen Netz auf allen Clients verfügbar waren. Bei der Neukonzeption meines Homeservers habe ich mir dann die Frage gestellt: "Warum dieser Aufwand?", denn die Mails sind bei den einzelnen Mail-Providern doch ganz gut aufgehoben, von überall, mit geeigneten E-Mail-Clients, abgreifbar und die Größengrenzen der E-Mailboxen für den Normalverbraucher ausreichend. | ||
+ | |||
+ | Damit bleiben dann eigentlich nur zwei Dinge offen, deren Lösungen in der Folge (beispielhaft) beschrieben werden: | ||
+ | * Servermeldungen/-zustände automatisiert versenden | ||
+ | * Archivierung einer Mailbox | ||
+ | |||
+ | ===Servermeldungen/-zustände automatisiert versenden mittels ssmtp=== | ||
+ | "Hat das Backup heute Nacht eigentlich funktioniert?", "Ist die Server-Festplatte demnächst der Meinung, ihren Geist aufzugeben?" oder "War die Verarbeitung von Job xyz erfolgreich?"... | ||
+ | |||
+ | Mal ehrlich, loggt sich der Admin regelmäßig jeden Tag, Woche etc. auf dem Server ein, um obiges zu überprüfen? Bestimmt nicht...! Also brauchen man eine automatisierbare Lösung, welche den Status von Jobs, den Zustand der Hardware oder was auch immer an eine Mail-Adresse sendet, welche man regelmäßig abfragt! | ||
+ | |||
+ | Befragt man dazu die bekannten Suchmaschinen, bekommt man zuerst die Antwort: "sendmail", "postfix" etc.. Aber warum so kompliziert, durch Zufall bin ich auf [https://de.wikipedia.org/wiki/SSMTP ssmtp] aufmerksam geworden: | ||
+ | |||
+ | '''Installation''' | ||
+ | <pre> | ||
+ | > apt-get install ssmtp | ||
+ | </pre> | ||
+ | |||
+ | '''Konfiguration''' | ||
+ | |||
+ | Es sind nach der Installation zwei Konfigurationsdateien anzupassen: | ||
+ | |||
+ | /etc/ssmtp/ssmtp.conf (z.B. für eine Mailbox von blabla@gmx.net auf gmx.net): | ||
+ | <pre> | ||
+ | root=blabla@gmx.net | ||
+ | mailhub=mail.gmx.net:465 | ||
+ | rewriteDomain=gmx.net | ||
+ | hostname=gmx.net | ||
+ | UseTLS=YES | ||
+ | AuthUser=blabla@gmx.DE | ||
+ | AuthPass=kenntnurblabla | ||
+ | FromLineOverride=NO | ||
+ | </pre> | ||
+ | |||
+ | /etc/ssmtp/revaliases (für jeden User, der etwas zu melden hat): | ||
+ | <pre> | ||
+ | root:blabla@gmx.net:mail.gmx.net:465 | ||
+ | blabla:blabla@gmx.net:mail.gmx.net:465 | ||
+ | </pre> | ||
+ | ...etc.. | ||
+ | |||
+ | '''Anwendung''' | ||
+ | <pre> | ||
+ | /usr/sbin/ssmtp blabla@gmx.net < /home/blabla/msg.txt | ||
+ | </pre> | ||
+ | |||
+ | ===Mailbox archivieren via archivemail=== | ||
+ | Falls man keinen eigenen, ständig ansprechbaren E-Mailserver betreibt, ist, aus meiner Sicht, die einfachste E-Mail-Lösung, die Mails einfach auf den Server des jeweiligen Providers zu belassen und seinen E-Mail-Client so zu konfigurieren, dass er diese E-Mail-Fächer bedient. Wie dies funktioniert, ist den diversen Beschreibungen im Internet zu entnehmen oder/und man vertraut den Installationshinweisen seines bevorzugten E-Mail-Clients. | ||
+ | |||
+ | Allerdings wird es doch irgendwann Zeit, die E-Mails vom Server des jeweiligen Providers herunter zu laden und zu archivieren! Hauptgründe dafür sind vor allem die begrenzte Größe der E-Mailbox beim jeweiligen Provider oder einfach nur die Übersichtlichkeit innerhalb des Postfach. Für meine Bedürfnisse habe ich dazu das Tool [http://archivemail.sourceforge.net/ archivmail] auserkoren: | ||
+ | |||
+ | '''Installation:''' | ||
+ | <pre> | ||
+ | apt-get install archivemail | ||
+ | </pre> | ||
+ | |||
+ | |||
+ | '''Verwendung''' | ||
+ | |||
+ | Archivierung einer Mailbox: | ||
+ | <pre> | ||
+ | archivemail --no-compress -q -d100 --pwfile /home/blabla/.pwd_web_de -o /home/blabla/web_de/ imaps://"blabla"@imap.web.de/INBOX | ||
+ | </pre> | ||
+ | Es werden alle Mails von blabla@web.de, welche sich im Mail-Verzeichnis "INBOX" des Postfach befinden und älter als 100 Tage sind, im (lokalen) Verzeichnis /home/blabla/web_de/ in einer Datei im mbox-Format abgelegt und auch auf dem Server des E-Mail-Providers gelöscht. Das Passwort für die angesprochene Mailbox auf dem Server des Mail-Providers befindet sich in der Datei ''/home/blabla/.pwd_web_de''. Weitere mögliche Aufrufparameter sind u.a. der [http://archivemail.sourceforge.net/manpage.html man-Page] von Archivemail zu entnehmen! | ||
+ | |||
+ | |||
+ | '''Öffnen/Lesen/verwalten des Mailarchiv''' | ||
+ | |||
+ | Die, von archivemail erzeugten Archive werden im [https://de.wikipedia.org/wiki/Mbox mbox-Format] angelegt. Um diese öffnen zu können benötigt man einen entsprechenden Reader. Da ich (bisher) nicht anderes gefunden habe, verwende ich dazu [http://www.mutt.org/ mutt]: | ||
+ | <pre> | ||
+ | mutt -f /home/blabla/web_de/INBOX-archive | ||
+ | </pre> | ||
=Kontakt= | =Kontakt= | ||
[[Benutzer:bergeruw|Uwe]] | [[Benutzer:bergeruw|Uwe]] |
Aktuelle Version vom 3. Februar 2019, 12:31 Uhr
Inhaltsverzeichnis |
[Bearbeiten] Motivation
Mein alter Homeserver, welcher seit Jahren klaglos seinen Dienst erledigt hatte, will nicht mehr so richtig. Zwar ist das Ding nicht irreparabel kaputt, aber ab und zu sollte man auch mal mit der Zeit gehen. Also der richtige Augenblick die Hardware zu tauschen, das Betriebssystem frisch zu installieren und die gewünschten Server-Dienste neu aufsetzen...
Die folgenden Kapitel sind in erster Linie eine Dokumentation für mich selbst, nützen aber vielleicht auch anderen "Freizeitadministratoren", die Ähnliches vorhaben.
[Bearbeiten] Hardware
"Mit der Zeit gehen..." heißt natürlich aktuelle, ressourcen-seitig ausreichende und, vor allem, stromsparende Hardware zu verwenden, denn immerhin soll der Server ja 24 Stunden, 7 Tage in der Woche arbeiten. Heutzutage ist es kein Problem ein geeignetes Board, welches mit dem Betriebssystem Linux läuft, zu finden. Meine Wahl fiel auf einen Banana Pro. An die, auf dem Board vorhandene, SATA-Schnittstelle wurde eine 2,5"-"WD Red"-Festplatte angeschlossen. Alles in einem entsprechenden Gehäuse eingebaut, ergibt es ein recht kompaktes Gerät, welches überall Platz finden sollte.
[Bearbeiten] Linux-Betriebssystem installieren und konfigurieren
[Bearbeiten] Installation
Als Linux-Distribution wird Bananian verwendet, was eigentlich ein Debian 7 ist, welche aber speziell für den Banana Pi/Pro angepasst wurde.
Die Installation gestaltet sich recht einfach. Nach dem Download des gepackten Images, ist es zu entpacken und auf eine passende SD-Karte zu kopieren (Beispiel für Linux :-)):
> dd if=bananian-1504.img of=/dev/<your-sd-card> bs=1M > sync
Danach ist die SD-Karte nur noch in den entsprechenden Slot des Banana Pi zu stecken, Netzwerk dran und Strom an! Das System sollte booten und eine IP-Adresse über DHCP beziehen. Zugriff auf das System hat man dann entweder lokal über die/den angeschlossene/n Tastatur/Monitor oder auch remote via ssh. Das root-Passwort lautet initial pi und sollte natürlich sofort geändert werden...
[Bearbeiten] Konfiguration
Eine erste Konfiguration des Systems, kann man mit folgenden Tool erledigen:
> bananian-config
Folgende Einstellungen können verändert werden:
- das root-Passwort
- die Zeitzone
- den Zeichensatz
- den Rechnernamen
- einige grundlegende Hardware-Einstellungen
Danach sollte das System einmal durchgestartet werden.
[Bearbeiten] Feste IP-Adresse
Ein Server sollte eine feste IP-Adresse haben. Dazu ist die Konfigurationsdatei /etc/network/interfaces anzupassen:
# interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback auto eth0 # dhcp configuration # iface eth0 inet dhcp # static ip configuration iface eth0 inet static address 10.1.1.42 netmask 255.255.255.0 gateway 10.1.1.1
Erläuterung: Die Netzwerkschnittstelle eth0 bezieht seine IP-Adresse nicht via DHCP (entsprechende Zeile einkommentiert), sondern wird fest auf (beispielsweise) 10.1.1.42, der Netzwerkmaske 255.255.255.0 und dem Gateway 10.1.1.1 eingestellt.
Danach sollte das Netzwerk neu gestartet werden oder der gesamte Rechner durchgestartet werden. Wird im Netzwerk ein DNS-Server betrieben, sollte dort IP-Adresse/-Name entsprechend aufgenommen werden, um den Server mit seinem IP-Namen ansprechen zu können. Alternativ kann diese Kombination auch in der jeweiligen Hosts-Datei (z.B. Linux /etc/hosts) der Clients aufgenommen werden.
[Bearbeiten] Bananian von einer Festplatte booten
Hat man eine SATA-Festplatte an seinen Banana Pi angeschlossen, ist es sinnvoll von dieser auch zu booten. Um dies so einzurichten, sind z.B. folgende Schritte zielführend (angenommen, /dev/sda ist die angeschlossene Festplatte):
> fdisk /dev/sda
...RTFM --> Partionierung der Festplatte.
> mkfs.ext4 /dev/sda1
...Formatierung der (ersten eingerichteten) Partition der Festplatte mit ext4.
Das root-Filesystem der SD-Karte muss auf die Festplatte kopiert werden (Annahme, es wurde nur die Partition /dev/sda1 auf der Festplatte angelegt; der Swap-Bereich befindet sich in der Datei /swapfile1 (Default bei Bananian)):
> mount /dev/sda1 /mnt/ > rsync -ax / /mnt/
Danach müssen noch die entsprechenden Boot-Parameter in der Datei /uEnv.txt eingestellt werden (der Editor joe ist installiert):
> umount /mnt/ > mount /dev/mmcblk0p1 /mnt/ > joe /mnt/uEnv.txt
Die Zeichenfolge 'root=/dev/mmcblk0p2' ist durch 'root=/dev/sda1' auszutauschen. Nach einem
> reboot
sollte von der angeschlossenen Festplatte gebootet werden...! Die SD-Karte muss natürlich im entsprechenden Slot bleiben, da sich darauf der Bootloader befindet. Bei einem Festplattendefekt hat man damit auch gleich ein funktionsfähiges Basissystem zur Verfügung (uEnv.txt entsprechend angepasst...).
[Bearbeiten] "Heartbeat" ausschalten
Um die nervig blinkende grüne LED auf dem Banana-Board auszuschalten, ist folgender Befehl (als root auszuführen) erfolgreich:
> echo none > /sys/class/leds/green\:ph24\:led1/trigger
Wird dieses Kommando in der Datei /etc/rc.local aufgenommen, erfolgt das Ausschalten der blinkenden "Herzschlag"-LED automatisch nach dem Hochfahren des Systems.
[Bearbeiten] Server-Dienste
[Bearbeiten] Printserver
Als Druck-Server wird CUPS verwendet. Die Installation gestaltet sich recht entspannt:
> sudo apt-get install cups cups-bsd printer-driver-foo2zjs-common printer-driver-foo2zjs
Mit dem Tool cupsctl sollte man folgendes einstellen:
- die lokalen, am Server angeschlossenen, Drucker im Netzwerk freigeben
- CUPS über das Netzwerk administrierbar machen
- die automatische Druckervermittlung aktivieren
> sudo cupsctl --share-printers --remote-admin --remote-printers
Ein User auf dem Server sollte CUPS administrieren dürfen (z.B. Drucker hinzufügen):
> sudo usermod -aG lpadmin <user>
Danach kann CUPS z.B. über einen Webbrowser administriert werden. URL: https://dein_server:631. Wie man Drucker einrichtet und administriert, kann der CUPS-Dokumentation entnommen werden bzw. die Web-Oberfläche ist auch recht selbsterklärend...
Ich besitze einen HP Laserjet 1018, es muss die Firmware aus dem Internet geholt und installiert werden, damit diese automatisch beim Einschalten des Druckers in selbigen kopiert wird:
> sudo getweb 1018 ...
Das Tool getweb ist Bestandteil des Paketes foo2zjs. Als Parameter wird die Typ-Nummer des Druckers angegeben. Das Tool richtet dann alles notwendige automatisch ein.
Danach empfiehlt sich ein Reboot des Systems.
[Bearbeiten] autofs
Spätestens beim Backup benötigt man sinnvoller Weise einen Datenträger, welcher nur während des Schreiben/Lesens in den Verzeichnisbaum eingebunden und sonst vom System jeder Zeit gefahrlos entfernbar ist. Es wird also ein Dienst benötigt, welcher z.B. eine bestimmte USB-Festplatte automatisch, vor dem ersten Zugriff, einbindet, wenn diese im System verfügbar ist und auch wieder selbstständig, nach einer einstellbaren Zeit der Inaktivität, entfernt. Ein solcher Dienst ist u.a. autofs.
Installation:
sudo apt-get install autofs
Festlegung des Verzeichnisses, unter dem der dynamische Datenträger eingebunden werden soll (alle Aktionen als Benutzer root):
> mkdir /autofs > cat /etx/auto.master /autofs /etc/auto.autofs --timeout=300 --ghost > cat /etc/auto.autofs usb-backup -fstype=ext3,sync :/dev/disk/by-uuid/0d5ef4bb-6f06-4814-95fe-7aa5acf09f4f
Also:
- ein Verzeichnis (/autofs) anlegen, unter dem die Datenträger eingebunden werden sollen
- auto.master --> alle Datenträger, welche unter diesem Verzeichnis (autofs) eingebunden werden sollen (mehrere möglich), sind in /etc/auto.autofs konfiguriert, werden nach 300 Sekunden ausgehangen (timeout) --> RTFM!
- im Unterverzeichnis usb-backup wird eine USB-Festplatte, formatiert mit ext3, (vor dem ersten Lesen oder Schreiben) eingebunden, wenn sie die angegebene UUID hat...
UUID ermitteln:
sudo blkid -o list -w /dev/null ... /dev/sdb1 ext3 (not mounted) 0d5ef4bb-6f06-4814-95fe-7aa5acf09f4f
Nach einer Änderung der autofs-Konfiguration ist der entsprechende Dienst neu zu starten:
< service autofs restart
[Bearbeiten] Fileserver
[Bearbeiten] sshfs
Die einfachste Methode ein Server-Verzeichnis in den Verzeichnisbaum des Clients einzubinden, bietet sshfs, vorausgesetzt:
- auf der Server-Seite ist ein ssh-Server (sollte eigentlich Standard sein...) und
- auf der Client-Seite ist sshfs (siehe z.B. folgende Dokumentation)
installiert.
Das Einbinden eines Server-Verzeichnisses via sshfs erfolgt (interaktiv) über folgendes Kommando:
> sshfs serveruser@server:/serververzeichnis /clientverzeichnis
Man wird nach dem Passwort des angegebenen Server-Benutzers gefragt...
Natürlich kann man auch alles automatisieren und z.B. das Einbinden eines Server-Verzeichnisses via sshfs über einen Eintrag in der Datei /etc/fstab erledigen. Eine weitere interessante Methode über den NetworkManager-Dispatcher ist z.B. hier beschrieben.
Ein, über sshfs eingebundenes Server-Verzeichnis, wird man mit folgenden Kommando wieder los:
> fusermount -u /clientverzeichnis
[Bearbeiten] NFS
...kommt (vielleicht) noch.
[Bearbeiten] Samba
Samba ist auch eine recht nette Möglichkeit, Zugriff auf Verzeichnisse des Servers zu bekommen. Vorteil ist, dass man damit auch Windows-Clients versorgen kann...
Installation Samba-Server plus einiger Tools:
> sudo apt-get install samba-common samba-common-bin samba samba-doc samba-doc-pdf tdb-tools
Samba verwaltet seine Benutzer in einer eigenen Datenbank (wenn nichts anderes konfiguriert):
> sudo smbpasswd -a <user> # Benutzer <user> in der Samba-DB anlegen/aktivieren > sudo smbpasswd -x <user> # Benutzer <user> aus der Samba-DB entfernen > sudo smbpasswd -d <user> # Benutzer <user> in der Samba-DB deaktivieren > sudo smbpasswd -e <user> # Benutzer <user> in der Samba-DB wieder aktivieren
Beim Anlegen eines Samba-Benutzers (erstes Kommando) kann man auch gleich ein Passwort vergeben. Mit dem gleichen Befehl kann dieses Passwort für den angegeben Benutzer auch geändert werden.
Die Konfiguration des Samba-Servers erfolgt über die Datei /etc/samba/smb.conf. Über die vielfälltigen Einstellungsmöglichkeiten sind diverse Beschreibungen im Internet zu finden. Um beispielsweise ein Verzeichnis auf dem Server im Netzwerk freizugeben, ist die Datei /etc/samba/smd.conf um folgende Zeilen zu ergänzen:
# Bilder [Bilder] path = /medien/bilder public = no writeable = yes
Erläuterung: Das Verzeichnis /medien/bilder auf dem Server wird als Share "Bilder" freigegeben, kann allerdings nur von Benutzern aus der Samba-DB (siehe oben) geöffnet werden und ist auch beschreibbar. (Nicht angegebene Optionen wirken mit ihrem Default-Wert (RTFM...)).
Bevor man die Samba-Dienst mit der veränderten Konfiguration durchstartet, sollte man deren Syntax überprüfen, um eventuelle Fehler auszuspüren:
> testparm
Das Durchstarten der Samba-Dienste kann z.B. mit folgenden Kommando erfolgen:
> service samba restart
ToDo:
- Client-Zugriff auf freigegebene Shares
- Zugriff auf "Server-Drucker" von Windows-Clients aus
- ?
[Bearbeiten] Backup
[Bearbeiten] Allgemeines zu rdiff-backup
Ein recht komfortables Backuptool zur Sicherung entfernter Rechner bzw. auch lokaler Serververzeichnisse auf einen externen Datenträger ist rdiff-backup. Das Tool ermöglicht eine einfache und platzsparende Sicherung (und natürliche auch Rücksicherung) von Daten. Nach einer initialen Vollsicherung werden in der Folge nur noch Änderungen versioniert in einer speziellen Verzeichnisstruktur gesichert (RTFM). Die Backups können auch über das Netzwerk gesichert via ssh erfolgen.
rdiff-backup ist ein Kommandozeilentool. Es gibt aber eine Reihe von GUIs, die u.U. die Bedienung vereinfachen. Ich selbst verwende zur Überprüfung/Sichtung der Backups auf dem Homeserver rdiffweb, eine kleine WEB-basierte Oberfläche.
[Bearbeiten] Verwendung von rdiff-backup
Backup:
rdiff-backup /home/user /backup/home/user
Es wird hier das Verzeichnis /home/user (mit allen Unterverzeichnissen) in das Backup-Verzeichnis /backup/home/user gesichert. Selbstverständlich können die Verzeichnisse jeweils auch Netzlaufwerke sein. Mit ein wenig Konfigurationsaufwand kann der Anstoß auch remote via ssh auf dem zu sichernden Rechner erfolgen. Weiterhin können, über entsprechende Aufrufparameter, die zu sichernden Verzeichnisse/Dateien über Include-/Exclude-Listen feiner spezifiziert werden. Hilfreich ist dazu die Dokumentation von rdiff-backup.
Restore:
Wenn einfach nur die aktuellste Sicherung einer Datei oder eines Verzeichnisses aus dem Backup zurückgeholt werden soll, reicht ein ein einfaches Kopieren vom Backup-Verzeichnis an den gewünschten Zielort.
Soll eine ältere Version aus dem Backup zurückgesichert werden kann dies z.B. mit folgendem Befehl erfolgen:
rdiff-backup -r 10D /backup/home/user/datei.txt /home/user/datei.txt
In diesem Beispiel wird die Version von vor 10 Tagen der Datei /home/user/datei.txt aus dem Backup an ihren Ursprungsort zurückgesichert. Natürlich kann auch ein anderes Rücksicherungsziel angegeben werden. Weitere Rücksicherungsoptionen sind der Dokumentation von rdiff-backup zu entnehmen.
Alte Sicherungen löschen:
Mit der Zeit sammeln sich einige Sicherungen an. Wenn man nicht alle aufheben möchte, bietet rdiff-backup eine Reihe von Befehlen an, um ältere bzw. bestimmte Backups aus dem Sicherungsverzeichnis zu eleminieren:
rdiff-backup --remove-older-than 180D /backup/home/user
Mit diesem Befehl werden z.B. alle Sicherungen gelöscht, welche älter als 180 Tage sind. Weitere Möglichkeiten sind der Dokumentation von rdiff-backup zu finden.
Status der Sicherungen abfragen:
Ab und zu sollte man auch mal überprüfen, ob das Backup überhabt noch funktioniert. Mit folgendem Befehl kann z.B. eine Liste alle Backups erzeugt werden:
rdiff-backup -l /backup/home/user
Möchte man sich auch die Mengen der gesicherten Daten innerhalb der einzelnen Backups ansehen, ist dieser Befehl hilfreich:
rdiff-backup --list-increment-sizes /backup/home/user
[Bearbeiten] Weitere Informationsquellen (zu rdiff-backup)
- http://www.nongnu.org/rdiff-backup/
- https://www.thomas-krenn.com/de/wiki/Backup_unter_Linux_mit_rdiff-backup
- https://www.howtoforge.com/linux_rdiff_backup
- http://arctic.org/~dean/rdiff-backup/unattended.html
- http://www.patrikdufresne.com/en/rdiffweb/
[Bearbeiten] Mail
[Bearbeiten] Allgemeines
Auf meinem alten Homeserver hatte ich einen Mailserver betrieben. Diverse Scripte, regelmäßig via Cron gestartet, holten meine E-Mails von den diversen Mail-Servern in Internet ab und verteilten diese in lokale Mailboxen bzw. -ordner, damit sie im lokalen Netz auf allen Clients verfügbar waren. Bei der Neukonzeption meines Homeservers habe ich mir dann die Frage gestellt: "Warum dieser Aufwand?", denn die Mails sind bei den einzelnen Mail-Providern doch ganz gut aufgehoben, von überall, mit geeigneten E-Mail-Clients, abgreifbar und die Größengrenzen der E-Mailboxen für den Normalverbraucher ausreichend.
Damit bleiben dann eigentlich nur zwei Dinge offen, deren Lösungen in der Folge (beispielhaft) beschrieben werden:
- Servermeldungen/-zustände automatisiert versenden
- Archivierung einer Mailbox
[Bearbeiten] Servermeldungen/-zustände automatisiert versenden mittels ssmtp
"Hat das Backup heute Nacht eigentlich funktioniert?", "Ist die Server-Festplatte demnächst der Meinung, ihren Geist aufzugeben?" oder "War die Verarbeitung von Job xyz erfolgreich?"...
Mal ehrlich, loggt sich der Admin regelmäßig jeden Tag, Woche etc. auf dem Server ein, um obiges zu überprüfen? Bestimmt nicht...! Also brauchen man eine automatisierbare Lösung, welche den Status von Jobs, den Zustand der Hardware oder was auch immer an eine Mail-Adresse sendet, welche man regelmäßig abfragt!
Befragt man dazu die bekannten Suchmaschinen, bekommt man zuerst die Antwort: "sendmail", "postfix" etc.. Aber warum so kompliziert, durch Zufall bin ich auf ssmtp aufmerksam geworden:
Installation
> apt-get install ssmtp
Konfiguration
Es sind nach der Installation zwei Konfigurationsdateien anzupassen:
/etc/ssmtp/ssmtp.conf (z.B. für eine Mailbox von blabla@gmx.net auf gmx.net):
root=blabla@gmx.net mailhub=mail.gmx.net:465 rewriteDomain=gmx.net hostname=gmx.net UseTLS=YES AuthUser=blabla@gmx.DE AuthPass=kenntnurblabla FromLineOverride=NO
/etc/ssmtp/revaliases (für jeden User, der etwas zu melden hat):
root:blabla@gmx.net:mail.gmx.net:465 blabla:blabla@gmx.net:mail.gmx.net:465
...etc..
Anwendung
/usr/sbin/ssmtp blabla@gmx.net < /home/blabla/msg.txt
[Bearbeiten] Mailbox archivieren via archivemail
Falls man keinen eigenen, ständig ansprechbaren E-Mailserver betreibt, ist, aus meiner Sicht, die einfachste E-Mail-Lösung, die Mails einfach auf den Server des jeweiligen Providers zu belassen und seinen E-Mail-Client so zu konfigurieren, dass er diese E-Mail-Fächer bedient. Wie dies funktioniert, ist den diversen Beschreibungen im Internet zu entnehmen oder/und man vertraut den Installationshinweisen seines bevorzugten E-Mail-Clients.
Allerdings wird es doch irgendwann Zeit, die E-Mails vom Server des jeweiligen Providers herunter zu laden und zu archivieren! Hauptgründe dafür sind vor allem die begrenzte Größe der E-Mailbox beim jeweiligen Provider oder einfach nur die Übersichtlichkeit innerhalb des Postfach. Für meine Bedürfnisse habe ich dazu das Tool archivmail auserkoren:
Installation:
apt-get install archivemail
Verwendung
Archivierung einer Mailbox:
archivemail --no-compress -q -d100 --pwfile /home/blabla/.pwd_web_de -o /home/blabla/web_de/ imaps://"blabla"@imap.web.de/INBOX
Es werden alle Mails von blabla@web.de, welche sich im Mail-Verzeichnis "INBOX" des Postfach befinden und älter als 100 Tage sind, im (lokalen) Verzeichnis /home/blabla/web_de/ in einer Datei im mbox-Format abgelegt und auch auf dem Server des E-Mail-Providers gelöscht. Das Passwort für die angesprochene Mailbox auf dem Server des Mail-Providers befindet sich in der Datei /home/blabla/.pwd_web_de. Weitere mögliche Aufrufparameter sind u.a. der man-Page von Archivemail zu entnehmen!
Öffnen/Lesen/verwalten des Mailarchiv
Die, von archivemail erzeugten Archive werden im mbox-Format angelegt. Um diese öffnen zu können benötigt man einen entsprechenden Reader. Da ich (bisher) nicht anderes gefunden habe, verwende ich dazu mutt:
mutt -f /home/blabla/web_de/INBOX-archive