sudo apt-cdrom add

Mir passiert es z.B. öfter, dass ich vergesse bei der Installation das Paket “vlan” mit zu installieren und stehe dann ohne Netzwerk da…

# 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.

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!

• grafisch ansprechend und freundlich formuliert
• Text enthält Details für Laien und technisch Interessierte (was auch die Zielgruppe der Seite ist)
• gut finde ich hier auch ausnahmsweise die Twitter-Integration. Auch wenn die eigenen Systeme/Datenbanken down sind, funktioniert die Twittereinbindung in eine statische Fehlerseite noch – da sie clientseitig eingebunden wird. Über der Stand der Arbeiten kann der Betreiber so noch informieren.

Wenn ich weiss warum etwas nicht funktioniert, ärgere ich mich auch nicht darüber…

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.

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

**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.

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

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.