Damit Outlook (ab 2007 SP1!) beim Einrichten eines Exchange-Kontos auch die richtige Server-Adresse anhand der Mail-Domain findet, gibt man der Domain einen DNS SRV Record mit den entsprechenden Daten:
# Domain example.com
_autodiscover._tcp IN SRV 0 0 443 office.example.com
Plesk User legen einen SRV-Record über die DNS Verwaltung an, dort allerdings die Unterstriche (“_”) jeweils weglassen.
Es geschehen noch Wunder. Ein ur-alter Patch, der PHP das Loggen der “mail()” Funktion beibringt hat es in den Core geschafft – und ich habe es nicht gemerkt ;).
Damit wird es auf Shared-Hosting Systemen endlich (ohne Klimmzüge) möglich, spammende Formulare etc. zu identifizieren…
So wird es aktiviert:
# /etc/php.ini
mail.add_x_header = On # Fügt einen neuen Mailheader hinzu:
# X-PHP-Originating-Script: :formmail.php
mail.log = /var/log/phpmail.log # Loggt jede Benutzung der mail() Funktion
Das Log sieht dann so aus:
mail() on [/var/www/formmail.php:3]: To: otto@example.org -- Headers:
many THANKS!
Letze Tage bei launchpad traf ich auf eine Fehlerseite. Wie ich finde, haben die das vorbildlich gelöst…
Wenn ich weiss warum etwas nicht funktioniert, ärgere ich mich auch nicht darüber…
Nachträglich ein DRBD Laufwerk eingerichtet. Vorher war auch schon ein LVM im System aktiv. Nach dem Einzug des DRBD-Layers meckerte LVM merkwürdigerweise immer mehrere Physical Volumes mit der selben ID an:
Found duplicate PV sX26QEl0aPdVRr1uMA8VhR7PpTIJ0Xu0: using /dev/sdb1 not /dev/drbd0
Found duplicate PV sX26QEl0aPdVRr1uMA8VhR7PpTIJ0Xu0: using /dev/sdc1 not /dev/sdb1
In der lvm.conf war der Filter korrekt gesetzt (damit nur das drbd Laufwerk nach PVs durchsucht wird), auch “write_cache_state” hatte ich disabled.
#/etc/lvm/lvm.conf
filter = [ "a|/dev/drbd|", "r/.*/" ]
write_cache_state = 0
Trotzdem kam mir immer wieder das alte PV ins Gehege. pvscan, reboot etc. nützte nichts… Letzendlich war der Grund der Cache vom LVM. Also die Cache-Datei gelöscht:
rm /etc/lvm/cache/.cache
Danach pvscan, vgscan etc. und alles war wieder gut.
Meine Vermutung zum Grund der ganzen Aktion ist, dass ich die lvm.conf Einstellungen erst geändert hatte nachdem ich das DRBD und ein neues LVM aktiviert hatte. Wenn die Einstellung “write_cache_state” dann deaktiviert wird, wird der Cache auch nicht mehr aktualisiert, wird aber dennoch verwendet! Wie gesagt: Vermutung.
Mal wieder ein dd angeschmissen und es dauert Stunden? Vergessen das dd durch eine Statistik-Pipe zu schicken?
dd ist empfänglich für das Signal “SIGUSR1” welches dd veranlasst zwischendurch seinen Status auszugeben. Also zunächst gilt es die pid des dd Prozesses herauszufinden und dann das Signal zu senden. Oder einfach wie hier “killall” zu verwenden:
killall -SIGUSR1 dd # sendet das Signal an alle dd Prozesse
Das Terminal mit dem laufenden dd Kommando gibt dann brav seinen Status aus:
1476369209+0 records in
1476369209+0 records out
755901035008 bytes (756 GB) copied, 30066.9 s, 25.1 MB/s
Die O2 Mailbox geht per default nach (gefühlten) 6 Sekunden dran. So kann man das ändern:
**61*333**20#
Jetzt geht die Mailbox erst nach 20 Sekunden dran… Anstelle der 20 kann man natürlich auch eine andere Zahl angeben – wobei ich glaube, dass diese durch 5 teilbar sein muss.
Hier befindet sich die Dokumentation zum md-Modul des Linux-Kernel:
http://www.mjmwired.net/kernel/Documentation/md.txt oder das Original
http://kernel.org/doc/Documentation/md.txt
Interessant sind einige Files zum triggern von RAID-Operationen: z.B.
sync_action oder sync_speed_min
Notiz zum DRBD Split-Brain recovery im primary/primary setup. Nutzung auf eigene Gefahr!
Auf dem nicht aktuellen Node ausführen:
vgchange -a n vmdata # lvm herunterfahren (falls vorhanden)
drbdadm secondary r0 # zu secondary deklarieren
drbdadm -- --discard-my-data connect r0 # eigene Daten ignorieren und zum
# anderen Node verbinden (resync startet)
drbdadm primary r0 # wieder zum primary machen
cat /proc/drbd # status überprüfen
...
0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----
ns:0 nr:80464 dw:80456 dr:2248 al:0 bm:89 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
Hier steht es auch nochmal offiziell.
Folgende mono-Librarys müssen nachinstalliert werden damit KeePass mit mono unter Ubuntu läuft:
sudo apt-get install \
libmono-system-runtime2.0-cil \
libmono-winforms2.0-cil
Beim Hinzufügen einer neuen Partition zu einem RAID kam vorhin folgende Meldung:
mdadm --add /dev/md0 /dev/sda1
mdadm: Cannot open /dev/sda1: Device or resource busy
Gemounted war die Partition nicht – was ich jedoch nicht beachtet hatte war, dass der device-mapper sich die Platte beim booten geschnappt hatte:
dmsetup ls
ddf1_System (253, 0)
ddf1_Systemp2 (253, 2)
ddf1_Systemp1 (253, 1)
D.h. ich musste die Platte noch aus der device-mapper Verwaltung herausnehmen:
# Entfernt alle (!!!) Platten aus der Verwaltung des device-mapper
dmsetup remove_all
Danach klappt auch das hinzufügen mit mdadm wieder:
mdadm -a /dev/md0 /dev/sda1
mdadm: added /dev/sda1