Das sicherste Betriebssystem? Windows! ;)

Viele Menschen glauben ja, mit einem MAC kann man sich keine Viren einfangen, weil die "besser" sind. Sie sind aber nur weniger stark verbreitet, und somit kein attraktives Ziel für breit angelegte "Angriffe". Aus einem Artikel vom GFI-Blog, welcher sich wiederum auf Daten der National Vulnerability Database stützt geht hervor, dass OSX gefolgt von iOS die meisten Sicherheitslücken überhaupt aufweisen. Auch der Linux-Kernel ist kein unbeschriebenes Blatt was die Fehlerzahl betrifft. Sind es bei den erfassten Windows-Varianten immer unter 40 Fehler, haben wir es bei Apple und Linux je mit über hundert Lücken zu tun.

Anders sieht es bei den Anwendungsporgrammen aus, hier ist der Internet Explorer mit seinen Lücken einsame Spitze. Es empfiehlt sich hier also tatsächlich, aus Sicherheitsgründen einen alternativen Browser zu verwenden. Na mal sehen, wie sich der neue Spartan schlagen wird.

Thumbs.db oder andere unnütze Dateien in der Bash löschen

Wer seine Daten auf einem Samba-Share speichert, sucht vielleicht manchmal nach einer Möglichkeit, verschiedene temporäre Dateien direkt am Server zu entfernen: find . -name "Thumbs.db" -print -delete Das "-print" zeigt die gefundenen Dateien an, damit man etwas Kontrolle hat

Merkzettel: MySQL-Datenbank in console dumpen und wiederherstellen

Backup:
mysqldump -uBENUTZER -pPASSWORT DATENBANK > SQLDATEI
Restore:
mysql -uBENUTZER -pPASSWORT DATENBANK < SQLDATEI

Alles Gute im neuen Jahr

Für das Fotografieren eines Feuerwerks gibt es genügend Workshops und Howtos, sodass ich mir hier weitere Einzelheiten erspare. Am Ende kommt es ohnehin eher darauf an, was man selbst erreichen will. Vielleicht möchte man etwas von der Umgebung auf dem Foto haben, vielleicht bevorzugt man aber auch nur eine Leuchtspur auf schwarzem Hintergrund. Sofern man in RAW fotografiert, kann man hier im Nachhinein das meiste nach seinen Wünschen anpassen.
Neben vielen Bildern mit verschiedenen Belichtungszeiten ist wohl der richtige Standort das wichtigste. Befindet man sich beispielsweise dort, wo die Raketen gezündet werden, hat man mit freiem Auge zwar das beste Bild, für die Kamera werden die Figuren aber selbst bei 16mm Brennweite (am Crop) zu groß. Also besser etwas abseits bleiben.

Eines möchte ich aber noch loswerden: Da die Lichtverhältnisse bei einem Feuerwerk nie konstant sind, gibt es auch keine Allheileinstellung für gute Bilder, man muss einfach oft genug den Auslöser quälen.

1,0s - f 6.3 - ISO 400 - 58mm (87mm) - D300s

1,3s - f 8.0 - ISO 640 - 58mm (87mm) - D300s

1,0s - f 6.3 - ISO 400 - 58mm (87mm) - D300s

1,0s - f 6.3 - ISO 400 - 58mm (87mm) - D300s

1,0s - f6.3 - ISO 400 - 58mm (87mm) - D300s

Heuer haben die Meraner beim Feuerwerk leider etwas gespart, es war nicht nur kürzer als sonst, es fehlten auch zahlreiche tolle Figuren. So war die Bildausbeute etwas spährlich.

Merkzettel: Software Raid5 mit mdadm

Hatte neulich Probleme mit meinem SATA Port Multiplier und die 4 daran angeschlossenen Platten fingen an, nicht mehr zu reagieren. Als Folge wurde mein Software-Raid nicht mehr richtig ausgehängt und ich konnte nicht mehr darauf zugreifen. Es sah zunächst so aus, als würde das 3TB große Array futsch sein - eher unerwünscht.

Das Software-Raid von Linux aber sehr robust und wenn man weiß, wie man es zum Laufen bekommt, bekommt man keine grauen Haare. Ich schreibe mir hier deshalb die nötigen Kommandos auf, die in diesem speziellen Fall nötig waren. Sofern man sicher ist, dass die Platten in Ordnung sind, kann man mit einen --force an der richtigen Stelle wieder auf die Daten zugreifen.

Um einen definierten Zustand zu haben, das Array mal stoppen:

phenom daniel # mdadm --stop /dev/md0
mdadm: stopped /dev/md0

Dann nach Mitgliedern suchen lassen

phenom daniel # mdadm --assemble --scan
mdadm: /dev/md/0 assembled from 2 drives - not enough to start the array.

Jetzt wissen wir was los ist und stoppen nochmal zur Sicherheit

phenom daniel # mdadm --stop /dev/md0
mdadm: stopped /dev/md0

Der eigentliche Auftrag -> Das Array forciert starten:

phenom daniel # mdadm --assemble --scan --force
mdadm: forcing event count in /dev/sdc1(1) from 19687 upto 19694
mdadm: forcing event count in /dev/sdd1(2) from 19683 upto 19694
mdadm: clearing FAULTY flag for device 3 in /dev/md/0 for /dev/sdc1
mdadm: clearing FAULTY flag for device 2 in /dev/md/0 for /dev/sdd1
mdadm: Marking array /dev/md/0 as 'clean'
mdadm: /dev/md/0 has been started with 4 drives.

Will man auf Nummer sicher gehen, kann man auch einen resync manuell anstoßen. Wieder das Array stoppen:

phenom daniel # mdadm --stop /dev/md0
mdadm: stopped /dev/md0

Dann den resync starten

phenom daniel # mdadm --assemble --run --force --update=resync /dev/mdX /dev/sdX /dev/sdY /dev/sdZ
mdadm: /dev/mdX has been started with XYZ drives

Mit einem

cat /proc/mdstat

kann man nachsehen, ob der rebuild auch wirklich läuft und wie lange er brauchen will. Am Ende kann man das Dateisystem dann (hoffentlich) wieder mounten.

Und sonst noch?

# Device dem Array hinzufügen
mdadm --add /dev/mdX /dev/sdaX

# Device aus dem Array entfernen
mdadm --manage /dev/mdX --fail /dev/sdaX
mdadm --remove /dev/mdX /dev/sdaX

# Fehlerhafte Devices entfernen
mdadm --manage /dev/mdX --remove faulty
mdadm --manage /dev/mdX --remove failed

# Partitionstabelle sichern
sfdisk -d /dev/sdX > sdX.partition

# Partitionstabelle wieder einspielen
sfdisk /dev/sdX < sdX.partition