(99 MB) 00:13:52
2014-04-20 10:00 🛈Video von Dave Jones (eevblog)
Meldung über vertauschte Stromkabel
Alternative Firmware
Meine Lieblingsbeschäftigung :)
(99 MB) 00:13:52
2014-04-20 10:00 🛈Video von Dave Jones (eevblog)
Meldung über vertauschte Stromkabel
Alternative Firmware
Da Eclipse/Java auf all meinen Produktivsystemen – mal wieder – nur am abstürzen ist sollte es „mal schnell“ eine VM richten. Leider gab es bei der Installation der Android Developer Tools den o.g. Fehler. Etwas seltsam, denn die Datei ist vorhanden und lässt sich auch mit less & co lesen. Auch ldd ist keine große Hilfe – statisch gelinkt.
Lösung ist aber in der selben Richtung: Tatsächlich müssen die 32-Bit-Libraries installiert sein. Für Debian/Ubuntu/Mint hilft ein
sudo apt-get install ia32-libs
Nach einem Absturz konnte Eclipse nicht mehr auf den zuletzt geöffneten Workspace zugreifen. Um den Workspace wieder freizugeben muss im zugehörigen Verzeichnis die Datei .metadata/.lock gelöscht werden. Natürlich sollte man vorher mit ps o.Ä. sicherstellen, dass tatsächlich kein Eclipse mehr läuft, andernfalls könnten simultane Zugriffe zu Datenverlust führen.
„Mal schnell“ eine GUI über SSH aufrufen – normal kein Problem: Wenn auf dem Server X11Forwarding in der Datei /etc/ssh/sshd_config auf yes steht lässt sich mit ssh -vCXY user@host eine Verbindung starten, welche GUI-Aufrufe auf dem lokalen Rechner darstellt.
Heute leider nicht: GUI-Aufrufe verabschiedeten sich mit folgender Meldung:
X11 connection rejected because of wrong authentication.
An der SSH-Verbindung konnte man nichts sehen, diese Endete mit
debug1: Requesting X11 forwarding with authentication spoofing.
, also ohne Fehler.
Das Problem ist mal wieder aus der Kategorie „so einfach, dass man es übersieht“: Die Platte war voll…
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda6 29G 28G 0 100% /
Nachdem wieder etwas Platz verfügbar war ging auch x11 per SSH wieder fehlerfrei.
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.
(14.5 MB) 00:04:58
2014-04-17 10:00 🛈Video von eflose: https://www.youtube.com/watch?v=rugXjKDQ2oA
Webseiten zum Thema:
http://netzfrequenzmessung.de
http://www.netzfrequenz.info
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“…
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
sollte das Problem beheben.