Anwendungen
Portal
Forum
Wiki
Ikhaya
Planet
Mehr
Anmelden

heute

Fedora 22

Permalink Michael Koflers Blog

Zur Abwechslung einmal nahezu pünktlich ist Fedora 22 fertig geworden — und präsentiert Linux von seiner modernsten Seite. Kernel 4.0, neuer Paketmanager dnf, neuer Grafik-Server Wayland beim Login etc.

Die vielen Änderungen in Fedora 22 sind auf dem Desktop kaum zu spüren
Die vielen Änderungen in Fedora 22 sind auf dem Desktop kaum zu spüren

Installation

Wenig Neues gibt es beim Installationsprogramm Anaconda. Die Partitionierung der Festplatte ist unübersichtlich geblieben, und wenn alle Welt den OK-Button rechts unten platziert, hindert das das Fedora- bzw. Red-Hat-Team keineswegs, diesen Button links oben anzuordnen. Zum Glück ist die Installation in der Regel schnell vorbei …

Merkwürdige Button-Anordnung in Anaconda, dem Installationsprogramm von Fedora
Merkwürdige Button-Anordnung in Anaconda, dem Installationsprogramm von Fedora

Versionsnummern

Fedora enthält die aktuellsten Versionen der wichtigsten Open-Source-Programme:

Basis           Desktop            Programmierung     Server
--------------  ------------------ --------------    --------------
Kernel    3.19  Gnome        3.16  bash       4.3    Apache    2.4
glibc     2.21  KDE          4.14  gcc        5.1    CUPS      2.0
X-Server  1.17  Firefox        38  Java         8    MariaDB  10.0
GRUB      2.02  Gimp          2.8  PHP        5.6    OpenSSH   6.8
Systemd    219  LibreOffice   4.4  Python 2.7/3.4    qemu/KVM  2.2
                Thunderbird    31                    Postfix   3.0
                                                     Samba     4.2

KDE ist standardmäßig nicht installiert. Der KDE-Spin enthält die KDE Software Compilation 4.14, die KDE Applications 15.04 sowie Plasma 5.3.

Neuerungen

  • DNF-Paketverwaltung: YUM wird in Fedora 22 endgültig durch DNF abgelöst. Das Kommando ist in der Bedienung weitestgehend kompatibel, d.h. anstelle von yum blabla tippen Sie nun eben dnf blabla ein. Hinter den Kulissen ist DNF aber von Grund auf neu entwickelt und läuft angeblich stabiler und schneller. (Ich hatte allerdings in der Vergangenheit auch mit YUM nie Probleme.) Details zu DNF können Sie hier nachlesen:

    http://dnf.baseurl.org
    http://dnf.readthedocs.org/en/latest/index.html
    http://dnf.readthedocs.org/en/latest/cli_vs_yum.html
    https://fedoraproject.org/wiki/Features/DNF

    PS: DNF steht für Dandified YUM, warum auch immer.

  • Wayland: Sofern der Grafiktreiber es zulässt, verwendet Fedora Wayland für den Login. Optische oder funktionelle Unterschiede zum herkömmlichen Login in einem unter X laufenden Display Manager sind nicht zu erkennen.

    Gnome wird standardmäßig weiterhin unter X ausgeführt; wie schon unter Fedora 21 können Sie sich aber beim Login für die Variante Gnome unter Wayland entscheiden. Der endgültige Umstieg auf Wayland ist für die nächste Fedora-Version geplant.

  • Neue Kernel-Pakete: Der Kernel ist nun über die Pakete kernel-core und kernel-modules aufgeteilt. Ein Linux-Betrieb ohne Module ist u.U. in virtuellen Maschinen denkbar und spart dann etwas Platz.

  • XFS-Dateisystem: Die Server-Edition von Fedora verwendet wie CentOS 7 XFS als Default-Dateisystem. Wenn Sie kein XFS wünschen, müssen Sie dies im Installationsprogramm während der Partitionierung kundtun. Die Workstation-Edition von Fedora verwendet weiterhin ext4.

Spins und Varianten

Die Auswahl der Fedora-Spins ist mittlerweile schon fast so groß wie die der Ubuntu-Varianten:

  • KDE Plasma Desktop
  • XFCE Desktop
  • LXDE Desktop
  • MATE-Compiz Desktop
  • SOAS Desktop

Außerdem gibt es eine Server-Variante, diverse Cloud-Images sowie ein Docker-Image.

Links

gestern

Interview mit einem (in)Tux

Permalink Intux

canoxnet

Wer mit Linux arbeitet und/oder mit dem Raspberry Pi sowie anderen Minirechnern, wie z.B dem Banana Pi, sucht mit Sicherheit im Netz nach Tutorials, Empfehlungen oder sonstigen Problemlösungen, bei der Verwirklichung der eigenen Projekte. Kaum ein Weg führt z.Zt. am noch recht jungen techniklastigen Blog von Steven Seifried canox.net vorbei. Hier findet man fast alles zur Thematik Linux, Open Source und Einplatinencomputer.

Am Pfingstwochenende durfte ich dazu Steven in Form eines kleinen Interviews Rede und Antwort stehen. Den entsprechenden Artikel findet man hier.

Viel Spaß!

25. Mai 2015

Linux: ddrescue

Permalink Linuxvoodoo – Thorstens Technikkruscht

Bei defekten Festplatten, Filesystemen oder heute bei einer zerkratzten (Kinderlieder-) CD  ist das sichern der gesamten Daten und anschließender Analyse der wiederhergestellten Dateien wichtig.

Heute hat mich eine der Kinderlieder CDs zuerst zum verzweifeln gebracht. Die von mir genutzten CD-Kopierprogramme scheiterten durchweg da zu viele Kratzer auf der CD enthalten waren und schon beim auslesen das CDROM sich “einen Wolf” gelesen hat.

Erst der Einsatz von ddrescue konnte weiterhelfen. Ein Großteil der Lieder konnte dabei gesichert und anschließend wiederhergestellt werden.

sudo apt-get install gddrescue
sudo ddrescue -v -r1 /dev/sr0 /tmp/kinderlider.iso rescue.log

ddrescueDie CD wurde zuerst vollständig in eine .iso Datei gesichert, anschließend gemountet und neu gebrannt.

Bis auf wenige kleine Springer funktioniert sie wieder ohne Probleme. Die Kids sind begeistert.

Falls Ihr ähnliche “rescue” Optionen genutzt habt die euch weitergeholfen haben bin ich in den Kommentaren gespannt auf eure Erfahrungen.

Postfix für das Mail Relaying im LAN nutzen

Permalink Finns Blog

Einige kennen das Problem vielleicht. Wer mit zu Hause mit einer dynamischen IP Adresse unterwegs ist, wird nur schwer seine E-Mails los. Gemeint sind nicht die Mails, die man per Hand mit einem Mail User Agent wie z.B. Thunderbird schreibt, sondern die Mails eines GNU/Linux Systems, die von der Konsole, cron oder anderen Diensten versendet werden. Wer mehrere Rechner oder Server hat, für den lohnt es sich, einen kleinen Mail Relaying Server zu konfigurieren.

Das Mail Problem

Eine Mail auf der Konsole ist schnell geschrieben:

echo "Hallo Welt" | mail -s "Betreff" kontakt@finnchristiansen.de

So etwas nutze ich manchmal in Skripten, um mich über Ereignisse oder Probleme zu informieren, wie z.B. bei meinen Backups. Ebenso habe ich in der Datei

/etc/aliases
oder
/etc/postfix/aliases
meine E-Mail Adresse angegeben, um E-Mails für die lokalen Benutzer an meine E-Mail Adresse weiterzuleiten. Ändert man diese Dateien, müssen die Änderungen erst noch mit dem Kommando
newaliases
  aktiveirt werden.

Das Problem hierbei ist nun die dynamsiche IP Adresse. Diese sind zum Empfangen und Senden von E-Mail ziemlich ungeeignet und Mails von solchen IP Adressen werden häufig gar nicht vom eigentlichen Mail-Server angenommen. Der Grund ist ein enormes Spamaufkommen aus diesen dynamischen Netzen, welches von Schadsoftware auf dem Rechner verursacht wird. Außerdem hat eignetlich niemand das Bedürfnis, Mail-Server mit dynamischen IP Adressen zu betreiben, da dies recht unzuverlässig sein kann.

Postfix installieren und als Relay Host konfigurieren

Die Lösung des Problems besteht darin, im lokalen Netzwerk einen Mail-Server zu haben, der sich am im Internet gelegenen Mail-Server authentifiziert. Genau das geschieht ja schließlich auch, wenn man mit Thunderbird eine Mail versendet.

Unter Debian, Ubuntu oder Raspbian ist die Installation schnell erledigt:

apt-get install postfix

Die Konfigurationsdateien liegen in

/etc/postfix
  und vor allem die
main.cf
  ist interessant, da dies die Hauptkonfigurationdatei ist. Vorher legen wir aber in diesem Verzeichnis die Datei
smtp_auth
an, in der die Logindaten des verwendeten Mail-Servers hinterlegt werden. Anschließend wird diese mit postmap in eine für Postfix lesbare Datenbank gehasht:
# Datei öffnen
vim smtp_auth
# Folgendes einfügen (eine Zeile) und mit :wq speichern und schließen
mail.finnchristiansen.de	username@finnchristiansen.de:password
# Datei hashen
postmap smtp_auth

Die

main.cf
  wird nun noch ein wenig erweitert:
# Diesen Mailserver als Relay-Host verwenden
relayhost = mail.finnchristiansen.de
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes

# Diese Parameter sind teilweise schon vorhanden, sollten aber auf Korrektheit überprüft werden
myhostname = mail.local
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail, localhost, localhost.localdomain, localhost
mynetworks = 127.0.0.0/8 
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
myorigin = /etc/mailname
inet_protocols = ipv4

# Um ein offenes Relay zu vermeiden (Mailversand ist sonst für alle überall hin möglich):
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unverified_recipient
relay_domains = $mydestination, finnchristiansen.de

# Optional, aber empfehlenswert, alte SSL Verfahren abschalten:
smtpd_tls_mandatory_ciphers = high
smtp_tls_mandatory_ciphers = high
smtp_tls_security_level = may
smtpd_tls_security_level = may

smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

smtp_tls_exclude_ciphers = aNULL, DES, RC4, MD5
smtpd_tls_exclude_ciphers = aNULL, DES, RC4, MD5
smtp_tls_mandatory_exclude_ciphers = aNULL, DES, RC4, MD5
smtpd_tls_mandatory_exclude_ciphers = aNULL, DES, RC4, MD5

Wer nur diesen einen Rechner für den Mail-Versand fit machen möchte, kann hier aufhören. Ein schließendes

service postfix restart
reicht nun aus, um für den authentifizierten Mailversand bereit zu sein.

Andere Rechner/Server diesen lokalen Relay Host nutzen lassen

So richtig praktisch wird die Sache, wenn noch mehr Rechner oder Server im Netzwerk sind und Mails versenden möchten. Man kann nun entweder die gleiche Konfiguration auf den übrigen Geräten wiederholen oder trägt diesen einen Server als Relay-Host ein. Dies ist möglich, weil der Parameter 

relay_domains
dafür sorgt, dass Mails für finnchristiansen.de angenommen und weitergeleitet werden.

Auf anderen Geräten mit Postfix reicht dann beispielsweise diese eine Zeile:

relayhost = mail.local

Ich verwende dieses kleinen Raspberry Pi Relay Host auf etwa 4 oder 5 Geräten und bekomme, außer Backup- und Update-Meldungen, relativ wenig Mails. Außer es hat sich ein Fehler in einem Cronjob eingeschlichen, dann gibt es bei häufiger Ausführung sehr viele Mails. Aber auch das ist sehr praktisch, da ich lokale Mails auf der Konsole häufig erst zu spät gesehen habe.

Erläuterungen zu Raumklimaüberwachung mit Nagios, DHT22/AM2302 und check_dht

Permalink Finns Blog

Die Temperatur und Luftfeuchtigkeit in meinen Räumen überwache ich mit einem Raspberry Pi und der Monitoring Lösung Shinken. Wem Shinken nichts sagt, streicht es einfach und ersetzt es durch Nagios, das spielt keine große Rolle. Hierfür habe ich das Monitoring Plugin check_dht.py samt Template für PNP4Nagios geschrieben. Oft erreichen mich aber ein paar Fragen, da das Plugin nicht oder nur zum Teil zu funktionieren scheint.

Notwendige Module und Einstellungen

Wer bereits einige Erfahrungen im Monitoring Bereich hat, sollte mit dem Plugin ziemlich gut zurecht kommen. Es gibt allerdigns zwei kleine Hürden, welche die Installation ein wenig erschweren. Erstens braucht das Plugin root-Rechte und zweitens wird zusätzlich das Python Modul Adafruit Python DHT benötigt.

Wer mit 

git clone https://github.com/Finn10111/nagios-plugins.git
  nicht alle meine Monitoring Plugins herunterladen möchte, kann auch mit
wget
das einzelne Plugin herunterladen und auf dem Raspberry Pi an seinen bevorzugten Ort für Plugins platzieren. Ich arbeite in solchen Fällen als root, aber ein vorangestelltes sudo tut es auch.
cd /usr/local/lib/nagios/plugins
wget https://raw.githubusercontent.com/Finn10111/nagios-plugins/master/check_dht/check_dht.py

Anschließend wird das Python Modul heruntergeladen und installiert:

cd /usr/local/src
git clone https://github.com/adafruit/Adafruit_Python_DHT.git
cd Adafruit_Python_DHT
python setup.py install

 

Damit das Plugin von Nagios, Shinken oder NRPE mit root-Rechten ausgeführt werden kann, wird dem Kommando ein sudo vorangestellt. Ich nutze NRPE, dann sieht das in der

nrpe.cfg
so aus:
command[check_dht_22]=/usr/bin/sudo /usr/local/lib/nagios/plugins/check_dht.py -p 23 -s 22 -w 25,70 -c 28,80

Nun fehlt noch ein Eintrag in

visudo
. Etwas übersichtlicher ist es vielleicht, wenn man diese Zeile in eine extra Datei in
/etc/sudoers.d/
  hinzufügt:
nagios ALL=(ALL) NOPASSWD: /usr/local/lib/nagios/plugins/check_dht.py

Ruft man das Plugin mit dem Parameter -h auf, so erscheint eine kurze Hilfe:

usage: check_dht.py [-h] [-s SENSOR] [-p PIN] [-w WARNING] [-c CRITICAL]

Nagios plugin to check DHT sensors using Adafruit DHT driver

optional arguments:
  -h, --help            show this help message and exit
  -s SENSOR, --sensor SENSOR
                        Sensor to use (supported sensors: 11, 22, 2302)
  -p PIN, --pin PIN     GPIO pin number (example: -p 4)
  -w WARNING, --warning WARNING
                        warning threshold for temperature and humidity
                        (example: -w 25,80)
  -c CRITICAL, --critical CRITICAL
                        warning threshold for temperature and humidity
                        (example: -c 30,85)

Der Parameter

-s
gibt den Typ des Sensors an, ich verwende DHT22 und AM2303 Sensoren. Mit
-p
wird der Pin am Raspberry Pi definiert, der an den DATA Pin des Sensors angeschlossen ist.

Anschluss an den Raspberry Pi

Eine Hilfe zur Pinbelegung gibt es für den Raspberry Pi 1 z.B. bei elinux.org und für den Raspberry Pi 2 ist die Pinbelegung bei element14.com zu finden. Ein AM2303 Sensor sieht in etwa so aus:

AM2303 Sensor mit Streifenrasterplatine und Widerstand

Links ist ein Stück Strifenrasterplatine zu sehen, auf dass ich den Sensor löte, um ein wenig mehr Stabilität zu erreichen. Der 4,7kOhm Widerstand wird bei diesem Sensor nicht gebraucht, denn der AM2303 ist ein DHT22 mit integriertem Widerstand. Fertig gelötet sieht der Sensor dann so aus:

AM2303 Sensor auf Streifenrasterplatine gelötet

Die Pinbelegung ist wie folgt:

  1. VCC (3,3 – 6V)
  2. DATA
  3. NULL (nichts)
  4. GND

Zum Testen können die Parameter für Warning und Critical weggelassen werden, als root Benutzer sollte das Plugin auch ohne sudoers-Eintrag bereits funktionieren:

root@nms:/home/finn# /usr/local/lib/nagios/plugins/check_dht.py -s 22 -p 23
OK - Temperature: 22.2 Humidity: 45.8 | temp=22.2;25;30 hum=45.8;80;85

Auswahl der Schwellwerte

Das Plugin unterstützt 2 Arten von Schwellwerten. Die einfachste Art ist folgende:

./check_dht.py -p 23 -s 22 -w 25,70 -c 28,80

Ein WARNING wird ausgelöst, wenn die Temperatur größer als 25°C oder die relative Luftfeuchtigkeit größer als 70% ist. Wie jetzt wohl zu erahnen ist, wird ein CRITICAL bei einer Temperatur größer als 28°C oder bei einer relativen Luftfeuchtigkeit von größer als 80% ausgelöst.

Da ich inzwischen aber auch beim Unterschreiten der gewisser Werte alarmiert werden möchte, habe ich das Plugin ein wenig erweitert. Folgendes ist jetzt auch möglich:

./check_dht.py -s 22 -p 23 -w 16:25,30:70 -c 14:28,20:80

Zusätzlich wird jetzt ein WARNING ausgelöst, wenn die Temperatur unter 16°C fällt oder die relative Luftfeuchtigkeit unter 30% fällt. Beim CRITICAL betragen die unteren Schwellwerte 14°C und 20%.

Im von PNP4Nagios gezeichneten Graphen sieht das dann innerhalb einer Woche so aus:

PNP4Nagios Graph von check_dht

Abschließendes

Warum nutze ich eine relativ komplexe Monitoring Lösung (OMD mit Shinken und verteiltem Monitoring), um ein paar Werte abzufragen?

Erstens besteht das Monitoring System sowieso, zweitens bin mit der Konfiguration des Monitorings sehr vertaut und drittens möchte ich auch E-Mails beim Erreichen der Schwellwerte erhalten, damit ich entsprechend reagieren kann.

Geht es auch einfacher?

Ja, wer etwas Ähnliches ohne Monitoring erreichen möchte, kann das Plugin etwa wie bei intux.de in Verbindung mit rrdtool nutzen. Das Auftreten eines Warning/Critical kann man durch den Exit-Code des herausfinden:

./check_dht.py -s 22 -p 23 -w 20,70 -c 25,80
WARNING - Temperature: 22.4 Humidity: 43.8 | temp=22.4;20;25 hum=43.8;70;80
root@nms:/usr/local/lib/nagios/plugins# echo $?
1

Eine 0 steht für ein OK, 1 für Warning, 2 für Critical und 3 für Unknown (tritt ein, wenn der Sensor nicht abgefragt werden kann).

24. Mai 2015

Ubucon 2015 in Berlin

Permalink svij | Blog

Vor wenigen Stunden haben wir die mittlerweile neunte deutsche Ubucon angekündigt. Ich selbst bin seit der Ubucon 2013 in Heidelberg im Organisationsteam. Dieses Jahr bin ich erstmals Hauptorganisator. Im Idealfall verteile ich also erfolgreich die Aufgaben an die anderen Leute im Organisationsteam, in der Realität sieht das ein wenig anders aus. ;-)

Die Ubucon findet dieses Jahr in Berlin an der HWTK vom 23. bis 25. Oktober 2015 statt. Am gleichen Ort wurde bereits die Ubucon im Jahr 2012 veranstaltet. Auch der „Call for Papers“ wurde zeitgleich gestartet.

Wallpaper – The Thing

Permalink DevDiary

Ich habe mir mal wieder einen neuen Hintergrund für meinen Desktop designt und stelle ihn hier kurz zum Downloaden bereit. Ich habe diesmal die Open Source Software Blender genutzt, da ich mir die neue Version mal anschauen wollte. Als render Engine in Blender habe ich die mit Blender ausgelieferte Cycles Engine verwendet. Da in dem „Ding“ jeder etwas anderes interpretieren kann, habe ich den Hintergrund den Namen „The Thing“ gegeben.

Wer sich den Hintergrund in der Auflösung von 1920 x 1080 herunterladen möchte, kann auf dies über einen Klick auf das Vorschaubild tun. Wie alle meine Hintergrundbilder steht er unkommerzieller Nutzung mit Namensnennung frei zur Verfügung.

Quelle - Eigenes Hintergrundbild
Quelle – Eigenes Hintergrundbild

Wenn Interesse besteht, wie man so etwas mit Blender kreiert, kann ich gerne einen Artikel dazu schreiben.

Ubucon 2015: Community in Touch

Permalink Ubucon

Vor wenigen Wochen haben wir gefragt, ob Ihr an einer virtuellen Ubucon teilnehmen würdet. Glücklicherweise konnten wir doch noch einen Standort für die Ubucon in diesem Jahr organisieren. Sie findet zum zweiten Mal in Berlin statt. Schon 2012 war die Ubucon zu Gast bei der HWTK in Berlin. Dieses Mal findet sie vom 23. bis zum 25. Oktober in der deutschen Hauptstadt statt.

Die Ubucon steht in diesem Jahr unter dem Motto „Community in Touch“. Dies bedeutet zum einen, dass die deutschen Ubuntu-Nutzer auf der Ubucon gemeinsam in Kontakt treten und Ideen und Lösungen austauschen können. Zum anderen soll es auch andeuten, dass das Thema „Ubuntu Touch“, das mobile Betriebssystem von Ubuntu, ein Thema spielen soll.

Zur Ubucon haben wir nun den Call for Papers ausgerufen. Menschen die einen Vortrag, einen Workshop, eine Diskussionsrunde oder ähnliche Veranstaltungen halten und leiten möchten, könnten diese nun einreichen. Doch auch Themenwünsche können eingereicht werden, wenn jemand etwas zu einem bestimmten Themengebiet wissen möchte. Gegebenenfalls finden sich dann Referenten für diese Themen.

Pakete mit eingeschränktem Support in Debian lokalisieren

Permalink (Mer)Curius

Debian bietet seit Version 8.0 Jessie nicht mehr für alle Pakete vollständigen Support an. Diese Ankündigung aus den Release Notes hat es leider in nicht allzu viele Nachrichtenmeldungen geschafft. Um Herauszufinden welche Pakete es konkret betrifft, sind einige Handgriffe notwendig.

debian jessie headerDebian Lines, Juliette Taka BELIN Lizenz: Creative Commons Attribution 3.0 Lizenz: Creative Commons Attribution 3.0

Debian gehört zu den Distributionen mit wirklich guten und umfangreichen Release-Notes. Getreu dem Motto RTFM, das ja niemand behaupten kann, er habe es nicht im Manual gelesen. Leider werden diese Ankündigungen von viel zu wenigen Anwendern wirklich genau gelesen. Das liegt vermutlich auch daran, dass wichtige und leicht verständliche Informationen gleichwertig neben absolutem Technikdeutsch stehen, welches lediglich die Server-Administratoren unter den Debian-Anwwendern interessieren dürfte.

Während Ubuntu noch nie für alle Pakete in seinen weit verzweigten Paketquellen offiziellen Support versprochen hat, galt bei Debian das Supportversprechen für die komplette Software - wenn oft auch nur noch auf dem Papier. Mit Debian 8.0 "Jessie" wurde nun auch offiziell der Support für einige Pakete eingeschränkt. Besonders betroffen sind eigentlich alle Webbrowser außer Iceweasel (das Firefox Äquivalent von Debian). Für diesen und Chromium kann man allerdings auch nur Support gewährleisten, indem man neue Upstream-Veröffentlichungen entgegen Debians Paketrichtlinien in die Stable-Version durchreicht. Bei Iceweasel bildet allerdings die Firefox-ESR Version die Grundlage, weshalb Aktualisierungen nicht zu oft vorkommen sollten.

Die Ursache liegt hier in der mangelnden Upstream Unterstützung:

Debian 8 enthält mehrere Browser-Engines, die einem ständigen Ansturm von Sicherheitsproblemen ausgesetzt sind. Die hohe Rate von Anfälligkeiten und die teilweise fehlende Unterstützung seitens der Originalautoren in Form von langfristig gepflegten Programmversionen machen es sehr schwierig, für diese Browser Sicherheitsunterstützung auf Basis von rückportierten Fehlerkorrekturen anzubieten. Zusätzlich machen es Abhängigkeiten zwischen beteiligten Bibliotheken unmöglich, auf neuere Upstream-(Orignal-)Versionen hochzurüsten. Browser, die auf den Engines webkit, qtwebkit und khtml aufbauen, sind daher in Jessie zwar enthalten, es besteht jedoch für sie keine Sicherheitsunterstützung. Diese Browser sollten nicht für Verbindungen zu vertrauensunwürdigen Websites verwendet werden.

Quelle: Debian Release Notes

Das eigene System kann man mittels des Pakets debian-security-support überprüfen. Dieses Paket gibt es erstmals seit der LTS Version von Squeeze und liefert die notwendigen Informationen über den Supportstatus der installieren Debian-Pakete. Es ist allerdings nicht vorinstalliert.

# apt-get install debian-security-support

Nach der Installation kann man den Supportstatus der einzelnen Pakete mit folgendem Kommando überprüfen:

$ check-support-status

Das ganze erinnert an das Ubuntu-Äquivalent, wenngleich die Unterteilung hier nur Support oder kein Support kennt.

Auf meiner recht schmalen Subnotebook Installation liest sich die Liste schon recht beachtlich.

Eingeschränkte Sicherheitsaktualisierungen für eines oder mehrere Pakete

Leider war es nötig, die Unterstützung von Sicherheitsaktualisierungen für
einige Pakete einzuschränken.

Davon sind die folgenden auf diesem System gefundenen Pakete betroffen:

* Quelle:kde4libs
  Einzelheiten: khtml has no security support upstream, only for use on trusted content
  Betroffene Binärpakete:
  - kdelibs-bin (installierte Version: 4:4.14.2-5)
  - kdelibs5-data (installierte Version: 4:4.14.2-5)
  - kdelibs5-plugins (installierte Version: 4:4.14.2-5)
  - kdoctools (installierte Version: 4:4.14.2-5)
  - libkcmutils4 (installierte Version: 4:4.14.2-5)
  - libkde3support4 (installierte Version: 4:4.14.2-5)
  - libkdeclarative5 (installierte Version: 4:4.14.2-5)
  - libkdecore5 (installierte Version: 4:4.14.2-5)
  - libkdesu5 (installierte Version: 4:4.14.2-5)
  - libkdeui5 (installierte Version: 4:4.14.2-5)
  - libkdewebkit5 (installierte Version: 4:4.14.2-5)
  - libkdnssd4 (installierte Version: 4:4.14.2-5)
  - libkemoticons4 (installierte Version: 4:4.14.2-5)
  - libkfile4 (installierte Version: 4:4.14.2-5)
  - libkhtml5 (installierte Version: 4:4.14.2-5)
  - libkidletime4 (installierte Version: 4:4.14.2-5)
  - libkio5 (installierte Version: 4:4.14.2-5)
  - libkjsapi4 (installierte Version: 4:4.14.2-5)
  - libkjsembed4 (installierte Version: 4:4.14.2-5)
  - libkmediaplayer4 (installierte Version: 4:4.14.2-5)
  - libknewstuff2-4 (installierte Version: 4:4.14.2-5)
  - libknewstuff3-4 (installierte Version: 4:4.14.2-5)
  - libknotifyconfig4 (installierte Version: 4:4.14.2-5)
  - libkntlm4 (installierte Version: 4:4.14.2-5)
  - libkparts4 (installierte Version: 4:4.14.2-5)
  - libkprintutils4 (installierte Version: 4:4.14.2-5)
  - libkpty4 (installierte Version: 4:4.14.2-5)
  - libkrosscore4 (installierte Version: 4:4.14.2-5)
  - libktexteditor4 (installierte Version: 4:4.14.2-5)
  - libkunitconversion4 (installierte Version: 4:4.14.2-5)
  - libkutils4 (installierte Version: 4:4.14.2-5)
  - libnepomuk4 (installierte Version: 4:4.14.2-5)
  - libnepomukquery4a (installierte Version: 4:4.14.2-5)
  - libnepomukutils4 (installierte Version: 4:4.14.2-5)
  - libplasma3 (installierte Version: 4:4.14.2-5)
  - libsolid4 (installierte Version: 4:4.14.2-5)
  - libthreadweaver4 (installierte Version: 4:4.14.2-5)

* Quelle:qtwebkit
  Einzelheiten: No security support upstream and backports not feasible, only for use on trusted content
  Betroffenes Binärpaket:
  - libqtwebkit4:amd64 (installierte Version: 2.3.4.dfsg-3)

Die Beobachtung muss aber gleich relativiert werden, da das Programm scheinbar nur die Quellcodepakete kennt. Dies sind in diesem Fall die kde4libs und qtwebkit. Durch die enorme Aufspaltung in Binärpakete liest sich die Liste dann aber recht ordentlich.

Im Grunde genommen ist die Konsequenz, das man nur noch Iceweasel und Chromium einsetzen kann. Das ist äußerst bedauerlich, zumal mir Qupzilla echt gut gefallen hat. Hier sind aber die Entwickler angehalten, den Projekten ein wenig zu zuarbeiten, da Debian & Co ihren Langzeitsupport sonst unmöglich einhalten können. Je schneller sich die Upstream-Projekte entwickeln, desto wichtiger ist es LTS-Versionen für die Distributionen und damit letztlich die Nutzer anzubieten. Die Kernel-Entwickler, das KDE-Projekt und auch Mozilla haben das verstanden.

Es ist allerdings schön, dass Debian hier nun mit offenen Karten spielt.

23. Mai 2015

Datenhistorie in Ubuntus Dash deaktivieren

Permalink raspitux

Die Dash in Ubuntus eigener Desktopumgebung Unity sammelt fleißig Nutzerdaten um die bestmögliche User Experience zu bieten. So ist es unter Anderem möglich die zuletzt geöffneten Dateien und Ordner zu sehen. Gerade wenn mehrere Benutzer unter dem gleichen Account am PC arbeiten wollen, wird der Aufruf nach Datenschutz größer. Hier zeige ich kurz die Möglichkeit das Sammeln der geöffneten Dateien zu unterbinden und alte Historien zu löschen.

Dazu öffnet man die Systemeinstellungen und klickt auf Sicherheit und Datenschutz. Anschließend auf den Reiter Date & Anwendungen. Dort gibt es einen Button, der das zukünftige Sammeln der Nutzerdaten unterbindet. Um die alten Nutzerdaten zu löschen klickt man auf Gebrauchsdaten löschen.

Systemeinstellungen

Privacy

Wer auch noch ein wenig mehr Privatsphäre haben möchte, kann im Reiter Suche und Diagnose auch noch Einstellungen vornehmen.

Kurztipp: amix vimrc

Permalink Finns Blog

Der Editor für die Konsole vi ist wohl auf sehr vielen GNU/Linux oder allgemein unixoiden System anzutreffen. Die verbesserte Variante vim ist ein wenig besser zu bedienen auch häufig anzutreffen. Eigene Einstellung können global in

/etc/vimrc
  oder pro Benutzer in
~/.vimrc
  gespeichert werden.

Einige Nutzer stellen ihre vimrc anderen zur Verfügung und bieten gute Voreinstellungen und praktische Plugins. Kürzlich bin ich über amix vimrc gestolpert, von der praktischerweise zwei Versionen installieren. Es gibt eine einfache und pluginfreie Basis-Version und eine umfangreichere Awesome Version.

Die Installation ist mit

git
schnell erledigt:
# Awesome Version
git clone git://github.com/amix/vimrc.git ~/.vim_runtime
sh ~/.vim_runtime/install_awesome_vimrc.sh

# Basic Version
git clone git://github.com/amix/vimrc.git ~/.vim_runtime
sh ~/.vim_runtime/install_basic_vimrc.sh

Eigene abweichende Einstellungen können in der 

~/.vim_runtime/my_configs.vim
  gespeichert werden. Alle Funktionen und Plugins habe ich noch nicht ausprobieren können, aber die allgemeine Bedienung und Anzeige gefällt mir schon ausgesprochen gut:

amix vimrc

Einen Versuch ist die Konfigration sicherlich wert.

 

Ein XMPP Server mit Prosody

Permalink Finns Blog

Was für einige von uns damals ICQ, AOL und MSN waren, das ist für die jüngere Generation WhatsApp und der Facebook Chat. Wenn man sich umsieht, ist vor allem der Verbreitungsgrad von WhatsApp immens und hat sich als Quasi-Standard für Kurznachrichten etabliert. Das Extensible Messaging and Presence Protocol (XMPP) kennen wohl nur die wenigstens, ist aber präsenter als man denkt. Wer sich den geschlossenen Netzwerken wie WhatsApp entziehen möchte, kann einen freien XMPP Server nutzen oder selbst einen Server mit beispielsweise Prosody betreiben.

XMPP und Jabber

Lange Zeit war der Name Jabber ein Synonym für den frei nutzbaren XMPP Dienst. Nach meinem Gefühl wird der Name Jabber inzwischen aber seltener verwendet. Vielleicht liegt das auch an Cisco, die mit Cisco Jabber eine umfangreiche, aber proprietäre Kommunikationslösung auf XMPP Basis anbieten. Ich möchte mich aber nicht beschweren, Cisco hat viel zum Protokoll beigetragen. Wem XMPP und Jabber bisher Fremdworte sind, dem lege ich die Seite einfachjabber.de ans Herz, die zwar nicht allzu aktuell ist, die Grundlagen aber gut erklärt.

WhatsApp und den Facebook Chat habe ich erwähnt, da diese für den Nachrichtenaustausch ebenfalls XMPP (also das XML basierte Protokoll, welches auch Jabber verwendet) verwenden. Der Unterschied zu einem eigenen oder einem anderen öffentlichen XMPP Server liegt in der Geschlossenheit. Die Technik bzw. das Protokoll ist bei WahtsApp und Facebook abgesehen von einigen Erweiterungen oder Anpassungen im Prinzip das gleiche, ermöglicht aber nicht die Kommunikation zu anderen XMPP Netzwerken.

Falls ich bei jemandem jetzt das Interesse geweckt habe, aber eine eigene Installation keine Option ist, empfehle ich jabber.de. Dort stehen Anleitungen, eine Anmeldung und eine Liste von öffentlichen Servern zur Verfügung.

Prosody installieren und konfigurieren

Ich selbst betreibe Prosody auf einem CentOS 6.6 Server, deshalb bezieht sich auch die Installation darauf. Bei andere Distributionen ist im Prinzip nur der Installationsvorgang ein wenig anders und dem Nutzer wahrscheinlich bekannt, die Konfiguration ist eigentlich eher distributionsunspezifisch.

Prosody installieren

Prosody ist im EPEL Repository in der aktuellen Version 0.9.8 verfügbar. Die Installation des EPEL Repositories kann auf labs.console.de schnell nachgesehen werden. Unter Debian und Ubuntu ist es in den Standardpaketquellen enthalten und es braucht kein weiteres Repository aktiviert werden. Nach Installation des EPEL Repositories und ist die Installation schnell erledigt:

yum install prosody

Da Prosody und dessen Module in LUA geschrieben sind, werden einige solcher Pakete als Abhängigkeit mitinstalliert.

Prosody grundlegend konfigurieren

Die globale Konfigurationsdatei

prosody.cfg.lua
  ist unter
/etc/prosody
  zu finden und beinhaltet eine gut kommentierte Standardkonfiguration. Eine der Stärken von XMPP ist die Erweiterbarkeit, deshalb werden viele Funktionen in Form von Modulen abgebildet.

In der Standardkonfiguration habe ich zwei weitere Module aktiviert: Privacy Lists (zum Blocken von Kontakten) und die Komprimierung. Das sieht dann so aus:

"privacy"; -- Support privacy lists
"compression"; -- Stream compression

Das ist kaum erwähnenswert, aber “–” ist ein Kommentar und durch das Entfernen der ehemals vorangestellten Kommentarzeichen werden die Module (nach dem nächsten Neustart von Prosody) aktiviert.

Wer die Registrierung für alle Benutzer aktivieren möchte, kann die Option

allow_registration
  auf
true
  setzen. In meinen Augen wichtiger ist aber zuerst die Aktivierung und Konfiguration der Transportverschlüsselung:
ssl = {
        key = "/etc/pki/tls/private/foobar.pem";
        certificate = "/etc/pki/tls/certs/foobar.crt";
        cafile = "/etc/pki/tls/certs/foobar_CA.crt"; -- falls eine eigene CA verwendet wird
        options = { "no_sslv2", "no_sslv3", "no_ticket", "no_compression", "cipher_server_preference", "single_dh_use", "single_ecdh_use" };
        ciphers = "HIGH+kEDH:HIGH+kEECDH:HIGH:+AES256:+GCM:!LOW:!MD5:!eNULL:!RC4:!PSK:!SRP:!3DES:!DES:!aNULL";
}

Die ersten 3 Optionen geben den Pfad zu meinem privaten SSL Schlüssel, dem Zertifikat und meiner CA an. Das Thema SSL möchte ich hier nicht behandeln. Wer kein kostenpflichtiges, aber öffentlich gültiges Zertifikat erwerben möchte, kann sich selbst ein SSL Zertifikat erstellen. Im Ubuntuusers Wiki ist das gut am Beispiel eines Apache Servers erklärt. Wesentlich sind nur die openssl Kommandos. Alternativ kann

prosodyctl
  aufgerufen werden, welches die Erstellung von Zertifikaten ebenfalls ermöglicht.

Die Optionen

options
  und
ciphers
deaktivieren einige unsichere SSL Mechanismen und sollten in der Regel keine Probleme verursachen.

Da die Transportverschlüsselung nun konfiguriert ist, kann diese für Clients (c2s – client to server) als notwendig vorgeschrieben werden:

c2s_require_encryption = true

Für die s2s Verbindungen (server to server) habe ich die Option bisher nicht aktiviert, da leider nicht alle Server eine Transportverschlüsselung anbieten. Da es vermutlich nur noch wenige sind, werde ich die Option demnächst mal aktivieren.

Eine in meinen Augen wichtige, aber häufig vergesse Einstellung ist die Speicherung der Kennwörter. Ich nutze dafür PostgreSQL, die Konfiguration der Speicher-Backends ist im Prosody Wiki gut erklärt. Eigentlich meinte ich aber die Art, wie Kennwörter gespeichert werden. Standardmäßig werden die nämlich unverschlüsselt im Klartext gespeichert, da einige alte Clients sich sonst nicht anmelden könnten. Alte Clients interessieren mich aber nicht, deswegen verwende ich die gehashte Variante, um Kennwörter zu speichern:

authentication = "internal_hashed"

Einen virtuellen Host anlegen

Prosody unterstützt virtuelle Hosts, wofür ein kleines Beispiel im

conf.d
Ordner vorliegt. Da die relevante Konfiguration bereits in der globalen prosody.cfg.lua erledigt wurde, sieht mein virtueller Host sehr mager aus:
VirtualHost "finnchristiansen.de"
        enabled = true

Hat man mehrere virtuelle Hosts, können Teile der gloaben Konfiguration in einem virtuellen Host überschrieben werden. Außerdem werden weitere Komponenten (Chat-Räume, Transport Proxy für ICQ etc.) in einem virtuellen Host konfiguriert.

Prosody starten und User anlegen

Nach der Konfigurationsänderung muss Prosody neu gestartet werden:

service prosody restart
Prosody XMPP (Jabber) server beenden:                      [  OK  ]
Prosody XMPP (Jabber) server starten:                      [  OK  ]

Alternativ hätte dies auch mit prosodyctl erledigt werden können. Spätestens aber zum Anlegen eines ersten Users wird dieses Programm benötigt:

prosodyctl adduser foobar@finnchristiansen.de

Das waren die wesentlichen Schritte. Ab diesem Zeitpunkt kann der User foobar@finnchristiansen.de mit anderen Nutzern des XMPP Netzwerkes kommunizieren.

Sinnvolle Ergänzungen

SRV Records

In Wirklichkeit betrebe ich Prosody auf einem anderen Server, welcher nicht unter finnchristiansen.de erreichbar ist (der A-Record des DNS zeigt auf eine andere IP).

Damit Clients und Server nun wissen, zu welcher IP sie sich wirklich verbinden sollen, habe ich zwei SRV Records in meinem DNS Server hinterlegt:

### Für Clients
# Name
_xmpp-client._tcp.finnchristiansen.de
# Inhalt
0 5222 services.finnchristiansen.de

### Für Server
# Name
_xmpp-server._tcp.finnchristiansen.de
# Inhalt
0 5269 services.finnchristiansen.de

Der Name des Records beinhaltet den Namen des virtuellen Hosts und der Inhalt beinhaltet die Priorität (sinnvoll, falls mehrere Server verwendet werden), den Port und den eigentlichen Server. Im XMPP Wiki gibt es weitere Erläuterungen.

Stream Management

Vor allem bei der Verwendung einer mobilen Internetverbindung ist es sinnvoll, die Stream Management Erweitung zu installieren und zu aktivieren. Diese wurde unter CentOS nicht mitinstalliert und befindet sich noch im Beta Stadium, funktioniert bei mir aber wunderbar. Vorher sind viele Nachrichten von oder zu mir im Nirvana verschwunden, das ist jetzt vorbei.

Generelles zur Installation von Modulen wird natürlich auch im Prosody Wiki beschrieben, auf die Schnelle geht es aber auch in etwa so:

cd /usr/lib64/prosody/modules
wget http://prosody-modules.googlecode.com/hg/mod_smacks/mod_smacks.lua

Dann fügt man die entsprechende Zeile in der prosody.cfg.lua im 

modules_enabled = { ... }
  Bereich hinzu:
"smacks";

Standardmäßig wird eine Session nun 5 Minuten lang am Leben gehalten, um dem Client in diesem Zeitraum ein Wiederbindungen ohne Nachrichtenverlust zu ermöglichen. Ich habe das aber auf 15 Minuten erhöht, ursprünglich hatte ich einen Tag konfiguriert. Das führt aber zu dem Problem, dass ein Client noch einen Tag lang als “online” anzeigezeigt wird, nachdem die Verbindung getrennt wurde.

# Nicht mehr im Modulbereich, sondern global hinzufügen:
smacks_hibernation_time  = 900

OTR Verschlüsselung

Das hat nichts mit dem Prosody Server zu tun, aber ich möchte es kurz erwähnen. OTR ist ein relativ benutzerfreundlicher Verschlüsselungsmechanismus, der inzwischen von vielen Clients unterstützt wird. Falls möglich, verwendet Ihn und verifiziert den Fingerabdruck / Schlüssel eures Gegenübers.

Clients

Nachdem der Prosody Server also nun einsatzbereit ist, braucht man natürlich noch einen Client, um überhaupt mit anderen kommunizieren zu können. Ich möchte keine Empfehlungen aussprechend, schließlich lassen sich mit Suchmaschinen genügend Clients finden.

Trotzdem kann ich aber erwähnen, dass ich Pidgin (läuft unter Windows, Mac und GNU/Linux) gerne eingesetzt habe, inzwischen Gajim am Rechner und Conversations (auch im F-Droid Repo verfügbar) auf dem Android Geräten nutze.

Wieso Jabber und nicht WhatsApp

Ich bin unter finn@finnchristiansen per Jabber (und E-Mail) erreichbar und nutze kein WhatsApp. Ich habe Wirtschaftsinformatik studiert, arbeite in der IT Branche und anscheinend macht es gerade das für viele Leute noch unverständlicher, warum ich kein WhatsApp nutze. Auf die Frage, ob ich WhatsApp nutze oder warum ich es nicht nutze, antworte ich einfach “ich bin doch nicht wahnsinnig”.

Aber die Entscheidung, sich von einem Unternehmen vollständig und freiwillig abhören zu lassen, bleibt jedem selbst überlassen.

Oft habe ich Jabber mit der E-Mail verglichen: Es ist ein freies und offenes System, der Aufbau aus Benutzername und Server ist gleich und die Bedienung ist ähnlich oder sogar einfacher. Ich habe mich wohl heftig geirrt: Ich habe einige Tage auf eine E-Mail eines Bekannten gewartet. Als wir uns trafen, fragte ich noch einmal nach der E-Mail, die bisher nicht angekommen war. Er antwortete: “Wie soll ich dir eine E-Mail schreiben, wenn du ja gar kein WhatsApp hast?”

Jenkins – Authentifizierung mit jenkins-cli.jar

Permalink Unerklärliches am Rande

Momentan konfiguriere ich mir einen Jenkins CI Server für private PHP Sachen. Da ich das nicht alle Tage mache schreibe ich mir hakelige Sachen oder Dinge die ich recherchieren mußte hier für das nächste mal nieder. Ich werde den Server primär zum Ausführen von Unit-Tests, dem Erzeugen von Dokumentation und Softwaremetriken nutzen. Eventuell hänge ich noch ein Deployment dran.

Eine schöne Anleitung für die PHP Projekte gibt es hier. Wenn man den Server per Kommandozeile steuern möchte – um z.B. Plugins zu installieren – muß man sich per SSH Key authentifizieren.

Hier die Konfiguration auf der Kommandozeile + Webinterface im Schnelldurchgang:

1. jenkins-cli.jar besorgen

Von der Seite http://yourserver.com/cli runterladen – der Eintrag im Jenkins Wiki zu dem Thema ist auch sehr nützlich

2. Key erzeugen

ms@jenkins:~$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ms/.ssh/id_rsa): id_rsa_jenkins_cli
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in id_rsa_jenkins_cli.
Your public key has been saved in id_rsa_jenkins_cli.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx ms@jenkins
The key's randomart image is:
+--[ RSA 4096]----+
| cxxxxxxxxxxx    |
| xxxxxxxxxxxx    |
| xxxxxxxxxxxx    |
|   xxxxxxxxxx    |
|     xxxxxxxx    |
|       x         |
|                 |
|                 |
|                 |
+-----------------+
ms@jenkins:~$ mv id_rsa_jenkins_cli* .ssh/

3. Public Key im Jenkins Webinterface eintragen

Die Url lautet https://yourserver.com/me/configure

ms@jenkins:~$ cat .ssh/id_rsa_jenkins_cli.pub

4. Beim Aufruf von jenkins-cli.jar den Pfad zum Key mit -i mitgeben.

ms@jenkins:~$ java -jar jenkins-cli.jar -i .ssh/id_rsa_jenkins_cli -s http://localhost/jenkins install-plugin checkstyle cloverphp crap4j dry htmlpublisher jdepend plot pmd violations warnings xunit
Installing checkstyle from update center
Installing cloverphp from update center
Installing crap4j from update center
Installing dry from update center
Installing htmlpublisher from update center
Installing jdepend from update center
Installing plot from update center
Installing pmd from update center
Installing violations from update center
Installing warnings from update center
Installing xunit from update center

RPM Dateien herunterladen und extrahieren

Permalink Finns Blog

Manchmal möchte man ein Paket nur herunterladen und vielleicht noch hineinschauen, es aber nicht installieren. Ich muss zugeben, dass es bei mir nur selten vorkommt, aber wenn doch, dann muss ich jedes Mal erneut überlegen, wie ich es beim letzten Mal gemacht habe. Das soll mir nicht noch einmal passieren.

RPM Paket herunterladen

Im Base Repository von CentOS ist das Yum Plugin downloadonly enthalten, welches fix installiert wird:

yum install yum-plugin-downloadonly

Nun hat man die Möglichkeit, beim Installieren oder Updaten von Paketen mit

yum
  die Option
--downloadonly
  anzugeben. Das Paket wird heruntergeladen, aber vor dem Aktualisieren oder installieren bricht die Operation dann ab. Das Paket ist dann standardmäßig in
/var/cache/yum
und den entsprechenden Unterordnern abgelegt.

Sollte es sich um ein bereits installiertes Paket handeln, für das keine Aktualisierungen vorliegen, kann man die Option für die Neuinstallation zum Herunterladen verwenden:

yum reinstall foobar --downloadonly

Möchte man es an einen anderen Ort ablegen, kann zusätzlich z.B. die Option

--downloaddir=/tmp
  angegeben werden, um das Paket nach
/tmp
  herunterzuladen.

RPM Paket entpacken

Wenn einen nicht das RPM Paket an sich sondern dessen Inhalt interessiert, kann man dies entpacken. Dafür steht das Paket rpm2cpio zur Verfügung, dessen Ausgabe dann mit cpio in Dateien geschrieben werden kann:

rpm2cpio foobar.rpm | cpio -idmv

Der Inhalt das Pakets wird in das aktuelle Arbeitsverzeichnis entpackt und kann nach Belieben durchsucht und angeschaut werden.

22. Mai 2015

Mailserver From Scratch (Debian 8)

Permalink debinux

Nach bald zwei Jahren, wenig freier Zeit, viel Unentschlossenheit und den üblichen Dramen, die einem das Leben um die Ohren wirft, revanchiere ich mich mit einer Neuauflage zum “Mailserver Artikel”.

Es mag einiges noch unaufgeräumt wirken sein, vergebt mir, die nächsten Zeilen habe ich spontan und in sehr kurzer Zeit geschrieben. Ich bin mir sicher, dass sich die Struktur noch verändert. :-)

An dieser Stelle möchte ich auch einfach mal vielen, vielen Dank sagen. Vielen Dank an euch, die Community, die ihr mir so unglaublich viel Feedback gegeben- und garantiert auch in vieler Hinsicht belehrt habt.
Das betrifft jeden einzelnen Artikel, den ich in den letzten Monaten, fast schon Jahren, geschrieben habe.

Der Geschmack, der ersten von Spenden finanzierten Pizza. Daran erinnere ich mich besonders gerne zurück, glaube ich… :-)

Zurück zum Thema.

Einige Eckdaten des Beispielsystems:

  • Debian Jessie (8.0)
  • Es genügt schon ein Single-Core System mit etwa 1GB RAM, lediglich ClamAV ist etwas hungriger nach Resourcen.
  • Viel wichtiger ist einem Mailserver ausreichende Disk-Leistung. Aber auch erst dann, wenn es ernst wird; und das kann dauern.

Ein Server sollte seinen RAM belegen, denkt daran.

Einige Versionen aus dem Debian Jessie Repository:

  • Nginx 1.6.2 – Der Webserver, der über HTTPS angesprochen werden soll.
  • MySQL 5.5.43 – Eine Datenbank dient der gesamten Mailbox-Verwaltung. Eine weitere Datenbank wird von Roundcube verwendet.
  • PHP 5.6.7 – Die Webanwendungen Roundcube und ViMbAdmin arbeiten mit dem PHP-Intepreter zusammen.
  • Postfix 2.11 – Der MTA: Zuständig für den Transport von Nachrichten.
  • Amavis 2.10.1 – Amavis dient als Content-Filtern und signiert die Nachrichten nach DKIM.
    -> ClamAV 0.98.6 – Prüft Nachrichten auf schädlichen Inhalt.
    -> Spamassassin 3.4.0 – Ein erprobter Spamfilter.

Anwendungen externer Quellen, die Versionen variieren.

  • Dovecot 2.2.x – Der MDA, IMAP- und POP3-Server Dovecot zeugt von höchster Stabilität. In stetiger Entwicklung, daher Installation aus offiziellem Repository.
  • Roundcube 1.1.x – Unterstützt den gesamten Dovecot Umfang
  • ViMbAdmin 3, sollte nicht mehr als Fork von Postfixadmin betrachtet werden, dient aber ebenso zur Vewaltung der und Mailboxen.

Variablen im Artikel

  • Als Hostnamen verwende ich in diesem Artikel mail.domain.tld.
  • Die primäre Maildomäne wird domain.tld lauten.
  • Platzhalter der primären IP, unter der mein Mailserver extern erreichbar ist, verwende ich 1.2.3.4.
  • Passwörter lauten immer changeme.

Im Schnelldurchlauf: Funktionsweise und Vorwort

Annehmen wird Postfix Mails von nicht-autentifizierten Sendern auf Port 25. Vorgeschaltet ist Postscreen, ein Prozess, welcher entscheidet, ob es sich beim Sender um einen “Zombie” handelt. Zombies können u.a. Spambots sein, die sich an keine/wenige Regeln halten und sich schon beim verbinden auf einfachster Ebene verdächtig anstellen. Auch übernimmt es die Aufgabe, eine IP gegen Blacklists zu prüfen. Postscreen ist in hohem Maße effizient und extrem simpel. Es ist in seiner Fähigkeit so beschränkt, dass es gültige Verbindungen an einen dafür vorgesehenen SMTP-Dienst durchreichen muss, um sie weiter zu verarbeiten.

Auf Port 587, gedacht zur authentifizierten Nachrichtenübertragung (“Submission”), arbeitet kein Postscreen Prozess. Postscreen würde Verbindungen von dynamischen Anschlüssen (etwa DSL, Cable) sofort abstrafen und unterbinden.

Beide SMTP-Dienste reichen empfangene Nachrichten an Amavis weiter. Amavis fungiert als SMTP-Proxy. Nachrichten nicht-authentifizierter Benutzer werden Amavis auf Port 10024 erreichen, alle weiteren wiederum auf Port 10025. Amavis wird angewiesen, Nachrichten auf Port 10025 als “von seinem System stammend” zu behandeln (“originating”). Auch werden lediglich solche Nachrichten DKIM-signiert.

Entscheidet sich Amavis dafür, die Nachricht anzunehmen, wird sie nach Bearbeitung in beiden Fällen auf Port 10035 Postfix zurückgeführt.

Postfix wird die Transportregeln nach weiterem Vorgehen befragen und womöglich LMTP verwenden, um Dovecot die Nachricht final zu übermitteln. Die LMTP-Verbindung wird verschlüsselt (Achtung: Funktioniert nicht mit Dovecot aus dem Debian LTMP versteht sich als relativ simple Ableitung des SMTP-Protokolls und wird hauptsächlich zu diesem Zweck verwendet. Es ähnelt als Abkömmling - logischerweise - stark dem SMTP.

Dovecot verwendet in nachstehender Konfiguration das Maildir-Format. Layout- und Namespace-Separator lauten “/”, hauptsächlich um höchste ACL-Kompatibilität zu erreichen. Benutzernamen mit dem Satzzeichen “.” stehen aus Erfahrung im Konflikt.
Das Hauptverzeichnis für virtuell geroutete Nachrichten lautet /var/vmail. Die weitere Struktur wird unterteilt in Domäne/Benutzer/, das “Maildir” des Benutzers zuletzt im Unterordner “Maildir” abgelegt. Für den Benutzer user1@domain1.tld ergibt so die Ordnerstruktur /var/vmail/domain1/user1/Maildir oder einfacher: ~/Maildir.
Dovecot stellt Postfix verschiedene Dienste zur Verfügung. Postfix ist unter anderem nicht in der Lage – und möchte auch nicht in der Lage sein -, Absender zu authentifizieren. Es greift auf einen Socket zurück, den Dovecot mit Hilfe des SASL-Mechanismus bereitstellt.

Was fehlt? …und warum?
Wo ist das Greylisting? Wo sind die Scripts, um Spam anzulernen?
Der ein oder andere könnte meine Meinung zum Greylisting bereits kennen. Wer es möchte, kann es einbinden.
Ich bin der Meinung, dass 99% der durch Greylisting abgestraften Mailserver zu Unrecht (temporär) blockiert werden. Ein kompromittierter E-Mail Account, etwa von Google Mail, wird sich an Greylisting nicht stören. Google Server versenden nach einem Fehlversuch erwartungsgemäß ein zweites mal.
Echte Spambots/Zombies werden wesentlich (!) performanter durch Postscreen ausgeschlossen. Hierbei wird auch kein temporärer Fehlercode missbraucht und die Zustellung nicht verzögert.
Das größte Übel: Ein fehlkonfigurierter Absender, der keinen zweiten Zustellversuch unternimmt und die Nachricht als unzustellbar zurück sendet.

Auch das Anlernen von Spam sehe ich zwiespältig. Einen Spamfilter vernünftig anzulernen, ist viel schwieriger als mancher es glauben mag. Zu schnell und unüberlegt bringen wir ihm bei, wie das Filtern nicht funktioniert. :-) Die größte Schuld an “false-positives” tragen genau diese Lehrversuche.
Kompromittierte Mail-Accounts stellen hier wieder ein großes Problem dar. Ein vertrauter Server versendet authentifizierten Spam. Spamfilter werden der Tatsache, dass der Benutzer authentifizert ist, eine viel höheren Bedeutung zusprechen als der Tatsache, dass 2-3 mal ein dubioses Wort im Text zu finden ist. Hier zu filtern ist ein Drahtseilakt.
Spamfilter sind heutzutage sehr effizient. Zusammen mit Postscreen filtern sie die üblichen Verdächtigen bravorös aus.

Noch einmal kurz und knapp, wie konfiguriere ich meinen Client?
IMAP – Mit STARTTLS auf Port 143, im SSL Wrapper auf Port 993
SMTP – Mit STARTTLS auf Port 587, Port 25 wird als Client bitte nie verwendet.

Inhaltsverzeichnis

1. First things first
2. Webserver
2.1 Webanwendungen
3. Mailserver
3.1 Postfix
3.2 Dovecot
3.3 Content-Filter
4. Dienste neustarten

1. First things first

Nachdem das Debian Jessie System frisch aufgesetzt wurde, vergewissert euch noch einmal, dass die Grundkonfiguration stimmt.

timedatectl set-timezone Europe/Berlin
hostnamectl set-hostname mail.domain.tld

Bitte nehmt Abstand davon, einen Hostnamen domain.tld zu verwenden. domain.tld alleine ist kein Hostname.
Wählt einen FQDN, der sich aus Hostnamen und Domäne zusammensetzt.
Ich gehe in diesem Artikel von einem Server aus, der sich lediglich im öffentlichen Netz bewegt. Ein interner Name kommt daher nicht in Frage.

Die Datei /etc/hosts sollte mindestens Folgendem entsprechen:

127.0.0.1 localhost
1.2.3.4 mail.domain.tld mail
# ...

Im Terminal teste ich die korrekte Einrichtung:

# hostname -a
mail
# hostname -d
domain.tld
# hostname -f
mail.domain.tld

Warum ist der Hostname bei einem Mailsystem so wichtig?
Zwar wird der Hostname auch in diesem Artikel gezielt noch einmal in der Postfix-Konfiguration gesetzt.
Es ist dennoch wichtig, dass alle Komponenten im System den korrekten Namen kennen und tragen. Mailserver verwenden strikte Regelwerke, das ist dem hohen Spamaufkommen geschuldet. Das Mindeste, das wir tun können, um diese Kontrollen zu bestehen, ist uns an die Standards zu halten, also RFC-konform zu sein.
RFC-Konformität bedeutet unter anderem, dass unser Mailserver beim Verbindungsaufbau, einen FQDN nennt (Postfix: “myhostname”), der zu seiner IP auflöst und vice versa:

# Server A, mail.domain.tld (1.2.3.4), verbindet sich mit Server B, mail.example.com (2.3.4.5):
> HELO mail.domain.tld
# Interne Prüfung durch mail.example.com: Löst 1.2.3.4 nach mail.domain.tld auf (rDNS)? Löst mail.domain.tld nach 1.2.3.4 auf? Wenn ja, weiter machen…
...

Daher bitte unbedingt einen korrekten Reverse-DNS Eintrag vorhalten!
Die meisten Benutzer werden heute einen (virtuellen) Server angemietet haben. Der ISP hält dafür in 99% aller Fälle eine Möglichkeit bereit, einen solchen Eintrag für die entsprechende IP eigenständig zu setzen. Diese Konfiguration ist nicht Bestandteil des lokalen Systems.

2. Webserver

In den ersten Schritten werden folgende Anwendungen installiert und weitesgehend konfiguriert:

  • Nginx (HTTPS)
  • PHP5
  • MySQL

Die Anwendungen werden mit einem Einzeiler installiert:

apt-get -y install nginx-full php-auth-sasl php-http-request php-mail php-mail-mime php-mail-mimedecode php-net-dime php-net-smtp php-net-socket php-net-url php-pear php-soap php5 php5-cli php5-common php5-curl php5-fpm php5-gd php5-imap php-apc php5-intl php5-mcrypt php5-mysql libawl-php php5-xmlrpc mysql-client mysql-server ca-certificates
Bitte vergebt während der Installation ein sicheres MySQL “root” Kennwort.

Die Mailboxverwaltung sollte über HTTPS erfolgen, daher erstelle ich vorab ein selbst-signiertes Zertifikat in /etc/ssl, das den Namen des FQDN trägt. Der Befehl kann 1:1 so kopiert werden, der Hostname wird automatisch ermittelt:

openssl req -new -newkey rsa:4096 -sha256 -days 1095 -nodes -x509 -subj "/C=DE/ST=STATE/L=CITY/O=MAIL/CN=`hostname -f`" -keyout /etc/ssl/`hostname -f`.key  -out /etc/ssl/`hostname -f`.cer

Der Key wird im Anschluss vor unbefugtem Zugriff geschützt:

chmod 600 /etc/ssl/`hostname -f`.key
Wer im Besitz eines Zertifikats ist, darf das Zertifikat jetzt als /etc/ssl/mail.domain.tld.cer ablegen, den Key analog dazu als /etc/ssl/mail.domain.tld.key

Bitte Folgendes nur bei einem selbst-signiertem Zertifikat ausführen, um dem Zertifikat zu vertrauen:

cp /etc/ssl/`hostname -f`.cer /usr/local/share/ca-certificates/
update-ca-certificates

Einige Anwendungen verweigern den Dienst, wenn das Zertifikat selbst-signiert und nicht vertrauenswürdig ist. Das betrifft unter anderem Roundcube und die IMAP-Schnittstelle neuerer PHP Versionen.

PHP sollte nun unsere Zeitzone kennenlernen, dazu bitt die entsprechende Konfiguration öffnen:

nano /etc/php5/fpm/php.ini

Die relevante Zeile wird editiert:

date.timezone = Europe/Berlin

Den Dienst im Anschluss neuladen:

systemctl reload php5-fpm.service

Nun endlich kann die Nginx Site-Konfiguration erstellt und aktiviert werden.

nano /etc/nginx/sites-available/mailserver

Der Inhalt im Folgenden.
Bitte ändert die Werte für server_name, ssl_certificate und ssl_certificate_key entsprechend eurer Konfiguration ab.

server {
	server_name mail.domain.tld;
	listen 443 ssl;
	listen [::]:443 ssl;
	ssl on;
	ssl_certificate         /etc/ssl/mail.domain.tld.cer;
	ssl_certificate_key     /etc/ssl/mail.domain.tld.key;
	# Einige Optionen nach Bettercrypto
	ssl_prefer_server_ciphers on;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA';
	add_header Strict-Transport-Security max-age=15768000;
	ssl_session_cache shared:SSL:5m;
	ssl_session_timeout 30m;
	client_max_body_size 0;
	root /var/www/html;
	index index.html index.htm index.php;
	location / {
		try_files $uri $uri/ index.php;
	}
	# Zugriff auf Roundcube Logs, sollte von außerhalb nicht möglich sein
	location ~ ^/webmail/logs/ {
		deny all;
	}
	location ~ \.php$ {
		include snippets/fastcgi-php.conf;
		fastcgi_read_timeout 630;
		fastcgi_keep_conn on;
		# Dient ViMbAdmin, da Nginx keine htaccess-Datei einlesen wird
		fastcgi_param APP_ENV production;
		fastcgi_pass unix:/var/run/php5-fpm.sock;
	}
	# Können sensible Daten enthalten, Nginx verwertet sie nicht
	location ~ /\.ht {
		deny all;
	}
	location = /favicon.ico {
		log_not_found off;
		access_log off;
	}
	# Keine Notwendigkeit
	location = /robots.txt {
		deny all;
		log_not_found off;
		access_log off;
	}
	location /admin {
		# Rewrite fix für ViMbAdmin
		try_files $uri $uri/ /admin/index.php?$args;
	}
}

Die Site-Konfiguration wird im Nginx Server aktiviert und der Dienst neugeladen:

ln -s /etc/nginx/sites-available/mailserver /etc/nginx/sites-enabled/
systemctl reload nginx.service

Zwei Datenbanken werden im nächsten Schritt angelegt. Im selben Schritt wird jeweils ein Benutzer das Recht erhalten, in jeweiliger Datenbank zu arbeiten.

changeme bitte in beiden Befehlen durch ein sicheres Kennwort ersetzen!
# ViMbAdmin: Datenbankname vimbadmin, Username vimbadmin
mysql --defaults-file=/etc/mysql/debian.cnf -e "CREATE DATABASE vimbadmin; GRANT ALL ON vimbadmin.* TO 'vimbadmin'@'localhost' IDENTIFIED BY 'changeme'; FLUSH PRIVILEGES;"
# Roundcube: Datenbankname roundcube, Username roundcube
mysql --defaults-file=/etc/mysql/debian.cnf -e "CREATE DATABASE roundcube; GRANT ALL ON roundcube.* TO 'roundcube'@'localhost' IDENTIFIED BY 'changeme'; FLUSH PRIVILEGES;"

2.1. Webanwendungen

Nachdem der Webserver vorbereitet ist, kann mit der Installation der Webanwendungen Roundcube und ViMbAdmin begonnen werden.

Die Abhängigkeiten vorab installieren:

apt-get install -y git curl

Mit cURL wird in einem späteren Schritt der PHP-Composer heruntergeladen, git ist eine direkte Abhängigkeit dessen.

Roundcube nun in einem Schritt herunterladen und entpacken. Anschließend wird der Ordner in webmail umbenannt und die Rechte werden angepasst:

cd /var/www/html
wget --content-disposition -O - http://sourceforge.net/projects/roundcubemail/files/latest/download | tar xfvz -
mv roundcubemail-* webmail

Eine Konfigurationsdatei für Roundcube wird angelegt:

nano /var/www/html/webmail/config/config.inc.php

Der Inhalt, dessen Werte für db_dsnw, default_host und smtp_server angepasst werden müssen.
Hinweis: Der Pfad db_dsnw folgt dem Muster schema://username:password@host/database.

<?php
$config = array();
$config['db_dsnw'] = 'mysql://roundcube:changeme@localhost/roundcube';
/* Auch lokal wird mit TLS gearbeitet (Stichwort: Sniffer) 
Der FQDN sollte "localhost" vorgezogen werden (Zertifikatsvalidierung) */
$config['default_host'] = 'tls://mail.domain.tld';
$config['smtp_server'] = 'tls://mail.domain.tld';
$config['smtp_port'] = 587;
$config['smtp_user'] = '%u';
$config['smtp_pass'] = '%p';
$config['support_url'] = '';
$config['product_name'] = $_SERVER['HTTP_HOST'];
/* Roundcube erhält die Möglichkeit, ACLs und Sieve Filter durch Plugins zu verwalten. */
$config['plugins'] = array(
	'acl',
	'managesieve',
);
$config['login_autocomplete'] = 2;
$config['imap_cache'] = 'apc';
$config['username_domain'] = '%d';
$config['default_list_mode'] = 'threads';
$config['preview_pane'] = true;
/* Da ein selbst-signiertes Zertifikat verwendet wird, gestaltet sich
die Zertifikatsvalidierung weniger restriktiv */
$config['imap_conn_options'] = array(
    'ssl' => array(
      'allow_self_signed' => true,
      'verify_peer'       => false,
      'verify_peer_name'  => false,
    ),
);
$config['smtp_conn_options'] = array(
   'ssl'         => array(
      'allow_self_signed' => true,
      'verify_peer'       => false,
      'verify_peer_name'  => false,
   ),
);

Die Datenbank im nächsten Schritt initialisieren:

mysql --defaults-file=/etc/mysql/debian.cnf roundcube < /var/www/html/webmail/SQL/mysql.initial.sql

Abschließend den Eigentümer des Webroots rekursiv auf “www-data” setzen:

chown -R www-data: /var/www/html

Nun zu ViMbAdmin, das sich im Gegensatz zu Roundcube mit dem PHP Composer installiert.

Den Composer daher vorab installieren und die ausführbare Datei composer.phar nach /usr/local/bin/ verschieben:

curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer

Im Anschluss startet die Installation des Paketes ViMbAdmin durch Composer:

composer create-project opensolutions/vimbadmin /srv/vimbadmin -s dev -n --keep-vcs

Nach erfolgreicher Installation, werden noch die Rechte für die Unterverzeichnisse var/ sowie public/ an den Webdienst angepasst:

chown -R www-data: /srv/vimbadmin/{public,var}

Zuletzt eine symbolische Verknüpfung einrichten, um mit dem Browser später das Panel via URL “https://mail.domain.tld/admin” zu erreichen:

ln -s /srv/vimbadmin/public/ /var/www/html/admin

Eine Beispielkonfiguration bringt ViMbAdmin gleich mit. An ihr kann sich orientiert werden:

cp /srv/vimbadmin/application/configs/application.ini.dist /srv/vimbadmin/application/configs/application.ini
nano /srv/vimbadmin/application/configs/application.ini

Wichtige Punkte, die unbedingt zu ändern sind, habe ich zusammengefasst. Bitte lest die Datei aufmerksam durch.

;; Die sontigen MySQL-Parameter wie Datenbankname und Benutzer (vimbadmin) stimmen bereits überein, daher brauche ich nur noch das Kennwort durch das vorab festgelegte zu ersetzen
resources.doctrine2.connection.options.password = 'changeme'
;; Entspricht dem späteren vmail-Benutzer, dem stellvertretend alle Mailverzeichnisse "gehören"
defaults.mailbox.uid = 5000
defaults.mailbox.gid = 5000
;; Das Maildir wird im Dovecot-Format festgehalten
defaults.mailbox.maildir = "maildir:/var/vmail/%d/%u/mail:LAYOUT=fs"
defaults.mailbox.homedir = "/var/vmail/%d/%u"
;; Einige Details, der Transport sollte per Standard lmtps sein, mit Zeiger auf den passenden Socket
defaults.domain.transport = "lmtps:unix:private/dovecot-lmtp"
;; Erlaubt das endgültige Löschen von Mailboxen vom Dateisystem
mailbox_deletion_fs_enabled = true
;; Den stärksten Hash-Algorithmus bietet Dovecot durch "doveadm"
defaults.mailbox.password_scheme = "dovecot:SHA512-CRYPT"
defaults.mailbox.dovecot_pw_binary = "/usr/bin/doveadm pw"
;; Hierbei handelt es sich um die Informationen der Willkommensmail.
;; "mail.%d" (= "mail.domain.tld") trifft für diesen Artikel zu, sollte dem eigenen Hostnamen nach angepasst werden.
server.smtp.host    = "mail.%d"
server.smtp.port    = "587"
server.smtp.crypt   = "TLS"
;; POP3 wird in diesem Artikel nicht verwendet/konfiguriert
server.pop3.enabled = 0
;; Wieder verwende ich "mail.%d"
server.imap.host  = "mail.%d"
server.imap.port  = "143"
server.imap.crypt = "TLS"
;; Der Webmailer Roundcube ist unter URL/webmail zu erreichen, bitte an den Hostnamen anpassen
server.webmail.host  = "https://mail.%d/webmail"

Das Archiv-Verzeichnis bitte jetzt erstellen, die Rechte müssen nicht verändert werden (siehe weiter unten zu “Cron”):

mkdir /srv/archives

Es befinden sich neben Parametern wie “Default Quota”, die nach eigenem Ermessen verändert werden können, auch noch Angaben zur Identität des Dienstes am Ende der Konfigurationsdatei. Diese Daten sollten selbstverständlich ebenfalls angepasst werden. Bequemen Menschen steht es frei, mit “sed” den Namen “example.com” reihenweise zu ersetzen:

sed -i "s/example.com/domain.tld/g" /srv/vimbadmin/application/configs/application.ini

Damit die Datenbank initialisiert werden kann, benötigt ViMbAdmin noch eine rudimentäre Datei /srv/vimbadmin/public/.htaccess, die der Beispieldatei /srv/vimbadmin/public/.htaccess.dist entsprechen darf:

cp /srv/vimbadmin/public/.htaccess.dist /srv/vimbadmin/public/.htaccess
Nginx liest keine solchen Dateien. Jedoch wurde in der Site-Konfiguration bereits die Umgebungsvariable “APPLICATION_ENV” auf “production” gesetzt.

Die Einrichtung der Datenbank kann nun beginnen:

cd /srv/vimbadmin/
./bin/doctrine2-cli.php orm:schema-tool:create

Das Tool beendet seinen Dienst etwa mit folgenden Informationen:

ATTENTION: This operation should not be executed in a production environment.
Creating database schema...
Database schema created successfully!

Noch einmal wird die Konfigurationsdatei ViMbAdmins geöffnet, um letzte Informationen einpflegen zu können.

nano /srv/vimbadmin/application/configs/application.ini

Parallel in einem Browser die URL https://mail.domain.tld/admin aufrufen und den Anweisungen nach die drei fehlenden Parameter für das Salting in der geöffneten Datei ergänzen.

Nach dem Hinzufügen des administrativen Accounts, wurde ViMbAdmin in Hinsicht seiner Fähigkeit als Webanwendung erfolgreich installiert und konfiguriert.

Cron wird abschließend noch angewiesen, die Archiv- und Lösch-Funktion ViMbAdmins zu automatisieren. Hierbei handelt es sich um Funktionen, die “root” ausführen muss.
Einzig die Aufgabe des Löschens, könnte dem Benutzer “vmail” zugeordnet werden, das nur als Hinweis.

crontab -e

An das Ende der Datei einzufügen:

# Die 10. Minute jeder 2. Stunde
10 */2 * * * /srv/vimbadmin/bin/vimbtool.php -a archive.cli-archive-pendings
# Die 30. Minute jeder 2. Stunde
30 */2 * * * /srv/vimbadmin/bin/vimbtool.php -a archive.cli-restore-pendings
# Die 50. Minute jeder 2. Stunde
50 */2 * * * /srv/vimbadmin/bin/vimbtool.php -a archive.cli-delete-pendings
# 3:15 AM
15 3 * * * /srv/vimbadmin/bin/vimbtool.php -a mailbox.cli-delete-pending

3. Mailserver

3.1 Postfix

Postfix gibt sich in seinen Abhängigkeiten bescheiden:

apt-get install postfix-mysql postfix-pcre postfix
Während der Installation wird um den “server configuration type” gebeten. Die Auswahl ist spielt keine Rolle, da die Konfiguration im Nachhinein überschrieben wird.

Zu Beginn erstelle ich das Verzeichnis /etc/postfix/mysql/, in welchem diverse SQL-Queries gespeichert werden, mit Hilfe derer Postfix ausfindig macht, welche Domänen wie behandelt werden und ob angefragte Domänen/Mailboxen dem System überhaupt angehören. Im Prinzip fragt Postfix an dieser Stelle ab, was wir vorher durch ViMbAdmin in die Datenbank einpflegen.

mkdir /etc/postfix/mysql/

Innerhalb dieses Ordners werden vier Dateien anglegt:

  • postfix-mysql-virtual_alias_maps.cf
  • postfix-mysql-virtual_domains_maps.cf
  • postfix-mysql-virtual_mailbox_maps.cf
  • postfix-mysql-virtual_transport_maps.cf
In jeder der folgenden Dateien wird der das Kennwort changeme bitte durch das MySQL-Kennwort des Benutzers der Datenbank “vimbadmin” ersetzt!

/etc/postfix/mysql/postfix-mysql-virtual_alias_maps.cf

user = vimbadmin
password = changeme
hosts = 127.0.0.1
dbname = vimbadmin
query = SELECT goto FROM alias WHERE address = '%s' AND active = '1'

/etc/postfix/mysql/postfix-mysql-virtual_domains_maps.cf

user = vimbadmin
password = changeme
hosts = 127.0.0.1
dbname = vimbadmin
query = SELECT domain FROM domain WHERE domain = '%s' AND backupmx = '0' AND active = '1'

/etc/postfix/mysql/postfix-mysql-virtual_mailbox_maps.cf

user = vimbadmin
password = changeme
hosts = 127.0.0.1
dbname = vimbadmin
table = mailbox
select_field = maildir
where_field = username

/etc/postfix/mysql/postfix-mysql-virtual_transport_maps.cf

user = vimbadmin
password = changeme
hosts = 127.0.0.1
dbname = vimbadmin
table = domain
select_field = transport
where_field = domain
additional_conditions = and backupmx = '0' and active = '1'

Das Passwort kann ebenso im Nachgang mit Hilfe von “sed” ersetzt werden:

sed -i 's/changeme/passwort/g' /etc/postfix/mysql/postfix-mysql-virtual_*

Konfigurationsdateien mit sensiblen Informationen, sollten vor unbefugtem Zugriff geschützt werden:

chown -R root:postfix /etc/postfix/mysql
chmod 750 /etc/postfix/mysql/
chmod 640 /etc/postfix/mysql/*

Nun zur Konfiguration des Postfix Servers.
Im ersten Schritt wird eine vorherige Konfiguration gelöscht und eine neue erstellt:

rm /etc/postfix/main.cf
nano /etc/postfix/main.cf

Es folgt ein vorrangig in englischer Sprache kommentierter Inhalt. Die “Restrictions” habe ich kurzerhand übersetzt.

# SMTPd greeting banner: You MUST specify $myhostname at the start of the text. This is required by the SMTP protocol.
smtpd_banner = $myhostname

# Disable local biff service
biff = no

# Do not append the string $mydomain to -locally- submitted email.
append_dot_mydomain = no

# Readme directory
readme_directory = /usr/share/doc/postfix

# HTML directory
html_directory = /usr/share/doc/postfix/html

# Certificates
smtpd_tls_cert_file = /etc/ssl/mail.domain.tld.cer
smtpd_tls_key_file = /etc/ssl/mail.domain.tld.key

# Opportunistic TLS. TLS auth only.
smtpd_tls_security_level=may
smtpd_tls_auth_only=yes

# TLS session cache for SMTPd
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# Disallow SSLv2 and SSLv3, only accept secure ciphers
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers=high

# Log TLS handling
smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1

# Delay reject until RCPT TO
smtpd_delay_reject = yes

# Enable elliptic curve cryptography, "ultra" needs more cpu time
smtpd_tls_eecdh_grade = strong

# Sender, recipient, client and data restrictions
# !! non-FQDN HELOs are rejected on Port 25 only, see master.cf

# Auth. Benutzer dürfen auch innerhalb der "mynetworks" nur von den Adressen senden, die ihnen zugehörig sind.
smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch,
# Erst jetzt werden "mynetworks" zugelassen
# Unauth. Benutzer wie der Cron-Dienst können so weiterhin Mails versenden, etwa
# als cron@fqdn
   permit_mynetworks,
# Anderen unauth. Benutzern das Benutzen jeder Adresse verbieten.
   reject_sender_login_mismatch,
# Alle auth. jetzt zulassen.
   permit_sasl_authenticated,
# Nicht im System vorhandene Absender jetzt ablehnen
   reject_unlisted_sender,
# Ablehnen, wenn die Sender-Domäne nicht existiert
   reject_unknown_sender_domain

# Akzeptiere alle Empfänger, die ein authentifizierter Absender oder ein Absender aus "mynetworks" angibt
smtpd_recipient_restrictions = permit_sasl_authenticated,
   permit_mynetworks,
# Schnittstelle zu Dovecot, um die Quota live zu überprüfen (verhindert Bounces)
   check_policy_service unix:private/quota-status,
# Ablehnen, wenn der HELO FQDN nicht aufzulösen ist
   reject_unknown_helo_hostname,
# Ablehnen, wenn KEIN PTR zu dieser IP existiert
# Verhindert nicht, dass ein FALSCHER PTR abgelehnt wird!
# Hierfür würde "reject_unknown_client_hostname" verwendet.
   reject_unknown_reverse_client_hostname,
# Kein offenes Relay
   reject_unauth_destination

# Unauth. Benutzer dürfen ihre Befehle nicht "pipen"
smtpd_data_restrictions =
   reject_unauth_pipelining,
   permit

# Eine Art Tabelle mit vorhanden Identitäten und ihren Zugehörigkeiten
smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql/postfix-mysql-virtual_alias_maps.cf

# Certificates
smtp_tls_cert_file = /etc/ssl/mail.domain.tld.cer
smtp_tls_key_file = /etc/ssl/mail.domain.tld.key

# Opportunistic TLS. Use TLS if this is supported by the remote SMTP server, otherwise use plaintext.
smtp_tls_security_level=may

# TLS session cache for SMTP
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# A custom list with secure ciphers.
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

# Use the FQDN for the local hostname!
myhostname = mail.domain.tld

# Alias maps and database for -local- delivery only
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

# The domain name that locally-posted mail appears to come from, and that locally posted mail is delivered to.
myorigin = mail.domain.tld

# The list of domains that are delivered via the -local- mail delivery transport. No external domains like "domain.tld" belong here! "mail.domain.tld" is fine.
mydestination = mail.domain.tld, localhost

# We lookup MX records to send non-local mail, so this stays empty
relayhost =

# Trusted SMTP clients with more privileges. Trusted clients can relay mail.
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

# The maximal size of any -local- individual mailbox
mailbox_size_limit = 0

# The maximal size of any -virtual- individual mailbox
virtual_mailbox_limit = 0

# Handle Postfix-style extensions
recipient_delimiter = +

# The network interface addresses that this mail system receives mail on.
inet_interfaces = all

# Specifies what protocols Postfix will use when it makes or accepts network connections, and also controls what DNS lookups Postfix will use when it makes network connections.
inet_protocols = ipv4

# VRFY command is not really needed anymore
disable_vrfy_command = yes

# Please say hello first...
smtpd_helo_required = yes

# The SASL plug-in type that the Postfix SMTP server should use for authentication.
smtpd_sasl_type=dovecot

# Where to passthrough our authentication information for the above plug-in
smtpd_sasl_path=private/auth_dovecot

# Enable SASL authentication in the Postfix SMTP server.
smtpd_sasl_auth_enable = yes

# Report the SASL authenticated user name in the smtpd Received message header.
smtpd_sasl_authenticated_header = yes

# Have Postfix advertise AUTH support in a non-standard way.
broken_sasl_auth_clients = yes

# The lookup tables that the proxymap server is allowed to access for the read-only service.
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps

## Virtual transport configuration
# A prefix that the virtual delivery agent prepends to all pathname results from $virtual_mailbox_maps
virtual_mailbox_base = /

# THIS contains a list of domains we are the final destination for (unlike "mydestination").
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql/postfix-mysql-virtual_domains_maps.cf

# Alias specific mail addresses or domains to other local or remote address.
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql/postfix-mysql-virtual_alias_maps.cf

# Specify a left-hand side of "@domain.tld" to match any user in the specified domain
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql/postfix-mysql-virtual_mailbox_maps.cf

# The minimum user ID value that the virtual delivery agent accepts
virtual_minimum_uid = 5000

# We use "vmail" user with UID/GID 5000 to lookup tables
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

# The default mail delivery transport and next-hop destination for final delivery to domains listed with "virtual_mailbox_domains"
virtual_transport = lmtps:unix:private/dovecot-lmtp

transport_maps = mysql:/etc/postfix/mysql/postfix-mysql-virtual_transport_maps.cf

## Queue configuration
# Consider a message as undeliverable, when delivery fails with a temporary error, and the time in the queue has reached this limit.
maximal_queue_lifetime = 1d

# Consider a bounce message as undeliverable, when delivery fails with a temporary error, and the time in the queue has reached this limit.
bounce_queue_lifetime = 1d

# The time between deferred queue scans by the queue manager.
queue_run_delay = 300s

# The maximal/minimal time between attempts to deliver a deferred message.
maximal_backoff_time = 1800s
minimal_backoff_time = 300s

# Maximum mail size (500 MiB)
message_size_limit = 524288000

# This tarpits a client after 3 erroneous commands for 10s
smtpd_soft_error_limit = 3
smtpd_error_sleep_time = 10s
smtpd_hard_error_limit = ${stress?1}${stress:5}

postscreen_access_list = permit_mynetworks

# Drop connections from blacklisted servers with a 521 reply
postscreen_blacklist_action = drop

# Clean Postscreen cache after 24h
postscreen_cache_cleanup_interval = 24h

postscreen_dnsbl_ttl = 5m
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites =
  b.barracudacentral.org=127.0.0.2*7
  dnsbl.inps.de=127.0.0.2*7
  bl.mailspike.net=127.0.0.2*5
  bl.mailspike.net=127.0.0.[10;11;12]*4
  dnsbl.sorbs.net=127.0.0.10*8
  dnsbl.sorbs.net=127.0.0.5*6
  dnsbl.sorbs.net=127.0.0.7*3
  dnsbl.sorbs.net=127.0.0.8*2
  dnsbl.sorbs.net=127.0.0.6*2
  dnsbl.sorbs.net=127.0.0.9*2
  zen.spamhaus.org=127.0.0.[10;11]*8
  zen.spamhaus.org=127.0.0.[4..7]*6
  zen.spamhaus.org=127.0.0.3*4
  zen.spamhaus.org=127.0.0.2*3
  hostkarma.junkemailfilter.com=127.0.0.2*3
  hostkarma.junkemailfilter.com=127.0.0.4*1
  hostkarma.junkemailfilter.com=127.0.1.2*1
  wl.mailspike.net=127.0.0.[18;19;20]*-2
  hostkarma.junkemailfilter.com=127.0.0.1*-2
postscreen_greet_banner = $smtpd_banner
postscreen_greet_action = enforce
postscreen_greet_wait = 3s
postscreen_greet_ttl = 2d
postscreen_bare_newline_enable = no
postscreen_non_smtp_command_enable = no
postscreen_pipelining_enable = no
postscreen_cache_map = proxy:btree:$data_directory/postscreen_cache
Wieder wird jedes Auftauchen von “mail.domain.tld” durch den eigenen FQDN ersetzt, wieder kann “sed” die Aufgabe übernehmen:
sed -i 's/mail.domain.tld/host.example.com/g' /etc/postfix/main.cf
Bitte die Domäne domain.tld nicht unter “mydestination” aufführen! Ziele, die in “mydestination” geführt werden, werden von Postfix als “lokal” behandelt. Ergo wird hierfür nicht der “virtuelle” Transport mittels Dovecot verwendet.

Nun zu den Diensten, die Postfix bereitstellt. Diese werden mit Hilfe der Datei /etc/postfix/master.cf definiert:

nano /etc/postfix/master.cf

Der Inhalt, wieder weitesgehend kommentiert:

# Postscreen on Port 25/tcp, filters zombies (spam machines) on first level with lowest costs.
smtp      inet  n       -       n       -       1       postscreen

# Postscreen passes sane clients to the real SMTP daemon here.
smtpd      pass  -       -       n       -       -       smtpd
# Reject non-FQDN HELOs on Port 25 (after passing postscreen process)
  -o smtpd_helo_restrictions=permit_mynetworks,reject_non_fqdn_helo_hostname
  -o smtpd_proxy_filter=127.0.0.1:10024
  -o smtpd_client_connection_count_limit=10
  -o smtpd_proxy_options=speed_adjust

# For mail submitting users. Authenticated clients and known networks only.
submission inet n       -       -       -       -       smtpd
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_proxy_filter=127.0.0.1:10025
  -o smtpd_client_connection_count_limit=10
  -o smtpd_proxy_options=speed_adjust

# Handles TLS connections for postscreen to make them readable
tlsproxy  unix  -       -       n       -       0       tlsproxy
# This implements an ad-hoc DNS white/blacklist lookup service
dnsblog   unix  -       -       n       -       0       dnsblog

pickup    fifo  n       -       -       60      1       pickup
cleanup   unix  n       -       -       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
tlsmgr    unix  -       -       -       1000?   1       tlsmgr
rewrite   unix  -       -       -       -       -       trivial-rewrite
bounce    unix  -       -       -       -       0       bounce
defer     unix  -       -       -       -       0       bounce
trace     unix  -       -       -       -       0       bounce
verify    unix  -       -       -       -       1       verify
flush     unix  n       -       -       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
proxywrite unix -       -       n       -       1       proxymap
smtp      unix  -       -       -       -       -       smtp
relay     unix  -       -       -       -       -       smtp
showq     unix  n       -       -       -       -       showq
error     unix  -       -       -       -       -       error
retry     unix  -       -       -       -       -       error
discard   unix  -       -       -       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       -       -       -       lmtp
anvil     unix  -       -       -       -       1       anvil
scache    unix  -       -       -       -       1       scache

# LMTP with STARTTLS support, needs newer Dovecot versions
lmtps     unix  -       -       -       -       -       lmtp
  -o lmtp_use_tls=yes
  -o lmtp_tls_loglevel=1
  -o lmtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
  -o lmtp_enforce_tls=yes
  -o lmtp_tls_mandatory_protocols=!SSLv2,!SSLv3
  -o lmtp_tls_protocols=!SSLv2,!SSLv3
  -o lmtp_tls_mandatory_ciphers=high
  -o lmtp_tls_ciphers=high
  -o lmtp_send_xforward_command=yes
  -o lmtp_tls_security_level=encrypt
  -o lmtp_tls_note_starttls_offer=yes

# Amavis reinjection, maximal 5 smtpd Prozesse, muss den Amavis Prozessen entsprechen!
127.0.0.1:10035 inet    n       -       -       -       5       smtpd
  -o smtpd_authorized_xforward_hosts=127.0.0.0/8
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o smtpd_data_restrictions=
  -o mynetworks=127.0.0.0/8
  -o receive_override_options=no_unknown_recipient_checks

In dieser Konfigurationsdatei muss nichts weiter angepasst werden.

3.2 Dovecot

Wie zu Beginn erwähnt, erfolgt die Installation aus dem offiziellen Repository Dovecots. Dieses wird zuerst eingebunden und der entsprechende Key installiert:

echo 'deb http://xi.rename-it.nl/debian/ stable-auto/dovecot-2.2 main' > /etc/apt/sources.list.d/dovecot.list
apt-get update -y
apt-get install --force-yes debian-dovecot-auto-keyring

Die Installation beginnt:

apt-get install dovecot-common dovecot-core dovecot-imapd dovecot-lmtpd dovecot-managesieved dovecot-sieve dovecot-mysql

Eine Konfigurationsdatei wird gelöscht und neu erstellt:

rm /etc/dovecot/dovecot.conf
nano /etc/dovecot/dovecot.conf

Der Inhalt:

auth_mechanisms = plain login
disable_plaintext_auth = yes
login_log_format_elements = "user=<%u> method=%m rip=%r lip=%l mpid=%e %c %k"
mail_home = /var/vmail/%d/%n
mail_location = maildir:~/Maildir:LAYOUT=fs
mail_uid = vmail
mail_gid = vmail
# notify wird von mail_log benötigt. mail_log informiert in diesem Fall über DELETE und EXPUNGE (weiter unten)
mail_plugins = quota acl mail_log notify
auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
ssl_protocols = !SSLv3 !SSLv2
ssl_cipher_list = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
log_timestamp = "%Y-%m-%d %H:%M:%S "
passdb {
  args = /etc/dovecot/dovecot-mysql.conf
  driver = sql
}
# Der "namespace separator" sollte "/" lauten, da es zusammen mit der ACL zu Konflikten käme, wenn der Benutzername das Zeichen "." enthält.
namespace inbox {
  inbox = yes
  location =
  separator = /
  mailbox Trash {
    auto = subscribe
    special_use = \Trash
  }
    mailbox "Deleted Messages" {
      special_use = \Trash
    }
    mailbox "Gelöschte Objekte" {
      special_use = \Trash
    }
    mailbox "Papierkorb" {
      special_use = \Trash
    }
  mailbox Archive {
    auto = subscribe
    special_use = \Archive
  }
    mailbox Archiv {
      special_use = \Archive
    }
  mailbox Sent {
    auto = subscribe
    special_use = \Sent
  }
    mailbox "Sent Messages" {
      special_use = \Sent
    }
    mailbox "Gesendet" {
      special_use = \Sent
    }
  mailbox Drafts {
    auto = subscribe
    special_use = \Drafts
  }
    mailbox Entwürfe {
      special_use = \Drafts
    }
  mailbox Junk {
    auto = subscribe
    special_use = \Junk
  }
  prefix =
}
# Dieser Namespace wird für die ACL Erweiterung benötigt.
# Freigegebene Ordner erscheinen automatisch in der Ordnerliste.
namespace {
    type = shared
    separator = /
    prefix = Shared/%%u/
    location = maildir:%%h/Maildir:LAYOUT=fs:INDEXPVT=~/Maildir/Shared/%%u
    subscriptions = yes
    list = yes
}
protocols = imap sieve lmtp
service dict {
  unix_listener dict {
    mode = 0660
    user = vmail
    group = vmail
  }
}
service auth {
  unix_listener /var/spool/postfix/private/auth_dovecot {
    group = postfix
    mode = 0660
    user = postfix
  }
  unix_listener auth-master {
    mode = 0600
    user = vmail
  }
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
  }
  user = root
}
service managesieve-login {
  inet_listener sieve {
    port = 4190
  }
  service_count = 1
  process_min_avail = 2
  vsz_limit = 128M
}
service managesieve {
  process_limit = 256
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    group = postfix
    mode = 0600
    user = postfix
  }
  user = vmail
}
listen = *
ssl_cert = </etc/ssl/mail.domain.tld.cer
ssl_key = </etc/ssl/mail.domain.tld.key
userdb {
  args = /etc/dovecot/dovecot-mysql.conf
  driver = sql
}
protocol imap {
  mail_plugins = quota imap_quota imap_acl acl mail_log notify
}
protocol lmtp {
  mail_plugins = quota sieve acl notify
  auth_socket_path = /var/run/dovecot/auth-master
  postmaster_address = postmaster@domain.tld
}
protocol sieve {
  managesieve_logout_format = bytes=%i/%o
}
protocol lda {
  mail_plugins = sieve quota acl notify
  postmaster_address = postmaster@domain.tld
}
plugin {
  mail_log_events = delete undelete expunge
# Um quasi-öffentliche Ordner für authentifizierte Benutzer via ACL zu erstellen
  acl_anyone = allow
# Wird automatisch verwaltet und beinhaltet eine Übersicht der Freigaben
  acl_shared_dict = file:/var/vmail/shared-mailboxes.db
# In jeder Mailbox wird von Dovecot eine Datei gepflegt, die die Freigaben regelt
  acl = vfile
  quota = maildir:User quota
# Die Ordner Trash und Sent erhalten +10% auf die Quota
  quota_rule = Trash:storage=+10%%
  quota_rule = Sent:storage=+10%%
# Eigene Sieve Filter liegen im Heimverzeichnis
  sieve = ~/sieve/dovecot.sieve
  sieve_dir = ~/sieve
# Der globale Filter außerhalb
  sieve_before = /var/vmail/before.sieve
  sieve_max_script_size = 1M
  sieve_quota_max_scripts = 0
  sieve_quota_max_storage = 0
# Auch dann weitermachen, wenn die Quota nicht ermittelt werden kann
# Gilt für den von Dovecot bereitgestellten Postfix policy service
  quota_status_success = DUNNO
  quota_status_nouser = DUNNO
  quota_status_overquota = "552 5.2.2 Mailbox is over quota"
}
service quota-status {
  executable = quota-status -p postfix
  unix_listener /var/spool/postfix/private/quota-status {
   group = postfix
   mode = 0660
   user = postfix
  }
  client_limit = 1
}
Neben mail.domain.tld bitte auch beide Postmaster-Adressen anpassen.

Wie auch Postfix, erhält Dovecot Anweisungen, wie es auf die MySQL-Datenbank zugreifen kann und an welcher Stelle es die notwendigen Daten erhällt.

nano /etc/dovecot/dovecot-mysql.conf
driver = mysql
connect = "host=localhost dbname=vimbadmin user=vimbadmin password=changeme"
default_pass_scheme = SHA512-CRYPT
password_query = SELECT username as user, password as password, \
        homedir AS home, \
        maildir AS mail, uid, gid, \
        concat('*:bytes=', quota) as quota_rule \
        FROM mailbox WHERE username = '%Lu' AND active = '1' \
        AND ( access_restriction = 'ALL' OR LOCATE( '%Us', access_restriction ) > 0 )
user_query = SELECT homedir AS home, \
        maildir AS mail, uid, gid, \
        concat('*:bytes=', quota) as quota_rule \
        FROM mailbox WHERE username = '%u'
iterate_query = SELECT username FROM mailbox;
changeme bitte durch das MySQL-Kennwort des Benutzer vimbadmin ersetzen.

Die Datei wird wieder vor unbefugtem Zugriff geschützt:

chown root:vmail /etc/dovecot/dovecot-mysql.conf
chmod 640 /etc/dovecot/dovecot-mysql.conf

Die weiteren Konfigurationsdateien innerhalb des Dovecot-Verzeichnisses werden nicht gelesen, können jedoch bestehen bleiben. Ein Löschen lohnt sich nicht, da sie durch “dpkg” bei einem Upgrade neu erstellt würden.

Dovecot wird angewiesen, einen Benutzer “vmail” mit der UID und GID 5000 zu verwenden. Dieser Benutzer muss noch angelegt werden, ebenso das Heimverzeichnis:

groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /var/vmail
mkdir /var/vmail
chown -R vmail: /var/vmail/

Eine Datei “/var/vmail/before.sieve” existiert als globales Sieve-Script, das erstellt werden kann, aber nicht muss.
Häufig wird solch ein Script verwendet, um als Spam markierte Nachrichten in den dafür vorgesehenen Ordner “Junk” zu verschieben, etwa:

require "fileinto";
if header :contains "X-Spam-Flag" "YES" {
  fileinto "Junk";
}

Von Benutzern durch einen Client erzeugte Scripts sind sofort lauffähig. Unser globales Script muss jedoch zur Ausführung kompiliert und berechtigt werden:

# sievec erstellt eine neue Datei before.svbin
sievec /var/vmail/before.sieve
# Beide Dateien möchten wir vmail zuweisen
chown vmail: /var/vmail/before.*

3.3 Content-Filter

Die Abhängigkeiten zu Beginn. Dieses mal mit etwas Abwechslung: Das “non-free” Repository muss aktiviert werden, um auch Anhänge filtern zu können, die mit dem unfreien Werkzeug “rar” gepackt wurden.

apt-get install zip rar unrar unzip p7zip-full amavisd-new clamav-daemon spamassassin

Ich starte mit der Anpassung des Amavis Filters.
Änderungen in der Datei /etc/amavis/conf.d/50-user überschreiben vorhandene Parameter, daher bitte nur in dieser Datei arbeiten.

nano /etc/amavis/conf.d/50-user

Der nächste Abschnitt dient als Vorlage einer gesamten Datei 50-user.

Bitte die Vorlage gründlich durchlesen und ergänzen/anpassen
use strict;

# Maximale Anzahl an Prozessen, die Amavis vorhält.
# Siehe auch Anmerkung in master.cf im Listener für Reinjection
$max_servers = 5;

# Amavis wird mitgeteilt, wie auf die MySQL-Datenbank zugegriffen werden kann.
# "changeme" bitte anpassen
@lookup_sql_dsn = (
    ['DBI:mysql:database=vimbadmin;host=127.0.0.1;port=3306',
     'vimbadmin',
     'changeme']);

# Hierdurch ermittelt Amavis die lokalen Domänen
$sql_select_policy = 'SELECT domain FROM domain WHERE CONCAT("@",domain) IN (%k)';

# Ein Listener für die Herkunft "external" sowie "submission"
$inet_socket_port = [10024,10025];

# Mails werden auf Port 10035 zurückgeführt
$forward_method = 'smtp:[127.0.0.1]:10035';
$notify_method  = 'smtp:[127.0.0.1]:10035';

# Listener :10025 bekommt eine eigene Policy
$interface_policy{'10025'} = 'SUBMISSION';

$policy_bank{'SUBMISSION'} = {
        # Diese Mails kommen von einem vertrauten System
        originating => 1,
        # 7-bit Kodierung erzwingen, damit ein späteres Kodieren die DKIM-Signatur nicht zerstört
        smtpd_discard_ehlo_keywords => ['8BITMIME'],
        # Viren auch von auth. Sendern ablehnen
        final_virus_destiny => D_REJECT,
        final_bad_header_destiny => D_PASS,
        final_spam_destiny => D_PASS,
        terminate_dsn_on_notify_success => 0,
        warnbadhsender => 1,
};

# "mail.domain.tld" bitte anpassen
$myhostname = "mail.domain.tld";

# Wer wird über Viren, Spam und "bad header mails" informiert?
# Den Benutzer "postmaster" bitte nachträglich in ViMbAdmin erstellen (Alias möglich)
$virus_admin = "postmaster\@$mydomain";
$spam_admin = "postmaster\@$mydomain";
$banned_quarantine_to = "postmaster\@$mydomain";
$bad_header_quarantine_to = "postmaster\@$mydomain";

# DKIM kann verifiziert werden.
$enable_dkim_verification = 1;

# AR-Header darf gesetzt werden
$allowed_added_header_fields{lc('Authentication-Results')} = 1;

# DKIM-Signatur
# Gilt nur, wenn "originating = 1", ergo für die SUBMISSION policy bank
# "default" ist hierbei der Selector
# "domain.tld" als Domäne bitte anpassen
# "enable_dkim_signing" nur "1" setzen, wenn Mails wirklich signiert werden sollen.
# "/var/lib/amavis/db/dkim_domain.tld.key" sollte ebenso dem Namen der Domäne angepasst werden.
# Die TTL beträgt im Beispiel 7 Tage
# relaxed/relaxed beschreibt die Header/Body canonicalization, relaxed ist weniger restriktiv

$enable_dkim_signing = 1;
dkim_key('domain.tld', 'default', '/var/lib/amavis/db/dkim_domain.tld.key');
@dkim_signature_options_bysender_maps = (
    { '.' =>
        {
                ttl => 7*24*3600,
                c => 'relaxed/relaxed'
        }
    }
);

# Viren- und Spamfilter ACL; werden automatisch ermittelt
@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);

@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

#------------ Do not modify anything below this line -------------
1;  # ensure a defined return

Der private Schlüssel für die DKIM-Signatur wird nun erstellt. Ein sicherer Schlüssel ist 2048 Bits lang:
Schon in der Amavis-Konfiguration sollte der Name des Schlüssels /var/lib/amavis/db/dkim_domain.tld.key angepasst worden sein.
Für diesen Artikel behalte ich den Namen bei.

amavisd-new genrsa /var/lib/amavis/db/dkim_domain.tld.key 2048

Nachdem der Schlüssel geschrieben wurde, kann der notwendige Parameter für die DNS-Zone ausgelesen werden:

amavisd-new showkey domain.tld

Die Ausgabe sollte dem DNS-Server zugeführt werden.
Bevor der DNS-Server nicht angepasst wurde, sollten DKIM-Signaturen gemieden werden.
Zwar würden signierte Nachrichten nicht abgelehnt werden. Dennoch sollte sich an die Spielregeln gehalten werden.
Generell ist die Notwendigkeit von SPF- und DKIM-Records umstritten. Administratoren tendieren dazu, das Vorhandensein positiv anzurechnen, etwa wenige (Zehntel)punkte im Spamfilter abzuziehen. Aber die wenigsten Systeme strafen ein Fehlen ab. Selbst fehlerhafte Records unterbinden selten die Annahme jener Nachrichten. Das hat durchaus seine Gründe, etwa ist ein SPF-Record das Sorgenkind des Forwardings. Aber auch da steht die Methode des Forwardings im Vordergrund und begründet die nächste Diskussion…

Ein System, das zu restriktiv filtert, möchte keiner gerne verwenden. So sehr sich der Administrator auch wehrt, wird er sich dem Druck der Anwender beugen müssen.

Um Amavis die Verwendung des Virenscanners ClamAV zu gestatten, bedarf es letzten Anpassungen:

# User clamav der Gruppe amavis hinzufügen
adduser clamav amavis
# Gestatte Gruppen, denen clamav zugehört, das Scannen
sed -i 's/AllowSupplementaryGroups false/AllowSupplementaryGroups true/g' /etc/clamav/clamd.conf

4. Dienste neustarten

Spätestens jetzt sollten wir alle Dienste einmal neustarten.

systemctl restart {dovecot,postfix,amavis,spamassassin,clamav-daemon,nginx,php5-fpm,mysql}

Bewundert nun euer Werk unter den Adressen https://mail.domain.tld/webmail und https://mail.domain.tld/admin!

Gebt nicht auf, wenn es mal klemmt. Wenn ihr auf Probleme stößt, können wir uns austauschen und den Fehler finden.
Natürlich setzt der Artikel einiges an Verständnis voraus, aber irgendwo hat jeder mal angefangen.

Arch Linux mit LUKS Verschlüsselung auf UEFI System installieren

Permalink thomas-leister.de

Gestern habe ich die Arch Linux Installation auf meinem Asus UX31a Ultrabook erneuert. Eine Schwierigkeit bei dem Ultrabook ist dabei das UEFI System. Mein vorheriges Arch Linux Setup auf dem Gerät war ziemlich kompliziert (wie sich herausgestellt hat: unnötig kompliziert), aber inzwischen habe ich einfachere Wege gefunden, die ich mit diesem Beitrag mit euch teilen will. Das UEFI Setup ist gar nicht mehr so schwierig, wenn man die richtige herangehensweise gefunden hat. Statt 4 Partitionen werden nur noch 2 benötigt und das Setup ist wesentlich kompakter. Der Großteil des Betriebssytems (alles außer /boot) wird via LUKS verschlüsselt auf der SSD abgelegt.

Zuerst sollte man die Festspeichereinteilung verinnerlichen. Die SSD wird in zwei Partitionen geteilt. Die erste Partition (EFI System Partition – ESP) wird vom UEFI benutzt und muss zwingend angelegt werden. Sie wird als FAT32-Dateisystem formatiert und als ESP markiert. Außerdem werden auf der ESP der EFI Bootmanager und der Linux Kernel mit allen relevanten Boot-Dateien abgelegt. Die zweite Partition ist unsere Nutzdatenpartition. Sie wird mit LUKS verschlüsselt und enthält einen LVM-Container, der wiederum eine virtuelle Root-Partition und eine SWAP-Partition für den Auslagerungsspeicher enthält. Während des Bootvorgangs wird die verschlüsselte LUKS-Partition mit einer Passphrase entschlüsselt.

Arch Verschlüsselt

Für den UEFI-Start soll der UEFI-Bootmanager „Gummiboot” genutzt werden. Er liegt auf der ESP und wird beim Start von der Firmware des Mainboard aufgerufen. Gummiboot wiederum gibt dem Mainboard die Anweisung, den Linux Kernel direkt via EFISTUB zu starten. Theoretisch könnte man bei einer ausgereiften UEFI Firmware auf dem Mainboard auch auf Gummiboot verzichten und den Linux Kernel direkt via EFISTUB starten, doch das ist nicht auf allen System ohne Hindernisse machbar: Viele Manboards implementieren UEFI nur teilweise und sind in den Konfigurationsmöglichkeiten deutlich eingeschränkt. In meinem Fall hätte ich keine Möglichkeit, dem Kernel zusätzliche Bootparameter zu übergeben, weil die UEFI Firmware meines Asus UX31a das nicht vorsieht. Man kann nur sehr, sehr grundlegende Starteinträge in der UEFI Oberfläche anlegen. Wenn der EFI-Manager der Mainboard-Firmware nichts taugt, nutzt man eben einen externen Bootmanager, der die Starteinträge verwaltet. In diesem Fall Gummiboot. Es ermöglicht und eine sehr einfache Konfiguration, die Nutzung von Startparametern beim Linux Boot und beschleunigt des Booten im Vergleich zur Nutzung eines Bootloaders wie z.B. GRUB deutlich.

Beim Start passiert also folgendes: Das UEFI sucht in der ESP nach einer ausführbaren Startdatei, findet Gummiboot, erhält von Gummiboot die Anweisung, den Linux-Kernel mit bestimmten Parametern zu starten und führt diese Anweisung dann aus. Und schon startet Linux wie gewohnt.

Arch Linux Image herunterladen und auf USB Stick kopieren

Ladet euch das aktuelle Arch ISO auf der Downloadseite herunter und kopiert es mit folgendem Befehl auf einen freien USB-Stick:

sudo dd if=arch-linux-2015-05-22.iso of=/dev/sdb

Bei „if” wird der Pfad zum ISO angegeben, bei „of” der Pfad zur Gerätedatei eures USB-Sticks. Wie die passende Gerätedatei heißt, könnt ihr über über den Befehl „lsblk” erfahren. Vorsicht: Stellt sicher, dass ihr tatsächlich das richtige Gerät beschreibt, und nicht eure interne Festplatte!

Startet den Rechner, auf dem ihr Arch Linux installieren wollt, in die UEFI Oberfläche und stellt sie so ein, dass vom eingesteckten USB-Stick gebootet wird. Wenn ich schon mal im UEFI Management seid: Schaltet „Secure Boot” aus. Bleibt es aktiv, startet Linux nicht. Beim nächsten Neustart sollte Arch Linux booten und ihr seht die Rootkonsole vor euch.

Bevor es losgeht …

… müssen noch ein paar Dinge eingerichtet werden. Zuerst wird das Tastaturlayout auf Deutsch umgestellt:

loadkeys de-latin1-nodeadkeys

Bei der Eingabe des Befehls ist zunächst noch das englische Tastaturlayout aktiv. „z” und „y” sind also vertauscht. Den Bindestrich erzeugt ihr mit einem Druck auf die „ß” Taste.

Damit wir später LUKS nutzen können, welches dm-crypt nutzt, muss noch ein Modul in den Kernel geladen werden:

modprobe dm-crypt

Als nächstes ist die Internetverbindung dran, denn sie ist für die Installation unverzichtbar. Falls ihr eine LAN-Verbindung nutzen wollt, steckt das Kabel an und lest den Schnittstellenbezeichner für euren Netzwerkadapter aus:

ip link

Bei mir trägt die Schnittstelle beispielsweise den Bezeichner eth8s0. Holt euch dann vom Router eine IP-Adresse:

dhcpcd eth8s0

Mit einem „ping 8.8.8.8″ könnt ihr eure Verbindung überprüfen.

Wer lieber eine WLAN-Verbindung nutzt, kann seine Verbindung über das Kommando

wifi-menu

herstellen. Dabei wird das passende Netzwerk ausgesucht, die Passphrase eingegeben und dann bestätigt. Die Verbindung wird automatisch hergestellt. Auch das lässt sich mit „ping 8.8.8.8″ überprüfen.

Partitionierung

In meinem Fall ist /dev/sda die intern verbaute SSD des Rechners. Welchen Bezeichner euer Festspeicher hat, könnt über „lsblk” erfahren. In den meisten Fällen ist es /dev/sda.

Für die Partitionierung nutzen wir das Tool gdisk, welches die GPT-Version von fdisk ist. UEFI benötigt nämlich eine GPT (GUID Partition Table).

gdisk /dev/sda
  • Alle Partitionen auf der Festplatte werden gelöscht: „o”
  • Neue Partition anlegen: „n”
  • Als erste Partition festlegen: „1”
  • Ersten Sektor auf 2048 setzen: [ENTER]
  • Letzten Sektor setzen / auf 512 MB Partitionsgröße setzen: „+512M”
  • „ef00″ als Partitionstyp wählen: „ef00″

Es folgt die Hauptpartition für die Nutzdaten:

  • Neue Partition anlegen: „n”
  • Als zweite Partition festlegen: „2”
  • Ersten Sektor wählen: [ENTER]
  • Letzten Sektor wählen: [ENTER]
  • Partitionstyp wählen: [ENTER]

Mit „w” werden die Änderungen auf die SSD geschrieben. Der Vorgang muss mit „Y” bestätigt werden.

LUKS Verschlüsselung einrichten

Die zweite, größere Partition (/dev/sda2) wird nun mit LUKS verschlüsselt. Dazu können verschiedene Algorithmen und Schlüssellängen gewählt werden. Welche Algorithmen auf dem System am schnellsten funktionieren, kann man mit einem Benchmark ermitteln:

cryptsetup benchmark

Ich habe mich für AES-XTS-PLAIN mit 512 Bit entschieden. Das reicht locker aus. Verschlüsselung von /dev/sda2:

cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2
  • „YES” eingeben
  • Gewünschte Passphrase zur Verschlüsselung eingeben
  • Passphrase wiederholen

Die Partition ist nun verschlüsselt.

LVM Container anlegen

Um nun LVM mit den virtuellen Partitionen dort ablegen zu können, muss sie entschlüsselt und als Gerät gemountet werden:

cryptsetup luksOpen /dev/sda2 lvm

(Passphrase eingeben)

In den nächsten Schritten wird ein LVM Container „main” erstellt und dahin die beiden virtuellen Partitionen „root” und „swap”:

LVM für die verschlüsselte Partition aktivieren:

pvcreate /dev/mapper/lvm

Neue Volume Group „main” erstellen:

vgcreate main /dev/mapper/lvm

Die Größe der SWAP-Partition sollte sich nach der Größe des RAMs richten. Mein Ultrabook hat 4 GB Ram, also muss auch meine SWAP-Partition 4 GB groß sein, wenn ich „Suspend to Disk” nutzen will. SWAP-Partition erstellen:

lvcreate -L 4G -n swap main

Der übrige Platz soll von der virtuellen root-Partition genutzt werden:

lvcreate -l 100%FREE -n root main

Nun müssen die neuen, virtuellen LVM Partitionen „root” und „swap” mit Dateisystemen beschrieben werden. Swap bekommt das SWAP-Dateisystem:

mkswap /dev/mapper/main-swap

… und „root” das Standard-EXT4 Dateisystem:

mkfs.ext4 /dev/mapper/main-root

Partitionen einbinden

Alle vorhandenen Partitionen werden jetzt an der richtigen Stelle eingebunden:

Root Partition:

mount /dev/mapper/main-root /mnt

ESP:

mkdir /mnt/boot
mount /dev/sda1 /mnt/boot

SWAP wird eingeschaltet:

swapon /dev/mapper/main-swap

Basissystem installieren

Pacman konfigurieren

Der Paketmanager Pacman kommt mit einer langen Liste an verfügbaren Mirror-Servern für die Arch Repositories. Die Liste sollte auf Server in der Nähe bzw. innerhalb des Landes reduziert werden, in dem man sich befindet. In meinem Fall also Server mit dem Standort Deutschland. Von der Liste der verfügbaren Server wird eine Kopie angelegt und die Liste dann bearbeitet:

cp /etc/pacman.d/mirrorlist /etc/pacman/mirrorlist.bak
nano /etc/pacman.d/mirrorlist

Je niedriger der „score”, desto besser ist der Server erreichbar. Ganze Zeilen lassen sich im nano-Editor mit STRG + K löschen. 3 Server in der Liste sollten ausreichen. Speichert die Datei nach euren Änderungen ab.

Basissystem mit Pacman installieren

Nun wird die Arch Linux Basis installiert:

pacstrap /mnt/ base base-devel

Wer eine WLAN-verbindung am Rechner nutzt, sollte neben „base” und „base-devel” auch „wpa_supplicant” und „dialog” installieren, sodass das neu installierte System direkt eine Internetverbindung für weitere Paketinstallationen herstellen kann. Der Installationsvorgang kann je nach Internetverbindung und Leistung des Rechners einige Minuten dauern.

Nach der Installation wird die wichtige Datei „etc/fstab” erzeugt. In ihr wird festgelegt, welche Partitionen mit welchen Optionen beim Linux Start zu mounten sind:

genfstab -p /mnt > /mnt/etc/fstab

Wenn der Vorgang erfolgreich war, sollten in der Datei /mnt/etc/fstab drei Einträge für die drei Partitionen zu sehen sein.

Arch Linux konfigurieren

Nachdem die Basis installiert wurde, geht es an die Konfiguration von Sprache, Zeitzone und vielem mehr. Dazu wird in das neue Arch System „gechrootet”:

arch-chroot /mnt/

Hostnamen setzen:

echo meinrechner > /etc/hostname

Spracheinstellung festlegen

echo LANG=de_DE.UTF-8 > /etc/locale.conf

Tastaturbelegung festlegen:

echo KEYMAP=de-latin1 > /etc/vconsole.conf

Zeitzone festlegen:

ln -s /usr/share/zoneinfo/Europe/Berlin /etc/localtime

Locale.gen konfigurieren:

nano /etc/locale.gen

Vor diesen Einträgen „#” entfernen:

#de_DE.UTF-8 UTF-8
#de_DE ISO-8859-1
#de_DE@euro ISO-8859-15

Locale generieren:

locale-gen

Root Passwort setzen:

passwd

Linux Kernel erzeugen

Damit die LUKS-Verschlüsselung beim Linux-Start erkannt und verarbeitet werden kann, müssen noch ein paar „Hooks” zur Datei „/etc/mkinitcpio.conf” hinzugefügt werden. Der Eintrag „HOOKS=” sollte so aussehen:

HOOKS="base udev autodetect modconf block keyboard keymap encrypt lvm2 filesystems fsck"

Die Reihenfolge der Module spielt eine bedeutende Rolle und sollte wie angegeben übernommen werden.

Linux Kernel erzeugen:

mkinitcpio -p linux

Gummiboot Bootmanager installieren und konfigurieren

Installation aus den Arch Repositories:

pacman -S gummiboot

Gummiboot Dateien nach /boot (ESP) installieren:

gummiboot --path=/boot install

Die Gummiboot-Konfiguration in /boot/loader/loader.conf sollte wie folgt abgeändert werden:

# timeout 0
default arch

„timeout” (hier auskommentiert) gibt die Zeit an, wie lange eine Auswahl zwischen verschiedenen Starteinträgen beim Boot möglich sein kann. Wird die Einstellung auf Null gesetzt (oder auskommentiert) wird beim rechnerstart keine Auswahl eingeblendet. Falls man trotzdem einmal einen anderen Starteintrag wählen will, oder Bootparameter ändern will, kann man das Gummiboot-Menü durch dauerhaftes Drücken der SPACE-Taste beim Start einblenden. „default” legt den Haupteintrag fest (hier „arch” genannt)

Für den „arch” Starteintrag wird eine passende Konfigurationsdatei angelegt:

nano /boot/loader/entries/arch.conf

Die Datei muss dabei denselben Namen tragen wie der Bezeichner in /boot/loader/loader.conf + Endung „.conf”. Inhalt der Datei:

title    Arch Linux
linux    /vmlinuz-linux
initrd   /initramfs-linux.img
options  cryptdevice=/dev/sda2:main root=/dev/mapper/main-root resume=/dev/mapper/main-swap lang=de locale=de_DE.UTF-8

Unter „options” werden die Standard-Bootparameter angegeben, die beim Start von Linux genutzt werden sollen. Wenn z.B. wegen eines Grafikproblems kurzfristig andere Bootparameter für den Stadt genutzt werden sollen, kann man beim Hochfahren des Rechners die Leertaste („SPACE”) drücken, den jeweiligen Eintrag auswählen und die Bootparameter temporär durch Drücken der Taste „e” ändern.

Fertig!

Die Installation und grundlegende Konfiguration von Arch Linux ist abgeschlossen. War doch gar nicht schwierig, oder? Die Chroot-Umgebung wird verlassen:

exit

… und die Partitionen ausgebunden:

umount /mnt/boot
umount /mnt

Mit einem „reboot” wird der Rechner neu gestartet. Vergesst nicht, den USB Stick zu ziehen ;)

Bei Start werdet ihr nach dem Passwort für die LUKS-Verschlüsselung gefragt. Nach der Verschlüsselung könnt ihr euch dann über den Benutzernamen „root” + selbst gewähltes Root-Passwort einloggen und alle weiteren Einrichtungsschritte in der offiziellen, deutschsprachigen Arch Linux Anleitung befolgen (weiter geht es bei „Einen Benutzer hinzufügen und Gruppen wählen”): https://wiki.archlinux.de/title/Anleitung_f%C3%BCr_Einsteiger#Einen_Benutzer_hinzuf.C3.BCgen_und_Gruppen_w.C3.A4hlen

Wenn ihr euer Passwort für LUKS ändern wollt, könnt ihr hier weiterlesen (mit /dev/sda2 statt /dev/sda3): https://thomas-leister.de/open-source/linux/arch-linux/luks-verschluesselung-passwort-aendern/

SSL-Schwachstelle bedroht Web- und Mail-Server

Permalink My-IT-Brain

Diverse Seiten im Internet berichten über eine neue SSL-Schwachstelle, die durch eine sogenannte Logjam-Attacke ausgenutzt werden kann.123

Dieser Artikel beschreibt, wie sich NGINX, Postfix und Dovecot härten lassen. Damit sind diese Dienste nicht mehr verwundbar für die aktuelle SSL-Schwachstelle.

Ich beschreibe die drei genannten Dienste, da ich diese selbst auf mehreren Ubuntu-Servern betreibe. Für weitere Dienste schaut bitte in der Quelle unter Punkt “3.” nach.

Zu Beginn wird eine Diffie-Hellman-Group für den Server generiert:

openssl dhparam -out dh_params.pem 2048

Anschließend folgt die Härtung der einzelnen Dienste.

NGINX

Im server Block der jeweiligen Webpräsenz werden die zu verwendenden “Cipher Suites” und Diffie-Hellman-Parameters angegeben:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;

ssl_dhparam /pfad/zur/dh_params.pem;

Anschließend wird der Dienst zur Übernahme der Einstellungen neu geladen:

sudo service nginx reload

Postfix

Beim MTA Postfix werden beide Parameter in der Datei /etc/postfix/main.conf eingetragen:

smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtpd_tls_dh1024_param_file = /pfad/zur/dh_params.pem

Auch hier werden die Einstellungen anschließend neu eingelesen:

sudo service postfix reload

Dovecot

Die beiden Parameter werden in die Datei /etc/dovecot/conf.d/10-ssl.conf eingetragen:

ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_prefer_server_ciphers = yes

#regenerates every week
ssl_dh_parameters_length = 2048

Und auch hier werden die Änderungen anschließend eingelesen:

sudo doveadm reload

Damit sollte man vor dieser Schwachstelle vorerst geschützt sein.

  1. Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet
  2. Tausende Web-Server betroffen: Neue HTTPS-Sicherheitslücke aufgetaucht
  3. Guide to Deploying Diffie-Hellman for TLS

Firefox 39: Mozilla stellt Suggested Tiles vor

Permalink Sören Hentzschel

Mozilla hat die Suggested Tiles angekündigt und erweitert damit die Seite, die standardmäßig beim Öffnen eines neuen leeren Tabs in Firefox erscheint, um Empfehlungen basierend auf bereits besuchten Webseiten – natürlich auf Wusch ganz einfach deaktivierbar.

Standardmäßig erscheint beim Öffnen eines neuen Tabs in Firefox eine Seite mit Vorschaubildern häufig besuchter Webseiten. Aber auch beliebige Seiten können vom Nutzer als Kachel festgelegt und angepinnt werden, so dass diese nicht überschrieben werden. Neue Nutzer, die noch keine Chronik besitzen, sehen hier die sogenannten Directory Tiles: das sind Vorschaubilder von Webseiten, die Mozilla vorschlägt, manche davon gesponsort, mehrheitlich aber Webseiten von Mozilla selbst. Mit den Suggested Tiles folgt nun die nächste Erweiterung. Basierend auf den vom Nutzer bereits besuchten Webseiten werden andere Webseiten vorgeschlagen, die den Nutzer interessieren könnten. So können beispielsweise Besucher einer Webseite über Smartphones eine Kachel angezeigt bekommen, welche auf Firefox für iOS aufmerksam macht.

Wie man es von Mozilla nicht anders erwarten würde, ist diese Neuerung optional. Um die Suggested Tiles zu deaktivieren, muss auch nicht erst in irgendwelchen Einstellungen gesucht werden oder ein Schaltername in about:config bekannt sein. Die Suggested Tiles können direkt auf der entsprechenden Seite mit nur zwei Klicks deaktiviert werden. Mit den überarbeiteten Kacheleinstellungen ist auch die Unterscheidung zwischen Klassisch und Erweitert weggefallen, was nur die allerwenigsten Nutzer verstanden haben dürften, da der Unterschied nicht offensichtlich war. Der Link zur Mozilla-Webseite, welche mehr Informationen bereithält, ist ebenfalls in das Einstellungsmenü gewandert und nicht länger permanent bei jedem Öffnen eines neuen Tabs im Blickfeld. Selbstverständlich ist es auch weiterhin möglich, einfach einen leeren Tab oder eine beliebige Webseite beim Öffnen eines neuen leeren Tabs anzuzeigen (beides wie gehabt: ersteres über die Kacheleinstellungen, letzteres über about:config, Schaltername: browser.newtab.url).

Die Suggested Tiles sind Mozillas Versuch, der Werbeindustrie zu zeigen, dass es möglich ist, relevante Empfehlungen anzuzeigen und gleichzeitig die Privatsphäre der Nutzer zu respektieren. Folgende Infografik gibt einen vereinfachten Überblick, wie das Ganze funktioniert:

Das Wichtigste aus Nutzersicht ist neben der Tatsache, dass das Feature kinderleicht deaktivierbar ist, dass zwar Metriken wie Klicks erfasst und in aggregierter Form berichtet werden, aber keinerlei persönlichen Daten gesendet werden.

Für Nutzer, welche den Do-not-Track-Header in den Privatsphäre-Einstellungen aktiviert haben, werden standardmäßig keine gesponsorten Kacheln angezeigt. Zwar kommt bei den Firefox-Kacheln sowieso keine Form von Tracking zum Einsatz, Mozilla geht aber davon aus, dass die meisten DNT Early Adopters grundsätzlich nichts dergleichen sehen wollen. Die Suggested Tiles können in dem Fall aber genauso einfach mit zwei Klicks aktiviert werden, wie sie umgekehrt deaktiviert werden können.

Die Suggested Tiles werden ab nächster Woche in der Firefox 39 Beta starten, zunächst nur für Nutzer der en-US-Version und anfangs auch nur für andere Mozilla-Seiten und noch ohne Partner-Empfehlungen. Im Laufe der Zeit wird dies dann ausgeweitet werden. Ein FAQ-Artikel beantwortet weitere Fragen aus Partnersicht zu diesem Thema.

Link zum YouTube-Video

Weitere Informationen (engl.):

21. Mai 2015

Serverzeit korrigieren bei Dovecot

Permalink Erfahrungen mit Ubuntu

Wenn man einen Mailserver betreibt ist es keine gute Idee
die Uhrzeit mit ntpdate zu korrigieren.
Der einfache Aufruf

    ntpdate ntp.ubuntu.com

korrigiert die Uhrzeit zuverlässig, setzt diese aber in einem Rutsch, ggf. auch Rückwärts. Das kann den Imap Dienst Dovecot aus dem Tritt bringen.
Im Log tauchen anschliessend folgende Fehlermeldungen auf:

    May 21 11:31:14 server1 dovecot: imap-login: Warning: Time moved backwards by 69
    seconds.
    May 21 11:31:16 server1 dovecot: imap: Fatal: Time just moved backwards by 69

    seconds. This might cause a lot of problems, so I'll just kill myself now. 
    http://wiki2.dovecot.org/TimeMovedBackwards

Die bessere Möglichkeit ist es die Uhrzeit vom ntp Dienst stellen zu lassen. Er führt
die korrekturen in kleinen Schritten durch so das laufende Programme nicht weiter behindert werden.

Installiert wird der Dienst schnell mit folgenden Aufruf:

    apt-get install ntp

Anschliessend kann man die Uhrzeit leicht mit folgenden Befehl anpassen:

    ntpd -q -g -x -n

20. Mai 2015

Firefox-Tipp: in Adressleiste nur nach bestimmter Art von Ergebnissen suchen

Permalink Sören Hentzschel

Die Adressleiste von Firefox ist ein mächtiges Werkzeug: man kann URLs zu Webseiten eingeben, Suchmaschinen durchsuchen, aber auch die Chronik oder die Lesezeichen durchsuchen. In diesem Praxisartikel gibt es Tipps, um nur nach einer bestimmten Art von Ergebnis über die Adressleiste zu suchen.

Nach dem Praxis-Tipp der vergangenen Woche zum Markieren von verlinkten Texten gibt es heute einen Tipp, um über die Adressleiste nur eine bestimmte Art von Ergebnissen zu durchsuchen. Dies kann unter anderem dann praktisch sein, wenn man weiß, dass die gesuchte Seite auf jeden Fall als Lesezeichen gesetzt ist. Dazu braucht es neben dem Suchbegriff nicht mehr als ein bestimmtes Zeichen, welches Firefox signalisiert, was man durchsuchen möchte. Diese Einschränkungen können auch beliebig miteinander kombiniert werden. Doch das ist nicht alles: jedes einzelne dieser Steuerzeichen kann über about:config konfiguriert werden, falls man lieber eine andere Belegung hätte.

Standardmäßig sind folgende Eingaben vorgesehen:

  • Alles durchsuchen, keine Einschränkung:
    Suchbegriff
  • Suchbegriff in den Lesezeichen suchen:
    Suchbegriff *
    about:config: browser.urlbar.restrict.bookmark
  • Suchbegriff in der Chronik suchen:
    Suchbegriff ^
    about:config: browser.urlbar.restrict.history
  • Suchbegriff in den geöffneten Tabs suchen:
    Suchbegriff  %
    about:config: browser.urlbar.restrict.openpage
  • Suchbegriff in den Schlagwörtern suchen:
    Suchbegriff +
    about:config: browser.urlbar.restrict.tag
  • Suchbegriff in Seiten suchen, die bereits früher eingetippt worden sind:
    Suchbegriff ~
    about:config: browser.urlbar.restrict.typed
  • Suchbegriff im Webseitentitel suchen:
    Suchbegriff #
    about:config: browser.urlbar.match.title
  • Suchbegriff in URL suchen:
    Suchbegriff @
    about:config: browser.urlbar.match.url

Beispiel für eine Kombination mehrer Einschränkungen:

  • Die gesuchte Seite ist ein Lesezeichen mit “hello” im Seitentitel oder URL, “mozilla” muss in der URL vorkommen:
    hello * mozilla @

Standard-Einschränkungen für die Adressleiste

Die gefundenen Resultate in der Adressleiste lassen sich auch standardmäßig einschränken, ohne dass ein weiteres Zeichen eingegeben werden muss. Dazu findet man in den Einstellungen im Reiter Datenschutz im Abschnitt Adressleiste drei Checkboxen: hier können Chronik, Lesezeichen sowie offene Tabs in jeder denkbaren Kombination aus- oder abgewählt werden.

Ubuntu automatisch aktualisieren mit Downloadlimit

Permalink FliegenToeter

Updates installieren ist wichtig und sollte immer schnellstmöglich erledigt werden – egal unter welchem Betriebssystem. Bei Ubuntu erhält man daher eine Benachrichtigung, wenn die Aktualisierungsverwaltung Programme gefunden hat, welche geupdated werden sollten. Das Ganze funktioniert sehr gut und normalerweise hat man die Aktualisierung auch mit ein paar Klicks erledigt. Da standardmäßig keine neuen Versionen der Programme installiert werden geht in der Regel nichts dabei schief. Mir kam dann mal der Gedanke, dass das doch bestimmt automatisch erledigt werden könnte, ganz ohne Bestätigung meinerseits.

Automatische Updates

Aktualisierung

Wie erwartet stellt das kein großes Problem dar und es gibt mehr als nur einen Ansatz es anzugehen. Die Lösung im Wiki von Ubuntuusers schien mir am naheliegensten. Nachfolgend gehe ich nur stichpunktartig auf das Vorgehen ein. Bitte einfach der Anleitung im verlinkten Wiki-Eintrag folgen.

  • Bei den Aktualisierungseinstellungen unter Sicherheitsaktualisierungen “Automatisch herunterladen und installieren”  auswählen
  • “unattended-upgrades” installieren und konfigurieren

  • “/etc/apt/apt.conf.d/50unattended-upgrades” editieren, um nicht nur Sicherheitsupdates, sondern auch normale Updates automatisch zu installieren

Wäre das erledigt, läuft die Aktualisierung ganz ohne Zustimmung oder Passworteingabe im Hintergrund ab.

Nun kommt es aber je nach System oder Nutzerverhalten auch öfter vor, dass die Updates schon mal größer ausfallen und der Download die Internetleitung lange Zeit aus-lastet. Gerade bei einer langsamen Internetverbindung ist das ein Knackpunkt. Deswegen habe ich die Downloadgeschwindigkeit für “apt-get” auf 25KB/s begrenzt.

Downloadlimit

Download Limit

Hier fand ich einen Vorschlag, wie man “apt-get” und damit auch die Updates im Download beschränken kann.

Dazu erstellt man die Datei “/etc/apt/apt.conf.d/76download

sudo nano /etc/apt/apt.conf.d/76download

und kopiert diesen Inhalt hinein:

Acquire
{
Queue-mode "access";
http
{
Dl-Limit "25";
};
};

Damit limitiert man aber nicht nur die Downloadgeschwindigkeit bei Updates, sondern auch die bei der Installation eines Programms im Terminal mittels:

sudo apt-get install PROGRAMM

Um die Sperre von 25KB/s hier zu umgehen und das gewünschte Programm z.B. mit 500KB/s zu installieren, nutzt man folgenden Befehl:

sudo apt-get -o Acquire::http::Dl-Limit=500 install PROGRAMM

Alias zum schnellen Installieren

Wie in den Kommentaren angemerkt, ist es nicht gerade einfach, sich den langen Installations-befehl ohne das 25KB/s Limit zu merken. Dafür kann man sich aber einfach ein Alias anlegen. Im Ubuntuusers Wiki ist auch das schön beschrieben.

Hier nehme ich mal “fastinstall” als Alias für “sudo apt-get -o Acquire::http::Dl-Limit=500 install“. Dafür einfach die .bashrc bearbeiten – folgendes im Terminal eingeben:

sudo nano .bashrc

und unter

# Alias definitions.

folgende Zeile eintragen und speichern.

alias fastinstall='sudo apt-get -o Acquire::http::Dl-Limit=500 install'

Nach einem

source ~/.bashrc

kann man Programme mit dem Befehl

fastinstall PROGRAMM

bequem mit 500KB/s installieren. Das Limit selbst kann jeder natürlich setzen wie er will.

Fazit

Damit sollten nun alle Updates installiert werden, ohne dass man als Nutzer etwas davon mitbekommt. Es werden keine Bestätigungen mehr benötigt und die Internetnutzung wird auch nicht von großen Aktualisierungen eingeschränkt.

– zumindest bis vielleicht doch mal etwas kaputt geht :P

Mails aus der Kommandozeile

Permalink Andre's Webblog

E-Mails sind bei vielen täglich das erste was morgens bei der Arbeit überprüft wird. Warum also sollte man sich nicht Status E-Mails zusenden lassen. Dies kann einem evtl. helfen schneller auf bestimmte Probleme zu reagieren. Wer aus einem Skript oder direkt von das Kommandozeile eine E-Mail versenden möchte und keinen eigenen Mailserver betriebt, kann dies mit Hilfe von ssmtp und mailutils realisieren. Dies benutze ich z.B. um mir von meinem Computer den Status und die Logdatei des letzten Backups zu kommen zu lassen. Voraussetzung ist ein E-Mailkonto bei einem Anbieter (Google, GMX o.ä.) oder einen eigenen SMTP-Relay-Server (Smarthost). Da wir so einen offiziellen Mailserver nutzen, sollten unsere Mails auch nicht beim Empfänger im SPAM-Ordner landen. Dies wäre unter Umständen der Fall wenn wir einen Mailserver mit dynamischer IP betreiben oder diesen falsch konfiguriert haben.

Schritt 1 Installation

Den extrem einfachen gehaltenen Mail-Transfer-Agent (MTA) ssmtp und das Mailframework mailutils installieren mit:

sudo apt-get install mailutils ssmtp

Schritt 2 Konfiguration

Jetzt müssen die Einstellungen vorgenommen werden, mit welchem Smarthost gesendet werden soll und welcher Benutzer senden darf.
Für den Smarthost muss folgende Datei angepasst werden:

sudo nano /etc/ssmtp/ssmtp.conf

Als Beispiel, zeige ich hier die Konfigurationen für GMX.de und GoogleMail. Ihr müsst diese nur noch mit euren Daten anpassen.

Beispiel GoogleMail

root=BEISPIEL@googlemail.com
mailhub=smtp.gmail.com:587
hostname=BEISPIEL@googlemail.com
UseTLS=YES
UseSTARTTLS=YES
AuthUser=BEISPIEL
AuthPass=MEINPA$$W0RT
AuthMethod=plain
FromLineOverride=YES

Beispiel GMX.de

root=BEISPIEL@gmx.de
mailhub=mail.gmx.net:587
hostname=gmx.net
UseTLS=YES
UseSTARTTLS=YES
AuthUser=BEISPIEL@gmx.de
AuthPass=MEINPA$$W0RT
AuthMethod=plain
FromLineOverride=YES

Wie Ihr seht, unterscheiden diese sich nicht sonderlich. Darum ist es auch sehr leicht dies für einen eigenen oder andern Mailserver anzupassen. Weiter Infos zu dieser Konfigurationsdatei kann auf der man page gefunden werden.

Nun muss die 2. Konfigurationsdatei angepasst werden. Hier legt Ihr fest welcher Benutzer senden darf.

sudo nano /etc/ssmtp/revaliases

Beispiel wäre:

root:BEISPIEL@googlemail.com:smtp.gmail.com:587
BENUTZER1:BEISPIEL@googlemail.com:smtp.gmail.com:587
BENUTZER2:BEISPIEL@gmx.net:mail.gmx.net:587

Bzw. müssen die Daten dann für einen andern Smarthost angepasst werden.

Schritt 3 Testen

Jetzt könnt ihr endlich die erste Testmail von der Kommandozeile senden.
Gebt dazu folgenden Text ein:

echo "Hallo dies ist ein Test" | mail empfaenger@beispiel.de -s "MeinBetreff"

Um einen Anhang mitzusenden muss der Parameter -A mitangeben werden:

echo "Hallo dies ist ein Test mit Anhang" | mail empfaenger@beispiel.de -s "MeinBetreff" -A "/tmp/beispiel.txt"

Wer Probleme hat, bzw. glaubt keine E-Mails zu senden, kann sich mit folgendem Befehl:

echo "Subject:TEST" | ssmtp -v empfaenger@beispiel.de

den Verbindungsablauf ins Terminal holen. So gibt es bei Problemen nützliche hinweise auf z.B. falsche Port und Adressen Einstellungen.

Optional Schritt 4 Die Konfiguration schützen

Da die Datei /etc/ssmtp/ssmtp.conf euer Passwort im Klartext enthält, sollte diese besonders geschützt werden! Dazu empfiehlt es sich eine eigene Gruppe für den MTA ssmtp anzulegen, dass nur dieser und ROOT die Datei lesen darf.
Folgende Schritte sind hierzu notwendig:

su
groupadd ssmtp
chown :ssmtp /etc/ssmtp/ssmtp.conf
chown :ssmtp /usr/sbin/ssmtp
chmod 640 /etc/ssmtp/ssmtp.conf 
chmod g+s /usr/sbin/ssmtp 
exit

Ein Dank geht hierfür an den Arch Linux Wiki Artikel. Ohne diese Absicherung wäre mit diese Methode auch zu unsicher gewesen.
Die Rechte können abschließend mit ls -l überprüft werden und sollten jetzt wie folgt gesetzt sein:

ls -l /etc/ssmtp/ssmtp.conf 
-rw-r----- 1 root ssmtp 761 Mai 20 17:31 /etc/ssmtp/ssmtp.conf

 

Jetzt solltet Ihr auch in der Lage sein, einen Status aus z.B. einem Backupskript per Mail zu versenden.
Dies könnte folgendermaßen aussehen:

#!/bin/bash
RECP="empfaenger@beispiel.de"      # E-Mail Empänger des Statusbericht
SOURCE=$HOME                       # Backup Quelle
BACKUPDIR=/mnt/usb1/backup         # Backup Ziel
DATE=$(date +%d.%m.%Y" "%H:%M)     # Datums & Uhrzeit
#
tar -cpf ${BACKUPDIR} ${SOURCE}    # Backup starten
#
if [ $? -ne 0 ]; then              # Überprüfen ob der letzter Befehl erfolgreich war
mail $RECP -s "Backup war fehlerhaft!" <<EOM
Das Backup wurde mit Fehler(n) beendet.
Start: ${DATE}
Ende: `date +%d.%m.%Y" "%H:%M`
Bitte das letzte Backup überprüfen und ggf. wiederholen.
EOM
else
mail $RECP -s "Backup war erfolgreich" <<EOM
Das Backup wurde erfolgreich in ${BACKUPDIR} erstellt.
Start: ${DATE}
Ende: `date +%d.%m.%Y" "%H:%M`
EOM
fi
#EOF

Natürlich ist dies nur ein sehr einfaches Beispiel und dient nicht zum Sicher irgendwelcher Daten. Möglichkeiten so Mails zu versenden gibt es viele, mit etwas Kreativität können auch sinnvollere Skripte zu Stande kommen.

ENDE :)

19. Mai 2015

Mozilla veröffentlicht Thunderbird 31.7

Permalink Sören Hentzschel

Während Thunderbird 38 noch ein paar Tage auf sich warten lässt, hat Mozilla Thunderbird 31.7 veröffentlicht und behebt damit mehrere Sicherheitslücken.

Download Mozilla Thunderbird 31.7 für Windows, OS X und Linux

Thunderbird 38 ist nicht zeitgleich mit Firefox 38 erschienen, sondern wird sich etwas verzögern. Dennoch bekommen Thunderbird-Nutzer etwas zum Aktualisieren, nämlich Thunderbird 31.7. Die neue Version behebt sechs Sicherheitslücken, von denen vier als besonders kritisch eingestuft werden.

18. Mai 2015

Linux?

Permalink Intux

Vor mittlerweile sechs Jahren habe ich mich entschieden mein Betriebssystem zu wechseln. Ein Kollege zeigte mir damals Ubuntu (Danke Eckhard!). Das war der eigentliche Startschuss es mit Linux ohne ein weiteres OS nebenher zu versuchen.

Wobei Linux der Kernel ist. Das eigentliche Betriebssystem drum herum ist die Distribution, die sich wiederum in Derivate aufteilen kann. Das klingt für den Anfänger bzw. Umsteiger sehr verwirrend.

Warum gibt es also so viele “Linux-Versionen”?

Weil die entsprechenden Entwickler das perfekte Betriebssystem jedem einzelnen Endanwender mit unterschiedlichsten Anforderungen zur Verfügung stellen wollen.

Wenn man sich nun als künftiger  Umsteiger mit dieser Materie im Vorfeld beschäftigt, stellt man sich die Frage:

Welche Distribution ist für mich die Richtige?

Die Antwort hierauf ist sicherlich nicht ganz einfach.

Zur Entscheidungsfindung kann hier der Distrochooser von Christoph Müller sehr hilfreich sein.

dc

Also viel Erfolg beim Um- bzw. Einstieg in die wunderbare Linux-Welt!

Linux: Dateien die älter als x Tage sind, finden und löschen

Permalink Pirates Of Art

Heute mal ein Kurztipp für Euch.
 
Ab und an läuft einem zum Beispiel eine Platte voll und man muss kurzfristig Platz schaffen um den Betrieb aufrecht zu erhalten, oder man möchte einfach alte Datein löschen.
 
Dies geht über die Linux-Konsole recht einfach.


Mit dem Befehl find, könnt Ihr Euch erstmal die Dateien anzeigen lassen, die betroffen sind:
find /zielverzeichnis -type f -mtime +5 | xargs ls -l
 
Habt Ihr die Ausgabe überprüft, könnt Ihr die Dateien anschließend wie folgt löschen:
find /zielverzeichnis -type f -mtime +5 | xargs rm
 
Achtung: Diese Dateien können nicht wiederhergestellt werden. Löscht diese nur, wenn Ihr Euch sicher seid.
 
Syntax des Befehles:
find – Das Programm das wir für die Suche einsetzen
/zielverzeichnis – Das Verzeichnis, in dem Ihr suchen wollt.
-type f – Beschränkt die Suche auf Dateien
-mtime +5 – Die Zeitangabe in Tagen (älter als)
| – leitet die Ausgabe des vorherigen Befehles an den nächsten Befehl weiter
xargs – Führt den folgenden Befehl aus
ls -l – Auflistung der Datein
rm – Löschen der Dateien
 
 
Fazit:
Dieser Befehl lässt sich natürliche wie immer weiter ausbauen und verfeinern. Hier steht einem aber eine einfache Methode zur Verfügung um zügig alte Dateien zu löschen.
 
 
Alles klar an Deck …
Euer RSB