Unison ist ein mächtiges Synchronisations-Tool, das sowohl unter MAC, Linux als auch Windows läuft. Sozusagen ab Werk handelt es sich um ein Kommandozeilen-Werkzeug. Unter anderem für Windows gibt es eine Ausführung mit grafischer Oberfläche.

Unison steht für Windows in zwei Varianten zur Verfügung. Verdeutlichen kann man das mit den zum Zeitpunkt des Schreibens dieses Beitrags aktuellen Versionen (Stand: 14.11.2018).

Herunterladen kann man diese z.B. auf GitHub:

https://github.com/bcpierce00/unison/releases

Die neuere Version vom 27.Januar 2018 findet sich in dem Archiv „unison-windows-2.51.2-text.zip“. „text“ steht dabei (vermutlich) für Text-Konsole, also Eingabeaufforderung, Kommandozeile oder wie auch immer man es nennen mag.

Möchte man eine für Windows-typische Oberfläche haben, so muss man auf die Version vom 29. September 2016 zurückgreifen. In dem Archiv „Unison-Windows-2.48.4.zip“ findet sich die Datei „unison 2.48.4 GTK.exe“.

Wie der Dateiname schon andeutet, wird GTK benötigt, damit die Ausführung klappt. Möchte man dieses nun nicht extra installieren, kann man die Installationsdatei entpacken, einen Ordner umbenennen und temporär per Batch-Skript die „Path“-Umgebungsvariable erweitern.

GTK vorbereiten

• Das aktuelle GTK-Runtime-Setup herunterladen:
  https://gtk-win.sourceforge.io/home/index.php/Main/Downloads
• Diese Datei mit 7-Zip entpacken.
• In den Ordner, z.B. „gtk2-runtime-2.24.10-2012-10-10-ash“, wechseln.
• Den Ordner „$_63_“ in „bin“ umbenennen.

Unison GTK ausführen

Ein Batch-Skript erstellen und folgende Zeilen einfügen:

@echo off

title Unison GUI

rem Pfad-Variablen um GTK erweitern

 set GTKPath=..\gtk2-runtime-2.24.10-2012-10-10-ash\bin
 set Path=%Path%%GTKPath%

rem Unison ausfuehren

 "unison 2.48.4 GTK.exe"

Führt man das Skript nun aus, wird für die Dauer der Ausführung die „Path“-Variable um GTK erweitert und Unison GTK wird gestartet. Sobald Unison geschlossen wird, verfällt die Änderung.

Quelle:

Using Unison on Specific Operating Systems – Windows

Kurz notiert, da ich gerade so einen Fall hatte: Hat man auf ein System z.B. nur per PsExec Zugriff oder möchte via Skript die aktuellen CPU- und Arbeitsspeicher-Auslastung erfassen, so gibt es gleich mehrere Wege.

Beispiele:

C:\Windows\Temp>wmic cpu get loadpercentage
LoadPercentage
5

C:\Windows\Temp>wmic ComputerSystem get TotalPhysicalMemory
TotalPhysicalMemory
4157726720

C:\Windows\Temp>wmic OS get FreePhysicalMemory
FreePhysicalMemory
1031288

Wie man hier sehen kann, gibt es nur 5% Gesamt-CPU-Auslastung, 4 GB RAM sind verbaut, 1 GB ist davon noch frei.

Für den Arbeitsspeicher kann man zudem „systeminfo“ verwenden:

C:\Windows\Temp>systeminfo | find /I "Speicher"
Gesamter physikalischer Speicher: 3.965 MB
Verfügbarer physikalischer Speicher: 1.116 MB
Virtueller Arbeitsspeicher: Maximale Größe: 7.928 MB
Virtueller Arbeitsspeicher: Verfügbar: 3.600 MB
Virtueller Arbeitsspeicher: Zurzeit verwendet: 4.328 MB

Das ist jetzt nur der Schnellschuss, daneben gibt es noch mehr Möglichkeiten über die PowerShell oder andere Tools.

Quellen:

stackoverflow – Get CPU Usage from Windows Command Prompt

stackoverflow – How to get the Percentage of memory utilization using WMIC in batch script?

squidworks – How-to Emulate the TOP command in Windows

Die letzte Zeit ist mir bereits öfters aufgefallen, das bei der Abfrage des Ordnerinhalts von „C:\Windows\Temp“ über PsExec nichts gefunden wird.

Das das im Regelfall nicht ganz der Wahrheit entspricht zeigt dieser Screenshot:

Wie man im daneben geöffneten Explorer sieht, ist der Temp-Ordner keineswegs leer, sondern enthält gut 19.000 Elemente. Allein an der Anzahl kann es nicht liegen, denn selbst als nur noch wenige hundert Elemente vorhanden sind bleibt die Anzeige leer.

Da Angaben wie z.B.

15.11.2018 11:05 <DIR> .
15.11.2018 11:05 <DIR> ..
0 Datei(en), 0 Bytes
2 Verzeichnis(se), 106.239.619.072 Bytes frei

fehlen scheint die Ausgabe irgendwie vorzeitig abzubrechen.

So spontan auf die Schnelle habe ich im Netz leider dazu nichts finden können. Bei anderen Ordnern ist mir dieses (Fehl-)Verhalten noch nicht aufgefallen.

Vor ein paar Monaten schrieb ich ein kleines Tool, um die Eingabe des Kennworts in so manche Anwendung zu automatisieren. Ziel war es schnell und einfach den Start von Anwendungen durchführen zu können.

Voraussetzung ist, das beim Start der jeweiligen Anwendung direkt im Feld für das Kennwort auf eine Eingabe gewartet wird. Gemeint ist: Das man direkt ohne Umschweife das Kennwort eingeben kann, denn letztlich simuliert das Tool nur Tastenanschläge.

Die Syntax ist einfach:

unipass.exe <Fenstertitel> <Kennwort>

Bislang erfolgreich getestet wurde das Tool mit JTL-Wawi, Lexware Financial Office und „Windows-Sicherheit“. Letztgenanntes nur sofern der Benutzername vorbelegt war. Das betraf bislang Remotedesktop- als auch RemoteApp-Verbindungen, bei denen z.B. in der jeweiligen *.rdp-Datei der Benutzername vordefiniert ist:

prompt for credentials:i:1
username:s:<Benutzername>

Der AutoIt-Quellcode sieht so aus (völlig unspektakulär):

; AutoIt TrayIcon ausblenden

 #NoTrayIcon

; Auf das Fenster warten

 $WindowTitle = $CmdLine[1]
 WinWait ($WindowTitle)

; Dem Fenster den Fokus geben und warten, bis dass das Fenster wirklich den Fokus hat

 WinActivate ($WindowTitle)
 WinWaitActive ($WindowTitle)

; Das Kennwort eintragen

 $Password = $CmdLine[2]
 Send ($Password)

; Mit Enter bestätigen

 Send ("{ENTER}")

Download

Das Archiv enthält den Quellcode als auch eine *.exe für 32- und 64-bit.

UniPass.zip

Es klingt banal, ist aber leider nicht ganz so einfach: Das Problem dabei ist, das die vorhandene Sitzung der zuvor gestarteten RemoteApp dann für alle nachfolgenden RemoteApps verwendet.

Startet man also „RemoteApp A“ mit „Benutzernamen A“ und startet man dann „RemoteApp B“ wird automatisch die Sitzung von „Benutzername A“ verwendet. Das ist soweit gewollt und für sehr viele Fälle auch völlig in Ordnung.

Etwas schwieriger wird es dann, wenn man „RemoteApp B“ als „Benutzername B“ ausführen möchte. Möglich ist es, mit zwei kleinen Ergänzungen der *.rdp-Datei der jeweiligen RemoteApp. Man trägt die folgenden zwei Zeilen nach:

prompt for credentials:i:1
username:s:<Benutzername>

Diese sorgen dafür, das auf jeden Fall nach den Anmeldedaten gefragt wird. Der Benutzername ist dann bereits vorbelegt, so das man nur noch das Kennwort eingeben muss:

Automatische Anmeldung als anderer Benutzer

Da Windows beim Abruf von Anmeldedaten für Terminalserver nicht nach Benutzername unterscheidet, sondern lediglich den Servernamen als Kriterium heranzieht, ist erstmal keine automatische Anmeldung möglich. Das funktioniert weder mit Bordmitteln wie „mstsc“ und „cmdkey“, als auch mit Tools wie Remote Desktop Plus (RDP+).

Ideal wäre wenn anhand der Angabe „Benutzername“ und „Servername“ dann das Kennwort aus der Anmeldeinformationsverwaltung verwendet werden würde.

Abhilfe schaffen Passwort-Manager, die den jeweilien Anmeldedialog erkennen. Als Lösung Marke Eigenbau habe ich auf UniPass gesetzt. Die RemoteApp ansich müsste dann z.B. via Batch gestartet werden:

start unipass.exe "Windows-Sicherheit" <Kennwort>
mstsc "RemoteApp.rdp"

Man sieht zwar kurz die Anmeldefenster, einen Augenblick später ist dann auch schon die RemoteApp gestartet.

Was geschieht, wenn mehrere Sitzungen bereits bestehen?

Bestehen mehrere Sitzungen und es wird eine weitere RemoteApp geöffnet, wird nachgefragt, mit welchem Benutzer, eigentlich ist die vorhandene Sitzung gemeint, verwendet werden soll:

Für eine Test-Wiederherstellung einer Datensicherung sollte eine virtuelle Maschine unter VirtualBox herhalten. Allerdings streikte die Maus beim Rettungsmedium.

Die Wiederherstellung soll mit der Rettungs-CD von Acronis True Image 2014 Premium erfolgen. Grundsätzlich startet das Bootmedium fast ohne Schwierigkeiten, allerdings fielen zwei Dinge auf:

• • Das Rettungsmedium startet nicht, sobald eine USB-Festplatte an die VM weitergeleitet wird. Abhilfe schafft, diese erst nach dem erfolgreichen Bootvorgang weiterzuleiten.
  • Die Maus funktioniert nicht. Behelfen kann man sich z.B. dadurch, in dem man eine USB-Maus an den Host anschließt und diese an die VM durchreicht:
    

Witzigerweise funktionierte in diesem Fall dann sowohl das Touchpad, VirtualBox läuft hier auf einem Notebook, als auch die USB-Maus. Bemerkung am Rande: Wie die zuvor erwähnte USB-Festplatte wurde die Maus erst nach dem Bootvorgang weitergeleitet, ob es ab dem Starten der VM ebenfalls klappt wurde nicht getestet.

Drei weitere Möglichkeiten zu dem Maus-Thema finden sich beim Hersteller:

Acronis Knowledge Base – 48698: Acronis True Image 2015: Keyboard or Mouse Is Not Detected under Bootable Media

Um die Wiederherstellung einer Datensicherung zu testen, bieten sich virtuelle Maschinen an. Diese haben den Vorteil, das man keine zusätzliche Hardware benötigt und das Live-System nicht für solche Tests unter Umständen platt gemacht muss.

Vor allem wenn der Test schief läuft, steht man im Zweifelsfall nicht ohne funktionierendes System da. Moderne Systeme verwendet meist UEFI als BIOS-Nachfolger, folglich sollte die eingesetzte Virtualisierungslösung dieses ebenfalls anbieten.

(U)EFI unter VirtualBox aktivieren

VirtualBox macht es einem einfach, EFI zu aktivieren. Dieses kann einfach in den Einstellungen der virtuellen Maschine erfolgen:

• • Gewünschte virtuelle Maschine auswählen.
  • Auf „Ändern“ klicken.
  • Zu „System – Hauptplatine“ wechseln.
  • Bei „Erweitert“ den Haken setzen bei „EFI aktivieren (nur spezielle Gäste)“.
    

(U)EFI unter VMware Workstation Player aktivieren

VMware Workstation Player bietet keine Möglichkeit über die grafische Oberfläche an, um EFI zu aktivieren. Durch eine kleine Änderung in der Konfigurationsdatei der virtuelle Maschinen lässt es sich dennoch einstellen:

• VMware Workstation Player beenden.
• In den Ordner der gewünschten virtuellen Maschine wechseln.
• Die Datei „*.vmx“ editieren und folgende Zeile hinzufügen:

  firmware = "efi"

  Wichtig: Auf die exakt gleiche Schreibweise achten, da andernfalls diese Option ignoriert wird!

Tipp

Damit es keine Probleme mit der Online-Aktivierung von diversen Lizenzen, doppelten Computernamen etc. gibt, das Netzwerk der virtuellen Maschine nicht verbinden!

Abschlussbemerkung

Unter beiden genannten Virtualisierungslösungen wurde erfolgreich eine Wiederherstellung einer Windows 10 Home-Installation von einem Acer-Notebook, die mit Acronis True Image gesichert wurde, wiederhergestellt.

Quelle:

Antary – UEFI-Modus in VMware Player benutzen

Mal eben den Anfang oder das Ende eines Videos zurechtschneiden oder Teile davon ausschneiden kann schnell und ohne große Einarbeitung der VidCutter.

Das Open Source-Tool steht für alle gängigen Plattformen zur Verfügung. Die Handhabung ist denkbar einfach:

• Video laden.
• SmartCut aktivieren.
• Über die Schaltflächen „Start Clip“ und „End Clip“ einen oder mehrere Bereiche auswählen.
• Mit „Save Media“ das neu zu erstellende Video abspeichern.

Tipps:

Die ausgewählten Bereiche (Clips) können mit der Maus in ihrer Reihenfolge geändert werden.

Externe Clips können über „+ Add“ hinzugefügt werden.

Um ein Video mit Ton zu unterlegen, bieten sich viele Videoschnitt-Systeme an. Möchte man für ein Video zunächst den (eigenen) Soundtrack in der Digial Audio Workstation (DAW) seiner Wahl kreieren wird’s etwas kniffelig.

Nicht jede DAW ist in der Lage, Videos zu Laden. Zwei Programme (DAW und Medienplayer) nebeneinander Laufen zu lassen ist zwar eine Option, allerdings ist die Wiedergabe dann nicht synchron, für’s Timing ist das dann nicht gerade förderlich.

Sofern die DAW VST(i) unterstützt, besteht mit dem Plugin VidPlayVST die Möglichkeit, ein Video wiederzugeben.

Am Beispiel von Synapse Audio’s Orion oder energyXT sieht das so aus:

Damit das Starten des Videos in energyXT klappt, muss „Cue with any C note“ in VidPlayVST aktiviert werden.In LMMS klappt es mit dem Stoppen des Videos nicht. Den exakten Start kann man wie bei EnerygXT durch Aktivieren von „Cue with any C note“ regeln.

Video samt Ton erzeugen

Der klassische Weg um Bild und Ton zusammenzubringen besteht darin in einem Videoschnittprogramm die Bild- und Tonspuren zusammenzufügen.

Mit dem kostenlosen zusätzlichen Plugin VidRenderVST kommt sogar eine Möglichkeit das Video zusammen mit dem Ton direkt aus der DAW heraus zu rendern.

Leider gibt es diesen Zusatz nur für 64-bit Windows bzw. Mac.

Was ist mit Linux?

VidPlayVST gibt es in einer Linux-Ausgabe:

VidPlayVST for Linux

Für Linux ist das Plugin kostenlose verfügbar. VidRenderVST gibt es hingegen nicht für Linux.

Einschränkungen der Demo-Version

Die Demoversion spielt nur die ersten 30 Sekunden eines Videos ab, ferner wird weder das geladene Video noch Presets gespeichert. D.h. man muss nach jedem DAW-Neustart das Video neu laden.

Preis

Mit 18,00 USD zzgl. MwSt., zum Zeitpunkt des Schreibens dieser Zeilen waren das insgesamt 20,72 €, durchaus bezahlbar.

Gerne werden in Kennwörtern Sonderzeichen verwendet. Damit das dann via Batch-Skript in Verbindung mit WinSCP funktioniert, muss man diese umwandeln und eine Kleinigkeit beachten.

Ohne Sonderzeichen würde man eine Session-URL so schreiben:

ftp://username:meinkennwort@domain.tld

Kommt jetzt beispielsweise ein „+“ ins Spiel funktioniert folgende Schreibweise nicht im Batch-Skript bzw. genauer ausgedrückt dann bei der „WinSCP.com“ :

ftp://username:mein+kennwort@domain.tld

Die Authentifizierung scheitert und man kassiert ein „Access denied“.

Das „+“-Zeichen muss konvertiert werden. Gemäss der Anleitung bei WinSCP (siehe Quelle) wird dann „%2B“ daraus:

ftp://username:mein%2Bkennwort@domain.tld

Gibt man diese Zeile via „echo…“ aus, verschwindet allerdings das „%“ und die Anmeldung scheitert erneut:

ftp://username:mein2Bkennwort@domain.tld

Das erste „%“ wird seitens CMD als Einleitung für einen Parameter verstanden und folglich sozusagen geschluckt. Daher müssen es zwei „%%“ sein:

ftp://username:mein%%2Bkennwort@domain.tld

Nun klappt’s auch mit einem vorangestelltem „echo“:

echo ftp://username:mein%%2Bkennwort@domain.tld > winscp.txt

Übergibt man nun die „winscp.txt“ an WinSCP.com („WinSCP.com /script=winscp.txt“),  es müssen/sollten natürlich noch weitere Angaben enthalten sein, funktioniert die Anmeldung.

Quelle:

WinSCP – Documentation – Features – Session URL

Quasi als Nachtrag oder Ergänzung zum Beitrag Askozia Desktop Telephony Server auf 3CX umstellen folgt nun die Anleitung für den 19″ Telephony Server.

Auch hier ist im Grunde alles im Wiki von Askozia beschrieben:

Askozia Wiki – How to install 3CX on Askozia Telephony Servers/de – 1 19″ Telephony Server

Dennoch ein paar kleinere Anmerkungen und etwas Troubleshooting.

• Aktuelle 3CX Debian-ISO herunterladen: https://www.3cx.com/phone-system/download-links/
• Mit einem geeigneten Tool (z.B. imageUSB, Rufus, …) auf einen USB-Stick überspielen.
• Den 19″ Telephony Server mittels VGA oder HDMI mit einem Display verbinden und eine USB-Tastatur anschließen.
• Den 19″ Telephony Server mit dem zuvor erstellen Stick starten.
  Ggf. im BIOS zuvor die Boot-Reihenfolge ändern (laut Wiki auf P1 stellen, bitte den Abschnitt Troubleshooting weiter unten beachten!). Das BIOS-Kennwort lautet: ozia.
• „Install“ auswählen.
• „enp1s0“ als Netzwerkschnittstelle auswählen.
• Per Standard holt sich Debian eine IP-Adresse per DHCP. Möchte man während der Installation eine feste IP-Adresse vergeben, so muss man bei der Abfrage nach dem „Hostname“ „ESC“ drücken, dann „configure network manually“ auswählen, die IP-Adresse, das Gateway und den DNS-Server angeben.
  Wichtig: Die IP-Adresse kann später nicht ohne weiteres bzw. nur mit Backup, Neuinst. und Restore geändert werden. Dies liegt nicht an Debian, sondern an 3CX, da Diese die Änderung der IP-Adresse auf OS-Ebene nicht richtig mitbekommt.
• „Hostname“ eingeben.
• „Domain“ eingeben.
• „Sprache“ und „Land/Region“ auswählen.
  Bemerkung: Selbst wenn man z.B. Deutsch ausgwählt hat, kommt es vor, das Teile der Installation auf Englisch sind.
• Das „root“-Passwort festlegen und bestätigen.
• Bei „Partition disks“ „Guided – use entire disk“ auswählen.
• „sda“ auswählen.
• „All files in one partition“ auswählen.
• „Finish partitioning and write changes to disk“ auswählen.
• Die Sicherheitsabfrage mit „Yes“ bestätigen. Letzte Chance um abzubrechen!
• Die Installation benötigt ein paar Minuten, man muss also ein wenig Geduld haben. Es erfolgt ein automatischer Neustart, an dieser Stelle sollte der USB-Stick entfernt werden. Nach diesem Neustart werden automatisch die 3CX-Pakete installiert.
• „3CX Stable <Version>“ auswählen (außer man möchte natürlich einen SBC installieren).
• Das „License Agreement“ bestätigen.
• Es folgt der zweite automatische Neustart.
• „1“ drücken um „Using a Web Browser“ auszuwählen.
  Hinweis: Nach dem zweitem Neustart kann es passieren, das keine Anmeldemöglichkeit auf der Konsole erscheint, die 3CX Weboberfläche und via ssh ist das System allerdings erreichbar. Ab dem nächsten Neustart erscheint das Login wie erwartet.

Ab hier geht’s dann von einem anderen Computer bzw. Web-Browser unter „http://<IP-Adresse des 3CX-Computers>:5015?V=2“ weiter. Nun kann man der Erstkonfiguration folgen:

Erstkonfiguration der 3CX-PBX

Troubleshooting:

Ganz gleich auf welche SSD, im 19″ Telephone Server sind Zwei (1x M.2, 1x 2.5″) verbaut, die 3CX installiert und welche Boot-Reihenfolge im BIOS eingestellt wurde, nach dem ersten Neustart ging es nicht mehr weiter, man sah nur noch einen schwarzen Bildschirm.

Abhilfe schaffte erst das Entfernen einer der SSDs und eine weitere Neuinstallation der 3CX. Im Rahmen dieser Fehlerbehebung wurde dann testweise sowohl auf die M.2-SSD als auch, nach deren Entfernung, auf eine 2.5″ SSD installiert. Getrennt, also wenn immer nur eine SSD aktuell verbaut bzw. verbunden ist, klappt alles wie erwartet.

Nach der Umstellung von Askozia zu 3CX fiel bei einem Kunden auf, das sich das Mobilteil (snom M25) sehr häufig neu registriert. Alle paar Minuten, schlimmstenfalls alle paar Sekunden geschah dies.

Auffällig war, das während man mit dem Web-Interface der Basis verbunden ist, ein Firmware-Update oder -Upgrade durchführte oder gar Telefonierte keine Neuregistrierung stattfand.

Im Syslog der snom M300-DECT-Basis fanden sich häufige „Link down“- bzw. „Link up“-Meldungen. Zunächst ging man also von einem Netzwerkproblem aus. Da die Basis direkt mit dem Switch verbunden ist (1m Kabel) war dieses schnell ausgetauscht. Da dies nicht half, wurde im Switch von automatischer Aushandlung der Geschwindigkeit auf manuelle 100Mbit/s Full-Duplex umgestellt. Das half leider nichts. Ein Blick ins Syslog des Switches zeigte dort allerdings keine Link-Stati-Änderungen für den Port an dem die M300 hing. Somit war klar, es liegt nur ein der DECT-Basis.

Um die Theorie zu bestätigen, das es keine Link-Stati-Änderung und folglich Neu-Registrierung an der 3CX gibt, wurde ein Dauerping auf die DECT-Basis ausgeführt. Während dieser lief, kam es zu keinerlei Überraschungen. Das stüzte die Vermutung, das während mit der Basis kommuniziert wird, nichts negatives geschieht.

Ein wenig Recherche führte dann zu diesem Treffer:

snom – Solution home – DECT – FAQ – My DECT base is resetting the ethernet link periodically (M300 / M700)

Allerdings konnten wir den dort hinterlegten Text, geschweigedenn die genannte Option nicht finden. Dies klärte sich nach dem Studium der Firmware-Release-Notes:

snom – Wiki – M-series/Firmware/Release Notes

Sucht man dort nach „eth_driver_initialize“ stellt man fest, das diese Einstellungsmöglichkeit erst ab

Version BSV400B4 – January 2018 – Release Candidate 1

vorhanden ist. Aktuell ist noch die Firmware V400B2 installiert.

Für den Moment ergeben sich daraus zwei, drei Möglichkeiten:

• Da es keine Schwierigkeiten mit dem Telefonieren gibt, das Ganze ignorieren.
• (Weiterhin) Einen Dauerping auf die Basis ausführen.
• Die Firmware aktualisieren.

Letztgenanntes ist vmtl. die sauberste Lösung, allerdings ist unklar, ob diese Firmware von 3CX bereits freigegeben ist bzw. supportet wird. Soweit man es aktuell beurteilen kann, wird die Einstellung für „eth_driver_initialize“ von 3CX noch nicht provisioniert.

Ob die Probleme schon bei der vorigen Askozia PBX in Verbindung mit der damaligen 3.55-Firmware der DECT-Basis aufgetreten sind, wurde nicht untersucht.

Bei der Neuinstallation einer 3CX scheiterte zunächst die Aktivierung der Lizenz.

Während der Ersteinrichtung erhielt man folgende Meldung:

Nach der Anmeldung an der Verwaltungskonsole sah es auf dem Dashboard nicht fiel besser aus:

In den Lizenz-Einstellungen gab es dann etwas mehr Info(s):Die Verbindung ist allerdings in der Firewall zugelassen, die Firewall-Tests der 3CX waren zudem erfolgreich.

Die Lösung bestand darin, alle aktuellen Updates zu installieren und das gesamte System neu zu starten. Anschließend nochmals in die Lizenzeinstellungen zu wechseln und auf „Lizenzschlüssel-Daten aktualisieren“ zu klicken. Die Aktivierung klappte nun. Nicht irritieren lassen darf man sich von unvollständigen Angaben auf der Lizenzeinstellungen-Seite. Sobald man diese nach erfolgreicher Aktivierung verlässt und nochmals aufruft sind alle Angaben vorhanden.

Keine Ahnung ob es an mir, den hier rumliegenden APU1-Boards von PC Engines oder sonstetwas liegt. Bei dem Versuch Debian 9.6.0 Stretch via Netinst-USB-Stick auf mehrere dieser Boards einzurichten ging ein bischen was schief. Hingegen vieler Anleitungen im Netz wollte es nicht so recht klappen. Die Kombi aus mehreren Anleitungen verhalf dann letztlich erfolgreich zum Ziel.

Unterschiede APU(1) und APU2

Unterschiede zwischen den APU(1) und APU2-Boards gibt es einige, wie z.B. anderer Prozessor, schnellerer RAM, Realtek- (APU1) bzw. Intel (APU2)-NICs, usw.

PC Engines – APU

PC Eninges – APU2

APU(1)-Boards sind schlicht die älteren Boards, verrichten aber bislang in vielen Appliances treu ihren Dienst, zumindest hatten wir bislang keinen Ausfall.

Boot-Probleme

Der Start vom USB-Stick blieb mitunter bereits nach „ISOLINUX“ hängen, spätestens aber nach „Probing EDD…“ stehen. Man kam jedenfalls nicht weiter.

BIOS aktualisieren

Auf dem Board sollte die aktuellste BIOS-Version installiert sein, andernfalls kommt es unter Umständen zu Abstürzen:

3CX/Debian: Kernel Panic bei der Installation auf PC Engines APU1-Board

USB-Stick erstellen

• Zuerst lädt man das aktuelle Debian-Netinst-ISO herunter.
• Dieses Abbild schreibt man mit Rufus auf einen USB-Stick.

Hinweis: Mit anderen Tools als Rufus kann man die ISO zwar ebenfalls auf einen USB-Stick übertragen, allerdings booteten diese dann nicht bei mir erfolgreich durch.

USB-Stick anpassen

Damit der Bootvorgang auf dem APU(1)-Board gelingt und man über die serielle Schnittstelle sowohl das Bootmenü und später den Installer dargestellt bekommt, müssen folgende Änderungen auf dem USB-Stick vorgenommen werden:

Im Root des USB-Sticks die Datei „syslinux.cfg“ editieren und am Anfang die folgenden beiden Zeilen einfügen:

CONSOLE 0
SERIAL 0 115200

Dadurch wird bereits das Bootmenü an die serielle Schnittstellen umgeleitet.

Im Ordner „isolinux“ die Datei „txt.cfg“ editieren. Die Zeile mit „append…“ muss wie folgt aussehen:

append vga=off console=ttyS0,115200n8 initrd=/install.amd/initrd.gz --- quiet console=ttyS0,115200n8

Wichtig: Unbedingt die Reihenfolge beachten, andernfalls klappt es nicht! Am besten die Zeile so übernehmen wie sie hier steht.

Diese Änderung sorgt dafür, das der Text-Installer, nachdem man „Install“ aus dem Bootmenü ausgewählt hat, an die serielle Schnittstelle umgeleitet wird und man darüber letztlich die eigentliche Installation durchführen kann.

Zu guterletzt muss man noch die Realtek-Firmware für die Netzwerkkarten auf den Stick kopieren:

• Die Datei firmware-realtek_20161130-4_all.deb herunterladen und auf dem Stick in den Ordner „Firmware“ kopieren.

Debian installieren

Nun kann man das Board mit dem Stick starten und die Installation wie gewünscht durchführen.

Bemerkung zur Sprachauswahl:

Eigentlich steht nur „English“ zur Auswahl und „Land/Region“ kann man auswählen. Letztgenanntes ist relevant! Um „Europe“ und folglich „Germany“ auswählen zu können, zunächst „other“ auswählen. Die „locales“-Auswahl wie vorgeschlagen lassen. Nach der Installation kann man „locales“ wie folgt ändern:

dpkg-reconfigure locales

Nach Ausführung des obigen Befehls erschien bei mir folgende Ausgabe:

Generating locales (this might take a while)...
de_DE.UTF-8... done
en_US.UTF-8... done
Generation complete.
*** update-locale: Warning: LANGUAGE ("en_US:en") is not compatible with LANG (de_DE.UTF-8). Disabling it.

Das klingt zunächst unerfreulich. Nach einer Runde Ab- und Anmelden und Prüfung durch folgenden Befehl scheint alles gut zu sein:

root@debian:~# env | grep LANG
LANG=de_DE.UTF-8

Anpassungen nach der Installation

Sobald die eigentliche Installation abgeschlossen ist, sollte man noch den GRUB-Bootloader anpassen, sonst sieht man zukünftig keine Ausgabe an der Konsole.

Hinweis: Dieser Schritt ist nur notwendig, wenn man zuvor in der „txt.cfg“ nicht zu Erweiterung „console=ttyS0,115200n8“ am Ende drin stehen hat.

• nano /etc/default/grub
• Folgendes Einfügen bzw. Ergänzen und Speichern:

  GRUB_CMDLINE_LINUX="console=ttyS0,115200n8"

• update-grub

Was tun, wenn ssh nicht läuft und man an der Konsole nichts sieht

Hat man die Änderung von Grub vergessen und ssh nicht installiert oder es läuft es irgendwelchen anderen Gründen nicht, so kann man beim Booten noch händisch eintragen, das auf die serielle Schnittstelle umgeleitet werden soll:

• Das Board neu starten und „e“ drücken.
• Den „linux“-Eintrag um „console=ttyS0,115200n8″ ergänzen“ und „F10“ drücken.

Abschlussbemerkung

Wenn man weiß wo und wie ist die Einrichtung ganz simple. Ohne die Anleitung von Marcel Stritzelberger wäre ich allerdings ganz schön aufgeschmissen gewesen.

Quellen:

How to install Ubuntu using serial console

computing competence – Installation von Debian auf einem APU Embedded Board (APU.2C4)

debian – Wiki – Locale

debian – Wiki – ChangeLanguage

Update 26.11.2018

Kaum den Beitrag geschrieben und veröffentlich, schon gibt’s ein Update: Kleinere Fehler korrigiert. Automatische Aktualisierung von Grub eingetragen, dadurch entfällt das manuelle Nachtragen. Falls man die Grub-Änderung doch mal vergessen haben sollte hinzugefügt und einen Abschnitt zur Installation bzw. zu den „locales“ hinzugefügt.

Das Installations-Image aus der Umstellungszeit von Askozia-zu-3CX ist mittlerweile veraltet und basiert noch auf Debian 8 Jessie. Man kann es zwar nach wie vor verwenden, darf dann allerdings sowohl für Debian als auch 3CX viele Updates installieren. Das letzte Mal als ich das so gemacht habe, hat es gut zwei Stunden in Anspruch genommen, die kann man sich zum Teil sparen, wenn man das aktuelle 3CX-Debian-Netinst-Image nimmt.

Leider klappt das nur zum Teil, das mit dem Zeit sparen, denn im Gegensatz zur regulären 3CX-Linux-Installation läuft das automatische Setup nach dem Neustart leider nicht weiter. Stattdessen kann bzw. muss man per Hand mit der 3CX-Installation fortfahren. Dazu später mehr.

Grundsätzlich gibt es zwei Möglichkeiten 3CX auf ein APU-Board zu bekommen. Entweder man installiert zunächst ein reguläres Debian und führt dann die restliche Installation von Hand durch oder man startet gleich mit dem 3CX-Debian-ISO. Letztgenanntes kommt für diesen Beitrag zum Einsatz.

USB-Stick vorbereiten

• Aktuelle 3CX Debian-ISO herunterladen: https://www.3cx.com/phone-system/download-links/
• Das Abbild mit Rufus auf den USB-Stick schreiben:

Die folgenden Dateien auf dem Stick müssen angepasst werden:

Im Root des USB-Sticks die Datei „syslinux.cfg“ editieren und am Anfang die folgenden beiden Zeilen einfügen:

CONSOLE 0
SERIAL 0 115200

Im Ordner „isolinux“ die Datei „adtxt.cfg“:

label expert
menu label E^xpert install
kernel /install.amd/vmlinuz
append priority=low vga=off console=ttyS0,115200n8 initrd=/install.amd/initrd.gz ---
include rqtxt.cfg
label auto
menu label ^Automated install
kernel /install.amd/vmlinuz
append auto=true priority=critical vga=off console=ttyS0,115200n8 initrd=/install.amd/initrd.gz --- quiet

Im Ordner „islolinux“ die Datei „txt.cfg“ editieren. Die Zeile mit „append…“ muss wie folgt aussehen:

label install
	menu label ^Install
	kernel /install.amd/vmlinuz
	append vga=off console=ttyS0,115200n8 initrd=/install.amd/initrd.gz auto=true priority=high  url=http://downloads.3cx.com/downloads/debian9iso/preseed_9.5.0.txt --- quiet THREECXMARKER=DEBIAN-3CX-ISO console=ttyS0,115200n8

Im wesentlichen werden über die Änderungen dem System mitgeteilt, das es statt via VGA über die serielle Schnittstelle die Ausgabe erledigen soll.

Zusätzlich für APU(1)-Boards muss noch die Firmware für die Realtek-Netzwerkkarten auf den Stick gepackt werden:

• Die Datei firmware-realtek_20161130-4_all.deb herunterladen und auf dem Stick in den Ordner „Firmware“ kopieren.

Da ich aktuell kein APU2-Board zur Hand habe, konnte nicht getestet werden, ob evtl. weitere Anpassungen von nöten sind.

Debian installieren (lassen)

• Das Board mit dem vorbereiteten Stick starten.
• „Install“ auswählen.
• „enp1s0“ als Netzwerkschnittstelle auswählen.
• Per Standard holt sich Debian eine IP-Adresse per DHCP. Möchte man während der Installation eine feste IP-Adresse vergeben, so muss man bei der Abfrage nach dem „Hostname“ „ESC“ drücken, dann „configure network manually“ auswählen, die IP-Adresse, das Gateway und den DNS-Server angeben.
  Wichtig: Die IP-Adresse kann später nicht ohne weiteres bzw. nur mit Backup, Neuinst. und Restore geändert werden. Dies liegt nicht an Debian, sondern an 3CX, da Diese die Änderung der IP-Adresse auf OS-Ebene nicht richtig mitbekommt.
• „Hostname“ eingeben.
• „Domain“ eingeben.
• „Sprache“ (eigentlich steht nur „English“ zur Auswahl) und „Land/Region“ auswählen. Letztgenanntes ist relevant! Um „Europe“ und folglich „Germany“ auswählen zu können, zunächst „other“ auswählen. Die „locales“-Auswahl wie vorgeschlagen lassen.
• Das „root“-Passwort festlegen und bestätigen.
• Bei „Partition disks“ „Guided – use entire disk“ auswählen.
• „sda“ für die mSATA SSD auswählen.
• „All files in one partition“ auswählen.
• „Finish partitioning and write changes to disk“ auswählen.
• Die Sicherheitsabfrage mit „Yes“ bestätigen. Letzte Chance um abzubrechen!
  Die Installation benötigt ein paar Minuten, man muss also ein wenig Geduld haben.
  Es erfolgt ein automatischer Neustart, an dieser Stelle sollte der USB-Stick entfernt werden.

Die eigentliche 3CX-Installation durchführen

Da es wie eingangs erwähnt nicht bis zum Ende mit der automatischen Installation klappt, muss man ein die folgenden Befehle an der Konsole oder via ssh, nachdem man sich als root angemeldet hat, ausführen:

wget -O- http://downloads-global.3cx.com/downloads/3cxpbx/public.key | apt-key add -

echo "deb http://downloads-global.3cx.com/downloads/debian stretch main" | tee /etc/apt/sources.list.d/3cxpbx.list

apt-get update

apt-get install 3cxpbx

apt-get install net-tools

An der seriellen Konsole gibt’s eine kleine Falle. Sieht man über längere Zeit nur folgendes Bild:

Scrollt man am besten mal nach unten und siehe da, das Setup wartet darauf, das man dem Lizenzvertrag zustimmt:

Abschließend noch „1“ drücken um „Using a Web Browser“ auszuwählen.
Ab hier geht’s dann von einem anderen Computer bzw. Web-Browser unter „http://<IP-Adresse des 3CX-Computers>:5015?V=2“ weiter. Nun kann man der Erstkonfiguration folgen:

Erstkonfiguration der 3CX-PBX

Quellen:

3CX – Installieren der 3CX-Telefonanlage unter Debian Linux

3CX – Installing Debian for 3CX on a Mini PC

computing competence – Askozia Hardware für 3CX (Debian) nutzen

Bei der Arbeit mit PC Engine APU-Boards und dem vielen rumprobieren mit dem Debian-Installer und der Ausgabe auf der seriellen Schnittstelle stellte ich mir die Frage, ob man das nicht auch irgendwie anders testen könnte, statt ständig USB-Stick abziehen, Einstellungen ändern, wieder dran stecken, booten, etc. Kurzum: Ja, es geht.

Bei VirtualBox (und VMware soll’s auch können) kann man für die virtuellen Maschinen serielle Schnittstellen konfigurieren. Soweit nichts neues. Der Trick besteht darin, keine COM-Schnittstelle anzusprechen, sondern eine Pipe. Die wiederum kann von PuTTY oder KiTTY auf der Gegenseite verwendet werden.

Inspiriert durch die Anleitung bei Haiku ging es gleich ans Werk:

Haiku – Guides – Virtualizing Haiku – VirtualBox Serial Debugging on Windows

Eine neue virtuelle Maschine unter VirtualBox anlegen und wie folgt ändern:

• Zu „Serielle Schnittstellen“ wechseln.
• Auf der Registerkarte „Port 1“ den Haken setzen bei „Serielle Schnittstelle aktivieren“.
• „Portmodus“ auf „Host-Pipe“ stellen.
• Den Haken entfernen bei „Mit Pipe/Socket“ verbinden.
• Bei „Pfad/Adresse“ z.B. „\\.\pipe\vboxserial“ eingeben.

Sobal die virtuelle Maschine gestartet ist, steht die Pipe zur Verfügung.

• Das Terminalprogramm (PuTTY, KiTTY,…) seiner Wahl starten.
• Bei Connection type“ auf „Serial“ stellen.
• Bei „Serial line“ den gleichen Pfad eintragen wie bei VirtualBox.
• Auf „Open“ klicken.

Damit es auf der seriellen Schnittstelle etwas zu sehen gibt habe ich kurzerhand eine Debian-Installation gestartet und die Ausgabe umgeleitet:

• Beim Bootemenü „H“ für „Help“ drücken oder mit den Pfeiltasten auswählen.
•  „<F8> Special boot parameters for install system.“ drücken.
• Mindestens „console=ttyS0“, besser „vga=off console=ttyS0“ eingeben und Enter drücken.

Tipp: Da der Installer und das Tastaturlayout noch auf Englisch steht, muss man bei einer deutschen Tastatur folgende Tasten drücken:

console´ttzS0
bzw.
vga´off console´ttzS0

Das vorläufige Ergebnis sieht dann z.B. so aus:

Ein Kunde störte sich an den unterschiedlichen Klingeltönen für interne als auch externe Anrufe bei seinen snom-Telefonen.

3CX gibt per Vorlage folgende Klingelton-Konfiguration vor:

Schaut man ins Web-Interface eines Telefons sieht man folgendes:

Es zeigt sich: Der Standard-Klingelton der 3CX gilt für interne Rufe, nicht aber für Externe.
Das für externe Rufe der Klingelton 2 verwendet wird, ist fest in der Vorlage eingetragen.

Leider gibt es aktuell, außer über die Custom Templates, keine Möglichkeit, den Klingelton bei snom-Telefonen über die Verwaltungsoberfläche zu ändern. Einzig kann man den Standard-Klingelton auf „Ring 2“ setzen, damit für interne und externe Anrufe wenigstens der gleiche vorgegebene Klingelton verwendet wird.

Das Thema wurde bereits bei den 3CX Ideas angesprochen:

Snom ringtone for external calls

Ich habe da gleich mal für gevotet.

Custom Template erstellen und anpassen

In der Vorlage ist dieser Abschnitt für den externen Klingelton verantwortlich:

Am einfachsten zu finden über die Suche nach „alert_external_ring_sound“.
Man kann die Vorlage kopieren und dann den Telefonen zuweisen.

Die Original-Vorlage ist zumindest nicht über die Verwaltungskonsole anpassbar. Tricksen könnte man z.B. via ssh, WinSCP, o.ä. Anbei die Pfade zu den Original-Vorlagen und den Custom Templates unter Linux:

/usr/share/3cxpbx/skel/Data/Http/Templates/phones

/var/lib/3cxpbx/Instance1/Data/Http/Interface/provisioning/<AuthGenDir>/CustomTemplates/phones

Allerdings griffen bei mir die Änderungen, die an der Original-Vorlage vorgenommen wurden (trotz Dienste-Neustart) nicht beim Provisionieren der Telefone.

Vorsicht bei Updates

Werden die Vorlagen im Rahmen von Updates geändert, so sollte man seine eigenen Vorlagen ebenfalls aktualisieren. Das geht dann nur per Hand.

„Problemfall“ Support

Die Custom Templates bieten mächtige Möglichkeit zum Individualisieren der Telefone. Leider bietet 3CX bei deren Einsatz keinen Support an.

Im Dashboard wird vor „Telefone“ ein rotes Ausrufezeichen gesetzt und man erhält beim Klick darauf folgenden Text:

Für von Ihnen genutzte Telefone oder Geräte mit benutzerdefinierter Vorlage besteht keine Unterstützung, sodass Probleme auftreten können.
Eine Übersicht zu unterstützten IP-Telefonen finden Sie hier.

Unter „Telefone“ werden zudem alle Telefone die eine angepasste Vorlage verwenden rot markiert. Selbst wenn man sich an den Support mit einem Problem meldet, welches überhaupt nichts mit den Vorlagen zu tun hat, ist der Call bzw. Case gleich beendet.

Quellen:

3CX – V15 – Creating Custom IP Phone Templates

So langsam zieht das Thema Smart Home bei uns ein. So wurde bereits im Sommer ein AVM FRITZ!DECT 210 im Außenbereich installiert, um saisonabhängig verschiedene Dinge, im Moment hängt die Weihnachtsbeleuchtung dran, zu schalten. Nun kam passend zur Heizperiode ein Comet DECT Heizkörperregler hinzu.

Warum nicht von AVM?

Vom FRITZ!Box-Hersteller gibt es mit dem FRITZ!DECT 301 ebenfalls einen Heizkörperregler. Der ist allerdings im Vergleich zum Comet DECT teurer und zum anderen liest man in so manchen Bewertungen und Kommentaren mitunter durchwachsenes zu Qualität, Batterielaufzeit und weiteres.

Mir war jetzt erstmal wichtig, ein neues Thermostat für den Heizkörper im Keller-Büro zu haben, der programmierbar und für den Einstieg günstig ist. Da die nicht-smarten Teile teils fummelig zu programmieren sind, sagte mir eine Variante die per Browser und ohne Hersteller-Cloud konfigurierbar ist eher zu.

Dazu kam nun der Zufall, das der Comet DECT im Angebot war und zudem von der Stiftung Warentest in der Ausgabe 01/2017 als „Gut“ getestet wurde.

Was gibt’s als Alternative?

Als weitere Variante gibt es Heizkörperregler die per USB oder Bluetooth ansprechbar sind, das wäre sicher auch eine Option. Wie es sich dann aber mit so mancher App und dem Nach-Hause-Telefonieren oder der Langzeitpflege (Updates, Unterstützung neuer Android/iOS-Version) verhält ist dann ein anderer Punkt. Jedenfalls wollte ich nicht von einem Smartphone was dieses Thema betrifft abhängig sein.

Der Vollständigkeit halber erwähnt sei natürlich, das es Regler für verschiedene Smart Home-Systeme gibt.

Comet DECT

Bei der Inbetriebnahme kann man sich auf das mitgelieferte Handbuch verlassen. Bislang war alles genau so wie beschrieben. Nach dem Anbinden an die FRITZ!Box meldete das Gerät zudem gleich die Verfügbarkeit eines Updates, das sich ohne Probleme installieren lies.

Was soll man sagen?! Einen Zeitplan für das Heizen zu „Malen“ ist halt imho schneller und einfacher, als z.B. auf irgendwelchen kleinen Gummitasten rumdrücken zu dürfen:

Dazu gibt es noch Einstellungen wann nicht geheizt werden soll, dies sogar dediziert für Urlaub und Heizperiode. Eine Fenster-auf-Erkennung ist ebenfalls an Bord. Ein weiterer Vorteil ist die Einstellung eines Offsets (Temperaturabweichung) zwischen der am Heizkörper gemessen und der tatsächlichen Raum-Temperatur. Das macht im Moment gut 2° C bei uns aus.

Und noch was: Kalkschutz ist ebenfalls implementiert, d.h. einmal wöchentlich fährt das Ventil einmal komplett auf und zu, dies verhindert, das sich Kalk ablagert und das Ventil unbrauchbar wird. Genau dieses Problem hatten wir an diesem Heizkörper vor nicht allzulanger Zeit schonmal, von daher nun die Hoffnung, das einem das (so schnell) nicht wieder begegnet.

Klitze kleine Kritik

Im Gegensatz zum eingangs erwähnten FRITZ!DECT 210 wird in der Übersicht („Heimnetz – Mesh“) nicht die aktuell gemessene Temperatur angezeigt, lediglich die Soll-Temperatur wird dargestellt:

Das ist nun nicht weiter tragisch, denn entwender unter „Heimnetz – Smart Home“ oder nach einem Klick auf „Details“ bekommt man die aktuelle Temperatur. So nebenbei bemerkt: In der FRITZ!App hingeben wird die gemessene Temperatur angezeigt.

Der Wechsel

Da wir Heimeier-Heizkörperventile haben, war der Austausch ein Kinderspiel. Kurz die Rohrzange angesetzt und gedreht, schon war der alte Regler ab und Schwupps der Neue dran.

Abschlussbemerkung

Das Thema Smarter Heizkörperregler ist bei uns jetzt noch frisch, mal sehen, wie sich auf die Dauer das Ganze schlägt. Nach der zügigen und simplen Inbetriebnahme muss ich folgendes zum Besten geben: Wenn doch nur alles so einfach wäre!

Bei einem von der Telekom bereitgestellten LANCOM-Router sollte bei einem Kunden für einen Untermieter eine DHCP-Reservierung eingerichtet werden.

Diese ist notwendig, damit vom gemeinsam genutzten Multifunktionsgerät auf den PC des Untermieters gescannt werden kann. Mehr als Internet, Drucken und Scannen ist durch entsprechende Firewall-Regeln nicht erlaubt, d.h. die beiden LANs können sonst nicht gegenseitig aufeinander zugreifen.

Soweit so gut, die Firewall-Regeln wurden von der Telekom angelegt, beim Punkt mit der DHCP-Reservierung hieß es dann allerdings, das könne „der LANCOM so nicht“. Damit war der Fall für den Techniker erledigt und er zog von dannen.

Nebenbei bemerkt: Eine statische IP-Konfiguration auf dem PC und einem Notebook kam nicht in Frage, da die Geräte auch außer Haus verwendet werden. Da die Anwenderin technisch nicht so fit ist, war das schlicht keine Option. Beim alten Router den der Kunde zuvor hatte, war das Thema bzw. die Aufgabe überhaupt kein Problem, allerdings wurde im Zuge der All-IP-Umstellung leider der Router getauscht.

Das es dennoch geht, fällt wohl in den Bereich gewusst wie. Schaut man via Suchmaschine trittt man meist auf den unter Quelle verlinkten Beitrag von LANCOM. Irritierend kann sein, das dort nicht von der umgangsprachlichen DHCP-Reservierung die Rede ist. Jedenfalls kann man unter

Konfiguration - IPv4 - BOOTP - Stationen - Hinzufügen

Zuweisungen anlegen. Man gibt folgendes ein:

• MAC-Adresse ohne Trennzeichen
• Netzwerk auswählen
• IP-Adresse eingeben
• Stationsnamen (Computername, Hostname) eintragen

Boot-Image lässt man leer bzw. so wie es ist. Für das Vorhaben wird es nicht verwendet.

Die bereits verteilten IP- und zugehörigen MAC-Adressen kann man in der DHCP-Tabelle auslesen:

Systeminformation - Gerätestatus - DHCP - DHCP Tabelle

oder

LCOS-Menübaum - Status - TCP-IP - DHCP

Quelle:

LANCOM – Docs – Zuweisung von festen IP-Adressen an bestimmte Stationen konfigurieren

Im Idealfall verwendet man an seinem Synology NAS in Verbindung mit der Surveillance Station durch den Hersteller direkt unterstützte IP-Kameras. Hat man allerdings nicht-unterstütze Bestandskameras oder kommen solche Projekte wie MotionEye hinzu, muss man geringfügig von der Komfortzone abrücken. Keine Sorge, meist ist es einfacher als das es nun klingt.

Gut ist, wenn die IP-Kamera zumindest ONVIF spricht, aber auch Kameras die „nur“ einen MJPEG-Stream liefern können verwendet werden.

Als Beispiel dienen hier einmal eine „Marke-Eigenbau“ IP-Cam auf Basis von MotionEyeOS und eine velleman CAMIP7N. Beide liefern nur MJPEG-Streams, unterstützen kein ONVIF oder RTSP.

Bei MotionEye war es kein Problem, die Adresse des Streams zu bekommen. Diese wird einfach unter „Video Streaming – Streaming URL“ nach einem Klick vorausgewählt zum Kopieren angeboten:

Etwas schwieriger war es mit der Kamera von velleman. Da bei diesem Modell der eigentliche Hersteller nicht bekannt ist, wurde kurz und knapp mittels „Web-Entwickler – Netzwerkanalyse“ des Firefox die richtige Zeile ermittelt:

Ich muss allerdings zugeben, das zuvor diverse andere Adressen die von so mancher China-Cam bekannt sind erfolglos durchprobiert wurden.

Schöner ist’s natürlich, wenn der Hersteller alles dokumentiert hat. Am Beispiel von Instar finden sich die CGI-Befehle und damit die Streaming-URL, in der FAQ des Herstellers:

Instar – Complete CGI Instruction Set

Mit den richtigen Streaming-URLs zur Hand, kann die entsprechende Kamera in der Surveillance Station angelegt werden:

• Auf „IP-Kamera – Hinzufügen“ klicken.
• Einen Namen vergeben.
• Bei „Marke:“ „[Benutzerdefiniert]“ auswählen.
• Bei „Typ:“ „Streaming – HTTP“ auswählen.
• Bei Pfad die zuvor erfasste Streaming-URL einfügen.

An dieser Stelle gibt es eine kleine Falle, zumindest was MotionEye betrifft: An die Streaming-URL muss noch „/irgendwas“ angefügt werden, andernfalls streikt der Assistent. Wie im Screenshot zu sehen, habe ich einfach mal „/test“ drangehängt.

Quelle:

Herr Schroedinger learns coding ’n stuff – How I connected my RaspberryPi Zero W (with camera) to my Synology NAS (DS 216 II+) and use it in the Diskstations Surveillance Station