siyman.de | blogging und GNU/*buntu – Backup
… spread the (s)word ;)
Nur zum kurzen Verlinken: wer Probleme dabei hat, ActivInspire von Promethean auf seinem Ubuntu 17.10 zu installieren, sollte einmal kurz hier vorbeischauen. Es klappt ;c)
Update, 29.09.2018: Das verlinkte Tutorial funktioniert ebenso reibungslos unter Ubuntu 18.04 Bionic Beaver, wobei alle Angaben 1 zu 1 erhalten bleiben.
Manchmal gönnt man sich etwas. Nachdem ich zehn Jahre lang meinen eeePC 901 als digitale Schreibmaschine für die Uni eingesetzt habe, war es leistungstechnisch höchste Eisenbahn, aufzurüsten. Das habe ich getan mit einem hübschen Gebrauchtgerät von notebooksbilliger.de: Ein Toshiba Protégé Z30A aus dem Jahr 2014 mit Intel core i5-4310U (vPro), 8 GB Ram, 128 GB SSD auf 13,3 Zoll. Schönes, neues Schreibmaschinchen.
Doch was ist das? Nachdem ich Kubuntu 17.10 aufgespielt und eingerichtet habe und nahezu alles funktioniert (Keyboardhotkeys sind etwas gemein und auch das Einrichten des Touchpads erfordert Geduld) ist mir aufgefallen, dass manchmal, nach dem Aufwachen aus dem Standby (resume from suspend to ram, S3) der Lüfter (mein gröter Fan) auf Höchsttouren lief. Ein Heruntertakten der Geschwindigkeit hat nicht eingesetzt. Einfachste Lösung: Schlafen legen, wieder wecken und gut. Aber warum?
Das ganze geht wohl auf einen Kernel Bug aus dem Jahre 2013 zurück, der zwischenzeitlich angeblich gelöst war, dann wieder nicht … und letztlich alle Linux-Derivate betreffen kann. Gelöst werden kann das ganze wiederum über ein praktisches Skript von franz-knipp, welches derart aussehen muss und von hier stammt:
#!/bin/sh
#
# Reset fan speeds after resume, otherwise they blow at maximum speed
#
# Used as work-around for ACPI kernel bug 58301
# https://bugzilla.kernel.org/show_bug.cgi?id=58301
#
# The idea for this fix was taken from
# http://ubuntuforums.org/showthread.php?t=1761370
#
# Author: franz@qnipp.com
#
# To be saved as /etc/pm/sleep.d/11_fan_3.11.0case “$1” in
thaw|resume)
for i in /sys/class/thermal/cooling_device* ; do
type=`cat $i/type`
if [ “$type” = “Fan” ] ; then
echo 0 > $i/cur_state
fi
done
;;
esac
Das ganze als root (also bspw. aus dem Terminal als “sudo nano /etc/pm/sleep.d/11_fan_3.11.0“) unter /etc/pm/sleep.d/11_fan_3.11.0 anlegen, speichern und beim nächsten Suspend wird es aufgeführt. Simple Lösung für ein nerviges Problem, sehr schön und danke Franz! 😉
Seit Monaten sitze ich an dem Problem, wie ich einen Telekom Hotspot mittels eines Repeaters so verstärken kann, dass zumindest ein Client dahinter ins Internet kann. Einschlägige Foren der Telekom-Community (Telekom hilft) beschwören stets, dass dies nicht ginge. Andere Aussagen bezüglich exotischer Hardware in diversen Foren wiederum bestätigen, dass es doch irgendwie geht. Doch keiner schreibt genau, wie. Außerdem möchte ich doch vorhandene Hardware nutzen, weshalb ich das ganze in dd-wrt nachgebaut habe. Und das mit Erfolg!
Ich habe mich zunächst an dieser Anleitung orientiert und alle Schritte befolgt, die notwendig waren. Das wichtigste ist dabei die IP-Konfiguration:
Router IP: 172.17.2.2
Subnet: 255.255.255.0
DNS: 172.17.2.1
Gateway: 172.17.2.1
Das Netzwerk ist bridged, das WLan heißt Telekom_Fon und das gebridgede Netzwerk kann einen ganz eigenen Namen tragen. Einen DHCPD-Service braucht es gar nicht, wichtig ist lediglich, dass die Firewall aus ist. Auch mit VLAN-Tagging muss ich mich nicht beschäftigen, alles sollte bereits richtig konfiguriert sein.
Doch ein Problem bleibt bestehen: Zwar bekomme ich schon korrekterweise vom Telekom-Hotspot eine dynamische IP zugewiesen, doch sehe ich die Vorschaltseite mit den Zugangsdaten nicht. Warum aber?
Dies liegt am Umstand, dass der Hotspot die erste Mac-Adresse, die er sieht, mit dieser Seite behelligt. Hat nun der Repeater eine andere Mac als mein Client, so geht letzterer leer aus und kann schlicht nicht ins Internet – mein Repeater kann ja nicht antworten. Entsprechend reicht es, das Mac-Adress-Cloning einzuschalten und die Mac-Adresse des Clients zu übertragen. Et voilà – der Hotspot ist repeatet und sollte mittels Richtfunkantenne die entlegegensten Winkel mit Internet versorgen.
Es ist ein tatsächlich seltenes Thema, aber doch nicht gänzlich unbekannt: Interaktive Whiteboards selbst bauen mit vorhandenen Bildschirmen/Projektoren und günstigen Eingabemöglichkeiten. Fertige, marktorientierte Lösungen schlagen mit mindestens 1500,-€ zu Buche, und das ist eindeutig zu fett. Warum also nicht mal DIY?
Einschlägige, preiswerteste Lösungen funktionieren mit einer Wiimote (dem Nintendo Wii/Wii U Controller), einem Infrarotstift und spezieller Software. Doch soll diese ja, obgleich des recht betagten Alters (latest release 2010), auch noch unter aktuellen Linux-Distributionen laufen. Nur wie?
Et voilá – läuft, sitzt, wackelt und hat Luft. Zumindest auf dem von mir getesteten Asus eeePC 901.
Index.php und index.html sind leer. Wirklich leer. Tatsächlich ohne Inhalt, 0 KB. Das ganze nach einem Upgrade von Version 7.0.4 auf 8.0.2. Nicht-PHP-Dateien wie COPYING-APL werden vom Apache ordentlich durchgegeben, sodass es zunächst nach einer per directory Misskonfiguration aussieht. Aber auch das kann nicht der Grund sein, es hat sich ja nichts geändert. Also in die .htaccess reingeschaut – sieht alles gut aus. Wie in Gottes Namen kann das also sein.
Und hier liest es sich dann. Eine Regression einer Abhängigkeit, welche für Core nicht mehr wichtig ist aber von essentiellen Apps wie Calendar und Contacts genutzt wurde, ist entfernt worden. Entsprechend ist es auch nötig, dass die Apps, die darauf zugreifen, zunächst aus dem apps Verzeichnis entfernt werden. Warum das der Owncloud Updater nicht selbst macht bzw. ein Update fährt erschließt sich mir nicht. Ebenfalls ist die Informationspolitik phänomenal schlecht. Zudem ist es strukturell ein Witz, dass Apps die gesamte Installation im Frontend abschießen.
Sei’s drum, nun geht es wieder zufriedenstellend. Übrigens lief Owncloud die ganze Zeit durch, denn Zugriff via remote.php wurde gegeben, was man an Synchronisierungen via Owncloud-App (Android, Linux) sehen konnte.