Diese Anleitung ist veraltet, denn seit kurzem ist letsencrypt direkt über das Repository von omv-extras.org als Openmediavault Plugin verfügbar.
Mit Letsencrypt bekommt man kostenlose SSL Zertifikate die von allen gängigen Browsern und Geräten als vertrauenswürdig eingestuft werden. Damit lässt sich mit wenig Aufwand Verschüsselte Kommunikation realisieren. In diesem Fall mit einem openmediavualt Server.
Mehr Informationen unter: letsencrypt.org
Wechselt zunächst in das Verzeichnis in welchem ihr letsencrypt Installieren möchtet. In meinem Fall verwende ich einfach ~ (Home) von root. Anschließend lässt sich letsencrypt direkt von github installieren.
cd ~
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
Bei diesem Schritt wird auf eurer lokalen Maschine ein privater Schlüssel erstellt und ein öffentliches Zertifikat bei Letsencrypt angefragt, welches automatisch auf eurer Maschine gespeichert wird.
Um mehrere Subdomains gleich mitzubekommen einfach mit -d die benötigten Domains angeben.
letsencrypt-auto certonly --webroot -w /var/www/openmediavault/ -d meinhomeserverxyz.no-ip.com -d www.meinhomeserverxyz.no-ip.com -d cloud.meinhomeserverxyz.no-ip.com
Nach erfolgreicher erstellung wird folgende Meldung angezeigt. Notiert oder merkt euch den Speicherort für euer neues Zertifikat.
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/meinhomeserverxyz.no-ip.com/fullchain.pem. Your cert will
expire on 2016-03-03. To obtain a new version of the certificate in
the future, simply run Let's Encrypt again.
- If like Let's Encrypt, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
Hinweis: Die ID im Dateinamen ist bei jedem System unterschiedlich.
Vorhandenes Zertifikat und dessen Schüssel umbenennen.
mv /etc/ssl/certs/openmediavault-23d764ab-3546-47eb-9bed-e2cecaf1488b.crt /etc/ssl/certs/openmediavault-23d764ab-3546-47eb-9bed-e2cecaf1488b.crt.old
mv /etc/ssl/private/openmediavault-23d764ab-3546-47eb-9bed-e2cecaf1488b.key /etc/ssl/private/openmediavault-23d764ab-3546-47eb-9bed-e2cecaf1488b.key.old
Symbolische Links erstellen
ln -s /etc/letsencrypt/live/meinhomeserverxyz.no-ip.com/fullchain.pem /etc/ssl/certs/openmediavault-23d764ab-3546-47eb-9bed-e2cecaf1488b.crt
ln -s /etc/letsencrypt/live/meinhomeserverxyz.no-ip.com/privkey.pem /etc/ssl/private/openmediavault-23d764ab-3546-47eb-9bed-e2cecaf1488b.key
Nginx Config neu einlesen
service nginx reload
Wenn ihr in Zukunft euer Zertifikat erneuern möchtet einfach nochmal das Kommando aus Schritt 3 ausführen. Dies kann man auch automatisiert in einem Cronjob alle 89 Tage machen (Das Zertifikat von Letsencrypt läuft nach 90 Tagen ab).
Der Standard Netzwerktreiber (genau genommen Kernel Extension) von FreeNas unterstützt leider kein WOL (Wake-on-LAN) mit einem HP Microserver N40L / N36L / N54L. Mithilfe des Netzwerktreibers aus der ähnlichen, ebenfalls auf FreeBSD basierten Distribution Nas4Free, kann man diese Funktion jedoch Nachrüsten.
Die Folgende Anleitung funktioniert mindestens für FreeNAS-9.3-STABLE-201506042008 bis FreeNAS-9.10.2-U6 (561f0d7a1) und den HP Microserver N40L / N36L / N54L.
mount -uw /cp if_bge.ko /boot/kernelchmod 555 /boot/kernel/if_bge.kochown root:wheel /boot/kernel/if_bge.komv /boot/kernel/if_bge.ko /boot/kernel/if_bge_wol.ko
Nach Erfolgreicher Durchführung erscheint bei Ausführen von ifconfig folgende Ausgabe. Man beachte die Option "WOL_MAGIC".
[root@nas ~]# ifconfig bge0
bge0: flags=8843 metric 0 mtu 1500
options=c219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
Dies ermöglicht euch nun euer FreeNAS System nach Herunterfahren per Wake-on-LAN Paket und seiner MAC Adresse aufzuwecken.
Unter Linux beispielsweise erfolgt dies mit folgendem Befehl, wobei die MAC Adresse entsprechend angepasst werden muss.
wakeonlan 99:AA:BB:CC:DD:EE
Zur besseren Übersicht und Versionskontrolle lassen sich Webprojekte die auf fertigem Code basieren mithilfe symbolischer Verknüpfungen besser trennen.
/%SOFTWAREQUELLENNAME%-%VERSION%/
tar xf archiv.tar -C ZIELORDNER
tar xjf ARCHIVNAME.tar.bz2 -C ZIELORDNER
tar xzf ARCHIVNAME.tar.gz -C ZIELORDNER
ZIP-Archive:
unzip ARCHIVNAME.zip -d ZIELORDNER
tar xjf owncloud-5.1.0.tar.bz2 -C owncloud-5.1.0/
unzip typo3-7.1.zip -d /typo3-7.1
Möchte man folgende Datei anpassen
/cmssystem-3.4.7/module/modul.php
erstellt man sich eine Kopie in einem separatem Ordner
/custom-cmssystem-3.4.7-kundexy/module/modul.php
und erstellt dann einen symbolischen Link im Originalpfad auf die modifizierte Datei mit:
ln -s /Pfad_1/echte_Datei /Pfad_2/Symlink
ln -s /custom-cmssystem-3.4.7-kundexy/module/modul.php /cmssystem-3.4.7/module/modul.php
Dadurch lassen sich die Anpassungen die im Ordner /custom.... liegen, sauber trennen, sichern und beispielsweise mit Subversion oder Git versionieren, ohne den sowieso separat verfügbaren Quellcode mit zu sichern.
Besitzt man nur eine öffentliche IP-Adresse und möchten mehrere Webseiten/Web-Applikationen über diese bereitstellen, kommt man an einem Reverse Proxy nicht vorbei. Eine einfache und schlanke Lösung bietet hier der nginx Webserver.
In diesem Beispiel Betreiben wir zwei Subdomains mit jeweils eigenen SSL Zertifikaten. Beide stellen über Port 443 Web-Applikationen bereit. Der nginx Server übernimmt hierbei auch die SSL-Verschlüsselung (SSL-Offloading). Die Server sind in diesem Beipiel im internen Netz über 192.168.0.8 Port 80 und 192.168.0.9 Port 8080 erreichbar.
Die nachfolgende nginx Konfiguration ist unter Beachtung der mit # vorangeführten Kommentaren selbsterklärend.
# Ein Listener auf Port 80 sorgt dafür, dass Anfragen an http automatisch über ein HTTP 301 an https umgeitet werden
server {
listen 80;
server_name app1.domain.tld app2.domain.tld; # Hier sind alle betriebenen Domains/Subdomains einzutragen. Auch eine Wildcard *.domain.de ist möglich.
return 301 https://$server_name$request_uri;
}
# Web-Applikation 1
server {
listen 443 ssl;
server_name app1.domain.tld; # Domain für die erste Web-Applikation
ssl on;
ssl_certificate /usr/local/etc/nginx/openssl/certs/app1.domain.tld.combo.pem; # Zertifikatsbundle für erste Web-Applikation
ssl_certificate_key /usr/local/etc/nginx/openssl/private/app1.domain.tld.nopass.key; #Zertifikatsschlüssel für erste WebApplikation
# Manche Web-Applikationen leiten einen auf http:// um. Die nachfolgende Anweisung leitet http:// anfragen an Port 443 auf https:// um
error_page 497 = https://$server_name:$server_port$request_uri;
location /
{
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://192.168.0.8:80; # Interne IP und Port
}
# Web-Applikation 2
server {
listen 443 ssl;
server_name app2.domain.tld; # Domain für die erste Web-Applikation
ssl on;
ssl_certificate /usr/local/etc/nginx/openssl/certs/app2.domain.tld.combo.pem; # Zertifikatsbundle für zweite Web-Applikation
ssl_certificate_key/usr/local/etc/nginx/openssl/private/app2.domain.tld.nopass.key; #Zertifikatsschlüssel für zweite WebApplikation
# Manche Web-Applikationen leiten einen auf http:// um. Die nachfolgende Anweisung leitet http:// anfragen an Port 443 auf https:// um
error_page 497 = https://$server_name:$server_port$request_uri;
location /
{
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://192.168.0.9:8080; # Interne IP und Port
}
}
Manchmal nimmt man ein System in Betrieb und ist sich nicht ganz sicher, ob die ECC Fehlerkorrektur des Arbeitsspeichers läuft oder nicht.
Bei unixoiden Systemen kann man dies folgendermaßen herausfinden.
Konsolen Kommando dmidecode -t 17 zeigt an, was Speichertechnisch am System eingebunden ist.
[...]
Handle 0x0016, DMI type 17, 28 bytes
Memory Device
Array Handle: 0x0014
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: DIMM0
Bank Locator: BANK0
Type: Other
Type Detail: Synchronous
Speed: 1333 MHz
Manufacturer: Manufacturer00
Serial Number: SerNum00
Asset Tag: Not Specified
Part Number: ModulePartNumber00
Rank: Unknown
[...]
In diesem Fall wird angezeigt: Data Width = 64bits und Total Width = 72 bits. Also 64 Bits und 8 Bits Parität. Das bedeutet ECC wird verwendet.
Schaut man auf einem anderem System ohne ECC steht dort bei Data Width und Total Width derselbe Zahlenwert.
Achtung: Softwaretechnisch ist es für Software/Betriebssysteme nicht relevant ob der Speicher ECC unterstützt/nutzt oder nicht.
Deshalb gibt es im Consumer-Hardwarebereich leider immer wieder BIOS/Chipsätze die dem Betriebssystem erst gar nicht verraten ob ECC genutzt wird. Hier hat man leider keine andere Wahl, als dem Mainboard blind zu vertrauen. Professionelle Serverhardware dagegen gibt diese Information an das System weiter.