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: <uid>: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
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_allDanach klappt auch das hinzufügen mit mdadm wieder:
mdadm -a /dev/md0 /dev/sda1 mdadm: added /dev/sda1
JavaScript-Schnipsel um mit Google Maps API die Himmelsrichtung einer Linie aus einem Polygon zu bestimmen, lässt sich auch noch einfach erweitern um auch noch die Nord/Süd Richtung zu bekommen (“lat()”) – ich brauchte aber nur West/Ost :
var p1 = polyline.getVertex(0); var p2 = polyline.getVertex(1); var direction = false; if (p1.lng() < p2.lng()) { direction = "east"; } else if (p1.lng() > p2.lng()) { direction = "west"; }