In der Regel hebe ich meine Datenbanksicherungen ca. einen Monat auf. Hierzu habe ich diese meist in meinem in der Nextcloud angeschlossenen Storage gelöscht. Da i.d.R. einige Datenbanken zu sichern sind, nahm das Ganze immer etwas Zeit in Anspruch. Nun habe ich mich damit beschäftigt, wie ich das automatisieren kann. Dies zeige ich nun am Beispiel meiner Datenbank zu meinem Blog.
Zuerst wird über
1
crontab-e
ein Cronjob angelegt. Hierbei wird die Löschung überflüssiger Dateien jeden Tag um 3:00 Uhr morgens angestoßen.
1
*3***/home/intux/clean.sh
Nun benötigt man ein Script in dem der Befehl zum Löschen überflüssiger Dateien (älter als 30 Tage) eingegeben wird. Diese Datei kann natürlich bei mehreren Datenbanken beliebig erweitert werden.
Nachdem auf meinem neuen vServer ein Webserver und ein Mailserver installiert und eingerichtet waren, tauchte ein neues Problem auf. Meine Webseiten und meine Nextcloud konnten via PHP keine Mails mehr absetzen. Die Ursache hierfür liegt auch dieses Mal in der Konstellation meines Servers mit der installierten Container-Lösung Mailcow Dockerized, wo Postfix im Container seinen Dienst verrichtet und von dem Apache so nicht angesprochen werden konnte.
Was kann man tun?
Am einfachsten ist es in WordPress, Joomla! und der Nextcloud den Mailversand via SMTP einzurichten. Genau das hatte ich auch zur schnellen Lösung umgesetzt. Leider funktionierte das Ganze nicht wirklich mit Elgg.
Wie löst man das Problem zufriedenstellend?
Ganz einfach, indem man ein Mail Relay einbaut. Dazu wird ein lokaler MTA für den Docker Host eingerichtet. Das klingt aber alles komplizierter als es tatsächlich ist.
Dazu habe ich Postfix installiert.
1
# apt install postfix
Postfix Konfiguration
Postfix Konfiguration – Internet SitePostfix Konfiguration – System mail namePostfix Konfiguration – System mail name – intux
Während der Installation wird man nach dem System mail name gefragt. Hier wurde der Hostname des Servers (intux) eingetragen.
Vorsicht: Nicht die Domain eingeben!
Nach Abschluss der Installation, musste noch die /etc/postfix/master.cf geändert werden. Dazu wurde der SMTP Listener mit # auskommentiert.
1
# nano /etc/postfix/master.cf
1
#smtp inet n - y - - smtpd
Danach musste noch 172.22.1.1 als Relay Host hinzu gefügt und das Docker Interface aus inet_interfaces entfernt werden.
Mit dem Aufsetzen eines neuen Servers auf Basis von Debian 9 kamen wieder einige neue Dinge auf mich zu. Da ich mich für die Mailserver-Groupware Mailcow-Dockerized von André Peters entschieden hatte, musste ich mich erstmals mit einem Reverse Proxy auseinander setzten.
Wozu brauche ich einen Reverse Proxy?
Auf dem neuen Server sollte neben dem Webserver ein Mailserver installiert werden. Da Mailcow-Dockerized eine Container-Lösung ist und in diesem Container neben Postfix, Dovecot und Co. auch der Webserver Nginx läuft, würden aber die Ports 443 und 80 mit dem zuvor installierten Apache, auf dem eine Test-Webseite aktiv ist, kollidieren.
Mailcow UI
Um Mailcow zu installieren, musste zuerst der Apache gestoppt werden. Der Mailserver wurde dann in ein paar Minuten aufgesetzt und eingerichtet. Das Mailcow UI konnte wie gewünscht via HTTP und HTTPS erreicht werden. Im Anschluss wurde die Konfiguration nochmals geöffnet, um die Bindung an die Ports 80 und 443 entsprechend in 8080 und 8443 in der /root/mailcow.dockerized/mailcow.conf zu ändern.
1
2
3
4
5
HTTP_PORT=8080
HTTP_BIND=127.0.0.1
HTTPS_PORT=8443
HTTPS_BIND=127.0.0.1
Natürlich hätte man das auch während der Installation durchführen können, jedoch wollte ich zuvor die testen, ob der Mailserver ordnungsgemäß läuft.
Nach dem nochmaligen Durchlauf der Konfigurationsänderungen, konnte nun das Mailcow UI natürlich von außen nicht mehr aufgerufen werden.
Nun wurde der Apache wieder gestartet und die Test-Websites ging wieder online.
Erstellen eines neuen Virtual Host
Um nun auch den Nginx in Mailcow-Dockerized zu erreichen, musste ein Reverse Proxy eingerichtet werden. Dazu habe ich einen Virtual Host, welcher auf Port 80 und Port 443 lauscht, in einer neu erstellten /etc/apache2/sites-available/proxy.conf mit folgendem Inhalt eingerichtet. Dieser leitet die Anfragen von mail.domain.tld an den Nginx im Container weiter. Das hatte zur Folge, dass die alten Zertifikate aus Mailcow-Dockerized unbrauchbar wurden. Ich habe darauf hin mein bestehendes Zertifikat um die Subdomain https://mail.domain.tld erweitert. Der Ort, wo die Zertifikate hinterlegt sind, musste im Codeblock (siehe unten) noch eingetragen werden.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<VirtualHost *:80>
ServerName mail.domain.tld
RewriteEngine On
RewriteRule^/?(.*)https://%{SERVER_NAME}/$1 [R,L]
ProxyPass/http://127.0.0.1:8080/
ProxyPassReverse/http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
</VirtualHost>
<VirtualHost *:443>
ServerName mail.domain.tld
ProxyPass/http://127.0.0.1:8080/
ProxyPassReverse/http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
# This header does not need to be set when using http
Zu beachten gilt, dass für die Subdomain mail.domain.tld ein separates Zertifikat erstellt werden muss, da das in Mailcow-Dockerized vorhandene nicht mehr funktioniert. Zur Erstellung eines validen SSL-Zertifikats kann man auf die Anleitung „Let’s Encrypt auf dem Raspberry Pi“ zurück greifen.
Aus IT-technischer Sicht sollte man Web- und Mailserver auf getrennten Systemen laufen lassen. Da ich aber meinen Server privat betreibe und das Ganze mehr ein Hobby ist, laufen bei mir Web- und Mailserver auf einem Host.
Übersicht der laufenden Prozesse mit htop
Angefangen hatte ich mit Debian 8 auf dem bisher meine Seite intux.de lief. Parallel dazu hatte ich einen Mailserver mit Mailcow 0.14 aufgesetzt. Beides arbeitete bisher ohne Probleme und es gab eigentlich keinerlei Bedarf hieran irgendetwas zu ändern, da Debian 8 als LTS noch bis Ende April 2020 unterstützt wird.
Da ich aber mein System auf die aktuelle Version Debian 9 Stretch anheben wollte, musste ich mir Gedanken machen, wie das am besten zu realisieren ist. Da es momentan kein Upgrade für Mailcow 0.14 gibt und diese Version nicht auf dem aktuellen Debian Stretch läuft, kam für mich nur die Container-Variante Mailcow Dockerized in Frage.
Ein Upgrade auf Debian 9 wäre natürlich möglich gewesen, jedoch habe ich mich dazu entschlossen Stretch auf einem separaten Server zu installieren und alle Dienste nacheinander rüber zu holen. Dieses Vorhaben konnte ich ohne Zeitdruck auf Servercow realisieren. Der grandiose Support von André Peters war hierbei mehr als hilfreich. Bei einigen Problemen hatte ich so einen kompetenten Ansprechpartner, der sehr schnell auf Anfragen reagierte.
Da Mailcow Dockerized autonom und aus dem System herausgelöst in einer eigenen Virtualisierung arbeitet, wär mein Apache 2 mit dem Webserver Nginx in Dockerized kollidiert. Hierzu war es notwendig einen Reverse Proxy auf dem Apache, wo mein Blog läuft, einzurichten. Des Weiteren konnten von meinem frischen System keine Mails über PHP abgesetzt werden. Auch hier musste ich mich in eine für mich neue Thematik, einen Local MTA, einarbeiten, welcher dann u.a. Systemnachrichten an Mailcow Dockerized zum Versenden übergibt.
Fazit
Den Server parallel einzurichten und alle Dienste nach und nach umzuziehen stellte sich aus der Situation als die richtige Entscheidung heraus. Ich war so nicht gezwungen alles am Stück wieder zum Laufen zu bringen. Mailcow Dockerized ist leicht zu installieren und ohne ewige Konfiguration sofort einsatzbereit. Trotz zwei nun nebeneinander arbeitender Webserver läuft das gesamte System performanter als vorher.
Ich habe mich zur Verwirklichung meiner kleinen Projekte vor fast 10 Monaten bewusst und aufgrund guter Kritiken für Servercow entschieden. Bei Problemen am Server und speziell mit Mailcow steht ein kompetenter Ansprechpartner zur Seite. Diesen Schritt habe ich zu keinem Zeitpunkt bereut. Sicher hat man mit einem eigenen Server einiges an Arbeit und Verantwortung auf dem Schirm, aber man ist dafür wesentlich flexibler. Dafür bietet Servercow ein gutes Zuhause.
Uberspace, der nerdige Hoster von Jonas Pasche aus Mainz, hat nun erstmals Uberspace 7 (U7) der Allgemeinheit vorgestellt. Nach einem Test der Closed Beta mit 50 Usern, ging nun die Public Beta an den Start. Zeit sich das Ganze mal etwas näher anzusehen. Da ich selbst eine ganze Weile meine Seite auf Uberspace betrieben habe, war die Einrichtung nicht ganz so schwer. Die neue Doku unter https://manual.uberspace.de soll dem U7-Neuling beim ersten Umgang etwas unter die Arme greifen. Leider ist die Dokumentation noch sehr übersichtlich gehalten und auch nur in englischer Sprache verfügbar. Trotz alledem sind die notwendigsten Schritte zum Aufsetzen einer eigenen Webseite auf Uberspace 7 recht gut erklärt. Anfänger, denen der Umgang mit der Shell nicht so vertraut ist, werden es jedoch auch mit U7 weiterhin recht schwer haben. Da Uberspace aus meiner Sicht hauptsächlich durch Mund-zu-Mund-Propaganda wächst, steht hier aber meist ein erfahrener Uberspace-User helfend zu Seite.
Kurz und knapp gesagt bzw. geschrieben, ist es kein Hexenwerk eine Domain aufzuschalten und eine Webseite bzw. eine eMail-Adresse in der Public Beta einzurichten. Noch fehlen zwar einige Dinge, wie Spamfilter, Webmail, phpMyAdmin, Adminer oder die Möglichkeit virtuelle Mailuser anzulegen. Dafür muss man sich aber in Zukunft keine Gedanken mehr um SSL-Zertifikate und deren Verlängerung auf dem neuen Uberspace machen. Let’s Encrypt ist Standard. Weiterhin wird von Haus aus von HTTP auf HTTPS umgeleitet. Als Datenbank-Verwaltungs-System wird nun MariaDB, welches kompatibel zu MySQL ist, verwendet.
Wo bekommt man das alles?
Hierzu verweise ich erst einmal auf den Blog, der über alle News rund um Uberpace informiert. https://blog.uberspace.de
Mit ein wenig Bastelei konnte ich in kürzester Zeit eine Testseite sowie eine eMail-Adresse im neuen Uberspace 7 migrieren. Das Aufschalten der für den Test verwendeten Domain lief ebenfalls völlig unspektakulär. Zwar fehlen noch einige Features im neuen System, dennoch öffnet Uberspace mit der U7 Public Beta eine neue Tür.
Der Preis zum Hosting, kann nach wie vor selbst bestimmt werden. Man bekommt einen kompetenten Hoster mit super Support zu einem fairen Preis.
Heute möchte ich ein wenig Werbung für die regionale Open Source Community von Halle (Saale) machen. Ende Januar 2016 hatten Andreas und ich die Idee eine Online-Community für Gleichgesinnte zu gründen. Im Vordergrund sollte der Gedankenaustausch rund um freie und quelloffene Software stehen.
Hierzu haben wir am 10.02.2017 den Grundstein gelegt. Es wurde damit begonnen ein kleines soziales Netzwerk unter hality.org aufzubauen. Daran teilnehmen kann natürlich jeder! Hierbei spielt keine Rolle ob ihr Hallenser seid oder aus einer anderen Ecke der Republik kommt.
Um die Community etwas lebhafter zu gestalten, möchten wir natürlich auch Treffen organisieren. Dabei soll der Fokus auf freier Software liegen. Installationshilfen sowie Workshops sind geplant.
Unter XMPP und IRC stehen entsprechende Chaträume bereit.
Neulich musste ich feststellen, dass ich ein neues WordPress-Theme nicht installieren konnte, weil es zu groß war. Durch das Hochsetzen der Standard-Werte für upload_max_filesize und post_max_size in der /etc/php5/apache2/php.ini würde das kleine Problem behoben.
1
# nano /etc/php5/apache2/php.ini
Die Einträge
1
2
upload_max_filesize=2M
post_max_size=8M
wurden in
1
2
upload_max_filesize=2G
post_max_size=2G
geändert. Nach dem Neustart des Webservers konnte das Theme problemlos hochgeladen werden.
Am Montag habe ich die CeBIT 2017 besucht. Wie geplant konnte ich mich dort mit Jurist und Tech-Blogger Didi von DIDIS BLOGAZOtreffen, mit dem ich dann die gesamte Zeit auf der Messe verbrachte.
2017 ist Japan das Partnerland der diesjährigen CeBIT. Trotz vieler neuen Innovationen war mein persönlicher Eindruck davon geprägt, dass die Präsenz von Hooverboards, VR-Brillen, 3D-Druckern und sogar den beliebten Drohnen ihren Höhepunkt wohl überschritten haben. Dieser subjektive Eindruck aber nur am Rande.
„Wir sind die Roboter!“
Da wir rechtzeitig auf dem Messegelände waren, konnten wir den ersten Vortrag im Open Source Forum „Enterprise-Zwei-Faktor-Authentifizierung für ownCloud und Nextcloud“ von Cornelius Kölbel lauschen. Ich persönlich finde die Idee dahinter nicht schlecht, da Angriffe auf solche Systeme nicht nur häufiger, sondern auch immer raffinierter ausgeführt werden. Praxisnah habe ich nun begonnen, diese WordPress-Installation sowie meine Nextcloud mit einer TOTP-Zweifaktorauthentifizierung (Time-based One-Time Password algorithm) auszustatten.
Zwischendurch suchten wir den Stand von KNOPPIX auf. Hier wurden u.a. unter Knoppix erstellte 3D-Modelle gedruckt. Desweiteren konnte man praxisnah und verständlich erfahren, wozu diese Live-Distribution im Stande ist.
Zurück im Open Source Park unterhielt ich mich mit einem Mitarbeiter von TUXEDO über die neuesten Modelle. Hier fiel sofort das neue 13″ InfinityBook ins Auge. Dieses wirkt auf den ersten Blick noch gelungener als das Vorgängermodell. Vielleicht werde ich dieses Modell einmal antesten und etwas genauer vorstellen.
Danach ging es zum Vortrag „Knoppix 8.0 – die CeBIT Edition“. Hier erfuhren wir, welche Neuerungen Klaus Knopper und sein Team dieser besonderen Version spendiert haben. Sehr interessant war, dass es möglich ist ein bestehendes Knoppix-Live-System so zu vervielfältigen, dass Systemänderungen mit übernommen werden. Diesen Aspekt finde ich besonders bemerkenswert, wenn im Fokus des Einsatzgebietes z.B. ein Schulprojekt steht. So können speziell angepasste und völlig identische Systeme auf Live-Sticks den Anwendern zur Verfügung gestellt werden.
Klaus Knopper erklärt Knoppix 8.0
Zum Schluss habe ich Didi in meine Arbeitswelt, den Straßenbau, entführt. Es ging zum Stand vom Komatsu, wo ein GPS-gesteuerter Kettenbagger der neuesten Generation vorgestellt wurde, der PC210LCi-11. Nachdem Didi im Gerät Platz genommen hatte, war er kaum wieder raus zu bekommen.
Didi im Komatsu PC210LCi-11Didi vor dem Komatsu PC210LCi-11
