In einem Shell-Script war diese Funktion von `date` gerade sehr nützlich: Mittels einer Option kann man ausgehend vom aktuellen Datum beliebig weit zurück in die Vergangenheit gehen.
# heutiges Datum (nett formatiert)
> date +”%Y-%m-%d”
2011-12-06# 1 Tag zurück
> date -v-1d +”%Y-%m-%d”
2011-12-05# 1 Jahr und 3 Monate zurück
date -v-1y -v-3m +”%Y-%m-%d”
2010-09-06
Obwohl Firefox 8 schon vor einiger Zeit erschienen ist, wurde es bis jetzt nicht offiziell in Ubuntu 11.10 als Update angeboten. Für Ungeduldige wird praktisch überall gesagt, man soll das ppa:mozillateam/firefox-next einbinden. Aber wer will das schon? Ich möchte jedenfalls nicht ständig die BETA Version von Firefox nutzen – das könnte auf Dauer ärgerlich sein.
Deshalb bin ich froh, dass es in einem Forum den entscheidenden Tipp gab: In ppa:ubuntu-mozilla-security gibt es Firefox 8. Also gleich mal einbinden…
sudo add-apt-repository ppa:ubuntu-mozilla-security
sudo apt-get update
Mit großer Wahrscheinlichkeit wird es hier noch eine Meldung geben:
W: GPG-Fehler: http://ppa.launchpad.net oneiric Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY A6DCF7707EBC211F
Also noch den Schlüssel importieren…
sudo apt-key adv –recv-keys –keyserver keyserver.ubuntu.com A6DCF7707EBC211F
…und endlich Firefox 8 installieren:
sudo apt-get upgrade
Unser 32-Bit Paketbau-Server ist langsam und es werden keine neuen 32-Bit Server mehr installiert. Deshalb gibt es schon länger die Idee, ob man nicht die 32-Bit Pakete auch auf den 64-Bit Servern bauen könnte.
Da wir unsere Pakete mit Tinderbox bauen, waren die ersten Tests schnell durchgeführt. Hierzu haben wir eine 32-Bit Jail auf einem der 64-Bit Tinderbox-Server eingerichtet. Zusätzlich wurde im Tinderbox-Verzeichnis unter scripts/etc/env ein ENV-File für den 32-Bit Build hinterlegt, damit auch wirklich 32-Bit Pakete gebaut werden können. Folgende Anpassungen waren hierfür notwendig:
# cross compiling
export ARCH=i386
export MACHINE_ARCH=i386
export UNAME_m=i386
export UNAME_p=i386# disable CPU optimization
export CFLAGS=-pipe
Die Ergebnisse waren vielversprechend: etwa 800 Pakete konnten sofort fehlerfrei erstellt werden. Aber trotzdem gab es letztendlich noch immer einige wenige 32-Bit Pakete, die wir auf den 64-Bit Servern nicht erstellen konnten:
Das war also das technische K.O. für unsere Anstrengungen, auf Cross-Compiling umzusteigen. Zumindest vorerst. Denn wir haben nun nach einiger Zeit einen neuen Versuch gestartet. Diesmal haben wir aber nicht FreeBSD 7.3 auf dem Build-Host verwendet, sondern ein frisches FreeBSD 8.2 ausprobiert. Und schon konnten alle Pakete fehlerfrei erstellt werden. Ich habe nicht recherchiert, welche Änderungen zwischen FreeBSD 7.3 und 8.2 dies ermöglicht haben, aber offenbar gibt es Verbesserungen in Sachen Cross-Compiling.
Das will niemand: Alle Disklabel sind weg! Gut zu erkennen an folgender Ausgabe:
sudo disklabel /dev/da0s1
# /dev/da0s1:
# size offset fstype [fsize bsize bps/cpg]
c: 286734208 0 unused 0 0 # “raw” part, don’t edit
Es ist also nur noch die Raw-Disk “c” übrig, somit kann kein Dateisystem von dieser Disk mehr gemountet werden. Die Konsequenz: Nichts geht mehr. Zum Glück gibt es in den Ports ein Tool, um die Disklabel wiederherzustellen: sysutils/scan_ffs. Der Aufruf ist dann ganz einfach:
scan_ffs -l /dev/da0s1
Das Tool stellt die Disklabel nicht automatisch wieder her, sondern zeigt sie nur an. Wer dann noch Schwierigkeiten haben sollte, mit diesen Infos wieder ein Disklabel zu erzeugen, kann hier weiterlesen.
Heute hatte ich den Fall, dass ein MySQL Slave in einer Master-Master Replikation sein Relay Log nicht mehr lesen konnte:
Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master’s binary log is corrupted (you can check this by running ‘mysqlbinlog’ on the binary log), the slave’s relay log is corrupted (you can check this by running ‘mysqlbinlog’ on the relay log), a network problem, or a bug in the master’s or slave’s MySQL code. If you want to check the master’s binary log or slave’s relay log, you will be able to know their names by issuing ‘SHOW SLAVE STATUS’ on this slave.
Daraufhin bin ich der Empfehlung aus der Fehlermeldung gefolgt und habe das Relay Log manuell geprüft:
$ mysqlbinlog db02-relay-bin.000636
[Inhalt vom Relay Log]
ERROR: Error in Log_event::read_log_event(): ‘Sanity check failed’, data_len: 170, event_type: 80
ERROR: Could not read entry at offset 13712544: Error in log format or read error.
Es stimmt also: mein Relay Log ist wirklich kaputt. Was nun? Diesmal kam der entscheidende Hinweis nicht aus der exzellenten MySQL Dokumentation, sondern wieder aus einem Blog. Die Lösung ist ganz logisch: wir zwingen den Slave, das Binary Log nochmal vom Master abzurufen.
Dazu muss zunächst SHOW SLAVE STATUS\G; in der MySQL Konsole ausgeführt werden. Wichtig: Die Werte für Relay_Master_Log_File und Exec_Master_Log_Pos notieren, da wir sie später benötigen. Dann STOP SLAVE; in der MySQL Konsole ausführen, um die Replikation anzuhalten. Jetzt kann das Binary Log neu geholt werden:
mysql> CHANGE MASTER TO master_log_file=’<Wert von Relay_Master_Log_File>’, master_log_pos=<Wert von Exec_Master_Log_Pos>;
Danach die Replikation mit START SLAVE; wieder in Gang setzen. Letztendlich sollte beim Aufruf von SHOW SLAVE STATUS\G; die Replikation wieder fehlerfrei arbeiten.
Praktisch überall lassen sich falsche Informationen zum Thema “Rollierung von MySQL Logdateien” finden. Die meisten Erklärungen sehen vor, ein spezielles Skript namens mysql-log-rotate in den Rollierungsprozess einzubinden. Alternativ darf auch manuell der Befehl mysqladmin flush-logs ausgeführt werden. Alles Quatsch. Es genügt folgender Eintrag in /etc/newsyslog.conf:
/usr/log/mysql/general.log mysql:mysql 640 7 * $D0 J /var/db/mysql/hostname.pid
Natürlich müssen die Pfade noch den tatsächlichen Gegebenheiten angepasst werden. Aber danach wird das Log jede Nacht rolliert und MySQL geht es trotzdem gut. Warum ist das auch ohne das zuvor genannte Skript kein Problem? Weil MySQL automatisch ein FLUSH LOGS und FLUSH PRIVILEGES ausführt, wenn es ein SIGHUP empfängt. Genau dieses Signal schickt newsyslog bei der Rollierung der Logs.
Danke an Bram Schoenmakers, der diese Informationen in seinem Blog gepostet hat.
Heute durfte ich einen Server nach längerer Uptime mal wieder rebooten, weil ein Upgrade des installierten FreeBSD 7.1 bevorstand. Davor möchte ich gerne sicherstellen, dass der Server tatsächlich noch fehlerfrei bootet. Gute Idee, wie ich mal wieder feststellen konnte. Nach dem Reboot begrüßte mich das FreeBSD nämlich mit folgender Meldung:
Trying to mount root from ufs:/dev/da0s1a panic: Going nowhere without my init!
Was nun? Erstmal habe ich den Server mit einer FreeBSD Live-CD gestartet, einen fsck angeworfen und mich etwas umgesehen. Zuerst das Offensichtliche klären: Ist init wirklich noch da und funktionstüchtig? Ja, also ging die Suche weiter. Irgendwann schau ich mir die /boot/loader.conf an…
kern.dfldsiz="4294967296" kern.maxdsiz="4294967296"
…und komme auf die abwegige Idee, dass mein Auto-Tuning-Script mir einen Streich spielen könnte. Dieser 32-Bit Server hat zwar 4 GB RAM, aber laut dmesg…
real memory = 4093616128 (3903 MB) avail memory = 4003577856 (3818 MB)
…stehen uns die natürlich nicht vollständig zur Verfügung. Also habe ich die Werte erstmal komplett aus /boot/loader.conf rausgelöscht und schon bootete der Server wieder. Im nächsten Schritt habe ich die Werte auf 2 GB halbiert, was auch noch gut funktionierte. Der Server läuft wieder, auf zum nächsten Abenteuer… zum Beispiel das Auto-Tuning-Script überarbeiten. Wer noch mehr Hintergrundinformationen möchte, kann ja mal hier klicken.
Wie bekomme ich die Kontakte von meinem alten Sony Ericsson W810i Handy in das neue iPhone? Zuerst dachte ich an die PC Suite von Sony Ericsson. Aber die nächsten Fragen waren natürlich: Wenn die Kontakte erstmal mit der PC Suite synchronisiert wurden, wie geht es dann weiter? In das Windows Adressbuch kopieren? Dann mit iTunes auf das iPhone synchronisieren? Bleiben bei dieser Sync-Orgie alle Daten unverändert erhalten? Fragen über Fragen…
Statt es einfach auszuprobieren, habe ich weiter gesucht. Und das war gut so, denn ich bin auf eine geniale Lösung aufmerksam geworden: PhoneCopy. Dabei handelt es sich um einen Web-Service, es muss also (fast) keine Software installiert werden. Das für mich Erstaunliche dabei ist, dass viele uralte Handys wie mein W810i die Synchronisation bereits unterstützen. Genial.
Also habe ich die vorbildliche Anleitung für mein Sony Ericsson W810i befolgt und erfolgreich synchronisiert. Danach noch die selbsterklärende App für das iPhone heruntergeladen und in Windeseile waren dort alle Kontakte drin. Ich bin begeistert!
Was kann PhoneCopy sonst noch? Die synchronisierten Daten können im persönlichen Bereich auf der Website eingesehen und verändert werden. Außerdem kann das als Backup der Kontakte genutzt und bei Bedarf wiederhergestellt werden. Und ich kann Änderungen über einen längeren Zeitraum dort einsehen und nachvollziehen. Sehr praktisch.
Anforderung:
Zusätzlich zum Überschriftenfeld wird ein Feld für den Untertitel bei Contentelementen (Seiteninhalten) benötigt.
In folgendem Beispiel wird das Untertitel-Feld für die Contentelemente “Text” und “Text mit Bild” gesetzt.
Lösung:
<?php
if (!defined ('TYPO3_MODE')) {
die ('Access denied.');
}
t3lib_div::loadTCA('tt_content');
#t3lib_extMgm::addTCAcolumns('be_groups',$tempColumns,1);
t3lib_extMgm::addToAllTCAtypes("tt_content", 'subheader;;8','text,textpic', 'after:header');
$GLOBALS['TCA']['tt_content']['columns']['subheader']['config']['type'] = 'text';
$GLOBALS['TCA']['tt_content']['columns']['subheader']['config']['cols'] = 48;
$GLOBALS['TCA']['tt_content']['columns']['subheader']['config']['rows'] = 3;
t3lib_extMgm::addStaticFile($_EXTKEY,'static/css_styled_content_subheader_output/', 'subheader output in C-Types');
?>
# Subheader in verschiedenen C-Typen (text,textpic) ausgeben lassen
tt_content.text = COA
tt_content.text {
15 = TEXT
15 {
field = subheader
required = 1
dataWrap = <h2>|</h2>
htmlSpecialChars = 1
editIcons = tt_content:subheader,layout
editIcons.beforeLastTag = 1
editIcons.iconTitle.data = LLL:EXT:css_styled_content/pi1/locallang.xml:eIcon.subheader
prefixComment = 2 | Subheader:
}
}
tt_content.textpic = COA
tt_content.textpic {
15 = TEXT
15 {
field = subheader
required = 1
dataWrap = <h2>|</h2>
htmlSpecialChars = 1
editIcons = tt_content:subheader,layout
editIcons.beforeLastTag = 1
editIcons.iconTitle.data = LLL:EXT:css_styled_content/pi1/locallang.xml:eIcon.subheader
prefixComment = 2 | Subheader:
}
}
Man muss ja nicht immer alles selbst schreiben. Deshalb verweise ich an dieser Stelle mal auf den sehr guten Artikel von Kai ‘Oswald’ Seidler. Wer sich schon immer gefragt hat, warum der Exclude bei rsync nicht wie vermutet funktioniert, der sollte einen Blick riskieren.