Server automatisch per Skript herunterfahren

 

Vor fast 4 Jahren beschrieb ich hier im Blog, wie ich in meiner Umgebung das automatische Herunterfahren und den Neustart meines Servers über Wake over LAN (WOL) bei Bedarf realisiert habe. Die Nutzung von WOL war durch die verwendete Fritz!Box kein Problem – damals eine 7490, heute die 6490 cable. Das automatische Herunterfahren des Servers mit Hilfe eines Scripts stellte sich hingegen schwieriger dar. Erst mit Hilfe eines Skripts vom Blogger Markus Wochele (der Link führt ins Nirwana, nur der Vollständigkeit halber) und einigen wenigen Änderungen an diesem Skript durch mich, funktionierte alles zu meiner Zufriedenheit.

Da die Urheberschaft des verwendeten Bash-Skripts nicht bei mir lag und ich mich auch nicht mit fremden Federn schmücken wollte, verwies ich im Artikel lediglich auf die Webseite von Markus, wo er seine Lösung zum Download anbot und ausdrücklich auf die freie Nutzung verwies. Vier Jahre sind eine lange Zeit und so musste ich inzwischen feststellen, dass der gesetzte Link nunmehr ins Leere führt – der Blog von Markus scheint nicht mehr existent zu sein!

Mir ist die ganze Sache wieder eingefallen, da die Zugriffe auf einen 4 Jahre alten Artikel durchaus stabil bleiben und ich daraus schlussfolgere, dass ein beständiges Interesse am Thema gibt. Da ich die Funktion noch immer verwende und die enthaltene Funktionalität sehr schätze, möchte ich an dieser Stelle das Skript – inklusive der kleinen Änderungen von mir – zum Download zur Verfügung stellen. Selbstverständlich habe ich die Urheberschaft bei Markus Wochele belassen …

Zur Nutzung des Skripts bitte beachten:

  1. Der Server muss WOL unterstützen
  2. Im Bereich Config des Skripts müssen die IP-Adressen oder Adressbereiche der zu überwachenden Clients an die entsprechende Umgebung angepasst werden
  3. die von mir im Configbereich definierte Variable d dient lediglich zur Ausgabe von Datum und Uhrzeit in der Logdatei
  4. das Bash-Skript muss ausführbar gesetzt werden um zu funktionieren
  5. ein Cron-Job definiert die Häufigkeit der Prüfung und damit des Herunterfahrens bei Nichtaktivität der definierten Clients.

Ansonsten bleibt mir nur, viel Erfolg mit dem Shutdown-Skript zu wünschen!

Plex – Client auf dem TV II

Meine Freigabe des Plex-Servers über das Internet (in diesem Artikel beschrieben) hatte ungeahnte Folgen: Plex war durch meinen Samsung-TV nicht mehr erreichbar. Die Freigabe ist ja schon ein paar Tage her, trotzdem fiel mir die Sache erst gestern auf. Ein deutliches Zeichen dafür, dass der Zugriff auf meine Medien über die Kombination Smart-TV / Bluerayplayer deutlich nachgelassen hat. Die Erreichbarkeit der Mediensammlung über die Sonos-Player macht sich bemerkbar.

Erstaunlich war die Sache schon ein wenig, konnte ich doch vom Rechner aus ohne Probleme meine MP3s abspielen. Nach einiger Recherche, war das Problem recht schnell behoben. In der „Samsungvariante“ von Plex müssen nach der Freigabe über das Internet IP-Adressen eingetragen werden, denen der Zugriff auf den Plex-Server ohne Authentifizierung erlaubt ist (der Zugriff per Android-App und Webschnittstelle erfolgt ja mit dem hinterlegten Plex-Account). Samsungs Variante kann offensichtlich nicht mit dieser Authentifizierung umgehen.

Über die Webschnittstelle den Menupunkt Einstellungen/Netzwerk wählen. Im Punkt „List of IP Adresses and networks that are allowed without auth“ das eigene Netz und/oder einzelne IP-Adressen eintragen.

Zur Freigabe meines gesamten internen Netzes war dazu folgender Eintrag notwendig:

plexfreigabe1

Die Syntax des Eintrags ist etwas ungewöhnlich, aber funktioniert … In der Maske können mehrere Einträge vorgenommen werden, die durch Kommas getrennt werden müssen.

Nach dieser kleinen Änderung der Konfiguration arbeitete auch die Samsung-App von Plex wieder klaglos.

Microsoft und die Sicherheit

Ich bin ja sehr für Sicherheit, auch und gerade am Rechner. U.a. deshalb setze ich privat kein OS aus Redmond ein. Nun gehöre ich nicht zu den Religionskriegern – auch nicht was Betriebssysteme betrifft – aber so manches „Feature“ von Windows, MS-Office usw. läßt mich doch am gesunden Menschenverstand der Programmierer und/oder Verantwortlichen bei Microsoft zweifeln.

Heute wurde ich in der Firma mit einer solchen Glanzleistung konfrontiert. Als Office-Programm setzen wir MS-Office 365 ein. Neben der leidigen „Online-Featuritis“ (die umgehbar ist) und dem ebenso umgehbaren Zwang alle Komponenten des Paketes zu installieren, überwiegen tatsächlich die Vorteile dieser Variante. Vor allem preislich auch wegen der erworbenen Upgraderechte eine interessante Option.

Ich vermeide es aber grundsätzlich die von Microsoft vorgeschlagenen Standardeinstellungen zu übernehmen, zu leidvoll meine Erfahrungen mit den „Features“ diverser Programme von Microsoft in der Vergangenheit. Einer meine User, nein einer meiner „Poweruser“ teilt allerdings weder meine Abneigung gegen die Politik der Redmonder Firma noch meine Vorsicht im Umgang mit den Programmen derselben. Das Ergebnis war mal wieder niederschmetternd.

Von einem Tag auf den anderen ließen sich Dateien auf Netzlaufwerken nicht mehr öffnen. Lapidarer Kommentar von Word, Excel und Co.: „Die Datei x.x ließ sich leider nicht öffen.“. Die Auswertung der Ereignismeldungen führte nicht zu Lösung, da ähnlichen Informationsgehalts.

Nach einigem Stöbern im Internet kam die Ursache für dieses Verhalten schließlich ans Licht: seit Office 2013 setzt Microsoft wohl wieder einmal auf mehr „Sicherheit“. Über das in Office implementierte „Trustcenter“ werden sichere Speicherorte definiert und nur dort abgelegte Dateien lassen sich öffnen. Netzlaufwerke gehören grundsätzlich nicht dazu. Diesen Fakt musste ich erst einmal verarbeiten.

Ich schätze das ca. 90% aller MS-Office-Lizensen von Firmen erworben werden und die wiederum speichern geschätzte 99% ihrer Dateien auf Netzlaufwerken! Da für Windows auch Cloudspeicher nichts anderes als Netzlaufwerke sind, wird der Wahnsinn noch offenkundiger. Ich vermute allerdings, dass Microsofts Onedrive von diesem Misstrauen ausgenommen ist (wir setzen es nicht ein). Zumindest wäre das für mich die einzige halbwegs plausible Erklärung dieses hirnrissigen „Features“.

In dem geschilderten Fall half allerdings weder die Definition der Netzlaufwerke als „sicher“ noch die Neuinstallation von Office 365 – die auf ihnen abgelegten Office-Dateien liessen sich nicht öffnen. Erst eine komplette Neuinstallation der Arbeitsstation lösten das Problem.

Unfassbar auf welche Art und Weise „Product Placement“ durch Microsoft betrieben wird! An Fehler oder Dummheit der Programmierer und/oder Entscheider will ich nicht glauben. Das wäre allerdings noch desaströser …