Es ist wieder einmal so weit: Ich gehe durch die in den letzten Wochen gesammelten Video-Downloads und post hier die interessantesten resp. kuriosesten Exemplare
Sound of Honda – Ayrton Senna 1989
Sonntag, 11. August 2013
Es ist wieder einmal so weit: Ich gehe durch die in den letzten Wochen gesammelten Video-Downloads und post hier die interessantesten resp. kuriosesten Exemplare
Sound of Honda – Ayrton Senna 1989
Tags: Ayrton Senna, Formel 1, Video, Youtube
Labels: Gesellschaft
Sonntag, 11. August 2013
Es ist wieder einmal so weit: Ich gehe durch die in den letzten Wochen gesammelten Video-Downloads und post hier die interessantesten resp. kuriosesten Exemplare
Mary Roach: 10 things you didn’t know about orgasm
Tags: Mary Roach, Orgasmus, Sex, Sexualität, TED, Youtube
Labels: Gesellschaft
Sonntag, 11. August 2013
Es ist wieder einmal so weit: Ich gehe durch die in den letzten Wochen gesammelten Video-Downloads und post hier die interessantesten resp. kuriosesten Exemplare
Derek Sivers: Weird, or just different?
Tags: Derek Sivers, TED, Youtube
Labels: Gesellschaft
Samstag, 10. August 2013
«It does not matter how slowly you go so long as you do not stop.»
— Konfuzius
Donnerstag, 25. Juli 2013
Auf Grund eines defekten Kabelmodem-Netzteils und einem wackeligen Switch-Netzteil war mein Debian-Server im Elternheim kürzlich für mehr als 3 Tage offline. Für einen IT-Auditoren, welcher tagtäglich mit Load Balancing, Geo-Redundanz und Failovers in Kontakt kommt, eine untolerierbare lange Zeit!
Hintergrund: Als meine linke Hand mittels Telefonsupport das tote Kabelmodem analysierte, hatte er wohl aus Unachtsamkeit das Netzteil des Gigabit-Switches aus der Fassung gerissen (zu seiner Entschuldigung: Irgendetwas ist am Switch-Netzteil defekt, es sitzt nicht mehr fest in der Steckerleiste). Obwohl am nächsten Tag dank des Austauschs des Kabelmodem-Netzteils der Router und ein Teil des Netzwerks wieder online, blieb der Switch offline (ich war beim Austausch des Netzteils nicht vor Ort, konnte deshalb keine Diagnose machen — ansonsten hätte ich den dunklen Switch innert Minuten als Fehlerquelle isoliert).
Was tun? Einerseits habe ich mir auf Ricardo einen iKVM-Switch (Avocent SwitchView IP 1010 Remote Access Device) ersteigert, welchen ich in den nächsten Wochen mit dem Server verbinden werde. Das Netzwerkkabel wird direkt an den Router eingestöpselt, um Fehler in der restlichen Netzwerktopologie auszuschliessen.
Andererseits habe ich mich entschieden, den Server über zwei Netzwerkkarten an das Netzwerk anzubinden. Da ich mir vor langer Zeit eine performante Intel Gigabit-Netzwerkkarte geleistet habe, war mit dem Onboard-NIC meines Asus P5QPL-VM EPU bereits eine zweite Netzwerkschnittstelle vorhanden, die aktiviert werden wollte.
Natürlich ging es aber nicht darum, den Server mittels dieser zweiten NIC an den Router zu verbinden und dieser NIC eine zweite IP-Adresse zu geben — der Server sollte beim Ausfall der einen NIC logisch immer noch unter derselben IP-Adresse ansprechbar sein — physisch halt aber über die Onboard-NIC.
Bonding musste her!
Im Netz gibt es viele (alte und neuere) Anleitungen dazu, aber folgendermassen habe ich den Plunder nach langem Pröbeln zum Laufen gebracht:
In der Datei /etc/modules lädt man das bonding-Modul beim Start des Betriebssystems:
bonding fuse ...
Die Konfiguration des Moduls — ich bin immer noch nicht sicher, ob es das wirklich braucht — legt man in /etc/modprobe.d/bonding ab:
alias bond0 bonding options bonding mode=1 miimon=100
Erläuterungen:
Ob man diese Packages effektiv braucht, kann ich nicht sagen — installiert habe ich sie aber auf anraten von Anleitungen im Netz:
# apt-get install ifplugd ifenslave-2.6
Vorbemerkung: Am Besten macht man sich zuallererst eine Kopie der aktuellen /etc/network/interfaces — bei meinen Tests musste ich zig Reboots durchführen und teilweise wieder die alte Interface-Konfiguration laden, um Dinge aus dem Netz herunterzuladen.
Meine finale, sauber funktionierende /etc/network/interfaces sieht folgendermassen aus:
auto lo iface lo inet loopback auto bond0 iface bond0 inet static address 192.168.100.101 netmask 255.255.255.0 network 192.168.100.0 broadcast 192.168.100.255 gateway 192.168.100.1 bond-mode active-backup bond-miimon 500 bond-slaves none auto eth1 iface eth1 inet manual bond-master bond0 bond-primary eth1 eth2 auto eth2 iface eth2 inet manual bond-master bond0 bond-primary eth1 eth2
Wie man klar erkennen kann, werden hier die bonding-Parameter nach /etc/modprobe.d/bonding erneut gesetzt, und dies teilweise sogar mit anderen Werten. Einige Notizen:
Den Status des Bondings erfährt man über das proc-Dateisystem unter /proc/net/bonding/bond0:
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: fault-tolerance (active-backup) Primary Slave: eth1 (primary_reselect always) Currently Active Slave: eth1 MII Status: up MII Polling Interval (ms): 500 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth2 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:00:00:00:00:00 Slave queue ID: 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:00:00:00:00:00 Slave queue ID: 0
Via: Debian-Installation mit zwei Netzwerkkarten ausfallsicher(er) machen
Tags: active-backup, Bonding, Debian, NIC, Redundanz, Trunking
Labels: Linux
Sonntag, 7. Juli 2013
Auf Grund eines längeren Ausfalls meines Servers (Gründe: Netzteil des Cablemodems ist gestorben, Switch auf Grund eines Wackelkontaktes des Netzteils ohne Strom) war ich heute im Elternhaus. Aus gegebenem Anlass habe ich mich entschieden, die Debian-Installation von einer Samsung HD161GJ (160GB) auf eine hier unbenutzt herumliegende 128GB SSD–Festplatte (Crucial M4-CT128M4SSD2) zu migrieren.
Nachfolgend eine Schritt-für-Schritt-Anleitung, wie dieses Vorhaben in möglichst kurzer Zeit bewerkstelligt werden kann.
Nachdem die Festplatte erfolgreich an den SATA-Bus angeschlossen worden ist, sollte sie sowohl unter /var/log/messages als auch mittels fdisk -l aufgelistet werden. Den von dort übernommenen Device-Namen (in meinem Fall: /dev/sdd) verwendet man, um das Partitionierungstool fdisk zu starten:
# fdisk /dev/sdd
Ich habe mir zuerst eine primäre Partition für /boot erstellt (p, 1024MB) und die Partition bootbar gemacht (a). Anschliessend habe ich eine erweiterte Partition erstellt, in welcher ich einerseits eine Swap-Partition erstellt habe (Typ 82, 1024MB — so gross wie der verfügbare RAM-Speicher) als auch die root-Partition.
Ganz wichtig ist, alle Änderungen am Schluss mittels w auch effektiv auf die SSD zu schreiben.
Die Formatierung ist schnell erledigt. Mittels mkfs.ext4 formatiert man die /boot-Partition:
# mkfs.ext4 /dev/sdd1
… als auch die / (root)-Partition:
# mkfs.ext4 /dev/sdd6
Mittels mkswap formatiert man die Swap-Partition:
# mkswap /dev/sdd5
Solange man die /etc/fstab-Einträge noch nicht umgebogen hat, müssen /boot und / (root) manuell gemountet werden:
# mount /dev/sdd1 /mnt/neu/boot # mount /dev/sdd6 /mnt/neu/root
Der Filesystem-Typ wird automatisch erkannt.
Die beiden Partitionen klont man folgendermassen:
# cd / # rsync -av --one-file-system . /mnt/neu/root # cd /boot # rsync -av --one-file-system . /mnt/neu/boot
Die fstab-Datei muss auf der neuen / (root)-Partition angepasst werden. Die Festplatten sollte man heutzutage mit den UUIDs ansprechen. Die UUIDs findet man mit dem Befehl blkid heraus:
... /dev/sdd1: UUID="3993c6e2-de5c-4227-9cae-637bbfc820b7" TYPE="ext4" /dev/sdd5: UUID="79c00de9-06a7-41e5-a470-641b5f68b909" TYPE="swap" /dev/sdd6: UUID="9672eb79-b6da-4192-a507-45de2662af2d" TYPE="ext4" ...
Die Partitionen definiert man basierend darauf folgendermassen in /etc/fstab:
... #/etc/fstab: static file system information. # #UUID=3993c6e2-de5c-4227-9cae-637bbfc820b7 /boot ext4 discard,noatime,errors=remount-ro 0 2 UUID=79c00de9-06a7-41e5-a470-641b5f68b909 none swap sw 0 0 UUID=9672eb79-b6da-4192-a507-45de2662af2d / ext4 discard,noatime,errors=remount-ro 0 1 ...
Gemäss SSD-Fetischisten sind die Optionen discard,noatime unendlich wichtig, um die Lebensdauer der SSD-Festplatte von 19 auf 19.1 Jahre zu erhöhen … Randbemerkung: Die SSD-Optimierer erscheinen mir ähnlich suspekt wie die Idioten, welche bei jedem Mac-Problem erst einmal raten, Repair Permissions durchzuführen (Richtigstellung: Seriously, ‘Repair Permissions’ Is Voodoo).
Mittels folgendem Befehl wird der grub Bootloader in den MBR der neuen Festplatte geschrieben:
# grub-install /dev/sdd
ACHTUNG: Viele Web-Seiten raten in diesem Schritt, den Computer von einer Linux Live-CD zu starten, mittels chroot das Root des Systems auf die SSD-Festplatte umzubiegen sowie sys, proc und dev neu zu mounten. Wer den hier notierten Anweisungen folgt, kann sich diesen umständlichen Schritt sparen.
In meinem Fall war im BIOS hardkodiert, dass die 160 GB-Platte von Samsung die zu bootende Festplatte war. Da diese nun fehlte, blieb das System ohne Fehlermeldung hängen. Im BIOS musste ich deshalb die SSD-Festplatte neu als Boot-Festplatte aufnehmen.
Da ich grub-install ausgeführt hatte, als Linux noch von der Samsung-Festplatte als Systemplatte lief, wurden die UUIDs der Partitionen dieser Festplatten in den grub-MBR der SSD-Festplatte geschrieben.
Als das BIOS den Bootloader von der SSD-Platte startete, erschien folgende Fehlermeldung auf dem Schirm:
No such Device: ad4103fa-d940-47ca-8506-301d8071d467
Mittels des Befehls ls wurden mir alle erkannten Festplatten und Partitionen angezeigt. Nachdem ich die System-Festplatte in der grub-Nomenklatur ausgemacht hatte, konnte ich grub mitteilen, wie es zu starten hatte:
set prefix=(hd0,msdos0)/grub set root=(hd0,msdos5) insmod normal normal
Mit diesen Angaben fand grub die Partitionen mit den benötigten Boot-Informationen und Debian startete sauber — und dank SSD blitzschnell.
Da das System nun von SSD-Festplatte lief, konnte ich grub-install erneut ausführen. Dieses Mal übernahm grub die UUIDs der SSD-Partitionen, was ich mir mit update-grub bestätigen liess. Der letzte Befehl schrieb die grub-Konfiguration im Klartext in die Datei /boot/grub/grub.cfg.
Tags: ext4, fdisk, grub, grub2, rsync, SSD, Swap
Labels: Linux
Samstag, 29. Juni 2013
Es ist vollbracht: Ich habe soeben alle meine Feeds unter Google Reader gelöscht, nachdem ich sie als OPML-Datei exportiert hatte.
Meine Feeds habe ich zu Feedbin gezügelt und habe mich nicht gescheut, den Jungs dort im Jahr einige paar Dollars für die Dienstleistung zu überweisen.
Mein initiales Setup zum Konsum von RSS Feeds sieht am 29. Juni 2013 folgendermassen aus:
Besonders geschmerzt hat der Umstand, dass Silvio Rizzis Reeder auf dem iPad weiterhin nur die Synchronisation mit Google Reader unterstützt. Ich musste mich deshalb schweren Herzens von dieser App trennen. Mr. Reader funktioniert tadellos mit Feedbin, aber das UI stört mich. Zu viele Schatten und Rundungen, wo doch der Trend bezüglich iOS-Applikationen klar Richtung flachem, skeumorph-losen Designs geht.
Tags: Feeds, Google Reader, iOS, iPad, iPhone, Mr. Reader, ReadKit, Reeder, RSS
Labels: Blogosphäre, IT
Samstag, 22. Juni 2013
Am 11. Juni wurden die in meinem Dashboard eingebundenen Twitter-Feeds plötzlich still. Der Grund: Twitter hat an diesem Tag API 1.0 deaktiviert und macht es seither Entwicklern und Script-Kiddies schwer, mit wenigen Zeilen Code auf öffentliche Twitter-Feeds zuzugreifen.
Wer vor dem selben Problem wie ich steht, sei hier eine kurze Anleitung präsentiert, um die Grundfunktionalität wieder online zu schalten:
Ich habe mich für die PHP-Klasse Codebird entschieden, da ich keine Lust hatte, OAuth-Requests und sonstigen Firlefanz auf eigene Faust zu programmieren.
Zuerst eröffnet man über den offiziellen Entwicklungsbereich mit dem persönlichen Twitter-Konto eine neue Twitter-Applikation. Wichtig ist, dass man sich den Consumer Key und das Consumer Secret merkt, denn diese beiden Variablen werden von der Klasse zur Kommunikation mit Twitter benötigt — authentifizieren sie doch die Applikation gegenüber dem Kurznachrichtendienst.
Nachdem man codebird.php sowie — ganz wichtig — cacert.pem in einem Unterverzeichnis des Web-Roots abgelegt hat, integriert man die Klasse in die bestehen Infrastrukutur:
function __construct() {
parent::__construct();
require_once(dirname(__FILE__) . '/twitter/codebird.php');
\Codebird\Codebird::setConsumerKey('AAAAAAAAAAAAAAAAAAAAA', 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
$this->cb = \Codebird\Codebird::getInstance();
}
Als nächstes benötigt man einen sog. Bearer Token. Einmal generiert kann dieser für jeden weiteren Request an die Twitter API wiederverwendet werden — sofern man den Token nicht manuell deaktiviert. Alternativ kann man diesen Token auch bei jedem Aufruf des PHP-Scripts neu von Twitters Server abholen, was aber nicht einer guten Entwicklungspraxis (Cacheing!) entspricht.
Den Bearer Token erhält man in etwa folgendermassen:
$reply = $this->cb->oauth2_token(); $bearerToken = $reply->access_token; \Codebird\Codebird::setBearerToken($bearerToken);
Jetzt also ist man wie mit API 1.0 in der Lage, eine simple Abfrage abzusetzen — im vorliegenden Fall rufe ich die letzten Tweets von John Gruber ab:
$this->cb->setReturnFormat(CODEBIRD_RETURNFORMAT_JSON);
$jsonData = $this->cb->statuses_userTimeline(array('screen_name' => 'daringfireball','count' => 25),true); // 'true' is needed for app only auth
Damit die Kompatibilität von bestehendem Code mit der neuen Klasse gewahrt wird, nenne ich JSON explizit als Antwortformat. Ganz wichtig ist, dass die Codebird-Methode als zweiten Paramenter true übergeben erhält — dies weist die Klasse an, die Anfrage im Kontext einer Applikation und nicht eines bestimmten Benutzers abzusetzen.
Tags: API, API 1.0, API 1.1, Codebird, Dashboard, PHP, Twitter
Labels: Web
Montag, 10. Juni 2013
Nachfolgend ein E-Mail, welches ich soeben der Kantonspolizei Bern zugestellt habe:
Sehr geehrte Damen und Herren
Ich bin Anwohner der Schlösslistrasse hier in Bern.
In einem Parkfeld der blauen Zone vor unserem Haus (Nr. 39) ist seit mindestens Mitte April 2013 (!) ein Opel Meriva 1.7 DTI mit spanischem Nummernschild „7329 CZG“ parkiert. Nach der Anbringung von Parkbussen haben Kontrolleure des ruhenden Verkehrs das Auto spätestens am 29. April 2013 mit einer Fussfessel versehen (vgl. Foto im Anhang).
An einem Mai-Wochenende habe ich bemerkt, dass zwei Ihrer Beamten vor dem Gefährt gestanden sind und über die Zentrale die Nummer nach Spanien zu übermitteln versucht haben (inklusive der üblichen Sprachprobleme).
Das Auto steht nun nachweislich seit mindestens 45 Tagen in der blauen Zone (vgl. EXIF-Tags).
Meine Vermutungen als Laie:
- Dem Besitzer des Fahrzeugs ist in oder um Bern etwas Schlimmes zugestossen
- Das Fahrzeug wurde in Spanien gestohlen und wurde in die Schweiz gefahren. Dies würde bedeuten, dass der ursprüngliche Besitzer das Fahrzeug in Spanien nicht als gestohlen gemeldet hat, ansonsten dessen Nummer in einer international zugänglichen Datenbank auch für die Kantonspolizei Bern einsehbar wäre und so hätte zurückgeschafft werden können
Item. Gerne möchte ich Sie über diesen Kanal bitten, das Fahrzeug doch endlich abzuschleppen, damit der Parkplatz für Besucher freigemacht werden kann. Ich jedenfalls gehe nicht davon aus, dass sich der Besitzer nach dieser langen Zeit noch bei Ihnen melden wird.
Danke für Ihre Bemühungen
Viele Grüsse
Mario Aeby
Quelle: E-Mail von Mario Aeby an beschwerdestelle@police.be.ch
Am 20. Juni 2013 — nur gerade 10 Tage nach meiner elektronischen Anfrage — habe ich folgende offizielle Antwort erhalten:
die Abklärungen betreffend des Fahrzeughalters eines ausländischen Fahrzeugs nehmen leider immer viel Zeit in Anspruch. Die Kantonspolizei Bern verfügt leider nicht über den notwendigen Platz, wo die blockierten Fahrzeuge aufbewahrt werden können. Daher muss das Fahrzeug bis zum Abschluss der Abklärungen an der Schlösslistrasse abgestellt bleiben.
Wahrscheinlich kann ich im Juni 2014 darüber bloggen, dass das Fahrzeug erfolgreich aus der blauen Zone entfernt wurde.
Merke: Parkplatzterrorismus à la 2013. Gegner des Individualverkehrs reiben sich die Hände.
Tags: Auto, Bern, Blaue Zone, Kantonspolizei, Kritik, Parkbusse, Parkplatz, Polizei, Stadtpolizei
Labels: Gesellschaft
Sonntag, 9. Juni 2013
Wer wie ich zu Hause einen Linux-Server betreibt, benötigt manchmal auch die Möglichkeit, E-Mails zu versenden.
Mit folgenden Einstellungen versende ich mit Linux E-Mails über meinen schweizerischen Qualitätshoster cyon:
... relayhost = [server00.cyon.ch] smtp_use_tls = yes smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = login smtp_sasl_password_maps = hash:/etc/postfix/sasl/outgoing smtp_sasl_security_options = noanonymous
Damit der Versand aber effektiv klappt, muss ich wie im Attribut smtp_sasl_password_maps angegeben noch die Zugangsdaten eines cyon-Mail-Kontos hinterlegen:
[server00.cyon.ch] user@domain.tld:password
Bevor postfix zum ersten Mal gestartet wird, muss diese Datei gehasht werden:
# postmap /etc/postfix/sasl/outgoing
Damit wird eine neue Datei unter /etc/postfix/sasl/outgoing.db angelegt, welche von postfix beim nächsten Start eingelesen wird.
Zu Testzwecken versende ich nun per Kommandozeile eine E-Mail:
$ echo "Bla" | mail -s "Test" user@domain.tld
WICHTIG: Es empfiehlt sich, im cyon-Control Panel eine dediziertes E-Mail-Konto anzulegen, welches nur dem E-Mail-Versand dient. Sollte der Server gehackt werden, kann sich der Angreifer so nicht im privaten E-Mail-Verkehr herumtummeln.
Die beiden Dateien /etc/postfix/sasl/outgoing und /etc/postfix/sasl/outgoing.db sollten zudem nur für den Besitzer lesbar gemacht werden:
# chmod 600 /etc/postfix/sasl/outgoing /etc/postfix/sasl/outgoing.db