Draußen waren es heute 31°C. Im Rechenzentrum war es offenbar ähnlich warm, denn gegen 15:30 Uhr hat sich ein Datenbankserver in den Feierabend verabschiedet. Der Reboot hat dann gut 30min gedauert (aufgrund der Filesystem-Checks). Das blöde ist allerdings, dass das Raid-1 nen Knacks wegbekommen hat und sich nun neu synchronisiert. Beim Support hat man mir empfohlen, die Festplatten mit smartctl einmal zu überprüfen. Das Ganze funktioniert folgendermaßen:
Kategorie: Administration
Jeder Admin kennt wohl das Problem, dass irgendwelche Verzeichnisse mit der Zeit immer voller werden, wenn man sie nicht zyklisch leer räumt. Ein kleiner Cronjob kann einem hier lästige Handarbeit abnehmen. So löscht folgender Einzeiler beispielsweise alle Apache-Log-Dateien, die älter sind, als 30 Tage:
/usr/bin/find /var/log/apache2/ -name "*.gz" -mtime +30 -exec rm {} \;
Das Ganze als täglichen Cronjob eingerichtet und schon hat man eine mögliche Sorge weniger.
Heute morgen war es mir mit der derzeitigen Filezilla-Version von Ubuntu 10.04 leider nicht mehr möglich, ein insgesamt 1,8 GB großes ZIP-Archiv an der Stelle mit dem Upload fortzusetzen, wo gestern der Feierabend dazwischen gefunkt hat. Da gestern bereits ca. 65% der Datei übertragen wurden, musste eine Alternative her. Eine kurze Suche bei der Suchmaschine meiner Wahl brachte das gewünschte Ergebnis.
rsync -av -P -e ssh localfile.zip user@remotehost:/remotedir/
hat genau das getan, was mir Filezilla verweigert hat. Der Schalter -P ist übrigens der ausschlaggebende.
Kategorien
Murphy mal wieder…
Sehr geehrter Kunde, hiermit nehmen wir Bezug auf die unerwartete Unterbrechung des Netzwerkverkehrs in unserem europäischen Rechenzentrum am heutigen Nachmittag zwischen 16:14 Uhr und 16:17 Uhr MEZ. Aufgrund eines defekten Interfaces auf einer Line-Card kam es zu einer Störung innerhalb eines kleinen Bereichs unseres europäischen Rechenzentrums. Erst bei einer weiteren Analyse und der Behebung des Fehlers kam es zu einer unerwarteten Reaktion der Router, wodurch es zu einer sehr kurzen Nichterreichbarkeit des Rechenzentrums kam. Zwecks Analyse des Vorfalls wurden entsprechende Speicherabbilder erzeugt, die Konfigurationen kopiert und beim Hersteller eine Störungsmeldung geöffnet. Weitere Maßnahmen werden wir gemeinsam mit dem Hersteller koordinieren, wenn die genauen Hintergründe bekannt sind. Wir bitten für die entstandenen Unannehmlichkeiten um Entschuldigung.
Shit happens… nur leider war es quasi in der Hauptverkaufszeit von Buchfreund und in der Hauptarbeitszeit unserer Antiquariatskunden – dementsprechend war die Hotline überlastet. Am besten fand ich den Vorschlag, den Antiquariaten auf einer Webseite die Störung auch in Zukunft mitzuteilen. An und für sich gar nicht dumm, aber welcher Provider bietet mir für überschaubares Geld 100% Ausfallwahrscheinlichkeit, damit ich diese Webseite dort hosten kann? ;-)
Zuerst hat heute die API von Amazon gemeldet, dass die Response-Group „Subjects“ deprecated sei und einige Zeit später streckte ein DNS-Resolver von Server4you die Fühler, wie die Netzwerkauslastung des Buchfreund-Webservers anschaulich illustriert (der Ausfall war zwischen 15 und 16 Uhr).
Der Tag hätte gerne auch unaufgeregter verlaufen können…
Von einer Linux-Commandozeile kann man mit folgendem Aufruf einen SOAP-Request absetzen:
curl -H "Content-Type: text/xml; charset=utf-8" \ -H "SOAPAction:" \ -d @soaprequest.txt \ -X POST http://soapEndpoint
In der Datei soaprequest.txt sollte sich der gesamte SOAP-Request befinden. Falls es Probleme mit dem ggfs. vorhandenen SSL-Zertifikat auf Server-Seite geben sollte, einfach noch die cURL-Option „-k“ hinzu.
Kategorien
mdadm vermeldet „Faulty Spare“
Pünktlich zum Tag der Deutschen Einheit meint eine Festplatte auf dem Buchfreund-Webserver sich verabschieden zu müssen.
/dev/md0: Version : 00.90.03 Creation Time : Wed Jun 17 15:26:29 2009 Raid Level : raid1 Array Size : 97536 (95.27 MiB 99.88 MB) Device Size : 97536 (95.27 MiB 99.88 MB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Sun Oct 3 06:59:13 2010 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 UUID : 3c5f840f:745a0173:7792c71e:7dc17aa4 Events : 0.64 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 0 0 1 removed 2 8 1 - faulty spare /dev/sda1