Alle Beiträge von adlerweb

Arch Linux: Schlüsselfehler bei Update

Nur „mal kurz“ updaten – „pacman -Syu“, paar mal Enter und schon ist das notwenige Übel von der Todo-Liste verschwunden. Nunja, üblicherweise. Auf einem System trat heute nach dem Download folgender Fehler auf:

Fehler: key "B02854ED753E0F1F" could not be looked up remotely
Fehler: Erforderlicher Schlüssel fehlt im Schlüsselbund
Fehler: Konnte den Vorgang nicht durchführen (Unerwarteter Fehler)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Ursache ist ja schon recht gut beschrieben: Ein Paket ist offenbar mit einem Key signiert, den das System noch nicht kennt. Üblicherweise versucht pacman dann diesen von den Arch-Servern(?) nachzuladen. In meinem Fall erfolglos – der Rechner hat keinen direkten Internetzugang und kommt nur per HTTP-Proxy nach draußen.

Um den Fehler zu beheben sollte man vor dem Systemupdate das Paket archlinux-keyring neu installieren. Dieses bringt alle aktuellen Schlüssel mit und aktualisiert die lokale Datenbank, danach sollten auch die restlichen Aktualisierungen problemlos laufen.

WordPress, HTTPs optional und die SEO-Leute

OK, Zertifikate erneuert, dann auch noch „schnell mal“ HTTPs im Blog einschalten. Oder auch nicht…

Ich habe bereits seit langem den Adminbereich meines Blogs über HTTPS eingebunden, hierzu ist lediglich ein einfaches

define('FORCE_SSL_ADMIN', true);

in der wp-config.php notwendig. Den Blog selbst hatte ich seinerzeit auf HTTP gelassen, denn nicht jeder hat die von mir verwendete Zertifizierungsstelle CACert installiert was zu unschönen Warnungen führen würde. Optional wäre toll, aber damals zeigte sich schnell, dass die SEO-Funktionen von WordPress aus dieser einfachen Sache mal wieder eine lange Geschichte machen. Anstatt Anfragen einfach zu verarbeiten wird zur Optimierung der Suchmaschinenplatzierung alles unbekannte auf die konfigurierte Hauptadresse umgeleitet – incl. dem für WordPress unbekannten https://….

Im Netz findet man häufig kleine Codefragmente, welche in der wp-config.php die interenen Adressen bei HTTPS-Zugriffen umbiegen sollen. In meinem Fall biss sich diese Methode leider mit dem verwendeten Cache-Plugins. Fündig geworden bin ich im Plugin „WP-SSL„. Über wenige Filter werden die Adressen direkt über die API ersetzt. Da so auch die Cacher entsprechende Ausgaben erhalten ist auch der parallele Einsatz kein Problem. Das Plugin ist für mich eher Vorlage als Fertiglösung gewesen – einige Zeilen für alternative URLs und Plugins musste ich ergänzen, aber generell ist die Methode praktisch und schnell zu verstehen.

Rekonfiguration erfolgreich – somit ist diese Seite jetzt auch offiziell (auf Wunsch) per HTTPS erreichbar – selbstverständlich auch mit PFS und paranoiden Schlüssellängen, auch wenn es wohl für einen einfachen Blog nicht wirklich etwas zur Sache tut ;).

Anm: Offenbar gibt es doch noch den ein oder anderen Client (IE auf WinXP, Android 2.3), welche noch kein SNI unterstützen – für die heißt es: „Sorry, aber ohne Update geht’s nur ohne“…

Gentoo: You’re missing a /dev/fd symlink to /proc/self/fd.

Hui, ich dachte der wäre schon mal da gewesen, aber hey… Während eines Updates verabschiedete sich Portage mit folgender Meldung:

Gentoo: You're missing a /dev/fd symlink to /proc/self/fd.

Auslöser ist, dass das udev-initscript, zumindest auf meinem hardened-System, nicht bei Systemstart ausgeführt wird. Ein kurzes

rc-update add udev sysinit
/etc/init.d/udev start

[Source]

sollte das Problem beheben.

Windows 8.1: Meteo-Apps zeigen nur Splashscreen

Das neue Update 1 für Windows 8.1 treibt einen doch dazu die Kachelkiste nochmal näher anzuschauen – üblicherweise sitzt sie nur als Monitoring-Anzeige in der Ecke und wird nur für Softwaretests aktiv genutzt. Schnell mal in den Store und… Ach nein – ich vergaß. Alle hier verwendeten Rechner wurden seinerzeit mit Windows 8 installiert und über den Store auf 8.1 aktualisiert – mit einigen Nebenwirkungen: Nirgendwo konnten nach dem Update Meteo-Apps aufgerufen werden. Nach dem Start wird lediglich der Splash-Screen angezeigt, danach landete man wieder auf der Übersicht. Das früher gut funktionierende Motto „Installieren wir das Update nochmal drüber“ fällt leider flach, da MS diese nicht mehr Separat anbietet sondern – aus Gründen der Usability – nur im Store bereit stellt. Klasse, denn a) Er lässt sich nicht mehr öffnen und b) Da das Update ja schon da ist ließe es sich vermutlich nicht mehr auswählen.

Die Lösung war nach einigem Hin und Her nicht wirklich auszumachen, zumeist dürfte es aber an Registry- oder Datei-Fehlern oder zu langer Ladezeit liegen. Gegen letzteres hilft es üblicherweise zu prüfen, ob die aktuellsten SATA/AHCI und Grafikkartentreiber installiert sind. Auch Virenscanner sind häufig nur notdürftig auf Windows 8.1 portiert worden und führen häufig zu einem solchen Verhalten. Gegen Systemfehler stellt Microsoft ein Tool namens „AppsDiagnostic.diagcab“ zu Verfügung, welches Registry & Dateien prüft und automatisch korrigiert.

Wie immer sollte man natürlich vor allen Änderungen ein Backup machen. In meinem Fall konnte ich alle betroffenen Rechner wieder mit Kacheln bestücken und die Update-Orgie in Gang setzen.

wget 1.14 & Perl 5.18.x: Expected text after =item, not a number

Beim Kompilieren eines OpenWRT machte eben wget-ssl dicke Backen: „Expected text after =item, not a number“ im Dokumentationsordner ließ die letzte Meldung verlauten. Grund sind striktere Syntaxchecks in Perl ab Version 5.18. Im Wget-Upstream ist das Problem bereits erledigt (0102e0e7e503c4fcd70a14eba4ffe357c84de3bb), für 1.14 gibts einen passenden Patch von Javier Vasquez, bei OpenWRT schwirrt auch etwas passendes von Jonathan McCrohan herum, hat es aber noch nicht in den Trunk geschafft.

Wer dem ganzen Problem ausweichen möchte: Seit Januar ist wget 1.15 verfügbar, hierzu einfach in feeds/packages/net/wget/Makefile folgende Änderungen vornehmen:


11c11
< PKG_VERSION:=1.14 --- > PKG_VERSION:=1.15
16c16
< PKG_MD5SUM:=316f6f59292c9098ad81fd54f658c579 --- > PKG_MD5SUM:=7a279d5ac5594919124d5526e7143e28

Fotos Karnevalsumzug Plaidt 2014

Hat etwas gedauert, aber nun sind auch die Fotos aus Plaidt hier und auf 56648.de zu finden. Leider gabs in der Zeitung keine Liste der Teilnehmer, daher belasse ich es mal unsortiert. Neben den „normalen“ Fotos stehen die 2 Panoramen auch höher aufgelöst auf Flickr zur Verfügung.

Bild: https://adlerweb.info/gallery2/gallery2/d/48089-4/IMG_9728a-IMG_9730_scale.jpg

Und wo twitter ich jetzt, dass Twitter down ist?

…oder: Mit dezentralen Diensten wär‘ das nicht passiert… Ich verweise nochmal dezent auf status.net, pump.io & co 😉


An dieser Stelle traure ich im Übrigen dem Fail Whale hinterher – war viel schöner als der jetzige Roboter 😉

W     W      W        
W        W  W     W    
              '.  W      
  .-""-._     \ \.--|  
 /       "-..__) .-'   
|     _         /      
\'-.__,   .__.,'       
 `'----'._\--'      
VVVVVVVVVVVVVVVVVVVVV

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2014/03/Bildschirmfoto-Twitter-Error-Chromium-300×93.png


Bild: https://www.adlerweb.info/blog/wp-content/uploads/2014/03/Bildschirmfoto-Twitter-Maintenance-Chromium-1-300×94.png Ja, 2012!

Oha – Status.twitter.com hat reagiert:

Service issue 2 minutes ago
Most users are experiencing issues accessing Twitter on web and mobile apps. We’re looking into it.


Der Retweet-Button neben der Meldung, dass Twitter nicht funktioniert, ist im Übrigen sehr hilfreich 😀


Newsticker

  • [19:33] Seit 30 Minuten schon Stille in der Timeline – die ersten Sekten versammeln sich und drohen gegenüber Mitbürgern aus Verzweiflung einer sinnvollen Beschäftigung nachzugehen
  • [19:35] Ein verwirrt dreinschauender junger Mann erklärt uns: „So kann’sch ja nur Arbeit’n!“. Seinen Namen kann er ohne Profilzugriff leider nicht nennen.
  • [19:36] Sebastian Nerz prügelt als erster einen Tweet durch die noch immer schwankenden Server. Auch er gedenkt des Fail-Whales.
  • [19:36] Dank beharrlichem Dauerklicken macht sich nun auch mein kopierter ASCII-Fail-Whale auf den Weg über die Twitter-Server
  • [19:41] Immer mehr Leute entdecken die Macht des Dauerklickens und können so ihre weltbewegenden Neuigkeiten verbreiten – und die Twitter-Server noch weiter in die Knie zwingen.
  • [19:42] Wir korrigieren die letzte Aussage – es handelt sich zum Großteil nicht über weltbewegende Neuigkeiten sondern um eine sonderform des so genannten „Twitter-Bashings“, wie ein Experte uns soeben bestätigte.
  • [19:46] Twitter-Mitarbeiter DanaDanger postet erste Informationen über den Ausfall
  • [19:48] Soeben sind die Promoted Tweets zurückgekehrt. Analysten werten dies als ein gutes Zeichen, in einer nicht repräsentativen Umfrage unter 2 Nutzern wurde die Maßnahme eher als „nervig“ eingestuft.
  • [19:49] Es ist etwas essbares in der Redaktion eingetroffen, der Newsticker schließt somit vorübergehend

Aufzeichnung des Karnevalsumzug Saffig 2014

Die Aufzeichnung des diesjährigen Karnevalsumzuges Saffig ist jetzt auf YouTube verfügbar:

http://www.youtube.com/watch?v=TI7q-BSfKK8

Zugverlauf

  • Baltasar-Neumann-Straße / Im Bann / Friedhofstraße (Aufstellen)
  • Bassenheimer Straße
  • Hauptstraße
  • Plaidterstraße
  • Von-der-Leyenstraße
  • Andernacherstraße
  • Eckerstraße
  • Neuwiederstraße
  • Hauptstraße
  • Bassenheimerstraße
  • Pösch
  • Neuwiederstraße
  • Auflösen Ecke Andernacherstraße/Plaidterstraße

Zugaufstellung