Neben aufwendigen Mechanismen um Einbruchsversuche oder Passwort-Tests zu vermeiden habe ich nach einer einfachen Möglichkeit gesucht ungewollte Besucher auszusperrren. Die Lösung läßt sich mit einer globalen Apache-Konfiguration erstellen:
/etc/apache2/conf.d/blacklist
order allow,deny
allow from all
deny from 111.111.122.222
#deny from
Für eine OwnCloud-Test-Installation benötige ich ein Zertifikat, ein guter Anlass ein neues Zertifikat mit langer Lebensdauer für diverse Tests zu erzeugen.
openssl genrsa -des3 -out server.key 2048 openssl req -new -key server.key -out server.csr
um nicht bei jedem Apache-Start den Privatekey einzugeben :
openssl rsa -in server.key -out server2.key
openssl x509 -req -days 3650 -in server.csr -signkey server2.key -out server.crt
Das Zertifikat ist nun 10 Jahre gültig.
Wichtig beim Beantworten der Fragen ist dass der CN (CommonName des Zertifikat dem Servername aus der Apache-Konfigutation entspricht) – ansonsten gibt es bei Owncloud Probleme.
die Dateien kopiert mal z.B. nach /etc/ssl
und konfiguriert Apache innerhalb eines VirtualHost-Containers:
SSLEngine On SSLCertificateFile /etc/ssl/server.crt SSLCertificateKeyFile /etc/ssl/server2.key
Hier wird beschrieben wie man Zertifikate von CACert verwendet
Die Fehlermeldung sieht etwa so aus :
PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature
Zu erst habe ich versucht das Problem über die Installation der PCLZIP-Library mit
apt-get install libphp-pclzip
zu lösen – leider ohne Erfolg.
Ich habe dann versucht herauszufinden, ob Piwik das aktuelle Software-Release heruntergeladen hat.
unter
piwik-pfad/tmp/latest/latest.zip
lag eine aktuelle aber sehr kleine Datei. Bei näherem Betrachten, stellte sich die Datei als HTML-Fehlermeldung der Download-Seite heraus. Zum Glück war im HTML-Text der richtige Download-Link enthalten der in der
piwik-pfad/config/config.ini.php
als
latest_version_url = "http://piwik.org/latest.zip"
auf
latest_version_url = "http://builds.piwik.org/latest.zip"
geändert werden musste.
Nach dem Update auf Version 2.10 verschwindet die Konfigurations-Option dann und ich bin gespannt wie das nächste Update ablaufen wird.
Nach einigen Neustarts fiel mir auf das einige Dienste nicht gestartet wurden, kein Wunder in den Runlevel-Verzeichnissen waren die entsprechenden Init-Start-Stop-Skripte nicht verlinkt.Zum Beispiel für mysql:
ls -l /etc/rc?.d/*mysql
Ich kannte noch den Mechanismus mit update-rc.d, allerdings nutzt man unter Debian 7 nun insserv. Um MySQL die Standard-StartUp-Skripte zu verpassen, führt man den Befehl:
insserv -d mysql
aus.
IPV4 Adressen werden zwar langsam knapp, dennoch stehen mir aktuell mehrere zur Verfügung, die ich auch irgendwie mit Postfix nutzen wollte und daher bei mynetworks eingetragen hatte.
Ausgehende Mails sollen jedoch immer von einer IP-Adresse verschickt werden, das hat den Vorteil, dass man die Adresse im Notfall (falls man auf einer Blacklist landet) ändern kann.
Um Postfix für ausgehende Mails auf eine IP-Adresse zu konzentrieren, muss man in /etc/postfix/main.cf die Konfigurationsoption
smtp_bind_address = 192.168.0.1
hinzufügen (die 192.168.0.1 wird durch die entsprechende IP-Adresse ersetzt).
Danach wird Postfix mit /etc/init.d/postfix restart neu gestartet und die Konfiguration ist wirksam
Neben Dropbox und Owncloud gibt es auch Ubuntu One als Cloud-Dienst. Ubuntu One ist automatisch installiert und man muss nur ein Konto anlegen um den Dienst zu nutzen.
Entfernen kann man den Dienst auch mit:
sudo apt-get remove --purge ubuntuone-client ubuntuone-client-gnome ubuntuone-control-panel ubuntuone-control-panel-gtk
Nach einem Update des Mailserver ist mir aufgefallen, dass Postgrey Verbindungen über IPV6 anbietet.
Interessant vorallem wenn man auch in den Logs solche Warnungen sieht:
warning: connect to 127.0.0.1:10023: Connection refused
Man ändert in der /etc/postfix/main.cf den Eintrag von
check_policy_service inet:127.0.0.1:10023
auf:
check_policy_service inet:::1:10023
und prüft ob die Option :
inet_protocols=all
in der Konfiguration enthalten ist.
Alternativ kann man vermutlich auch in der /etc/hosts die IPV6 Konfiguration für localhost löschen und postgrey weiterhin mittels IPV4 betreiben.
Manchmal bleibt der Arbeitsspeicher einfach belegt ohne Grund – also nach dem alle vorher genutzten Anwendungen wieder geschlossen wurden – , so kommt es mir zumindest vor.
Ein Reboot hilft auch aber einfacher sind die Befehle um den Arbeitsspeicher wieder zu leeren:
sync ; sync ; sync ; echo 3 > /proc/sys/vm/drop_caches sync ; sync ; sync ; swapoff -a && swapon -a
Das Ändern von IP-Adresssen in diversen Konfigurationsdateien kann mitunter zu nicht unbeträchtlicher Fleißarbeit führen – daher habe ich nach einer Möglichkeit gesucht mit der ich die IP-Adressen automatisch korrigieren kann.
Mit diesem kleinen Skript kann man zum Beispiel direkt alle IP-Adressen innerhalb der Apache-Konfiguration verändern. Natürlich könnte man das Skript auch direkt auf alle Dateien in /etc anwenden, das erschien mir aber erstmal unnötig.
#!/bin/bash IP_NEW="10.0.0.2" IP_OLD="10.0.2.1" for DATEI in $(grep $IP_OLD /etc/apache2/sites-enabled/* |cut -d : -f 1); do DAT_TMP=$DATEI"_tmp" sed -u 's/'"$IP_OLD"'/'"$IP_NEW"'/' $DATEI > $DAT_TMP cp -f $DAT_TMP $DATEI rm $DAT_TMP echo $DATEI done
Bei einem Festplattendefekt in einem Raid-System ist man erstmal auf der sicheren Seite.
Eine gute Anleitung zum wechseln einer defekten Festplatte gibt es in Florian’s Blog (MDADM Raid nach Ausfall wiederherstellen).
Ich habe nach einer Lösung gesucht mit der ich den Rebuid-Vorgang beobachten kann und bin zu folgender Lösung gekommen:
while true; do sleep 15; clear; sudo mdadm --detail /dev/md0; echo; cat /proc/mdstat; done
Jetzt wird alle 15 Sekunden die Anzeige von mdadm –detail und der Status in /proc/mdstat aktualisiert ausgegeben.