ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://kleine-photo-com.docker:9000/usr/src/myapp/$1
Soweit, so gut. Apache läuft bei mir übrigens nicht in einem Container. Warum eigentlich nicht? Könnte ich mir auch noch überlegen.
Jedenfalls habe ich dann das Problem, dass mein Host diese Domain nicht auflösen kann! Also habe ich anfangs die einzelnen Seiten in die etc/hosts eingetragen. Blöd ist dabei nur, dass die IPs natürlich rotieren können, sobald der Server mal neugestartet wird. Also habe ich plötzlich andere Inhalte hinter den Domains – extrem nervig. Das ist mir jetzt 2x passiert und nun habe ich mich mit einer Lösung beschäftigt. Am einfachsten war dabei für mich der Weg über einen weiteren Docker-Container für DNS.
docker run -itd --restart=always --hostname dns.docker --name dns-proxy-server -p 5380:5380 -v /var/run/docker.sock:/var/run/docker.sock -v /etc/resolv.conf:/etc/resolv.conf defreitas/dns-proxy-server
Nun werden alle DNS-Anfragen in den Container gejagt. Außerdem werden nun die Hostnamen der Docker-Container richtig aufgelöst und alles funktioniert wunderbar wie ich mir das vorgestellt habe. Sobald man den Container stoppt ist übrigens wieder alles wie vorher. Also kein Risiko. Danke restart=always wird der Container also nun auch immer brav mitgestartet und alles überlebt ebenfalls einen Neustart des Servers. Puh, das war einfacher als ich dachte!
Nun bin ich kein Sysadmin, sondern Softwareentwickler. Daher lese ich mir solche Themen immer an und bin froh, dass es so einfache Lösungen wie diese gibt. Wenn Du eine bessere oder einfachere Idee hast: Immer her damit!
]]>[mysqld-auth] enabled = true logpath = /var/log/mysql/error.log
Und den Filter musste ich wie folgt anpassen:
failregex = ^%(__prefix_line)s(\d{6} \s?\d{1,2}:\d{2}:\d{2} )?\[Warning\] Access denied for user '\w+'@'<HOST>' (to database '[^']*'|\(using password: (YES|NO)\))*\s*$
^%(__prefix_line)s(?:\d+ |\d{6} \s?\d{1,2}:\d{2}:\d{2} )?\[\w+\] Access denied for user '[^']+'@'<HOST>'
Die erste Zeile habe ich dabei nicht angefasst, sondern nur die zweite hinzugefügt. Statt einer Warning erscheint bei mySQL 5.7 nur noch „Note“. Der reguläre Ausdruck ist natürlich relativ allgemein, aber funktioniert für mich wunderbar. Endlich werden die ganzen Login-Versuche auf root entsprechend geblockt.
Testen kann man das ganze wie folgt:
fail2ban-regex /var/log/mysql/error.log /etc/fail2ban/filter.d/mysqld-auth.conf
Bei mir sieht die Ausgabe nun so aus:
Lines: 492 lines, 0 ignored, 54 matched, 438 missed [processed in 0.07 sec] Missed line(s): too many to print. Use --print-all-missed to print all 438 lines
Sieht also sehr gut aus!
]]>Die Lösung dafür ist relativ einfach – man darf die Regeln nur nicht als INPUT definieren, sondern muss diese für Forward definieren. Damit Ihr ein etwas leichteres Leben habt, habe ich eine neue Action geschrieben, welche ganz einfach angewendet werden kann:
[INCLUDES]
before = iptables-common.conf
[Definition]
actionstart = <iptables> -N f2bd-<name>
<iptables> -A f2bd-<name> -j <returntype>
<iptables> -I FORWARD -p <protocol> -m multiport --dports <port> -j f2bd-<name>
actionstop = <iptables> -D FORWARD -p <protocol> -m multiport --dports <port> -j f2bd-<name>
<iptables> -F f2bd-<name>
<iptables> -X f2bd-<name>
actioncheck = <iptables> -n -L FORWARD | grep -q 'f2bd-<name>[ \t]'
actionban = <iptables> -I f2bd-<name> 1 -s <ip> -j <blocktype>
actionunban = <iptables> -D f2bd-<name> -s <ip> -j <blocktype>
[Init]
blocktype = DROP
chain = FORWARD
Für alle Jails, welche für Docker-Container gelten, verwende ich als „banaction“ nur eben diese. Funktioniert bisher einwandfrei!
]]>Erstmal müssen wir mit root per ssh auf die DiscStation.
ssh root@xxx.xxx.xxx.xxx
Danach legen wir auf volume1 ein Public-Verzeichnis an (falls es dieses noch nicht gibt).
mkdir /volume1/public
Nun geht es mit vi weiter:
cd /volume1/public vi install.sh
Dort kommt der folgende Inhalt rein:
feed=http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable
ipk_name=`wget -qO- $feed/Packages | awk '/^Filename: ipkg-opt/ {print $2}'`
wget $feed/$ipk_name
tar -xOvzf $ipk_name ./data.tar.gz | tar -C / -xzvf -
mkdir -p /opt/etc/ipkg
echo "src cross $feed" > /opt/etc/ipkg/feeds.conf
hier kopieren, i (wie insert) drücken, einfügen (Strg + v), ESC drücken, „:wq“ schreiben und Enter drücken
Dann das folgende Verzeichnis anlegen und mounten:
mkdir /volume1/@optware mkdir /opt mount -o bind /volume1/@optware /opt
Dann die neue Datei ausführen:
sh install.sh
Nun müssen wir noch die PATH-Variable erweitern:
vi /root/.profile
Dort packen wir ganz ans Ende der Zeile folgenden Inhalt :/opt/bin:/opt/sbin (Bitte unbedingt auf die Doppelpunkte achten, diese trennen die verschiedenen Verzeichnisse voneinander). Bei mir sieht die komplette Zeile wie folgt aus:
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin:/opt/bin:/opt/sbin
Nun starten wir die DiscStation neu!
Wieder per SSH einloggen und folgendes nacheinander ausführen:
/etc/rc.optware start ipkg update
Nun kann man zum Beispiel bash installieren:
ipkg install bash
Zur Info: Bei mir wurde die ipkg version 0.99.163 installiert.
Viel Spaß damit!
ACHTUNG: Ich habe mehrfach gelesen, dass der ssh-login durch diesen Prozess kaputt gehen könnte. Auch anderen Schäden an der DiscStation oder den darauf gespeicherten Dateien sind natürlich nie ganz ausgeschlossen. Ich habe hier nur dokumentiert, wie ich es am Ende dann doch geschafft habe. Geht sehr vorsichtig vor! Ihr seid selbst dafür verantwortlich was ihr aus dem Netz kopiert und ausführt …
Dennoch hat es bei mir reibungslos funktioniert und ich habe vorher schon ganz viel kram ausprobiert.
]]>Danach geht man in die Einstellungen unter der neuen Anwendung „Mail Server“ und dort auf SMTP (schließlich wird dieses Protokoll zum versenden von Mails genutzt). Da ich die Mails nicht direkt vom NAS verschicken möchte, sondern über meinen Webserver, richte ich dort ein weiteres Postfach ein, und gebe die entsprechenden Daten unter „SMTP-Relay“ ein.
Dort auf den Button SMTP-Relais klicken:
Die genaue Konfiguration ist natürlich vom jeweiligen Provider abhängig. Genauso ist es aber denkbar, als SMTP-Relay einen GMX, T-Online oder einen anderen bestehenden Server einzutragen. Ein eigener Webserver ist also nicht zwingend erforderlich.
Danach kann man auch schon Mails verschicken:
sendmail -F nas@domain.de -t empfaenger@domain.de < inhalt.txt
Hierbei ist nas@domain.de der Absender und empfaenger@domain.de der Empfänger der Mail. Natürlich sollte man nur eine Domain anhängen, welche auch entsprechend registriert ist. Ansonsten werden die ausgehenden Mails schnell als Spam eingestuft!
]]>Was braucht man dafür?
- SSH-Zugang
- Einen Benutzer auf der Synology, welcher mit Key-Authentication auf den Webserver darf (dazu muss für den neuen Benutzer ein Key erstellt werden, welcher auf dem Webserver hinterlegt wird). Wie genau das geht, erklären hunderte von Beiträgen im Netz.
- Etwas Platz auf der DiscStation
Ich habe mir dazu einen neuen Benutzer namens „backup“ (kreativ, oder?) auf der Synology angelegt, welcher als einziger Zugriff auf einen neuen gemeinsamen Ordner Namens „backup“ bekommt. Alle anderen Benutzer dürfen dort nicht schreiben – außer die Administratoren.
Soweit, so gut. Danach habe ich die Datei „backup_webserver.sh“ im Home-Verzeichnis des Backup-Users erstellt und einen neuen Cronjob eingerichtet, welches dieser Datei jeden Tag um 23 Uhr ausführt.
Natürlich ist hinter „sh“ ein Leerzeichen und kein Zeichenumbruch. Die Textbox ist etwas klein geraten!
Der Inhalt der Datei ist dabei relativ simpel:
#!/bin/bash current_date=$(date +"%Y-%m-%d") USER="ssh-w0123456" SERVER="domain.de.w0123456.kasserver.com" PORT="22" SOURCE="/www/htdocs/w0123456/" TARGET="/volume1/backup/$current_date/data/" LOG="/volume1/backup/$current_date/backup_data.log" mkdir /volume1/backup/$current_date rsync -avz --progress -e "ssh -p $PORT" $USER@$SERVER:$SOURCE $TARGET >> $LOG 2>&1
Unter /volume1/backup/ wird nun also jeden Tag ein neues Verzeichnis erstellt, welches den kompletten Inhalt per rsync herunterlädt. Soweit, so gut. Aufräumen muss man noch selbst! Nach mehreren Monaten wird sich hier also ordentlich was ansammeln.
Fehlt noch die Datenbank. Damit wir das Kommando „mysqldump“ nutzen können, muss das Paket „MariaDB“ über die Paketverwaltung installieren. Ich habe den Dienst nach der Installation direkt wieder gestoppt, um Rechenleistung zu sparen. Die entsprechenden Binaries findet man dann unter „/usr/syno/mysql/bin/mysqldump“.
Für alle Datenbanken habe ich eine CSV-Dateie erstellt, welche nach folgendem Schema aufgebaut ist:
benutzer;passwort benutzer;passwort benutzer;passwort benutzer;passwort
Bei all-inkl ist der Benutzername auch immer gleich der Datenbankname – ansonsten bräuchte man noch eine Spalte.
Das Script sieht dann wie folgt aus:
#!/bin/bash
current_date=$(date +"%Y-%m-%d")
BACKUPDIR="/volume1/backup"
MYSQLTARGET="$BACKUPDIR/$current_date/mysql"
HOST="domain.de.w0123456.kasserver.com"
mkdir ${MYSQLTARGET}
OLDIFS=$IFS
IFS=";"
while read user password
do
echo "Backing up ${user}"
/usr/syno/mysql/bin/mysqldump --opt -h ${HOST} -u${user} -p${password} --databases ${user} | gzip -c -9 > ${MYSQLTARGET}/${user}.gz
done < $1
IFS=$OLDIFS
Fertig! Nun dafür auch noch einen Cron einrichten.
Und schon laufen jede Nacht die entsprechenden Jobs!
Aufräumen nicht vergessen!
[asa]B00G6AX604[/asa] [asa]B00X17ZWB6[/asa] [asa]B00GK48610[/asa]Bitte habt Verständnis dafür, dass ich für die genannten Scripte natürlich keine Garantie gebe. Es können sich natürlich immer Fehler einschleichen, welche zu Datenverlust führen. Ich bitte Dich daher, die hier gezeigten Scripte nur einzusetzen, wenn Du genau weißt was Du machst.
]]>Also habe ich mir ein Start-Kit bestellt, damit ich nicht alles einzeln zusammensuchen muss. Sicher etwas teurer, dafür hat man jede Menge Kram zum spielen dabei. Alles verpackt in einer kleinen praktischen Plastikbox.
Als erstes habe ich wiringPi installiert. Der Build dauert eine ganze Weile – also ruhig einen Kaffee holen in der Zeit.
Ob alles geklappt hat, kann man folgendermaßen testen:
pi@raspberry:~$ gpio -v gpio version: 2.31 Copyright (c) 2012-2015 Gordon Henderson This is free software with ABSOLUTELY NO WARRANTY. For details type: gpio -warranty Raspberry Pi Details: Type: Model B, Revision: 03, Memory: 512MB, Maker: Sony * Root or sudo required for GPIO access.
Fein. Und was nun?
Also eine runde Programmieren. Wahlweise mit C, Python oder eben per Shell. Für mich auch endlich mal eine Chance, etwas in Python einzusteigen. Das hatte ich schon viel zu lange vor. Aber soll ja nicht allzu schwer sein, wenn man schon Erfahrung in C, Java, PHP o.ä. hat.
Dank dem mitgelieferten Manual, hatte ich das erste C-Programm schnell (ab)geschrieben:
#include <wiringPi.h>
#include <stdio.h>
#define LedPin 0
#define SecondPin 3
int main(void)
{
if (wiringPiSetup() == -1) {
printf("Das war nix");
return 1;
}
pinMode(LedPin, OUTPUT);
while(1) {
digitalWrite(LedPin, LOW);
digitalWrite(SecondPin, HIGH);
printf("led on!\n");
delay(500);
digitalWrite(LedPin, HIGH);
digitalWrite(SecondPin, LOW);
printf("led off!\n");
delay(500);
}
}
Schnell kompiliert und ausgeführt:
gcc test.c -o led -lwiringPi sudo ./led
Dann noch alles ein wenig verkabeln, und schon steht die erste kleine Anwendung: Eine blinkende LED! Der Wahnsinn, oder?
Schon jetzt könnte ich meine erste kleine Anwendung schreiben: Status-LEDs für unsere Continous Integration-Umgebung. Heißt: Geht ein Build kaputt, leuchtet eine rote LED auf. Ist alles wieder heile, wird die LED grün. Cool, oder?
Wenn man keine Lust hat alles in C zu schreiben, könnte man die C-Programme natürlich auch mit anderen Sprachen (wie PHP) aufrufen und die LEDs so steuern.
Alternativ kann man die LED in diesem Beispiel natürlich auch per Shell an- und ausschalten:
/usr/local/bin/gpio -g write 17 1 /usr/local/bin/gpio -g write 17 0[asa]B00T2U7R7I[/asa] [asa]B00HU0Z4C2[/asa] ]]>