Lenovo Thinkpad Yoga: Touchscreen beim Schließen des Deckels deaktivieren

Wenn der Deckel des Lenovo Thinkpad Yoga geschlossen wird (und nicht in den Energiesparmodus wechselt), dann sorgt der Touchscreen für unerwünschte Eingaben auf dem Laptop.

Deshalb soll von nun an beim Schließen des Deckels der Touchscreen deaktiviert und beim Öffnen wieder aktiviert werden.

Der Dienst acpid sorgt dafür, dass Skripte in Abhängigkeit verschiedener Events ausgeführt werden können. Daher legen wir die Datei /etc/acpi/events/lid mit folgendem Inhalt an:

event=button/lid.*
action=/etc/acpi/yoga_lid.sh %e

Anschließend wird die Datei /etc/acpi/yoga_lid.sh angelegt:

#!/bin/bash

DEBUG_LOG=0
log=/home/stephan/yoga_lid.log

function debug() { ((DEBUG_LOG)) && echo "$*" >> $log; }

state=$(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}')

if [ $state == "open" ]; then
	debug "$(date +%Y-%M-%d_%H-%M-%S) Deckel offen - Touchscreen wird aktiviert"
	xinput --enable "ELAN Touchscreen"
	xinput --enable "Wacom ISDv4 EC Pen stylus"
	xinput --enable "Wacom ISDv4 EC Pen eraser"
else
	debug "$(date +%Y-%M-%d_%H-%M-%S) Deckel geschlossen - Touchscreen wird deaktiviert"
	xinput --disable "ELAN Touchscreen"
	xinput --disable "Wacom ISDv4 EC Pen stylus"
	xinput --disable "Wacom ISDv4 EC Pen eraser"
fi

und ausführbar gemacht mittels

chmod a+x /etc/acpi/yoga_lid.sh

Damit das Ganze auch wirklich ausgeführt wird, muss der acpid-Dienst neugestartet werden:

systemctl restart acpid.service

Verbindungsabbrüche bei Lenovo Thinkpad Yoga und OneLink Pro Dock

Mein Thinkpad Yoga hat im Zusammenspiel mit dem OneLink Pro Dock das Problem, dass der in der Dockingstation verbaute USB3-Hub öfters neu gestartet wird und somit etwa neben angeschlossenen USB-Sticks auch die am Dock vorhandene, per USB-zu-Ethernetadapter realisierte LAN-Schnittstelle die Verbindung verliert. Getestet hatte ich bereits zwei verschiedene Dockingstationen, um einen Hardwaredefekt auszuschließen. Außerdem hat mein parallel installiertes Windows 10 diese Probleme nicht.

Wie auch schon im Ubuntuusers-Forum dargestellt, bekomme ich in diesem Fall folgende Meldungen bei udevadm monitor:

KERNEL[620.462898] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/rx-0 (queues)
KERNEL[620.462987] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/tx-0 (queues)
KERNEL[620.463081] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1 (net)
UDEV  [620.465372] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/rx-0 (queues)
UDEV  [620.465449] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1/queues/tx-0 (queues)
UDEV  [620.469248] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0/net/eth1 (net)
KERNEL[620.488358] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0 (usb)
UDEV  [620.489213] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:1.0 (usb)
KERNEL[620.508182] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3 (usb)
KERNEL[620.508368] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1:1.0 (usb)
KERNEL[620.509552] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1 (usb)
UDEV  [620.509591] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1:1.0 (usb)
KERNEL[620.509612] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
UDEV  [620.509658] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3 (usb)
UDEV  [620.510619] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1 (usb)
KERNEL[620.510669] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
UDEV  [620.510699] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
UDEV  [620.511233] remove   /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
KERNEL[620.996518] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
KERNEL[621.198346] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
KERNEL[621.920579] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1 (usb)
KERNEL[621.922551] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1:1.0 (usb)
UDEV  [622.010547] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3 (usb)
UDEV  [622.013885] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0 (usb)
KERNEL[622.314107] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3 (usb)
KERNEL[622.314926] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0 (usb)
KERNEL[622.316478] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0/net/eth0 (net)
KERNEL[622.316523] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0/net/eth0/queues/rx-0 (queues)
KERNEL[622.316551] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.0/net/eth0/queues/tx-0 (queues)
KERNEL[622.316998] add      /devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/2-3.1.3/2-3.1.3:2.1 (usb)

Nach langem Suchen, Probieren und Testen mit verschiedenen Linux-Distributionen und Kernelversionen (getestet mit Ubuntu 14.04 LTS, Kubuntu 15.04, SystemRescueCd, GParted Live CD jeweils mit den Standard-Kerneln, sowie unter Kubuntu 15.04 zusätzlich mit den Kerneln 4.1 und 4.2), konnte ich das Problem lösen.

Ich kann es mir zwar nicht erklären, aber Abhilfe schafft es tatsächlich, die Energieverwaltung für die Soundkarte des Laptops zu aktivieren! Dies wird zwar zum generellen Energiesparen von powertop empfohlen, jedoch hätte ich dies nie im Zusammenhang mit der Dockingstation erwartet.

Die Einstellung lässt sich bspw. mittels

echo '1' > '/sys/module/snd_hda_intel/parameters/power_save';

in der Datei /etc/rc.local realisieren.

Eine etwas elegantere Variante wäre per UDEV-Regel. Dazu wird die Datei /etc/udev/rules.d/99-Yoga-Powermanagement.rules mit folgendem Inhalt angelegt:

SUBSYSTEM=="module", ACTION=="add", KERNEL=="snd_hda_intel", TEST=="parameters/power_save", ATTR{parameters/power_save}="1"

Die dritte und für Thinkpads meiner Meinung nach beste Variante ist die Benutzung des Tools tlp. Installationsanleitungen sind hier zu finden. Hier lassen sich viele Optionen zum Energiesparen relativ leicht einstellen.

Wichtig für die Aktivierung des Powermanagements der Audio-Hardware, insbesondere bei Betrieb am Netzstrom ist die Einstellung

SOUND_POWER_SAVE_ON_AC=1

in der Datei /etc/default/tlp.

darktable und lensfun: Objektivkorrekturen

Die Objektive unserer neuen Kamera, die Panasonic Lumix DMC-GX7, werden erst seit der Version 0.3.0 von Lensfun unterstützt (Objektivliste).
Ubuntu 14.10 ist allerdings noch bei der Version 0.2.8 im Paket liblensfun0.

Da ich auch kein passendes PPA gefunden habe, wird lensfun selbst kompiliert.

Als erstes den Quelltext runterladen und entpacken.
Danach dafür sorgen, dass es auch kompiliert werden kann

sudo apt-get build-dep liblensfun0

Jetzt sollte noch dafür gesorgt werden, dass liblensfun0 deinstalliert wird, damit es nachher keine Komplikationen mit der neuen Version gibt (in diesem Zusammenhang werden bei mir auch digikam und darktable deinstalliert, was erstmal ok ist)

apt-get remove liblensfun0
apt-get autoremove

Danach ins entpackte lensfun-Verzeichnis wechseln und folgende Befehle ausführen

mkdir cmake_build
cd cmake_build/
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../
make
sudo checkinstall -D --pkgname liblensfun0 --pkgversion 0.3.0-lokal

Danach kann man darktable und digikam wieder installieren

apt-get install darktable digikam

In den Objektivkorrekturen bei darktable steht nun für beiden Panasonic-Objektive die Objektivkorrektur bereit.

Kubuntu 14.10: Network-Manager startet nicht mehr automatisch

Nach dem Upgrade von Kubuntu 14.04 auf 14.10 funktionierte nach einem Neustart meine WLAN-Verbindung auf meinem Lenovo Thinkpad X220 nicht mehr.
Beim Booten kam die Meldung:

waiting for network configuration (kurz danach dann:)
waiting an additional 60 seconds for network configuration

Nach einiger Wartezeit startete KDE dann trotzdem, jedoch ohne eine Netzwerkverbindung aufzubauen.
Dann fiel mir auf, dass der Network-Manager nicht wie gewünscht automatisch gestartet ist.

Nach manuellen Starten des Network-Manager-Dienstes mittels

service network-manager start

funktionierten dann auch die Netzwerkverbindungen wieder.

Leider startete der Dienst beim Hochfahren nicht von alleine.

Eine Google-Suche brachte nur Hinweise darauf, dass die Datei /etc/network/interfaces evtl. falsche Einträge enthalte. Das tat sie bei mir nicht. Es standen lediglich die beiden Zeilen

auto lo
iface lo inet loopback

drin.

Ich habe dann festgestellt, dass lediglich das Upstart-Event „static-network-up“ aus irgendeinem Grund fehlte. Wenn ich nämlich im gestarteten System den Befehl

initctl emit static-network-up

aufrief, kam auch der Network-Manager hoch.

Nach einiger Zeit habe ich festgestellt, dass in der Datei /etc/init/networking.conf relativ weit am Anfang der Befehl „ifup -a“ aufgerufen wird, um die Netzwerkschnittstellen zu aktivieren.

Als ich ihn manuell ausführte, kam es bei mir allerdings zu einer Fehlermeldung, dass „bridge“ nicht aktiviert werden konnte (die genaue Meldung bekomme ich aus dem Gedächtnisprotokoll leider nicht mehr hin…).

Das Problem lag daran, dass im Ordner /etc/network/if-pre-up.d noch ein Symlink namens „bridge“ auf eine nicht mehr vorhandene Datei aus dem Paket „bridge-utils“ existierte, welches aber nicht (mehr?) installiert war.

Nach dem Löschen der fehlerhaften Verknüpfung klappt jetzt auch das Hochfahren des Rechners inklusive NetworkManager.

Man sollte also schauen, ob der Befehl

ifup -a

fehlerfrei durchläuft. Dann ist die Wahrscheinlichkeit hoch, dass auch das Upstart-Event „static-network-up“ emit-iert wird, woraufhin wiederum der NetworkManager automatisch startet.

PDF in Graustufen umwandeln

Folgender Befehl wandelt per GhostScript ein farbiges PDF in ein Graustufen-PDF um, um bspw. die Dateigröße etwas zu reduzieren:

gs -sOutputFile=output.pdf -sDEVICE=pdfwrite -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH input.pdf

StartSSL Zertifikate erneuern

Neues Certificate Signing Request erstellen (mit vorhandenem privaten Schlüssel)

openssl req -new -key ~/stephangsell.de.key -out ~/stephangsell.de.csr

Dann bei StartSSL den Inhalt der CSR-Datei hochladen und auf unterzeichneten Schlüssel warten.
Schlüsselinhalt in ~/stephangsell.de.crt speichern.

Folgende 3 Befehle sind nur beim ersten Mal notwendig, um eine gültige StartSSL-Zertifikatskette zu erzeugen

wget https://www.startssl.com/certs/ca.pem
wget https://www.startssl.com/certs/sub.class1.server.ca.pem
cat sub.class1.server.ca.pem ca.pem > startssl_alles.pem

UPDATE April 2016: Mittlerweile bekommt man bei StartSSL eine ZIP-Datei mit dem eigentlichen Zertifikat als .crt-Datei sowie einer Datei namens root_bundle.crt. Diese wird als ~/startssl_root_bundle.crt gespeichert.

Anschließend

cp ~/stephangsell.de.crt /etc/ssl/certs/ && cp ~/stephangsell.de.key /etc/ssl/private/
cp ~/startssl_root_bundle.crt /etc/ssl/pem/
cat ~/stephangsell.de.key ~/stephangsell.de.crt > /etc/ssl/pem/stephangsell.de.pem
cat /etc/ssl/pem/stephangsell.de.pem /etc/ssl/pem/startssl_root_bundle.crt > /etc/ssl/pem/stephangsell.de.startssl_alles.pem
systemctl restart apache2.service ; systemctl restart postfix.service ; systemctl restart dovecot.service 

owncloud + lighttpd: „413 – Request Entity Too Large“

Obiger Fehler führte dazu, dass in ownCloud keine größeren Dateien hochgeladen werden konnten.
Das Problem war leicht zu beheben, da nur der entsprechende Ordner fehlte, in dem lighttpd seine hochzuladenden Dateien zwischenspeichert.

Er wird so angelegt und anschließend schreibbar für den Benutzer www-data gemacht:

mkdir -p /var/cache/lighttpd/uploads
chown www-data:www-data /var/cache/lighttpd/uploads

lighttpd, ownCloud, FolderSync: 417 und Expectation Failed

Seit einiger Zeit hatte ich beim Synchronisieren zwischen ownCloud und Android-Telefon mit FolderSync das Problem, dass ich vom Telefon aus keine neuen Dateien in meine ownCloud hochladen konnte.
Fehlermeldung in FolderSync: ‚Expectation Failed‘.

Im lighttpd-access.log fand ich folgende Zeile:

89.XXX.XXX.XXX - - [17/Dec/2013:06:49:23 +0100] "PUT /remote.php/webdav/testdatei HTTP/1.1" 417 363 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"

Lösen lässt sich das Problem, indem in der Datei /etc/lighttpd/lighttpd.conf folgendes eingefügt wird:

server.reject-expect-100-with-417 = "disable"

Quelle: https://groups.google.com/forum/#!topic/tacitdynamics/k1MssqqVWYc

Debian 6 Squeeze: openssl 1.0.1e und lighttpd 1.4.33 selbst kompilieren (für TLS 1.2 mit PFS)

Nach den ganzen Geschichten um die NSA wollte ich dann meinen Webserver auch mal etwas besser absichern.

Dazu habe ich für den bei mir eingesetzten lighttpd hier eine Anleitung gefunden.

Problem ist allerdings, dass die meisten Chiffre mit der in Debian Squeeze eingesetzten openssl-Bibliothek in der Version 0.9.8o leider nicht funktionieren. Die Lösung: eine neue openssl-Version muss her. Aktuell (Stand November 2013) ist die Version 1.0.1e.

Dank Server4You und dem dort eingesetzten vServer bin ich leider auf das mittlerweile veraltete Debian 6 (Squeeze) angewiesen und kann mangels Unterstützung durch die Server4You-Host-Server nicht auf Wheezy aktualisieren. Deshalb bleibt uns nichts anderes übrig, als die notwendigen Pakete selbst zu kompilieren.

Damit lighttpd (lighty) auch mit der neuen openssl-Version umgehen kann, werden wir die derzeit letzte lighty-Version 1.4.33 runterladen und selbst kompilieren.

Ich gehe hier davon aus, dass lighttpd und openssl bereits aus den normalen apt-Quellen installiert sind.

Zunächst zu openssl:

apt-get build-dep openssl
wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
cd openssl-*
unp openssl-1.0.1e.tar.gz
./config shared zlib-dynamic
#so sähe die config-Zeile für den vollständigen Debian-openssl-Ersatz aus:
#./config --prefix=/usr --openssldir=/etc/ssl --libdir=lib shared zlib-dynamic
make
make test

#ohne den folgenden Befehl läuft checkinstall nicht durch
mkdir -p /usr/local/ssl/lib/engines

Das .deb-Paket erstellt nun checkinstall. Allerdings ändern wir den Paketnamen, damit wir nicht mehr der originalen Debian-openssl-Installation ins Gehege kommen:

checkinstall -D --pkgname openssl-pfs

Da wir die neue openssl-Version in /usr/local/* installieren, muss die originale Debian-Version nicht deinstalliert werden, d.h. wir können es einfach parallel installieren:

dpkg -i openssl_1.0.1e-1_i386.deb

Jetzt kann es mit lighttpd weitergehen. Wir sorgen zunächst dafür, dass alle Build-Abhängigkeiten von Debian gelöst werden:

apt-get build-dep lighttpd

wget http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.33.tar.gz
unp lighttpd-1.4.33.tar.gz
cd lighttpd-*
./autogen.sh
./configure --with-openssl --with-openssl-libs=/usr/lib --prefix=/usr --with-webdav-props --with-webdav-locks

#neues .deb-Paket erstellen
checkinstall -D

#alte Debian-Skripte sichern
cp -r /usr/share/lighttpd/ /root/usr_share_lighttpd

#die aktuelle lighttpd-Installation entfernen
apt-get remove lighttpd

#alte Debian-Skripte wiederherstellen 
#(da diese durch die Deinstallation verloren gegangen sind)
cp -r /root/usr_share_lighttpd /usr/share/lighttpd

Jetzt können wir endlich das gerade erstellte lighty-Paket installieren:

dpkg -i lighttpd_1.4.33-1_i386.deb

Mit einem

service lighttpd restart

starten wir den neu kompilierten Webserver. Danach sollten wir mal testen, ob alle Webseiten noch klappen 😉

Falls ja, können wir den Autostart von lighty wieder einrichten:

update-rc.d lighttpd defaults

Jetzt können wir endlich unsere Konfiguration so anpassen, dass der Webserver mit sicheren Chiffre und Perfect Forward Secrecy (PFS) arbeitet:

ssl.use-sslv2 = "disable"
ssl.use-compression = "disable"
ssl.honor-cipher-order = "enable"
ssl.cipher-list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:RC4-SHA"

Oder Alternativ komplett ohne Unterstützung für RC4 (dadurch keine Unterstützung für Java und IE unter Windows XP):

ssl.cipher-list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA"

UPDATE 20.01.2014:
Das funktioniert natürlich auch mit lighttpd Version 1.4.34 genauso. Einfach oben immer 1.4.33 ersetzen durch 1.4.34.