Raspian Jessie und FHEM – FHEM Start in systemd integrieren

Heute beginne ich damit, ein Pferd von hinten aufzuzäumen. Eigentlich beschäftige ich mich schon länger mit Hausautomation (November 2014 IIRC), habe aber noch nie einen Artikel in meinem Blog dazu verewigt. Aber heute ist es soweit. 🙂

Meine bisherige FHEM Installation läuft auf einem Raspberry Pi 2 unter Raspbian Wheezy, ist also Betriebssystem seitig nicht mehr ganz auf dem Stand der Zeit. Auf einem zweiten Raspberry habe ich daher das aktuelle Image von Raspbian Jessie Lite auf die SD-Karte geworfen und FHEM installiert. Nun kommt die FHEM Standardinstallation nach wie vor mit den klassischen SysV Startskripten daher, Rasbian/Debian Jessie setzt aber mittlerweile auf den systemd statt auf den klassischen SysV init. Nach der FHEM Installation wird FHEM zwar gestartet aber eben über das /etc/init.d/fhem Skript. Das wollte ich ändern und ich beschreibe hier, wie ich das tat.

FHEM systemd Unitfile erstellen

Der richtige Platz für eigene systemd Unitfiles ist /etc/systemd/system. Grundsätzlich unterscheidet systemd zwischen verschiedenen Arten von Unitfiles, eine Übersicht über die verschiedenen Arten können hier nachgelesen werden. Für unser Vorhaben wird ein Unitfile vom Typ .service benötigt, da wir einen Dienst starten wollen. Also die Datei /etc/systemd/system/fhem.service angelegt mit folgendem Inhalt:

Das Unitfile ist in 3 Bereiche eingeteilt: [Unit], [Service] und [Install]. Unter [Unit] werden allgemeine Informationen hinterlegt, wie Beschreibung, oder auch wo Dokumentation (manpage) gefunden werden kann (in obigem Beispiel nicht umgesetzt). Im [Service] Teil wird der eigentliche Start|Stop usw. des Dienstes konfiguriert.

Zum testen kann FHEM danach bereits mit dem Befehl systemctl start fhem.service  gestartet werden. Mit dem Befehl systemctl status fhem.service wird kontrolliert, ob der Dienst läuft:

Sieht gut aus, und FHEM kann über die IP oder den Hostnamen über den Browser aufgerufen werden. Die Ausgabe des Statusbefehls zeigt, dass FHEM nicht automatisch beim Systemstart gestartet wird. Das „disabled“ in Zeile 4 aus obigem Listing verrät uns dies.

FHEM bei Systemstart automatisch starten

Damit FHEM beim Systemstart automatisch gestartet wird, muss das erstellte Unitfile aktiviert werden. Dies geschieht über folgenden Befehl:

Der erste Befehl prüft ob das Unitfile evtl. bereit aktiviert ist, was nicht der Fall ist. Der zweite Befehl aktiviert das Unitfile. Beim nächsten Start des Systems würde FHEM automatisch gestartet werden. Die Aktivierung des Dienstes startet aber diesen nicht und muss mit systemctl start fhem.service nachgeholt werden.

Wichtig:
Damit es nicht zu Vermischungen von SysV Startskripten und systemd kommt, sollte das mit der FHEM Installation installierte Skript /etc/init.d/fhem entsorgt werden (besser: an einen anderen Platz verschoben werden, z.B. ~/backup/).

Wer weitere Informationen zu systemd haben will, dem empfehle ich einen Blick in die schön aufbereitete Dokumentation bei RedHat: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7

Veröffentlicht in Hausautomation Getagged mit: , ,

WSUS – Client Error: WARNING: Reporter failed to upload events with hr = 8024400e

Bei der gestrigen Microsoft Patchinstallation auf unseren Servern ist mir aufgefallen, dass Clients (egal ob PC oder Server) nach der Installation der Patches ihren Report an den WSUS-Server nicht loswerden konnten. Zunächst aufgefallen ist mir das, weil sich nach einem

kein aktualisierter Status in der WSUS Adminkonsole für den eben aktualisierten Host sichtbar wurde. Auch nicht nach mehrmaligem ausführen des Befehls. Selbst der WSUS-Server sollte noch ein verfügbares Update haben, das OS zeigte mir aber keine verfügbaren Updates mehr an.

Also auf die Suche gemacht und prompt fündig geworden. Im WindowsUpdate.log fanden sich folgende Zeilen:

Mein WSUS-Server läuft tatsächlich mit einer MS-SQL Datenbank im Hintergrund, die DB war aber definitiv verfügbar. Die Meldung scheint offensichtlich in die falsche Richtung zu deuten.  Also auf dem WSUS-Server selbst in das Eventlog geschaut:

Also einen Blick in die Dienste geworfen und nach einem nicht laufenden Dienst Ausschau gehalten, welcher normalerweise laufen sollte (Automatischer Start). Alles OK, keine Auffälligkeiten – alles was laufen soll, lief. Als nächstes überlegt, welche Dienste denn die Informationen verarbeiten, bzw. welcher Windows-Dienst mit „Berichterstellungs-Webdienst“ gemeint sein könnte und die folgenden 3 identifiziert:

  • IISAdmin
  • W2SVC (WWW-Publishingdienst)
  • WsusService

Nachdem die Clients per Https/SOAP mit dem WSUS-Server sprechen, lagen die ersten beiden Dienste auf dem WSUS-Server irgendwie nahe, allerdings zeigte sich nach einem Neustart der beiden Dienste keine Änderung am Verhalten. Die Clients wurden nach wie vor ihre Updatereports nicht los.

Letztendliche Lösung

Die letztendliche Lösung bestand schließlich in einem Neustart des WsusService. Danach konnten die Clients ihre Updatereports sofort erfolgreich an den WSUS-Server melden und der Status in der WSUS-Adminkonsole aktualisierte sich und zeigte den richtigen Status an.

 

Veröffentlicht in Admin Kram, Windows Server Getagged mit: , ,

RDP-Sitzungen über mehrere Monitore – spiegelverkehrte Darstellung abhängig von Windows-Version?!

Heute möchte ich von einem seltsamen Verhalten berichten, für welches ich bisher noch keine Lösung gefunden habe. Gegeben sei ein Windows Server 2012 R2 mit installierten Remote Desktop Services, der als Sessionhost verwendet wird. Soweit so unspektakulär. Ein Anwender berichtete mir nun das er verschiedene Darstellungen des Remotedesktops bei Verwendung unterschiedlicher PCs (von denen die RDP-Session aufgebaut wird) hat.

PC A ist ein Windows 8.1 PC, welcher in der Firma steht und sein Hauptarbeitsgerät ist. An diesem PC sind 2 Monitore angeschlossen und die RDP-Sitzung verwendet beide Monitore. In der RDP-Sitzung verteilt der Anwender nun seine laufenden Anwendungen wahlweise auf den rechten oder den linken Bildschirm. Der linke Bildschirm ist als Hauptanzeige festgelegt. Die RDP-Sitzung wird nicht abgemeldet sondern schlicht geschlossen/ge-x-t. Bei einer erneuten Verbindung mit dem RD-Server kann er genau da weitermachen wo er aufgehört hat.

PC B ist ein Windows 10 PC, welcher im Homeoffice des Anwenders steht. An diesem PC sind ebenfalls 2 Monitore (identische Auflösung wie im Büro) angeschlossen und die RDP-Sitzung verwendet ebenfalls beide Monitore. Funktioniert auch, mit dem Haken, dass die Desktops vertauscht sind. Die in der RDP-Sitzung auf PC A rechts platzierten Anwendungen, werden hier links dargestellt und anders herum. Ebenfalls hat die Hauptanzeige vom linken Monitor auf den Rechten gewechselt.

Der Anwender berichtete außerdem, dass er explizit darauf geachtet hat, dass auf beiden PC der jeweils linke Monitor von Windows als Display 1 identifiziert und als Hauptanzeige verwendet wird.

Dieses Verhalten konnte ich unter Verwendung meines Notebooks (Win 10) und eines anderen PCs (Win 8.1) hier in der Firma reproduzieren. Zur Verdeutlichung mal 2 Bilder:

Diese Diashow benötigt JavaScript.

Abgesehen von den dargestellten Inhalten der Anwendungen, sieht man auf den Bildern auch schön wie die Hauptanzeige von links nach rechts wandert anhand der auf dem Desktop hinterlegten Icons.

Bisherige Suche nach möglichen Ursachen, bzw. Möglichkeiten zur Behebung waren noch nicht von Erfolg gekrönt. Es gibt massenhaft Berichte darüber, dass Multimonitor RDP-Sessions als solches nicht funktionieren, bezieht sich aber auf ältere bis sehr alte Windows Versionen. Wer Tipps und Hinweise hat darf sich gern in den Kommentaren verewigen!

Veröffentlicht in Admin Kram, Windows Server Getagged mit: , , , , ,

WSUS und Windows 10 – November 2015 Update

Bisher waren Administratoren in Bezug auf die Upgrades von Windows 7 und 8 PCs auf das neue Windows 10 fein raus. Das lag daran, dass Microsoft das/die Updates mit dem berüchtigten GWX (Get Windows 10) Icon im Tray nicht über WSUS verteilte (oder ich eine Kombination Produkt/Klassifizierungen gefunden hatte, welche das verhinderte). Alle anderen Admins und Benutzer mussten sich immer wieder damit beschäftigen, weil Microsoft dieses Update KB3035583 jeden Monat wieder veröffentlicht und damit potentiell Gefahr läuft den Weg auf den PC zu finden. Das Problem hat man natürlich nur, wenn man Windows 10 nicht möchte.

Wie aber bekommen Windows 10 PCs im Firmenumfeld die großen Upgrades in einem WSUS Umfeld. Ohne zutun des WSUS-Administrators gar nicht. Microsoft hat einen WSUS-Patch (Hotfix) veröffentlicht, der den WSUS um die Funktionalität erweitert, Windows 10 Feature Updates verteilen zu können. Diesen WSUS-Patch findet Ihr hier bei Microsoft: https://support.microsoft.com/en-us/kb/3095113  Weiterlesen ›

Veröffentlicht in Admin Kram, Windows Server Getagged mit: , , , , , ,

Wie man vorinstallierte Metro-Apps ab Windows 8 los wird

Wer kennt das nicht? Man bekommt einen neuen PC auf den Tisch und muss ihn für eine/n neue/n Kollegen/in vorbereiten. Sofern man keine nackten PC’s ohne Betriebssystem kauft, kann da schon mal eine ganze Menge an Mist vorinstalliert sein. Früher beschränkte sich das auf das Ausmisten der vorinstallierten Programme über die Systemsteuerung. Seit Window 8 aber Metro Apps eingeführt hat, hat man hier unter Umständen auch einen ganzen Stall voll zu tun. Je nach Anzahl der vorinstallierten Apps dauert die ersten Anmeldung am PC für einen Benutzer schon mal ein paar Minuten und er kann sich dem tollen Farbwechselspiel von Windows hingeben.

Hello

Hallo! Ein paar Dinge müssen noch erledigt werden. Es dauert nicht lange. Oft aber doch.

Aber wie wird man diesen Wust von Apps jetzt los? App deinstallieren, na klar! Schließlich kann man auf der Startseite (Die Kachelseite bei Windows 8.x) oder im Startmenü (ab Windows 10) einen Rechtsklick auf die App machen und Deinstallieren auswählen.

AppxDeinstall

Windows Store App per rechtsklick Deinstallieren

Der Haken an der Sache? Die App wird nur für den angemeldeten Benutzer deinstalliert. Weiterlesen ›

Veröffentlicht in Admin Kram, Powershell Getagged mit: , , , , , ,