Eigene Chips in lm_sensors konfigurieren

Linux verfügt über ein großartiges Programm zum Lesen und Anzeigen von Sensorsdaten. Das Paket heißt lm_sensors. Da es aber sehr viele verschiedene Mainboards, respektive Chips auf den Boards gibt, kann es vorkommen, daß aktuelle Chips nicht richtig ausgewertet werden.

Der Chipsatz „it8721-isa-0290“ auf meinem Asusboard ist so ein Chip.

Das Problem

Wenn man sensors aufruft, erscheint z.B. so eine Ausgabe:

it8721-isa-0290
Adapter: ISA adapter
in0:          +2.82 V  (min =  +1.22 V, max =  +0.19 V)  ALARM
in1:          +2.80 V  (min =  +1.93 V, max =  +1.42 V)  ALARM
in2:          +0.80 V  (min =  +1.84 V, max =  +2.38 V)  ALARM      
+3.3V:        +3.34 V  (min =  +2.71 V, max =  +0.38 V)  ALARM
in4:          +1.20 V  (min =  +0.17 V, max =  +2.03 V)
in5:          +2.50 V  (min =  +1.18 V, max =  +2.52 V)  ALARM
in6:          +1.92 V  (min =  +1.43 V, max =  +0.23 V)  ALARM
3VSB:         +4.61 V  (min =  +3.65 V, max =  +2.76 V)  ALARM      
Vbat:         +3.36 V  
fan1:        1912 RPM  (min =  128 RPM)
fan2:           0 RPM  (min =   53 RPM)  ALARM           
fan3:           0 RPM  (min =   10 RPM)  ALARM           
temp1:        +39.0°C  (low  = -54.0°C, high = -127.0°C)  ALARM  sensor = thermistor
temp2:        +34.0°C  (low  = +19.0°C, high = -123.0°C)  ALARM  sensor = thermistor
temp3:       -128.0°C  (low  = -85.0°C, high = -32.0°C)  sensor = disabled 

Wie man leicht erkennen kann, sind die meisten Min/Max Werte falsch und folglich auch die ALARM Meldungen am Ende der jeweiligen Sensoren. Das liegt daran, daß in der /etc/sensors.conf keine Einträge für diesen Chip enthalten sind.

Fügen Sie am Ende der Datei einfach folgende Einträge an:

chip "it8721-*"
 label temp1 "CPU Temp"
 label fan1 "CPU Fan"
 label in0 "Core 0"
 set in0_min 3.0 * 0.90
 set in0_max 3.0 * 1.10
 set in1_min 3.0 * 0.90
 set in1_max 3.0 * 1.10
 set in2_min 0.8 * 0.90
 set in2_max 2.0
 set in3_min 3.3 * 0.90
 set in3_max 3.3 * 1.10
 set in6_min 1.9 * 0.95
 set in6_max 1.9 * 1.05
 set in7_min 5.0 * 0.90
 set in7_max 5.0 * 1.10
 set fan2_min 0
 set fan3_min 0
 set temp1_min 0
 set temp1_max 86
 set temp2_min 0
 set temp2_max 128

und dann starten Sie sensors mal mit dem Zusatz „-s“ : sensors -s . Danach ist die Ausgabe für Ihren Chipsatz korrekt.

Sie müssen erstmal herausbekommen, welchen Chip Sie da überhaupt haben, bevor Sie das obige Nachmachen können. Dabei hilft Ihnen sensors-detect . In einem Frage- und Antwortspiel werden Sie über Ihre Chips ausgefragt. Antworten Sie nach besten Wissen und Gewissen, dann klappt das schon.

YUM: Abhängigkeitsprobleme lösen

Es kann vorkommen, daß einzelne Abhängigkeiten bei einem Update über mehrere Repositories nicht aufgelöst werden können. Z.b. weil im Fedora Hauptrepo eine neuere Version des Pakets verteilt werden soll, wie in den anderen Repos referenziert werden. Oder anders ausgedrückt, jemand hat sein Update noch nicht fertig und hinkt hinterher.

Am Beispiel des jüngsten QMMP Updates, möchte ich das mal verdeutlichen :

---> Paket qmmp.x86_64 0:0.7.4-1.fc20 markiert, um aktualisiert zu werden
 --> Abhängigkeit qmmp(x86-64) = 0.7.4 wird für Paket qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 verarbeitet
 --> Abhängigkeitsauflösung beendet
 --> Transaktionsprüfung wird ausgeführt
 ---> Paket qmmp.x86_64 0:0.7.4-1.fc20 markiert, um aktualisiert zu werden
 --> Abhängigkeit qmmp(x86-64) = 0.7.4 wird für Paket qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 verarbeitet
 --> Abhängigkeitsauflösung beendet
 Fehler: Paket: qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 (@rpmfusion-free-updates)
 Benötigt: qmmp(x86-64) = 0.7.4
 Entfernen: qmmp-0.7.4-1.fc20.x86_64 (@updates)
 qmmp(x86-64) = 0.7.4-1.fc20
 Aktualisiert durch: qmmp-0.7.7-1.fc20.1.x86_64 (updates)
 qmmp(x86-64) = 0.7.7-1.fc20.1
 Verfügbar: qmmp-0.7.2-1.fc20.x86_64 (fedora)
 qmmp(x86-64) = 0.7.2-1.fc20
 Sie können versuchen, mit --skip-broken das Problem zu umgehen.
 Sie könnten Folgendes versuchen: rpm -Va --nofiles --nodigest

Was steht da jetzt wirklich ?

QMMP soll von 0.7.4 auf 0.7.7 aktualisiert werden,
ABER das qmmp-plugins-freeworld-0.7.4-1 Paket braucht 0.7.4-1 und nicht 0.7.7 .

Den Vorschlag SKIP BROKEN kann man einfach vergessen. Der Zustand kommt öfter vor,
deswegen hier gleich mal die Lösung:

 #  vi /etc/yum.conf

Ans Ende der Main-Sektion schreibt man nun einfach „exclude=qmmp*“ .

Das könnte dann so aussehen :

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=qmmp*

#  This is the default, if you make this bigger yum won't see if the metadata

Ein „yum update“ wird jetzt durchlaufen. In einer Woche können wir dann mal nachsehen, ob das qmmp-plugins-freeworld Paket auf Stand ist.

Systemd schickt alte Einträge zum Syslogd

Die Bild-Zeitung könnte mit der folgenden Schlagzeile öffnen:

„Systemd wahnsinnig – Syslogd kurz vor dem Zusammenbruch“

Wenn man einen Produktivserver im Netz hat, möchte man solche Schlagzeilen lieber nicht lesen, dennoch können Sie passieren. Mit den folgenden kleinen Anweisungen kann man das Desaster beenden.

Aber zunächst mal zum eigentlichen Problem:

Der Syslogd läuft mit 95% CPU Last, aber ansonsten ist auf dem System nichts zu sehen, was die Nachrichten produzieren könnte. Der erste Blick geht daher nach /var/log/messages:

Jul 16 20:21:01 systemd: Started Session 29860 of user root.
Jul 16 20:21:01 systemd: Starting Session 29859 of user munin.
Jul 16 20:21:01 systemd: Started Session 29859 of user munin.
Jul 16 20:21:01 systemd: Starting Session 29862 of user root.
Jul 16 20:21:01 systemd: Started Session 29862 of user root.
Jul 25 07:34:20 rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting

Was wir sehen, sind eine Flut von alten Nachrichten und die Meldung, daß imournal daran gehindert wurde, weitere Nachrichten zu loggen, weil es zu viele wurden. Was Sie oben nicht sehen ist, daß das Ganze mit Nachrichten aus April begonnen hat. 3,7 GB an Logfiles sollten nochmal durch den Syslogd gejagt werden.

Auch wenn die eigentlichen Nachrichten nicht mehr in /var/log/messages auftauchen, so verbraucht der Syslogd trotzdem noch eine Menge CPU Leistung, meistens soviel er bekommt.

Ein Neustart von syslogd machts nur schlimmer, weil die alten Nachrichten dann wieder ins Log geschrieben werden.

Die Lösung:

Man editiere /etc/systemd/journald.conf :

 [Journal]
 #Storage=auto
 #Compress=yes
 #Seal=yes
 #SplitMode=login
 #SyncIntervalSec=5m
 #RateLimitInterval=30s
 #RateLimitBurst=1000
 #SystemMaxUse=
 #SystemKeepFree=
 #SystemMaxFileSize=
 #RuntimeMaxUse=
 #RuntimeKeepFree=
 #RuntimeMaxFileSize=
 #MaxRetentionSec=
 #MaxFileSec=1month
 #ForwardToSyslog=yes
 #ForwardToKMsg=no
 #ForwardToConsole=no
 #TTYPath=/dev/console
 #MaxLevelStore=debug
 #MaxLevelSyslog=debug
 #MaxLevelKMsg=notice
 #MaxLevelConsole=info

in dem man das hier einfügt oder ändert, ganz wie Sie möchten:

[Journal]
 MaxRetentionSec=10day

Wenn man dann den Journaldienst des Systemd neustartet, werden alle alten Files aus /var/log/journal/ entfernt und der Systemd schickt nur noch 10 Tage Logs an den Syslogd. Das ist aber i.d.R.  in wenigen Sekunden durch und die Last des Systems geht auf normal zurück.

 systemctl restart systemd-journald

Als positiver Seiteneffekt werden gleich noch monatealte Logdaten gelöscht. In unserem Fall waren es satte 3 GB.

Das Ende der Orgie erkennt man im Logfile des Syslogds an dieser Meldung:

Jul 25 07:35:13 rsyslogd-2177: imjournal: 229963 messages lost due to rate-limiting

Das wäre früher oder vermutlich sehr viel später auch ohne die Anpassungen im in der journal.conf passiert.

Da aber nach 17 Minuten erst 1 Monat verarbeitet wurde, ist es aus Performancegründen des Servers ratsam das zu beschleunigen.

Fehlerhafte Updates rückgängig machen

Da mir grade das Problem in Form eines Spamassassinupdates begegnet ist, hier der Weg wie man so ein Update rückgängig macht.

Zunächst einmal muß man ermitteln wie das alte Paket hieß, also welche Versionnummer das war. Dazu kann man in das Yum.log schauen und nach dem vorletzten Update suchen:

grep spamassassin /var/log/yum.log

oder man benutzt einfach Yum selbst:

yum list --showduplicates spamassassin

Wenn es mehrere alte Pakete zur Auswahl gibt, kann man dann mit „yum erase“ und „yum install“ das alte Paket installieren.

Einfacher ist es allerdings, wenn man das mit „yum downgrade“ macht:

yum downgrade spamassassin

Damit wir die aktuelle Version des Pakets entfernt und die letzte Version installiert.

Was man beachten muß

Wenn man einen automatischen Updateprozess per Cron laufen hat, also z.b. „yum -y update“ alle 2 Stunden ausgeführt wird, installiert Yum sofort wieder das neue Paket. Daher muß man diesen Prozess  stoppen, oder das Paket auf die Sperrliste setzen.

Verräterlampe

Wie schon in einem früheren Artikel befürchtet, schreitet die Heimautomatisierung unaufhaltsam voran. Sie schreckt dabei auch nicht vor Geheimnisverrat zurück, wie ein aktuelles Beispiel zeigt.

Gestern wurde bekannt, daß LED-Lampen des Herstellers Lifx ein Sicherheitsproblem haben. Durch geschicktes Senden von WLAN Paketen an die Smarten LED-Lampen, kann ein Angreifer an das WLAN Passwort des verwendeten Netzwerkes gelangen. Das liegt darin begründet, daß sich die Lampen selbst vernetzen, so lange min. eine Lampe ins WLAN Netz einkonfiguriert wurde. Nötig ist das, damit man den Lampen der Handy App sagen kann, wie hell man es gern hätte.

Abhilfe schafft ein Firmwareupdate, aber mal ehrlich: Wer updated schon seine Deckenlampen ?

Quelle: http://contextis.com/blog/hacking-internet-connected-light-bulbs/

 

Probleme bei Linuxumzug vermeiden

Vor ein paar Tagen habe ich mein Linux von 32 auf 64 Bit umgestellt. Dabei mußte ich natürlich das neue System erst installieren und konnte dann meine alte Home Partition kopieren.

Dabei gibt es einige Sachen zu beachten. Zunächst einmal müssen wir das neue 64 Bit System komplett aufsetzen und alle Programme neu installieren, welche Sie auch schon auf dem alten System hatten. Dazu benutzen Sie am besten Yum und RPM.

Auf dem alten Computer exportieren wir zunächst einmal alle installierten Pakete:

rpm -qa >/tmp/rpms

Dazu kopieren wir zunächst die zusätzlichen YUM Repositories auf das neue System:

cp ...altedaten/etc/yum.repos.d/rpmfusion* /etc/yum.repos.d/
cp ...altedaten/etc/pki/rpm-gpg/*rpmfusion* /etc/pki/rpm-gpg/
yum make cache

Damit sind die Voraussetzungen geschaffen, daß alles reibungslos funktionieren könnte. Natürlich müssen Sie hier alle zusätzlichen Repos kopieren, nicht nur RPMFusion.

Auf dem neuen Computer müssen wir dann die Paketliste mit SED ein bisschen bearbeiten und Referenzen auf die alte 32 Bit Paketbezeichnung entfernen:

sed -e "s/-[0-9-\.]*\.fc20\.i686//"

Im Beispiel habe ich mal Fedora20 benutzt, das müssen Sie natürlich an Ihre Gegebenheiten anpassen. Danach importieren wir die Paketliste in Yum:

yum -y install $(cat /tmp/neuerpmliste)

Danach folgt meist eine größere Orgie an Installationen für mehrere hundert alte Pakete. Bei mir waren es satte 998 Installationen.

Wenn Sie Glück haben sind die meisten davon bereits durch die Neuinstallation wieder vorhanden. Allerdings gibt es viele Pakete, die von Hand nachinstalliert werden müssen, da Sie nicht in einem Repository vorkommen. Darunter fällt zum Beispiel das beliebte OpenOffice, vermutlich auch Ihr Lieblingsdruckertreiber und diverse Erweiterungen zum Abspielen von Videos und Audiodateien.

Der einfachste Weg hier eine Übersicht zu bekommen, was Sie von Hand nach installieren müssen, ist den Installationsvorgang von Yum einfach in eine Datei zu pipen und dort mit einem grep nach „Paket nicht gefunden“ zu filtern.

Nun kommt die Königsdisziplin, der vermeintlich einfachste Teil : der Umzug des home directories.

Was einfach gedacht ist, ist es in der Realität meist nicht. Die Masse an Funktionalitäten wird klappen, wenn Sie einige Punkte beachten.

Wenn Sie auf die tollkühne Idee kommen sollten, Ihr Homeverzeichnis als Ihr eigener Benutzer von der Festplatte Ihres alten Computers zu kopieren, werden Sie leider feststellen müssen, dass Ihre Einstellungen nicht übernommen werden, weil in dem Augenblick wo Sie sich ausloggen, diese einfach mit den aktuellen Einstellungen von Gnome überschrieben werden. Daher müssen Sie Ihr Homeverzeichnis als root User kopieren, als eingeloggter root User versteht sich.

Andernfalls werden Sie beim Kopieren der Inhalte feststellen, daß Teile Ihres Desktop plötzlich anfangen zu reagieren, weil Sie zum Beispiel Ihren Onlinekalender gefunden haben, Ihr E-Mail Programm plötzlich seine Postfächer findet und diverse andere Sachen passieren können. Wenn es dumm läuft, überschreiben Sie sich damit in einer Teil Ihrer Konfigurationen mit halbgaren Inhalten, weil andere Teile noch nicht vorhanden waren.

Daher nochmals der Rat, tun Sie es nur als in die Oberfläche eingeloggter root User und nicht als ihr bereits angelegter normaler Benutzer.

64 Bit Programme, beziehungsweise eine 64 Bit Umgebung, hat natürlich noch ganz andere Probleme zu bieten, als einfach nur 64 Bit zu sein. Ohne 32 Bit Komponenten kommt man auch dort überhaupt nicht aus. Wenn Sie beispielsweise eine Wine Umgebung haben, war diese auf Ihrem alten Computer in 32 Bit und hat auch nur einen 32 Bit Computer simuliert. In einer 64 Bit Umgebung fehlen viele Treiber, die Sie vorher benötigt haben, um zum Beispiel Ihre Spiele zu spielen. Diese waren auf die 32 Bit Treiber von Linux ausgelegt, die nun nicht mehr vorhanden sind, was z.b. bei Nvidia der Fall ist. Sie werden nun also viele Komponenten auf 32 Bit Basis nachinstallieren müssen. Zum Glück ist diese einfach möglich, da Linux als Betriebssystem Libraries zwischen 32 und 64 bit unterscheidet, selbst wenn sie denselben Namen haben, da Sie in anderen Pfaden liegen.

Wine selber liegt nun in einer 64 Bit Version vor. D.b. Sie müssen alle Pakete von Wine auch in der 32 Bit Version installieren. Sie können Yum benutzen um herauszufinden, welche Pakete von Wine installiert sind:

yum list wine*

Sollten Sie nun glauben, daß 64 Bit Programme auf Anhieb funktioniert werden, muss ich Sie leider enttäuschen. Denn Sie haben Ihre 32 bit Version von Wine kopiert. In dieser Umgebung können Sie keine 64 Bit Programme ausführen. Sie benötigen eine neue vollständige 64 bit Umgebung.

Dies ist allerdings recht einfach zu bewerkstelligen. Installieren Sie einfach mit Hilfe von Wine64 das von Ihnen präferierte 64 Bit Programm. Wine erstellt eine neue 64 Bit Umgebung, wenn Sie die entsprechende Wine Umgebungsvariable mit eingeben.

ENV WINEPREFIX=/home/username/.wine64 wine64 64bitprogramm.exe

Sie müssen bedenken, daß in den Menüs und anderen aufrufbaren Dateien, immer davon ausgegangen wird, daß Sie die 32 bit Version von Wine benutzen möchten. Sie haben dies ja schliesslich in Ihrem Standartwineverzeichnis so installiert. Wenn Sie also auf Ihre 64 Bit Programme zugreifen wollen, müssen Sie diese Umgebungsvariable jedem wine Befehl mitgeben:

Dank Verscriptung ist dies kein großes Problem. Es ist aber trotzdem zu überlegen, alle 32 Bit Programme in Wine auf 64 Bit umzustellen und 32 Bit zur Ausnahme zu machen.

Dichtungstrojaner

Mit Liebesgedichten versuchen Kriminelle derzeit Ihnen Trojaner unter zu jubeln.

Zitate wie diesem :

„Den richtigen Mann liebt man zweimal, einmal am Anfang und dann immer.

K. Hoyer“

folgen Anlagen von Emails wie „6434.zip“  worin dann z.b. das „gambling584.doc“ steckt.

Als treuer Leser dieses Blogs wissen Sie jetzt natürlich bereits, daß das ZIP zur Verdeckung des eigentlichen Trojaners dienen soll, in der Hoffnung, daß die Antispamstools das Zip nicht auspacken. Das Word Document ist wie immer an Windows User gerichtet und sollte auf keinen Fall geöffnet werden.

Neu ist die Gedichtsmasche übrigens nicht. Damit die Heueristiken der Antispamtools nicht so fündig werden, benutzen Spammer schon lange zufällige Textzeilen in den Emails, um die Erkennungsrate niedrig zu halten.

Wem das Gedicht nicht schon merkwürdig vorkam, kann sich natürlich auch mal den Header der Email ansehen:

Received: from [46.27.99.195] (helo=tgssand-soil.com.au)
	by XXXXXXXXXXXXXXXXXXX with smtp (Exim 4.80.1)
	(envelope-from .de>)
	id 1X2Tpg-0007uw-Ha
	for XXXXXXXXXXXXXXXXXXXXXXXXX; Thu, 03 Jul 2014 02:21:57 +0200

Da es sich im eine Deutsche Adresse handeln soll, fällt natürlich der australische Server sofort ins Auge. Da paßt so natürlich nicht zusammen.

X-Mailer: Ironhandedly v3.6

Wie uns Google glaubhaft versichert, gibt es dieses Emailprogramm nicht 🙂

Mehr Beweise braucht man eigentlich nicht mehr um es als Trojaner zu identifizieren. Also weg damit in die digitale Mülltonne.

 

 

 

/dev/dvd permanent einbinden

Vielleicht hat Ihnen Ihr MPlayer auch schon mal die Meldung gezeigt, daß „/dev/dvd“ nicht bereit war, obwohl die DVD im Laufwerk war. Das liegt daran, daß der Kernel seit einiger Zeit das DVD-Rom als /dev/sr0 ablegt. Die meisten Programme benutzen aber noch /dev/dvd.

Hier nun die Lösung, wie Sie das Problem beheben können

Speichern Sie dies :

# cat 60-cdrom_id.rules 
# do not edit this file, it will be overwritten on update

ACTION=="remove", GOTO="cdrom_end"
SUBSYSTEM!="block", GOTO="cdrom_end"
KERNEL!="sr[0-9]*|xvd*", GOTO="cdrom_end"
ENV{DEVTYPE}!="disk", GOTO="cdrom_end"

# unconditionally tag device as CDROM
KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1"

# media eject button pressed
ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"

# import device and media properties and lock tray to
# enable the receiving of media eject button events
IMPORT{program}="cdrom_id --lock-media $devnode"

KERNEL=="sr0", SYMLINK+="cdrom dvd", OPTIONS+="link_priority=-100"

LABEL="cdrom_end"

als neue Datei /etc/udev/rules.d/60-cdrom_id.rules ab und rebooten Sie kurz. Sie können auch den udevd neu starten, das liegt ganz bei Ihnen. Ab sofort wird der udevd Ihnen den Link zu cdrom und dvd richtig anlegen.