Suche

lichtschattenblog

Kategorie

Linux

PRTG – bash Skript zur Abfrage am Linux-Server – XML-Datensatz

Bei Einsatz von PRTG zur Überwachung von Systemen in einem Netzwerk können bei Bedarf eigene Skripte aktiviert werden, wo die gewünschten Daten/Informationen via XML ausgegeben werden.

In meinem Beispiel benötigte ich einen einfachen Sensor, wo ich als Ergebnis, zu einer Liste von Verzeichnissen, die Anzahl der Dateien und die Gesamtgröße mit allen Unterverzeichnisse als Datensatz bekomme. Ziel war es eine Fehlermeldung zu generieren und per E-Mail zu erhalten, um entsprechende Massnahmen durchführen zu können.

Damit das eigene Skript auf dem Server verfügbar ist, erstellen wir zunächst im Verzeichnis /var/prtg/scriptsxml auf dem betroffenen Server eine Datei mit sinnvollen Namen:

nano getfolderinfo

und fügen den folgenden Inhalt ein:

#!/bin/bash

echo "<?xml version=\"1.0\" encoding=\"Windows-1252\" >"
echo "<prtg>"

for i do

foldersize=$(du -s "$i" | cut -f1)
filescount=$(find "$i" -type f | wc -l)

 echo "<result>"
  echo "<channel>$i - folder size</channel>"
  echo "<value>$foldersize</value>"
  echo "<volumeSize>Byte</volumeSize>"
 echo "</result>"

 echo "<result>"
  echo "<channel>$i - files count</channel>"
  echo "<value>$filescount</value>"
 echo "</result>"

done

echo "</prtg>"

Anschließend machen wir die Datei ausführbar mittels:

chmod 755 getfolderinfo

 

Zur Info:

Mittels:

for i do
  ...done

werden die übergebene Argumente in einer Schleife abgearbeitet.

Mittels:

foldersize=$(du -s "$i" | cut -f1)
filescount=$(find "$i" -type f | wc -l)

werden die jeweiligen Informationen in Variablen geschrieben. Die restlichen Zeilen erzeugen die notwendige XML-Struktur.

 

Zum Test führen wir das Skript mit einem Argument aus, wobei das Argument als Verzeichnis auf dem Server vorliegen muss:

prtg_sensor_script_output

 

Anschließend aktivieren wir im PRTG den neuen Sensor. Hierzu wird zu einem bereits bestehenden Linux-System ein weiterer Sensor hinzugefügt. Zur Auswahl des Sensors wählen wir SSH Script Advanced:

prtg_sensor_sshxml

Im nächsten Schritt wählen wir das Skript auf dem Server:

prtg_sensor_select

Hinweis: Hier erscheint auch der Hinweis wo sich das Skript auf dem Server befinden muss!

und hinterlegen die zu prüfenden Verzeichnisse mit Leerzeichen getrennt als Parameter:

prtg_sensor_select_parameters

Anschließend schließen wir die Eingabe ab und warten mindestens zweimal die Zeit für das Aktualisierungsinterval ab, damit die Struktur vom Sensor via XML erfasst und anschließend mit ersten Daten befüllt wird.

Im Ergebnis und mit ein paar Anpassungen für aktivierte Grenzwerte (Limits -> Enable Limts) in der Spalte Settings zum jeweiligen Kanal (Beispiel):

  • Upper Error Limit (#): 1
  • Error Limit Message: … Aufnahmen (Bilder oder Video) …

sehen wir:

prtg_sensor_output.jpg

Wer einen Sensor mit bereits festen Vorgaben für Grenzwerte erstellen möchte, siehe sich bitte das Handbuch mit mindestens 3000 Seiten an:

https://www.de.paessler.com/support/manuals

Ansonsten ist die Datei: Demo Batchfile – Returns static values in four channels.bat auf dem PRTG-Server unter C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML eine gute Grundlage für die jeweiligen XML-Tags.

Weitere Quellen/Links:

 

Advertisements

Debian – Pakete können nicht mehr aktualisiert und installiert werden

Wer unter Debian bei Ausführung von:

apt-get update

folgende Meldungen oder ähnlich erhält:

Fehl http://ftp.de.debian.org squeeze/main Sources
  404  Not Found

W: Fehlschlag beim Holen von http://security.debian.org/dists/squeeze-lts/updates/main/binary-amd64/Packages.gz
  404  Not Found

W: Fehlschlag beim Holen von http://ftp.de.debian.org/debian/dists/squeeze/main/source/Sources.gz  404  Not Found

E: Einige Indexdateien konnten nicht heruntergeladen werden, sie wurden ignoriert oder alte an ihrer Stelle benutzt.

der sollte prüfen, ob ggf. zu seiner Debian-Version die Paketquellen nicht bereits ins Archiv verschoben wurden. Siehe hierzu:

https://www.debian.org/distrib/archive

Beispiel – Debian 6-Server:

Zunächst prüfen wir die aktuelle Version mittels:

cat /proc/version

Ausgabe:

Linux version 2.6.32-5-amd64 (Debian 2.6.32-48squeeze1) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Feb 25 00:26:11 UTC 2013

Anschließend passen wir unsere sources.list mittels:

 nano /etc/apt/sources.list

an (Beispiel für erste Zeile – mit # wird die alte Zeile auskommentiert und somit deaktiviert):

#deb http://ftp.de.debian.org/debian/ squeeze main
deb http://archive.debian.org/debian/ squeeze contrib main non-free

und aktualisieren die Paketquellen erneut mittels:

apt-get update

 

 

Installation und Einrichtung ocs inventory server unter Debian

Hinweis: Zum 16. Mai 2017 wurde die bestehende Version überarbeitet und erweitert. Neu sind zusätzliche Informationen zum Einsatz von SSL und der Softwareverteilung mittels ocs inventory.

In diesem Artikel beschreibe ich die von mir zuletzt durchgeführte Installation eines ocs inventory-Servers auf Debian 8.6-Basis. Es ist in meinem Fall eine Neuinstallation eines bestehenden Systems, mit Debian 6.

Die hier beschriebene Installation wird in einem Netzwerk mit Netzwerkproxy und sehr scharf aktivierter Firewall durchgeführt. Trotz entsprechender Konfiguration der Firewall werden trotzdem derzeit einige Pakete geblockt. Auf die Lösungen verweise ich später entsprechend.

Aus dem Grund der teilweise geblockten Pakete wurde die Installation mit der ersten DVD der Installationsdatenträger durchgeführt. Ansonsten reicht natürlich der Datenträger für Netzwerkinstallation aus.

Die Verwendung von Linux als Server hat an dieser Stelle gewisse Vorteile. Auf dem Server kann zum Beispiel zusätzlich der Unix Unified Agent installiert werden, wodurch das SNMP-Feature verwendet werden kann.

Wegen früheren Problemen bei meiner ersten Installation eines ocs inventory-Server, unter Debian 6, und einem damals vorhandenem Bug, wird die Installation zunächst ohne aktivierter Verschlüsselung der Kommunikation, beschrieben. Erst nach Prüfung der Funktionen ohne Verschlüsselung der Kommunikation wird dies nachträglich aktiviert.

Die Windows-Befehlsbeispiele wurden unter Windows 7 und Windows 10 mit 64-Bit durchgeführt.

 

Installation Debian 8.6 mit Datenträger DVD1:

Debian 8.6.0 über DVD-Installation mit:

  • SSH Server
  • Standard Systemwerkzeugen

installiert. Anschließend über die Kommandozeile das Netzwerk auf static geändert:

nano /etc/network/interfaces

debian_network_static_sample

Hinweis: ^ steht für die STRG-Taste. Somit mit STRG+o wird gespeichert und anschließend mit STRG + x wird nano beendet.

 

Dann wird der ssh-Zugriff für root aktiviert:

nano /etc/ssh/sshd_config

wo wir PermitRootLogin without-password mittels # auskommentieren und PermitRootLogin yes einfügen.

debian_activate_ssh_root_user_sample

 

Anschließend starten wir den Dienst neu:

 service ssh restart

Ab diesem Punkt verwende ich putty und winscp unter Windows zur vereinfachten Übernahme der Pakete und zur Übernahme geblockter Dateien durch eine Firewall.

 

Vorbereitung des Systems zur Installation von ocs inventory-Server:

Durch die Verwendung der DVD zur Installation entfernen wir zunächst diese als Installationsquelle in der sources.list-Datei von apt:

nano /etc/apt/sources.list

und kommentieren die Zeile mit beginnendem deb cdrom mit einem # aus.

debian_ocsng_apt_source_list

 

Sofern ein Netzwerk-Proxy verwendet wird, muss zunächst für git, wget und perl dies konfiguriert werden. Hier bitte ich folgenden Artikel zu beachten: http://wp.me/p6v8bD-6f

 

Anschließend aktualisieren wir die Konfiguration:

apt-get update

und führen:

apt-get install git git-core apache2 mysql-server-5.5 build-essential php5 php5-mysql php5-gd libapache2-mod-perl2 libxml-simple-perl libdbi-perl libdbd-mysql-perl libapache-dbi-perl libnet-ip-perl libsoap-lite-perl libproc-daemon-perl -y

aus. Während der Installation wird das Passwort für die MySQL-Datenbank abgefragt:

debian_mysql5_5_set_password

Dieses werden wir später benötigen.

Sollte folgende Meldung:

E: Fehlschlag beim Holen von http://ftp.de.debian.org/debian/pool/main/libs/libsoap-lite-perl/libsoap-lite-perl_1.11-1_all.deb  Größe stimmt nicht überein

erscheinen, wird die entsprechende Datei ggf. von einer Firewall geblockt. Als schnelle Lösung bietet es sich an, die Datei über ein anderes Netzwerk herunterzuladen und unter /var/cache/apt/archivies zu speichern. Für mehr Informationen bitte folgenden Artikel lesen: http://wp.me/p6v8bD-Jh

 

Anschließend installieren wir die benötigten Perl-Pakete mittels:

cpan Archive::Zip MIME::Tools XML::Entities YAML Apache2::SOAP

 

Bei Problemen mit der Meldung checksum mismatch bitte folgenden Artikel beachten: http://wp.me/p6v8bD-108

 

Sofern die Meldung:

debian_ocsng_error_cpan_apache2

erscheint, muss lediglich das Verzeichnis erstellt und die Installation der Pakete neu gestartet werden:

mkdir /usr/include/apache2
cpan Archive::Zip MIME::Tools XML::Entities YAML Apache2::SOAP

 

Installation von ocs inventory-Server:

Die Dateien zur Installation sind unter folgender Webseite verfügbar:

https://github.com/OCSInventory-NG/OCSInventory-Server

Um die Installation auf dem Server durchführen zu können, führen wir folgende Befehle aus:

cd /opt
git clone https://github.com/OCSInventory-NG/OCSInventory-Server.git
cd /opt/OCSInventory-Server
git clone https://github.com/OCSInventory-NG/OCSInventory-ocsreports.git
mv /opt/OCSInventory-Server/OCSInventory-ocsreports /opt/OCSInventory-Server/ocsreports
sh setup.sh

Zur Erläuterung: Wir laden zunächst die Installationsdatei für den ocs inventory-Server herunter. Anschließend laden wir die Dateien für die Webverwaltungsoberfläche herunter und starten die Installation.

Sofern keine Probleme vorliegen oder Anpassungen gewünscht werden, muss zur Installation, bei jeder Abfrage, nur die ENTER-Taste verwendet werden.

Zusammenfassend die Ausgaben zu meiner Installation:

debian_ocsng_setup_01

debian_ocsng_setup_02

debian_ocsng_setup_03

debian_ocsng_setup_04

debian_ocsng_setup_05

debian_ocsng_setup_06

debian_ocsng_setup_07

debian_ocsng_setup_08

debian_ocsng_setup_09

debian_ocsng_setup_10

debian_ocsng_setup_11

debian_ocsng_setup_12

debian_ocsng_setup_14

debian_ocsng_setup_15

debian_ocsng_setup_16

debian_ocsng_setup_17

debian_ocsng_setup_18

debian_ocsng_setup_19

debian_ocsng_setup_21

 

Anpassung Apache2:

Als erstes passen wir die Konfiguration zum Aufruf des Webservers an. Dies machen wir über den Befehl:

nano /etc/apache2/sites-available/000-default.conf

und fügen folgende Konfiguration zwischen dem VirtualHost-Tag ein:

        Alias / "/usr/share/ocsinventory-reports/ocsreports/"
                <Directory "/usr/share/ocsinventory-reports/ocsreports/">
                        Options Indexes MultiViews FollowSymLinks
                        AllowOverride None
                        Order allow,deny
                        Allow from all
                </Directory>

Im Ergebnis sollte es so aussehen:

debian_ocsng_apache_add_alias

Anschließend starten wir den Dienst neu:

service apache2 restart

Bei einem ersten Test mit einem Webbrowser und folgendem Aufruf:

http://<server-ip>

sehen wir:

debian_ocsng_test_ocsreports

 

PHP5 anpassen:

Damit bei der späteren Nutzung, zum Beispiel die Daten an den Server erfolgreich gesendet werden können, passen wir die php.ini nach Empfehlung der ocs inventory-Entwickler, mit den bereits enthaltenen aber sehr niedrig konfigurierten Werten, an:

nano /etc/php5/cli/php.ini
    max_execution_time = 180
    max_input_time = 180
    memory_limit = 256M
    upload_max_filesize = 300M   
    post_max_size = 300M

Anschließend starten wir den Apache2-Dienst neu:

service apache2 restart

Mysql anpassen (sofern benötigt):

Wer auf die Datenbank über externe Systeme zugreifen möchte, um zum Beispiel eigene Abfragen durchzuführen, kann dies durch Anpassung der my.cnf wie folgt durchführen.

Wir öffnen die my.cnf und kommentieren mittels # die Zeile mit bind-address aus:

nano /etc/mysql/my.cnf

Im Ergebnis sollte es so aussehen:

debian_mysql_bind-address

Anschließend starten wir den Dienst neu:

service mysql restart

 

Testen der ocsng-Verwaltungsoberfläche:

Wir rufen erneut die Seite in einem Webbrowser mittels:

http://<server-ip>

auf und geben erstmalig unsere Anmeldeinformationen ein.

debian_ocsng_setup_22

Anschließend sehen wir den abschließenden Installationsdialog und wählen:

Click here to enter OCS NG GUI

debian_ocsng_setup_23

Als Ergebnis sehen wir:

debian_ocsng_setup_24

 

Abschließende Maßnahmen und Fehlerkorrektur:

Nach Abschluss der Installation löschen wir die nicht mehr benötigte install.php mittels:

rm /usr/share/ocsinventory-reports/ocsreports/install.php

 

Dann prüfen wir, ob bei der Verwendung der Weboberfläche der Aufruf ggf. pro Seite 60 Sekunden dauert und im Fehler-Log des Apache2 entsprechende Probleme protokolliert werden:

tail -f /var/log/apache2/error.log

Sofern Zeilen wie folgt zu sehen sind:

[Fri Sep 23 11:27:27.991841 2016] [:error] [pid 1938] [client x.x.x.x:50670] PHP Warning:  file_get_contents(http://www.ocsinventory-ng.org/update.json): failed to open stream: Connection timed out in /usr/share/ocsinventory-reports/ocsreports/require/function_commun.php on line 413, referer: http://x.x.x.x/ocsreports/?function=visu_computers

passen wir entweder unseren Proxy, unsere hosts-Datei oder die entsprechende Funktion in der genannten Datei an.

Variante mit der hosts-Datei:

Wir öffnen die hosts-Datei mittels

nano /etc/hosts

und fügen an der zweiten Zeile (Abweichungen sind möglich!) mit zusätzlichem Leerzeichen oder Tabulator

www.ocsinventory-ng.org

an. Im Ergbnis sieht es so aus:

debian_ocsng_edit_hosts

Variante mit Anpassung der function_commun.php:

Wir öffnen mittels:

nano /usr/share/ocsinventory-reports/ocsreports/require/function_commun.php

die Datei und wechseln durch Eingabe STRG + SHIFT + Minus-Taste und anschließender Eingabe der aufgeführten Zeilennummer (Beispiel: 413) in die betroffene Zeile und schreiben vor die Zeile:

unset($content); //

Im Ergebnis sieht es so aus:

debian_ocsng_edit_function_commun_php

 

Prüfen der aktiven Konfiguration des Apache2:

Danach prüfen wir den Inhalt des Verzeichnis conf-enabled der Apache2-Konfiguration. Es sollten folgende Zeilen nach Eingabe von:

ls -l /etc/apache2/conf-enabled

mindestens zu sehen sein:

debian_ocsng_dir_conf-enabled_good

Zur Info: Bei meinen späteren Tests wurde in der Log-Datei ocsinventory.log für ocsinventory.exe folgende Zeile ausgegeben:

WARNING *** COM SERVER => Failed to send HTTP Post request <SSL connect error>

oder

ERROR *** AGENT => Failed to send Prolog <HTTP Status Code #404>

Hinweis: Speicherort unter Windows 7 und 10: C:\ProgramData\OCS Inventory NG\Agent

Zur Info: Der Aufruf des Servers auf /ocsinventory ist ein virtuelles Verzeichnis, welches über

 /etc/apache2/conf-available/z-ocsinventory-server.conf

konfiguriert ist. In meinem Fall musste ich den Symlink aus dem Verzeichnis /etc/apache2/conf-enabled auf die Datei zusätzlich, wie folgt, aktivieren:

cd /etc/apache2/conf-enabled && ln -s ../conf-available/z-ocsinventory-server.conf z-ocsinventory-server.conf

Anschließend den Apache2 mittels:

service apache2 restart

neu starten.

Hinweis: In den Log-Dateien auf Server und Client war das Problem nicht ersichtlich.

 

Testen der Kommunikation zwischen Windows Client und Server:

Zum Test der Kommunikation zwischen Windows Client und Server habe ich den ocsng Agent von der Webseite des Projekts heruntergeladen und mit folgenden Optionen anschließend installiert.

Download-Quelle: http://www.ocsinventory-ng.org/en/ (siehe Downloads)

windows_ocsng_agent_download

windows_ocsng_agent_installation01

windows_ocsng_agent_installation02

windows_ocsng_agent_installation03

In meinem Fall hatte ich anschließend das Programm nicht sofort gestartet, sondern über die Kommandozeile meines Windows 10-PCs folgende Befehle ausgeführt:

cd "%programfiles(x86)%\OCS Inventory Agent"
OCSInventory.exe /debug=2 /notag /force /np /server=http://<server-ip>/ocsinventory

Das Log-File ocsinventory.log ist unter:

C:\ProgramData\OCS Inventory NG\Agent

zu finden. Wenn die Verbindung zum Server erfolgreich ist, sollte in der ocsinventory.log zu sehen sein:

windows_ocsng_agent_test_success

Anschließend finden wir das System im OCSNG unter Alle Rechner, bzw. All computers.

Im access.log vom Apache2 ist zum Beispiel zu sehen:

debian_ocsng_apache2_access_log

Der Befehl hierzu ist:

tail -f /var/log/apache2/access.log

 

Hinweis: Sollte jedoch kein Eintrag entsprechend im OCSNG zu sehen sein, kann dies daran liegen, dass der Prozess ocsinventory.exe noch aktiv ist. In der Log-Datei ocsinventory.log ist ggf. zu sehen:

AGENT => Communication Server ask for IpDiscover
    IPDISCOVER => Scanning to detect IPv4 enabled hosts for network ... between each request

debian_ocsng_ocsinventory_exe_ocsinventory_log_ipdiscover

Erst nach Abschluss aller Vorgänge werden die Daten an den Server übermittelt.

Hinweis: Bei einem Class B-Netzwerk sind ein paar Stunden möglich. Bei einem Class C-Netzwerk mehrere Tage.

Zur schnellen Lösung muss der Prozess am PC beendet und im OCSNG die Option für IPDISCOVER auf OFF gesetzt werden.

Aufruf über: Konfiguration -> Konfiguration -> IP-Discover

debian_ocsng_check_ip-discover

Danach kann der Test erneut durchgeführt werden.

 

Korrektur Datenbank-Passwort:

Nachdem wir erfolgreich die Funktion des Systems testen konnten, passen wir das Standard-Passwort für die Datenbank an. Als Beispiel verwende ich als Passwort topsecret. Hierzu sind mehrere Anpassungen notwendig.

MySQL-Datenbank:

mysql -u root -p
<password eingeben>

use mysql;
update user set password=PASSWORD("topsecret") where User='ocs';
exit;

service mysql restart

 

ocsreports:

nano /usr/share/ocsinventory-reports/ocsreports/dbconfig.inc.php

Hier ändern wir PSWD_BASE wie folgt:

debian_ocsng_dbconfig_password

 

ocsinventory:

nano /etc/apache2/conf-available/z-ocsinventory-server.conf

Hier ändern wir PerlSetVar OCS_DB_PWD wie folgt:

debian_ocsng_z-ocsinventory-server_conf_password

 

Testen der Funktionen nach Anpassung des Passworts:

Unter Windows führen wir in der Kommandozeile folgende Befehle aus:

cd "%programfiles(x86)%\OCS Inventory Agent"
OCSInventory.exe /notag /force /np /server=http://<server-ip>/ocsinventory

Nach ca. 10 Sekunden sollte, nach Aktualisierung der Ansicht im ocs inventory, das System mit neuerem Zeitstempel, in der Spalte für letzte Inventarisierung, erscheinen.

Zusätzlich sollte die ocsinventory.log nicht folgende Zeile enthalten:

COM SERVER => HTTP Post response received <HTTP Status Code #500>

 

Abfragen von Registrierungswerten:

Mittels OCSNG ist es möglich Registrierungswerte von Windows-Clients abzufragen. Hierzu prüfen wir zunächst, ob die Option REGISTRY, in OCNSG mittels Konfiguration -> konfiguration -> Registrierung, auf ON gesetzt ist:

debian_ocsng_check_registry

Anschließend können einzelne Registrierungswerte zur Abfrage hinterlegt werden. Dies ist möglich über Manage -> Registrierung. Anschließend wählen wir Neues Feld und füllen das Formular aus.

debian_ocsng_set_registry_query

Im Log von ocsinventory.log sehen wir:

AGENT =>  Communication Server ask for Registry Query
    REGISTRY => Executing query asked by server
    REGISTRY => 1 query successfully executed

Hinweis: Wenn kein Wert gefunden wird, ist trotzdem die Abfrage erfolgreich!

Wichtiger Hinweis: Bei der Hinterlegung des Pfads zum Schlüssel muss Backslash verwendet werden. Die Verwendung mit einem einfachen Schrägstrich, gemäß Beispiel im OCSNG, ist falsch und funktionierte nicht bei Tests.

 

Aktivieren ipdiscover für nmap-basierende Netzwerkscans auf dem Debian-Server:

Zum Aktivieren von ipdiscover für nmap-basierende Netzwerkscans unter OCS Inventory führen wir folgende Befehle zum Herunterladen des UnixAgent und der vorbereitenden Installation aus:

cd /opt
git clone https://github.com/OCSInventory-NG/UnixAgent.git
cpan Digest::MD5 XML::Simple Net::IP LWP Net::CUPS Net::SNMP Net::Netmask Net::Ping
apt-get install Nmap -y
cd UnixAgent/
perl Makefile.PL
make
make install

Während der Installation erscheint eine Auswahl zur Erweiterung bestehender Konfigurationsdateien. Zu dieser Installation habe ich ausgewählt:

/etc/ocsinventory-agent

Anschließend müssen mehrere Fragen beantwortet werden. Im Ergbenis habe ich ausgewählt:

debian_unixagent_install

Anschließend sehen wir:

debian_unixagent_launch.jpg

Hinweis: SSL-Features sind zum jetzigen Zeitpunkt nicht aktiviert! Diese sind später für SNMP-Abfragen notwendig.

Gemäß Dokumentation müssen nun an einem Agent pro Teilnetzwerk das Ipdiscover aktiviert werden, damit das Netzwerk gescannt werden kann und das Ergebnis im Anschluss dem Server mitgeteilt wird. Wenn anschließend der UnixAgent am Server anfragt, erhält dieser eine Liste von Systemen im Netzwerk und eine Liste von SNMP-Informationen, die auf dem ocs inventory-Server hinterlegt werden müssen. Anschließend führt der UnixAgent die SNMP-Scans durch und liefert nach Abschluss eine Liste an den ocs inventory-Server zurück. Ein direkter Scan aller Systeme in verteilten Netzwerken ist nicht direkt möglich. nmap sieht zum Beispiel von Systemen außerhalb des eigenen Teilnetzwerkes nicht die MAC-Adresse.

Nach der Installation des UnixAgent prüfen wir zur Sicherheit die Aktivierung von ipdiscover. Hierzu prüfen wir, ob die Option IPDISCOVER, in ocs inventory mittels Konfiguration -> Konfiguration -> IP-Discover auf ON und als Anzahl 2 Rechner gesetzt sind:

debian_ocsng_ipdiscover_set_on

 

Testen des ocsinventory-agent und Probleme mit Class B-Netzwerken:

In meinem Fall liegt ein Class B-Netzwerk (Netzwerkmaske 255.255.0.0) vor. Das bedeutet, dass im Netzwerk mehr als 65000 Endgeräte verfügbar sein könnten. Die Standard-Ausführungszeit von 10 Minuten wird daher ohne Probleme überschritten. Im Log vom UnixAgent sehen wir hierzu:

[Tue Sep 27 08:29:10 2016][debug] Scanning the 128.1.0.0 network
[Tue Sep 27 08:39:10 2016][debug] Ocsinventory::Agent::Backend::IpDiscover::IpDiscover killed by a timeout.

Zur Lösung des Problems besteht die Möglichkeit die maximale Ausführungszeit zu erhöhen. Zum Test kann hierzu folgender Befehl verwendet werden:

ocsinventory-agent --debug --backend-collect-timeout=14400 --logfile=/var/log/ocsinventory-agent-debug.log
[Tue Sep 27 12:24:10 2016][debug] Scanning the 128.1.0.0 network
[Tue Sep 27 14:28:42 2016][debug] Running Ocsinventory::Agent::Backend::OS::Generic

Hinweis: Durch die längere Ausführungszeit haben wir das Problem, dass erst nach Abschluss des Netzwerkscans die Daten an den Server übermittelt werden.

Damit der längere Scan möglich wird, passen wir den entsprechenden Cronjob, auf einem System in einem betroffenen Netzwerk, jeweils mittels:

nano /etc/cron.d/ocsinventory-agent
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
10 4 * * * root /usr/local/bin/ocsinventory-agent --lazy > /dev/null 2>&1

zu:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
10 4 * * * root /usr/local/bin/ocsinventory-agent --backend-collect-timeout=14400 --lazy > /dev/null 2>&1

an. In diesem Beispiel sind es 4 Stunden.

 

Aktivieren der SSL-Verschlüsselung:

Zur Nutzung des SNMP-Scan Feature ist es zwingend erforderlich die SSL-Verschlüsselung zu aktivieren.

Im activity.log vom ocs inventory-Server sehen wir mittels:

cat /var/log/ocsinventory-server/activity.log | grep 'snmp'

dass es seit der Installation eine Vielzahl von Meldungen ähnlich:

Thu Sep 29 08:27:36 2016;6817;103;ocsng-2016-09-26-15-22-07;127.0.0.1;OCS-NG_unified_unix_agent_v2.2;snmp;error: agent must communicate using https to be able to get SNMP communities (only affects OCS unix agent) !!

gibt.

Zur Aktivierung der SSL-Verschlüsselung führen wir die folgenden Befehle aus:

cd /etc/apache2/
mkdir ssl_certificate
chown root.root ssl_certificate/
chmod 400 ssl_certificate/
cd /root/
openssl genrsa -out server.key 1024
openssl req -outform PEM -new -key server.key -x509 -days 1825 -out server.crt
mv /root/server.crt /etc/apache2/ssl_certificate/
mv /root/server.key /etc/apache2/ssl_certificate/

 

Hinweis: Die Eingaben zum Befehl openssl req … sollten unbedingt dokumentiert werden. Der Eintrag für Common Name, in meinem Fall die FQDN_des_Servers, muss später zur Agent-Installation und Softwareverteilung verwendet werden. So sollte die Eingabe aussehen:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Firma GmbH
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:ocsng.domainname.int
Email Address []:

 

Anschließend erweitern wir die Konfiguration zum Aufruf via ssl:

nano /etc/apache2/sites-enabled/default-ssl.conf

und fügen folgende Konfiguration zwischen dem VirtualHost-Tag ein:

                Alias / "/usr/share/ocsinventory-reports/ocsreports/"
                        <Directory "/usr/share/ocsinventory-reports/ocsreports/">
                                Options Indexes MultiViews FollowSymLinks
                                AllowOverride None
                                Order allow,deny
                                Allow from all
                        </Directory>

Im Ergebnis sollte es so aussehen:

debian_ocsng_apache_add_ssl_alias.jpg

Zusätzlich passen wir die Einträge für

  • SSLCerificateFile
  • SSLCerificateKeyFile

an:

debian_ocsng_apache_change_path_certs

Unter Debian führen wir zusätzlich aus:

a2enmod ssl
apt-get install ssl-cert -y
make-ssl-cert generate-default-snakeoil --force-overwrite
a2ensite default-ssl

Anschließend starten wir den Dienst neu:

service apache2 restart

und prüfen die error.log vom Apache2 mittels:

tail -f /var/log/apache2/error.log

Als Ausgabe erhalten wir in etwa:

[Thu Sep 29 15:20:34.907304 2016] [ssl:warn] [pid 16794] AH01906: server.domain.int:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Thu Sep 29 15:20:34.907364 2016] [ssl:warn] [pid 16794] AH01909: server.domain.int:443:0 server certificate does NOT include an ID which matches the server name
[Thu Sep 29 15:20:34.979878 2016] [mpm_prefork:notice] [pid 16794] AH00163: Apache/2.4.10 (Debian) OpenSSL/1.0.1t mod_perl/2.0.9dev Perl/v5.20.2 configured -- resuming normal operations

Sofern wir ein Fehler mit dem Zertifikat haben, sehen wir:

[Thu Sep 29 14:28:30.351887 2016] [ssl:emerg] [pid 15976] AH02565: Certificate and private key server.domain.int:443:0 from /etc/apache2/ssl_certificate/server.crt and /etc/apache2/ssl_certificate/server.key do not match

 

Bei einem ersten Test mit einem Webbrowser und folgendem Aufruf:

https://<server-ip>

sehen wir (Beispiel Firefox):

debian_ocsng_ssltest_ocsreports_firefox_message

Nach Bestätigung, dass wir unserem eigenen Server vertrauen, erhalten wir wieder die Anmeldemaske von unserem Server.

Anschließend sichern wir uns die server.crt (Verzeichnis /etc/apache2/ssl_certificate/) als cacert.pem, die wir später zur Kommunikation zwischen Agent und Server benötigen.

Auf dem Server führen wir zusätzlich die folgenden Befehle (Aktivierung SSL-Kommunikation und Hinterlegung cacert.pem-Datei) aus :

cp /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/certs/cacert.pem
cd /opt/UnixAgent
make install

Appending installation info to /usr/local/lib/x86_64-linux-gnu/perl/5.20.2/perllocal.pod
[ ! -f run-postinst ] || /usr/bin/perl postinst.pl
Do you want to configure the agent
Please enter ‚y‘ or ’n‘?> [y]
Config file found are /etc/ocsinventory-agent/ocsinventory-agent.cfg! Reusing it.
Should the old linux_agent settings be imported ?
Please enter ‚y‘ or ’n‘?> [y] n
[info] The config file will be written in /etc/ocsinventory-agent/ocsinventory-agent.cfg,
What is the address of your ocs server?> [http://127.0.0.1/ocsinventory]
Do you need credential for the server? (You probably don’t)
Please enter ‚y‘ or ’n‘?> [n]
Do yo want to install the cron task in /etc/cron.d
Please enter ‚y‘ or ’n‘?> [y]
Where do you want the agent to store its files? (You probably don’t need to change it)?> [/var/lib/ocsinventory-agent]
Should I remove the old linux_agent
Please enter ‚y‘ or ’n‘?> [n]
Do you want disable SSL CA verification configuration option (not recommended) ?
Please enter ‚y‘ or ’n‘?> [n]
Do you want to set CA certificate chain file path ?
Please enter ‚y‘ or ’n‘?> [y]
Specify CA certificate chain file path?>  /etc/ssl/certs/cacerts.pem
Do you want to use OCS-Inventory software deployment feature?
Please enter ‚y‘ or ’n‘?> [y]
Do you want to use OCS-Inventory SNMP scans feature?
Please enter ‚y‘ or ’n‘?> [y]
Do you want to send an inventory of this machine?
Please enter ‚y‘ or ’n‘?> [y]
Setting OCS Inventory NG server address…
Looking for OCS Invetory NG Unix Unified agent installation…
ocsinventory agent presents: /usr/local/bin/ocsinventory-agent
Setting crontab…
Creating /etc/ocsinventory-agent directory…
Writing OCS Inventory NG Unix Unified agent configuration
Creating /var/lib/ocsinventory-agent/http:__127.0.0.1_ocsinventory directory…
Copying SNMP MIBs XML files…
Activating modules if needed…
Launching OCS Inventory NG Unix Unified agent…
-> Success!
New settings written! Thank you for using OCS Inventory

Hinweis: Der erneute Aufruf von make install unter /opt/UnixAgent ist notwendig, damit das notwendige und bisher fehlende Verzeichnis /var/lib/ocsinventory-agent/http:__127.0.0.1_ocsinventory erstellt wird.

Zur Sicherheit prüfen wir anschließend die Konfiguration für den Unix Agent auf dem Server:

nano /etc/ocsinventory-agent/ocsinventory-agent.cfg
ca=/etc/ssl/certs/cacerts.pem
tag=OCSNG-Server
server=https://FQDN_des_Servers/ocsinventory
ssl=1
debug=1
timeout=14400
logfile=/var/log/ocsinventory-agent
basevardir=/var/lib/ocsinventory-agent

Hinweis: ssl muss 1 sein. Zusätzlich muss beachtet werden, dass zur Erstellung des Zertifikats die IP-Adresse des Servers oder die FQDN des Servers angegeben wurde. In meinem Fall war es die FQDN. Daher sind alle weiteren Tests mit der FQDN des Servers dokumentiert.

 

Jetzt prüfen wir die Einstellungen für den SNMP-Netzwerk-Scan über Alle Rechner -> Rechner auswählen -> Configuration -> Edit

debian_ocsng_edit_configuration

-> Netzwerk-Scan

debian_ocsng_edit_network_scan

und setzen, sofern nicht bereits erfolgt, SNMP_SWITCH zu ON und hinterlegen unter SNMP_NETWORK den zu scannenden Bereich. Es können auch mehrere, durch Komma getrennte, Netze hinterlegt werden.

Hinweis: Zum SNMP-Scan wird dem Unix Agent mitgeteilt, welche Systeme dem Server via ipdiscover durch die vielen zuvor durchgeführten Scans der Agents (Windows und Unix) bekannt sind. Dies können auch Adressen außerhalb des eigenen Teilnetzwerkes sein. Zum Beispiel 128.1.0.0,101.0.0.0 oder 128.1.0.0/16,101.0.0.0/24. snmp fragt bekannte Adressen ab und kann daher andere Netzwerke erreichen. Bei nmap ist es nur innerhalb des eigenen Teilnetzwerkes möglich die mac-Adresse zu einer IP zu ermitteln. Wichtig, es darf nur ein Komma und nicht Komma und Leerzeichen oder nur Leerzeichen als Trennzeichen sein. Im Log ist zu sehen, dass das Skript diese Varianten nicht als Trennzeichen korrekt lesen kann.

could not parse  128.1.0.0 at /usr/local/share/perl/5.20.2/Ocsinventory/Agent/Modules/Snmp.pm line 406.
Use of uninitialized value $ibase in addition (+) at /usr/local/share/perl/5.20.2/Net/Netmask.pm line 203.
could not parse 101.0.0.0 128.1.0.0 at /usr/local/share/perl/5.20.2/Ocsinventory/Agent/Modules/Snmp.pm line 406.
Use of uninitialized value $ibase in addition (+) at /usr/local/share/perl/5.20.2/Net/Netmask.pm line 203.

 

Zusätzlich hinterlegen wir für SNMP die notwendigen Communities und Versionen auf dem Server über Netzwerke -> Verwalten -> SNMP-Communities verwalten.

Hier hinterlegen wir mindestens:

  • Version: 1 und Name: public
  • Version: 2c und Name: public

debian_ocsng_set_snmp_community_version

Anschließend führen wir erneut einen Test durch:

ocsinventory-agent --debug --backend-collect-timeout=10 --logfile=/var/log/ocsinventory-agent-debug.log

Hinweis: Die Option –backend-collect-timeout=10 wurde bewusst auf 10 Sekunden gesetzt, damit ein möglicher ipdiscover abgebrochen wird. Bei class C-Netzwerken kann diese Option entfallen.

Anschließend prüfen wir parallel die Log-Datei:

tail -f /var/log/ocsinventory-agent-debug.log

Als Beispiel sollte zu sehen sein:

[Thu Sep 29 16:19:27 2016][debug] [snmp] Scanning 128.1.10.254 device
[Thu Sep 29 16:19:27 2016][debug] [snmp] Launching 11
[Thu Sep 29 16:19:27 2016][debug] [snmp] Running HP (11) MIB module
[Thu Sep 29 16:19:28 2016][debug] [snmp] Launching Printer_Mib
[Thu Sep 29 16:19:28 2016][debug] [snmp] Running Printer MIB module

Es können jedoch auch Meldungen wie:

[Thu Sep 29 16:30:47 2016][debug] [snmp] Scanning 128.1.9.65 device
[Thu Sep 29 16:31:23 2016][debug] [snmp] Failure in scanning Device 128.1.9.65: no snmp communication

erscheinen. Entweder ist hier kein snmp verfügbar, eine abweichende Community und Protokoll oder der Server ist nicht als Trusted Host auf dem abzufragenden System konfiguriert.

 

Windows Agent mit SSL konfigurieren und testen:

Hinweis: Zur spätern Verteilung in einem Windows Netzwerk bitte den späteren Abschnitt Windows Agent mittels GPO im Netzwerk verteilen beachten.

Zum Test mit OCS Inventory NG Agent verwenden wir die bereits heruntergeladene Datei von: http://www.ocsinventory-ng.org/en/ (siehe Download):

windows_ocsng_agent_download

Sofern der Agent schon auf einem Test-PC installiert war, deinstallieren wir dieses und prüfen anschließend ob die zuvor verwendete Verzeichnisse leer sind:

  • C:\Program Files (x86)\OCS Inventory Agent
  • c:\ProgramData\OCS Inventory NG-Verzeichnis

Bei diesem Test führen wir die Installation mit Verwendung der folgenden Parametern durch:

OCS-NG-Windows-Agent-Setup.exe /server=https://FQDN_des_Servers/ocsinventory /notag /force /ssl=1 /now /s

Hinweis: Damit anschließend die Übermittlung der Daten an den Server erfolgreich ist, empfiehlt es sich hier, vorab die cacert.pem ins Verzeichnis:

c:\ProgramData\OCS Inventory NG

zu kopieren.

Hinweis: Sofern keine Kommunikation mittels /ssl=1 möglich ist, empfiehlt es sich /ssl=0 zu testen. Wenn anschließend eine Kommunikation möglich ist, liegt ein Problem mit dem Zertifikat vor.

 

Durch den Parameter /S wird die Installation im SilentMode durchgeführt. Zusätzlich muss die cacert.pem (Kopie der server.crt vom Server) manuell ins c:\ProgramData\OCS Inventory NG-Verzeichnis kopiert werden.

Parallel zur Installation überwachen wir die activity.log am Server mittels:

tail -f /var/log/ocsinventory-server/activity.log

Wenn alles in Ordnung ist, sehen wir:

Tue Oct  4 09:17:25 2016;12232;100;Computername-2016-10-04-09-13-26;128.1.11.116;OCS-NG_WINDOWS_AGENT_v2.1.1.3;prolog;accepted
Tue Oct  4 09:17:25 2016;12232;311;Computername-2016-10-04-09-13-26;128.1.11.116;OCS-NG_WINDOWS_AGENT_v2.1.1.3;session;started
Tue Oct  4 09:17:32 2016;10278;319;Computername-2016-10-04-09-13-26;128.1.11.116;OCS-NG_WINDOWS_AGENT_v2.1.1.3;session;found
Tue Oct  4 09:17:32 2016;10278;104;Computername-2016-10-04-09-13-26;128.1.11.116;OCS-NG_WINDOWS_AGENT_v2.1.1.3;inventory;incoming
Tue Oct  4 09:17:32 2016;10278;113;Computername-2016-10-04-09-13-26;128.1.11.116;OCS-NG_WINDOWS_AGENT_v2.1.1.3;inventory;u:drives
Tue Oct  4 09:17:32 2016;10278;113;Computername-2016-10-04-09-13-26;128.1.11.116;OCS-NG_WINDOWS_AGENT_v2.1.1.3;inventory;u:softwares
Tue Oct  4 09:17:33 2016;10278;320;Computername-2016-10-04-09-13-26;128.1.11.116;OCS-NG_WINDOWS_AGENT_v2.1.1.3;session;end
Tue Oct  4 09:17:33 2016;10278;101;Computername-2016-10-04-09-13-26;128.1.11.116;OCS-NG_WINDOWS_AGENT_v2.1.1.3;inventory;transmitted

Zusätzlich wird im Verzeichnis der Installationsquelle eine OCS-NG-Windows-Agent-Setup.log erzeugt, deren Inhalt wie folgt aussieht:

debian_ocsng_ocs-ng-windows-agent-setup_log

Hinweis: Wer Probleme zur Installation hat, der kann zur Installation die Option /debug=2 hinzufügen. Hierdurch wird die Log-Datei zum Agent im Verzeichnis c:\ProgramData\OCS Inventory NG aktiviert. Die jeweiligen Einstellungen können zudem nachträglich in der ocsinventory.ini, im Verzeichnis c:\ProgramData\OCS Inventory NG, eingesehen und angepasst werden.

debian_ocsng_ocsinventory_iniV2

Vor Anpassung muss jedoch die ocsservice.exe über den Taskmanager beendet werden.

 

Hinweise zu Problemen mit dem Zertifikat:

Bei der Erstellung zum Zertifikat kann es Probleme geben, die zunächst nicht ersichtlich sind. Ein Hauptgrund hierfür ist meiner Meinung nach die Problematik, dass nicht alle Probleme unmittelbar aus Log-Dateien ersichtlich sind.

Bei Problemen mit aktivierter Option /ssl=1 prüfen wir:

  • wird https statt http verwendet?
  • wurde ein abweichender Port für SSL definiert?
  • wird die korrekte cacert.pem verwendet? Zur Prüfung den Inhalt von server.crt und cacert.pem prüfen und ggf. erneut server.crt zu cacert.pem kopieren.
  • wurde das Zertifikat korrekt erstellt?
  • wird die FQDN oder nur der Servername verwendet? Hier muss zwingend die Variante verwendet werden, wie es zur Zertifikatserstellung eingegeben wurde.
  • ausreichend Leserechte?

Im Fall dass das Zertifikat fehlerhaft ist, können wir dies auf unserem Unix-Server mittels curl testen. Hierzu installieren wir curl mittels:

apt-get install curl

und testen anschließend mittels:

curl -v --cacert /etc/ssl/certs/cacert.pem https://ocsng.domainname.int:443

Hier ein paar Beispiel, die ggf. bei Problemen helfen werden:

 

Beispiel – gleichzeitige Verwendung von FQDN und Servername:

curl -v --cacert /etc/ssl/certs/cacert.pem https://ocsng:443
* Rebuilt URL to: https://ocsng:443/
* Hostname was NOT found in DNS cache
*   Trying 127.0.1.1...
* Connected to ocsng (127.0.1.1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/cacert.pem
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*        subject: C=DE; ST=Some-State; O=Firma GmbH; CN=ocsng.domainname.int
*        start date: 2017-05-15 13:31:29 GMT
*        expire date: 2047-05-08 13:31:29 GMT
* SSL: certificate subject name 'ocsng.domainname.int' does not match target host name 'ocsng'
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'ocsng.domainname.int' does not match target host name 'ocsng'

 

Beispiel – cacert.pem ist nicht gleich server.crt:

curl -v --cacert /etc/ssl/certs/cacert.pem https://ocsng.domainname.int:443
* Rebuilt URL to: https://ocsng.domianname.int:443/
* Hostname was NOT found in DNS cache
*   Trying 127.0.1.1...
* Connected to ocsng.domainname.int (127.0.1.1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/cacert.pem
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: self signed certificate
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
curl: (60) SSL certificate problem: self signed certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

 

Beispiel – Nicht passende Eingaben zum Zertifikat:

curl -v --cacert /etc/ssl/certs/cacert.pem https://ocsng.domainname.int:443
* Rebuilt URL to: https://ocsng.domainname.int:443/
* Hostname was NOT found in DNS cache
*   Trying 127.0.1.1...
* Connected to ocsng.domainname.int (127.0.1.1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/apache2/ssl_certificate/server.crt
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*        subject: C=DE; ST=Thuringia; L=Dein Ort; O=Firma GmbH; OU=IT; CN=IT; emailAddress=it@firmagmbh.de
*        start date: 2016-09-29 13:18:01 GMT
*        expire date: 2021-09-28 13:18:01 GMT
* SSL: certificate subject name 'IT' does not match target host name 'ocsng.domainname.int'
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'IT' does not match target host name 'ocsng.domainname.int'

 

Beispiel – passende cacert.pem:

curl -v --cacert /etc/ssl/certs/cacert.pem https://ocsng.domainname.int:443
* Rebuilt URL to: https://ocsng.domainname.int:443/
* Hostname was NOT found in DNS cache
*   Trying 127.0.1.1...
* Connected to ocsng.domainname.int (127.0.1.1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/cacert.pem
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*        subject: C=DE; ST=Some-State; O=Firma GmbH; CN=ocsng.domainname.int
*        start date: 2017-05-15 13:31:29 GMT
*        expire date: 2047-05-08 13:31:29 GMT
*        common name: ocsng.domainname.int (matched)
*        issuer: C=DE; ST=Some-State; O=Firma GmbH; CN=ocsng.domainname.int
*        SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: ocsng.domainname.int
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 15 May 2017 13:34:30 GMT
* Server Apache/2.4.10 (Debian) is not blacklisted
< Server: Apache/2.4.10 (Debian)
< Set-Cookie: PHPSESSID=3il3trpi8p6asdgrgvv9gr4b4; path=/
< Expires: -1
< Cache-Control: must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Set-Cookie: VERS=7011; expires=Tue, 15-May-2018 13:34:31 GMT; Max-Age=31536000
< Cache-control: private
< Vary: Accept-Encoding
< Content-Length: 6621
< Content-Type: text/html; charset=utf-8
<
<!--DOCTYPE html-->
        <html>
                        <head>
                                <meta charset="utf-8">

...

 

Windows Agent mittels GPO im Netzwerk verteilen:

Zur Verteilung via GPO in einem Netzwerk mit Windows Domäne werden OCS Inventory NG Agent Deployment Tool und OCS Inventory NG Package benötigt, die wir auf der Webseite direkt herunterladen:

http://www.ocsinventory-ng.org

debian_ocsng_prepare_gpo_download

Anschließend entpacken wir jeweils die Ordner und kopieren die exe-Dateien in ein gemeinsames Verzeichnis. In dieses Verzeichnis kopieren wir zusätzlich die cacert.pem, welche wie bereits beschrieben eine Kopie der server.crt vom Server ist.

Anschließend führen wir die OcsPackager.exe aus.

Beim ersten Dialog wählen wir nein.

debian_ocsng_prepare_gpo_packager01

Im zweiten Dialog wählen wir die benötigten Dateien aus für:

  • OCS-NG-Windows-Agent-Setup.exe
  • cacert.pem

Als Command line options hinterlegen wir:

/notag /s /ssl=1 /server=https://FQDN_des_Servers/ocsinventory

debian_ocsng_prepare_gpo_packager02V2

Speichern alles ins gleiche Verzeichnis:

debian_ocsng_prepare_gpo_packager03

Anschließend lassen wir die OcsPackage.exe generieren:

debian_ocsng_prepare_gpo_packager04

Als Ergebnis haben wir nun:

debian_ocsng_prepare_gpo_packager05

Das Ergebnis können wir nun testweise mittels:

c:\gpo\ocspackage.exe /install /np

installieren.

Hinweis: Bei Problemen zur Installation bitte die ocspackage.log im Temp-Verzeichnis (Aufruf mittels %temp%) prüfen.

Damit wir jedoch die Installation via GPO durchführen können, laden wir zunächst die ocspackage.exe auf unserem OCS Inventory Server hoch. Hierzu öffnen wir den Upload-Dialog über Konfiguration -> Agent:

debian_ocsng_add_ocspackage_exe01

Wählen die ocspackage.exe zum Upload aus:

debian_ocsng_add_ocspackage_exe02

Hinweis: Bei Problemen mit dem Upload bitte in diesem Beitrag die php5.ini- und my.cnf-Anpassungen beachten.

Als Ergebnis bekommen wir:

debian_ocsng_add_ocspackage_exe03.jpg

Durch diesen Upload haben jetzt bereits bestehende Clients die Möglichkeit, ohne PC-Neustart, sich zu aktualisieren.

 

Jetzt müssen wir die OcsLogon.exe und OcsPackage.exe, zur Installation der Software auf den Clients, auf unserem Server, für die Verwaltung der Gruppenrichtlinienobjekte, hinterlegen.

Vorab sind jedoch ein paar Besonderheiten zu bachten:

  • die Version der ocslogon.exe sollte mit der Version zur Installation OCS-NG-Windows-Agent-Setup.exe passend sein
  • ocslogon.exe kann mittels Option /GPO mitgeteilt werden, dass die ocspackage.exe sich im gleichen Verzeichnis befindet. Der Download über Server und mögliche Probleme entfallen hiermit.
  • zum Aufruf ocslogon.exe muss mindestens die Option /PACKAGER übergeben werden
  • die Anwendung der GPO muss mit administrativen Rechten ausgeführt werden
  • damit die Installation bei einer bestehender Installation nicht zu jedem Rechnerstart erfolgt, muss als Parameter /DEPLOY die Mindestversion übergeben werden, die auf dem Client zur Nutzung vorliegen muss
  • es empfiehlt sich dringend /debug=2 zu setzen.

Zur Ermittlung der aktuellen Version unseres Windows Agents unter Windows prüfen wir dies über rechte Maus-Taste auf OCS-NG-Windows-Agent-Setup.exe, wechseln auf den Aktenreiter Detail und dokumentieren die Dateiversion:

debian_ocsng_get_version_windows_agent

Mit den aktuellen Informationen haben wir zur Vorbereitung der Installation unseres Windows Agents folgende Befehlszeile:

ocslogon.exe /GPO /PACKAGER /NP /DEBUG=2 /DEPLOY=2.1.1.3

Diese hinterlegen wir nun in einem neuen Gruppenrichtlinienobjekt / GPO auf unserem Active Directory-Server. In meinem Fall wurde dies unter der Benutzerkonfiguration hinterlegt. Der Hintergrund ist hierbei, dass wir nach der Installation sofort die Information an den Server senden und auf diesem Weg den Benutzer zur Anmeldung direkt erhalten. Ansonsten würden wir die Installation über Computerkonfiguration durchführen.

debian_ocsng_ad_server_add_gpo01.jpg

Hinzufügen:

debian_ocsng_ad_server_add_gpo02

Über Durchsuchen hinterlegen wir:

  • ocslogon.exe
  • ocspackage.exe

Bestätigen die Auswahl und hinterlegen als Skriptparameter:

/GPO /PACKAGER /NP /DEBUG=2 /DEPLOY=<Version des Agent in der ocspackage.exe>

 

Auf einem entsprechenden Client führen wir gpupdate /force aus uns starten das System neu.

Parallel zum Rechnerneustart und Benutzeranmeldung überwachen wir die activity.log am Server mittels:

tail -f /var/log/ocsinventory-server/activity.log

Am Client hilft uns bei Problemen die OCSInventory.log im Verzeichnis C:\ProgramData\OCS Inventory NG\Agent.

 

Aktivierung der Softwareverteilung mittels ocs inventory:

Zur Aktivierung der Softwareverteilung mittels ocs inventory erweitern wir zunächst unsere Apache2-Konfiguration durch jeweilige Anpassung der folgenden drei Dateien:

nano /etc/apache2/apache2.conf
<Directory /var/lib/>
        AllowOverride None
        Require all granted
</Directory>

ocsng_apache_apache2_conf

 

nano /etc/apache2/sites-enabled/000-default.conf
        Alias /download/ "/var/lib/ocsinventory-reports/download/"
                <Directory "/var/lib/ocsinventory-reports/download/">
                        <IfModule mod_authz_core.c>
                                Require all granted
                        </IfModule>
                        <IfModule !mod_authz_core.c>
                                Order deny,allow
                                Allow from all
                        </IfModule>
                </Directory>

ocsng_apache_default_download

 

nano /etc/apache2/sites-enabled/default-ssl.conf
                Alias /download /var/lib/ocsinventory-reports/download
                <Directory /var/lib/ocsinventory-reports/download>
                        Options Indexes FollowSymLinks MultiViews
                        AllowOverride None
                        Order allow,deny
                        allow from all
                </Directory>

ocsng_apache_ssl_download

 

Anschließend Starten wir Apache2 durch:

service apache2 restart

 

Test der Softwareverteilung:

folgt

 

Wichtige LOG-Dateien:

  • Log-Datei ocspackage.exe:
  • Debug Log-Datei Unix Agent:
  • Debug Log-Datei Windows Agent:
  • Apache2 Access-Log:
    tail -f /var/log/apache2/access.log
  • Apache2 Error-Log:
    tail -f /var/log/apache2/error.log
  • ocs inventory Server-Log:
  • MySQL-Log:
    mysql -u root -p
    <password>
    set global general_log_file = '/var/log/mysql/mysql.log'; set global general_log = on; set global log_output = 'file';

 

 

Weitere Quellen und hilfreiche Informationen:

Geblockte perl-Module unter Debian installieren – checksum mismatch

Bei der Installation von Perl-Modulen unter Debian mittels:

cpan Archive::Zip

kann es passieren, dass folgende Meldung ausgegeben wird:

Checksum mismatch for distribution file. Please investigate.

cpan_error_checksum_mismatch_mark

 

An dieser Stelle empfiehlt es sich die Datei mittels wget direkt zu testen:

wget http://www.cpan.org/authors/id/P/PH/PHRED/Archive-Zip-1.59.tar.gz

Den Pfad sehen wir hier:

cpan_error_checksum_mismatch_remote_path_file

 

Anschließend prüfen wir den Inhalt der Datei mittels:

 nano /root/.cpan/sources/authors/id/P/PH/PHRED/Archive-Zip-1.59.tar.gz

Den Pfad sehen wir hier:

cpan_error_checksum_mismatch_local_path_file.jpg

 

Wenn der Inhalt, zum Beispiel wie hier, html-Code enthält, ist die Datei voraussichtlich von der Firewall des Netzwerkes blockiert worden.

wget_test_download_archive_zip

Zum Vergleich – korrekt wäre:

wget_test_nano_correct_file

 

Zur Lösung des Problems besteht die Möglichkeit, neben einer Anpassung der Firewall, die betroffene Datei über ein anderes Netzwerk herunterzuladen:

http://www.cpan.org/authors/id/P/PH/PHRED/Archive-Zip-1.59.tar.gz

und anschließend im lokalen Verzeichnis (kann zu jedem Modul abweichend sein) des betroffenen Systems zu aktualisieren:

/root/.cpan/sources/authors/id/P/PH/PHRED/

 

Bei Verwendung von winscp unter Windows muss ggf. die Anzeige von versteckten Ordnern und Dateien auf dem Linux-Server aktiviert werden. Hierzu einfach STRG + ALT + H zum Wechsel der jeweiligen Ansicht verwenden.

PINE 64 – Download-Server mit jDownloader und Fernzugriff (vnc und rdp)

Hier beschreibe ich meine Verwendung eines meiner Pine64 (https://www.pine64.com/) als Download-Server mit JDownloader und Fernzugriff via xrdp und vnc. Ziel ist es einen kleinen Server zu verwenden, der eine sehr geringe Leistungsaufnahme hat und über Remote-Zugriff verwaltet werden kann.

Als Basis verwende ich das Ubuntu Image [20160530] direkt von den Download-Seiten zum Projekt:

Dieses Image habe ich entpackt und anschließend mit Win32 Disk Imager (https://sourceforge.net/projects/win32diskimager/) von meinem Windows PC auf eine geeignete Speicherkarte geschrieben. In meinem Fall eine SanDisk Extreme 64GB microSDXC, U3 Speicherkarte.
Anschließend mit einem Netzwerkkabel, USB-Tastatur und USB-Maus verbunden, das System gestartet und gemäß Vorgabe zum Image mit Benutzername ubuntu und Passwort ubuntu angemeldet.

Erste Schritte:

Da ich direkt zu Beginn keine Pakete installieren und aktualisieren konnte, habe ich über System, Administration, Software & Updates, Aktenreiter Other Software die Paketquellen für ubuntu-pine64-flavour-makers deaktiviert.

pine64_disable_pine64_sources

Wir verlassen das Menü über Close. Anschließend führen wir einen notwendigen Reload durch:

pine64_reload.png

Danach öffnen wir eine Konsole durch die Tastenkombination STRG + ALT und T und installieren die Pakete:

  • ssh
  • x11vnc
  • xrdp
  • mc
  • nano

mittels dem Befehl:

sudo apt-get install ssg x11vnc xrdp mc nano -y

pine64_apt-get_install_ssh_x11vnc_xrdp_mc_nano.png

Durch ssh haben wir nun die Möglichkeit das System über Fernzugriff zu steuern. Unter Windows können wir mittels putty (Download-Quelle: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) und winscp (Download-Quelle: https://winscp.net/eng/download.php) Befehle ausführen und Dateien auf das System kopieren.

Alternativ können wir bereits mittels mstsc von einem Windows-PC auf das System zugreifen. Hierzu einfach folgenden Befehl in der Kommandozeile (WIN-Taste + R) eingeben:

mstsc -v ip-adresse_pine64

Danach erscheint der folgende Dialog, wo wir die bekannten Anmeldedaten eingeben:

pine64_xrdp-test_mstsc01.png

Nachdem wir die Eingabe bestätigt haben, können wir bereits das System über die GUI steuern:

pine64_xrdp-test_mstsc02.png

In meinem Fall verwenden ich als Bildschirm einen LG 34UC98-W mit 3340x1440er-Auflösung Der pine64 hat somit kein Problem solch große Displays zu verwenden.

Zusätzlich werden jetzt Bildschirm, Maus und Tastatur nicht mehr am pine64 benötigt.

In meinem Fall habe ich meinen pine64 mittels Befehl:

 init 0

heruntergefahren und an seinem zukünftigen Platz installiert (nur Strom und Netzwerk).

Nach dem ersten Neustart  wird als Erstes die maximal verfügbare Größe der Speicherkarte dem System zur Verfügung gestellt.

Hierzu geben wir den folgenden Befehl in putty oder in einer Konsole auf dem System ein:

sudo /usr/local/sbin/resize_rootfs.sh

Zur Sicherheit überprüfen wir den Erfolg durch den Befehl df -h.

pine64_resize_rootfs

Zum Neustart des Systems geben wir folgenden Befehl ein:

sudo init 6

Sobald das System wieder verfügbar ist (etwa 1 Minute) führen wir ein paar notwendige Updates durch:

sudo apt-get upgrade -y

pine64_sudo_apt-get_upgrade.png
sudo /usr/local/sbin/pine64_update_kernel.sh

pine64_pine64_update_kernel

sudo /usr/local/sbin/pine64_update_uboot.sh

pine64_pine64_update_uboot.png

und starten anschließend das System durch.

 

Konfiguration von xrdp und x11vnc:

Nachdem das System wieder verfügbar ist, konfigurieren wir xrdp und x11vnc.

Zunächst konfigurieren wir die Verwendung von x11vnc. Hierzu setzen wir ein Passwort (Beispiel: jdownloader) mittels:

sudo x11vnc -storepasswd /etc/x11vnc.pass

pine64_x11vnc_storepasswd.png

Anschließend konfigurieren wir x11vnc zum Systemstart mittels:

sudo nano /lib/systemd/system/x11vnc.service

und fügen folgende Zeilen ein (Achtung: ggf. wird das Minus-Zeichen nicht korrekt übernommen):

[Unit]
Description=Start x11vnc at startup.
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -xkb -auth /var/run/lightdm/root/:0 -repeat -loop -shared -noxdamage -rfbauth /etc/x11vnc.pass -forever -bg -rfbport 5900 -o /var/log/x11vnc.log

[Install]
WantedBy=multi-user.target

Bei Verwendung von putty einfach rechts Maustaste verwenden.

Zum Speichern und Schließen geben wir folgende Tastenkombinationen ein:

  • STRG + O
  • ENTER
  • STRG + X

Anschließend aktivieren wir x11vnc zum Start mittels:

sudo systemctl daemon-reload
sudo systemctl enable x11vnc.service

pine64_set_service_x11vnc

Danach richten wir xrdp ein. Zur Sicherheit erstellen wir zunächst eine Kopie der aktuellen Konfig mittels:

sudo cp /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.ini_bak

Danach passen wir die aktuelle Konfig mittels:

sudo nano /etc/xrdp/xrdp.ini

an. Die Datei hat zu Beginn folgenden Inhalt:

[globals]
bitmap_cache=yes
bitmap_compression=yes
port=3389
crypt_level=low
channel_code=1
max_bpp=24
#black=000000
#grey=d6d3ce
#dark_grey=808080
#blue=08246b
#dark_blue=08246b
#white=ffffff
#red=ff0000
#green=00ff00
#background=626c72

[xrdp1]
name=sesman-Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1

[xrdp2]
name=console
lib=libvnc.so
ip=127.0.0.1
port=5900
username=na
password=ask

[xrdp3]
name=vnc-any
lib=libvnc.so
ip=ask
port=ask5900
username=na
password=ask

[xrdp4]
name=sesman-any
lib=libvnc.so
ip=ask
port=-1
username=ask
password=ask

[xrdp5]
name=rdp-any
lib=librdp.so
ip=ask
port=ask3389

[xrdp6]
name=freerdp-any
lib=libxrdpfreerdp1.so
ip=ask
port=ask3389
username=ask
password=ask

[xrdp7]
name=sesman-X11rdp
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
xserverbpp=24

In meinem Fall wurden die Konfig-Elemente xrdp2 und xrdp4 bis xrdp7 vollständig gelöscht und xrdp3 zu xrdp2 umbenannt. In nano können Zeilen zum Beispiel mittels Tastenkombination:

STRG + K

gelöscht werden. Ergebnis:

[globals]
bitmap_cache=yes
bitmap_compression=yes
port=3389
crypt_level=low
channel_code=1
max_bpp=24
#black=000000
#grey=d6d3ce
#dark_grey=808080
#blue=08246b
#dark_blue=08246b
#white=ffffff
#red=ff0000
#green=00ff00
#background=626c72

[xrdp1]
name=sesman-Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1

[xrdp2]
name=vnc-any
lib=libvnc.so
ip=ask
port=ask5900
username=na
password=ask

Wer wie ich das System lediglich so konfiguriert, dass andere Systeme auf dieses zugreifen, jedoch dieses nicht auf die anderen (es ist ein Frage zwischen Sicherheit und Komfort) kann zusätzliche Anpassungen für xrdp1 und xrdp2 durchführen.

[globals]
bitmap_cache=yes
bitmap_compression=yes
port=3389
crypt_level=low
channel_code=1
max_bpp=24
#black=000000
#grey=d6d3ce
#dark_grey=808080
#blue=08246b
#dark_blue=08246b
#white=ffffff
#red=ff0000
#green=00ff00
#background=626c72

[xrdp1]
name=sesman-Xvnc
lib=libvnc.so
username=ubuntu
password=ubuntu
ip=127.0.0.1
port=-1

[xrdp2]
name=vnc-any
lib=libvnc.so
ip=127.0.0.1
port=ask5900
username=na
password=jdownloader

Bei xrdp1 habe ich Benutzername und Passwort hinterlegt. Bei xrdp2 die Loopback-IP-Adresse, damit ich mittels vorliegender RDP-Sitzung die vnc-Sitzung auf dem pine64 direkt ansprechen kann und auch hier das Passwort für meine VNC-Sitzung.

Zum Prüfen, dass auch die Dienste zum Start korrekt ausgeführt werden, führen wir erneut einen Neustart durch.

Anschließend testen wir die Verbindungen mittels:

mstsc -v ip-adresse_pine64

pine64_xrdp-test_mstsc03.png pine64_xrdp-test_mstsc04.png

pine64_xrdp-test_mstsc05.png

pine64_xrdp-test_mstsc06.png

Zusätzlich sollte ein Test mit einem regulären VNCViewer erfolgen.

 

Weitere Anpassungen:

Zum Ende empfiehlt sich die Installation der deutschen Sprache auf dem System und die Umstellung des Tastaturlayouts. Als erstes rufen wir über die GUI mittels System, Personal, Language Support den Language Support auf.

pine64_language_support.png

Als erstes bestätigen wir Install und geben das Passwort ein:

pine64_language_support_install.png

Danach aktualisiert das System die Sprachpakete:

pine64_language_support_applying_changes.png

und im Anschluss danach fügen wir die deutsche Sprache hinzu:

pine64_language_support_add_language.png

Jetzt bestimmen wir das deutsche Tastaturlayout über System, Preferences, Hardware, Keyboard:

pine64_keyboard_layout

Danach öffnen wir den Dialog zum Hinzufügen eines neuen Tastaturlayouts:

pine64_keyboard_layout_add

Wählen als Land German und schließen das Fenster. Jetzt verändern wir die Reihenfolge zur Anwendung des Tastaturlayouts durch Auswahl German und Move Up:

pine64_keyboard_order

Anschließend führen wir erneut einen Neustart durch, da nicht unmittelbar die Korrekturen aktiv werden.

JDownloader – Installation:

Hinweis: Bitte die JDownloader2-Installation beachten!

Zur Installation von JDownloader fügen wir die PPA-Quellen hinzu und installieren die Pakete mittels:

sudo add-apt-repository ppa:jd-team/jdownloader
sudo apt-get update
sudo apt-get install jdownloader-installer unrar -y

pine64_jdownloader_add_repo

pine64_jdownloader_install

Anschließend können wir JDownloader über Anwendung, Internet, JDownloader starten:

pine64_jdownloader_start_menu

Die Meldung bzgl. falscher Runtime ignorieren wir:

pine64_jdownloader_java_error

Warten den Update-Prozess ab:

pine64_jdownloader_first_run.png

Führen ein paar Einstellungen durch:

pine64_jdownloader_config

Bestätigen das erfolgreiche Update:

pine64_jdownloader_update

… und führen kein Update durch, da dies derzeit fehlschlägt:

pine64_jdownloader_update_problem

JDownloader kann jetzt verwendet werden.

 

Installation SUN Java JDK:

Hinweis: Trotz erfolgreicher Installation von Java SDK war es anschließend nicht möglich JDownloader erfolgreich zu starten. Unabhängig der alten oder neuen Version. Für kurze Zeit war ein entsprechender Java-Prozess zu sehen der jedoch ohne weitere Meldung beendet wurde.

Wer es selbst versuchen möchte:

Die meiner Meinung nach korrekte Version hatte ich hierbei von SUN direkt heruntergeladen:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

pine64_sun_java_sdk_site.png

 

pine64_sun_java_sdk_download

 

Anschließend habe ich die folgende Befehle ausgeführt:

tar zxvf jdk-8u91-linux-arm64-vfp-hflt.tar.gz
sudo mv /home/ubuntu/Downloads/jdk1.8.0_91/ /usr/lib/jvm/
sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_91/bin/java" 1
sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.8.0_91/bin/javac" 1
sudo chmod a+x /usr/bin/java
sudo chmod a+x /usr/bin/javac
sudo chown -R root:root /usr/lib/jvm/jdk1.8.0_91/

Zur Prüfung der aktuell verwendeten Version können die Befehle:

  • javac -version
  • java -version
  • sudo update-alternatives –config java

verwendet werden:

pine64_sun_java_set_version02

Hinweis: Wer später Probleme hat JDownloader zu starten, muss lediglich:

sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_91/bin/java" 1

erneut ausführen und mittels 0 [Die Zahl] den alten Standard setzen.

 

JDownloader 2 – Installation:

Zur Installation von JDownloader2 habe ich zunächst ein Verzeichnis über die Konsole erstellt:

mkdir $HOME/.jd2

Anschließend habe ich den Installer über folgende Quelle heruntergeladen:

  • installer.jdownloader.org/JDownloader.jar

Hinweis: Erst als ich die Datei von meinem Windows-PC heruntergeladen habe und diese per WinSCP in das neue Verzeichnis gespeichert habe, konnte ich die Installation erfolgreich durchführen. Der Download mittels wget unter Ubuntu war zwar erfolgreich, jedoch konnte ich die Installtion nicht erfolgreich starten. Wer in WinSCP den versteckten Ordner .jd2 nicht sieht, kann mittels STG + ALT + H zwischen der zusätzlichen Darstellung von versteckten Dateien und Ordner wechseln. Unter Ubuntu ist diese Tastenkombination STRG + H.

2. Hinweis: Bei meinen Tests konnte ich auch die Datei JD2SilentSetup.sh (http://installer.jdownloader.org/JD2SilentSetup_x64.sh) zwar herunterladen, jedoch wurden die hierbei integrierten Pakete durch unrar200 nicht erfolgreich entpackt.

Anschließend setze ich die notwendigen Berechtigungen zur Ausführung:

chown -R ubuntu:ubuntu $HOME/.jd2

und erstellte eine Verknüpfung auf meinem Desktop mittels:

nano /$HOME/Desktop/jDownloader2.desktop

wo ich folgenden Inhalt hinterlege:

[Desktop Entry]
Encoding=UTF-8
Name=jDownloader2
Comment=jDownloader2
Exec=bash -c "java -jar $HOME/.jd2/JDownloader.jar"
Icon=$HOME/.jd2/themes/standard/org/jdownloader/images/logo/jd_logo_256_256.png
Type=Application
Categories=GTK;Utility;

Anschließend speichern und die Verknüpfung ausführbar machen:

chmod +x $HOME/Desktop/jDownloader2.desktop

Zur Sicherheit habe ich vorm ersten Start eine Sicherheitskopie der jar-Datei erstellt, da diese nach dem ersten Start aktualisiert wird:

cp $HOME/.jd2/JDownloader.jar $HOME/.jd2/JDownloader_backup.jar

Nach dem ersten Start mittels Verküpfung auf unserem Desktop sollte nun zu sehen sein:

pine64_jdownloader2_first_run

pine64_jdownloader2_first_run02

Anbei zum Vergleich der Verzeichnisinhalt nach erstem Start:

pine64_jdownloader2_ls_l

Erweiterung des verfügbaren Arbeitsspeicher mittels zram:

Es wird bei Systemen wie pine64 empfohlen keine SWAP-Partitionen zu verwenden. In meinem Fall verfügt mein pine64 lediglich über 1GB RAM und bei Tests mit JDownloader hatte ich mehrfach das Problem, dass die Anwendung unerwartet und ohne Meldung beendet wurde (RAM kleiner 10000). Es war zum Beispiel nie möglich die Plugins von JDownloader 2 zu öffnen. Der verfügbare RAM wurde innerhalb einer Minute immer kleiner, bis die Anwendung geschlossen wurde. Nach der Aktivierung von zram werden die Plugins innerhalb zwei Sekunden geöffnet.

Zum Aktivieren von zram erstellen wir zunächst eine Datei für einen neuen Service:

sudo nano /lib/systemd/system/zram.service

und fügen folgenden Inhalt ein:

[Unit]
Description=zRam block devices swapping

[Service]
Type=oneshot
ExecStart=/bin/bash -c "modprobe zram && echo 2G > /sys/block/zram0/disksize && mkswap --label zram0 /dev/zram0 && swapon --priority 100 /dev/zram0"
ExecStop=/bin/bash -c "swapoff /dev/zram0 && rmmod zram"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Anschließend speichern wir die Datei und führen den folgenden Befehl aus:

sudo systemctl enable zram
Für Tests kann auch der Befehl:
sudo /bin/bash -c "modprobe zram && echo 2G > /sys/block/zram0/disksize && mkswap --label zram0 /dev/zram0 && swapon --priority 100 /dev/zram0"

verwendet werden. Nach einem Neustart kann mit dem Befehl:

zramctl
geprüft werden, ob die Aktivierung erfolgreich war.
pine64_zram_test_command
Alternativ sehen wir das Ergebnis mit dem Befehl:
top
pine64_zram_active

Hinweis: In einigen Quellen wurde zusätzlich der Befehl echo lz4 > /sys/block/zram0/comp_algorithm unter ExecStart im Dienst hinterlegt. Leider existiert die Datei nicht und konnte auch nicht mit entsprechenden rechten erstellt werden. Ich bin jedoch derzeit mit der Leistung meines pine64 zufrieden.

Aktivierung ffmpeg-Unterstützung für Youtube-Download:

Wer gelegentlich Videos von Youtube herunterladet benötigt in JDownloader ffmpeg. Zur Installation muss der folgende Befehl ausgeführt werden:

sudo apt-get install ffmpeg -y

Anschließend hinterlegen wir den Pfad zu ffmpeg im JDownloader über das Menü Einstellungen, Profileinstellungen (linke Seite mit Warndreieck) und Suchen den Eintrag FFmpegSetup: Binary Path. Den Wert null ändern wir zu:

/usr/bin/ffmpeg

pine64_jdownloader_ffmpeg_path

Quellen:

 

Debian – Probleme bei Installation und Aktualisierung von Paketen (Größe stimmt nicht überein / Size mismatch)

Nach Aktualisierung einer Firewall war es anschließend nicht mehr möglich Pakete / Programme von unseren Linux-Servern mittels apt-get zu installieren, bzw. herunterzuladen. Es erschien hierbei die Meldung:

debian_apt_get_size_mismatch

Fehlschlag beim Holen von http://...deb  Größe stimmt nicht überein

bzw.

Failed to fetch http://...deb  Size mismatch

 

Typische Lösungen für das vorliegende Problem sind die Bereinigung des Cache von apt-get:

apt-get clean
apt-get update

oder aber, wenn ein Proxy-Server mit aktiviertem Cache verwendet wird, muss der Proxy-Cache auf dem Proxy-Server geleert werden.

 

Beispiel bei squid3:

Config-Datei öffnen

nano /etc/squid3/squid.conf

Zeile mit cache_dir suchen :

cache_dir ufs /var/spool/squid3 2000 16 256

und ins hinterlegte Verzeichnis wechseln:

cd /var/spool/squid3

Mittels

ls -l

lassen wir uns die bestehende Struktur anzeigen:

debian_apt_get_cache_dir_squid3

Jetzt Squid3 beenden:

/etc/init.d/squid3 stop

und anschließend im Verzeichnis mit den Cache-Dateien alle Dateien und Verzeichnisse löschen (hier unbedingt sicherstellen, dass man im wirklich richtigen Verzeichnis ist):

rm -R *

Danach starten wir squid3 neu:

/etc/init.d/squid3 start

und sehen folgende Ausgabe (Beispiel mit dem vorherigen Löschen der Cache-Dateien):

debian_apt_get_restart_squid3.jpg

In meinem Fall war es jedoch die Firewall und keine der Varianten war die Lösung. Ich habe daher versucht das benötigte Paket mittels:

 apt-get download <Paketname>

herunterzuladen. Bei Erfolg wäre die Datei im Verzeichnis /var/cache/apt/archivies gewesen. Leider nein, daher die Variante mittels wget als direkten Download der Datei vom Server versucht:

debian_apt_get_wget_test.jpg

In meinem Fall lag nun eine entsprechend benannte Datei vor, der Inhalt jedoch sah wie folgt aus:

 

debian_apt_get_wget_test_02

Gegentest mit einem anderen System mittels Webbrowser:

debian_apt_get_browser_test

Somit hat die Firewall die Datei geblockt.

Jetzt muss zur Lösung entweder die Firewall entsprechend konfiguriert und ggf. der Proxy-Cache geleert werden.

Eine andere Möglichkeit ist jedoch die benötigte Datei über ein anderes System herunterzuladen und im Verzeichnis /var/cache/apt/archivies zu speichern. Anschließend erneut den Befehl zur Installation des gewünschten Paketes ausführen:

 apt-get install <Paketname>

Die letzte Variante konnte ich dabei schon erfolgreich verwenden, wo nur eine Datei als Abhängigkeit zu einer Installation von der Firewall geblockt wurde.

FOG-Server – PXE-TOO: File name too long

Beim Einsatz vom FOG-Server des FOG-Projektes:

kann es bei einigen Clients vorkommen, dass der Boot des Netzwerk-Boot-Image über PXE via dhcp fehlschlägt. Bei Meldung:

PXE-T00: File name too long

PXE-T00_filename_too_long_error.JPG

kann der folgende Workaround verwendet werden.

 

Wir booten mit einer Boot-CD oder anderem bootfähigem Datenträger Clonezilla:

Nach dem erfolgtem Boot von Clonezilla wählen wir die Option:

  • Network boot via iPXE

PXE-T00_filename_too_long_01.JPG

  • Wechseln mit der Tastenkombination STRG + B in die Kommandozeile:

PXE-T00_filename_too_long_02.JPG

Wenige Sekunden später erscheint die Kommandozeile:

PXE-T00_filename_too_long_03.JPG

Hinweis: Mit help stehen uns die möglichen Befehle zur Verfügung.

PXE-T00_filename_too_long_04_help.JPG

  • Zum Aufruf des FOG-Servers über dhcp geben wir zunächst dhcp ein:

PXE-T00_filename_too_long_05_dhcp

  • … und anschließend autoboot:

PXE-T00_filename_too_long_06_autoboot.JPG

Anschließend wird das Netzwerk-Boot-Image vom FOG-Server wie gewohnt geladen:

PXE-T00_filename_too_long_07.JPG

PXE-T00_filename_too_long_08.JPG

Installation und Einrichtung TVHeadend auf einem Debian-Server mit Verwendung einer Tuner-Karte Cine S2 und Verwendung via Kodi

Historie Artikel:

  • Update 24. Oktober 2016 – Zusammenfassung Zeitprobleme EPG und Erweiterung um Troubleshooting bei Korrektur EPG, Serverzeit und Zeitzone
  • Update 2. Juni 2016 um 2. Variante zur Behebung Zeitprobleme EPG
  • Update 27. Mai 2016 um 1. Variante zur Behebung Zeitprobleme EPG

Bei diesem Eintrag geht es um die Installation und Einrichtung einer TVTuner-Karte Cine S2 V6.5 DuoFlex S2v4 von DigitalDevices unter Debian 8.4, mit anschließender Installation und Einrichtung von HTS Tvheadend 4.0.9-4. Zur späteren Verwendung wird Kodi 16.1 (Stand 24.04.2016) als Client genutzt.

Der Anwendungsfall beschreibt die Möglichkeit zum Sehen und Hören unseres deutschen Radio- und Fernsehangebots über Computer (Windows/Linux), Android-Tablet, Android-Smartphone, Amazon Fire TV-Stick, Raspberry Pi mit OpenELEC oder LibreELEC, jeweils auch über WLAN, im privaten Netzwerk, zum Beispiel abends im Garten.

In meinem Fall erfolgt die Verwendung eines Systems zur Verteilung des bestehenden SAT-Signals auf mehrere Endgeräte gleichzeitig über ein Kabel. Alternativ kann ein LNB mit mehreren Ausgängen verwendet werden. Hier empfehle ich dringend einen Fachmann zu Rate zu ziehen. Dieser verfügt über entsprechende Möglichkeiten zum Testen und kann vorab bestätigen, dass das Signal zur Verwendung wirklich anliegt. Sofern dies nicht sichergestellt ist, empfehle ich nicht die Anschaffung teuerer Hardware.

Folgende Punkte werden hier erläutert:

  • Vorauswahl der notwendigen TVTuner-Karte
  • Installation Debian 8.4 im Minimalzustand
  • Installation der Treiber für TVTuner-Karte Cine S2 V6.5 DuoFlex S2v4
  • Installation TVHeadend
  • Einrichtung TVHeadend
  • Verwendung TVHeadend innerhalb Kodi

Vorauswahl und Vorüberlegung zur Wahl der notwendigen TVTuner-Karte:

Vor dem Kauf einer entsprechenden Karte sind mehrere Punkte zu beachten. Dies sind:

  • Welcher Anschluss und welches Verfahren werden zur Signaleinspeisung verwendet?
  • Wie viele Clients werden maximal (auch langfristig gesehen) verwendet?
  • Wie viele Programme sollen mindestens gleichzeitig zur Verfügung stehen?
  • Wird eine CI-Karte für zusätzliche Inhalte benötigt?
  • Wie erfolgt die Übertragung des Satelitten-Signals? Über Mehrfach-LNB oder Verfahren wie Unicable?

Als erste notwendige Informationen möchte ich hierbei auf die Produktliste von DigitalDevices und den Senderlisten von Astra verweisen:

DigitalDevices bietet für unterschiedlichen Einsatzszenarien unterschiedliche Varianten an. In meinem Fall, den ich hier auch explizit beschreibe, wird das Signal über eine Sattelitenempfangsanlage  und einem Multischalter in das neue System eingespeist. Daher wird eine Karte mit S2 im Namen verwendet. S2 steht hierbei für die interne Verwendung eines DVB-S/S2-Tuner. Wird hingegen ein DVB-C (Kabel)-Tuner oder DVB-T-Tuner benötigt, so muss eine Variante mit CT gewählt werden. In meinem Fall bietet die von mir verwendete Karte 4 Eingänge die anschließend über ein zusätzliches DuoFlex-Modul mit 4 weiteren Eingängen erweitert werden kann und später beschrieben, wird. Hierzu wird die neue Karte mit zwei Flachbandkabeln mit der bestehenden direkt verbunden.

Ich bitte um Beachtung, dass ich hier nur den computerseitigen Bereich behandle, nicht jedoch den der SAT-Anlage. Diese bestand bereits im Vorfeld!

Die Möglichkeiten bei den Karten von DigitalDevices sind sehr groß, daher sollte im Vorfeld genau geprüft werden, welche Variante die sinnvollste im eigenen Sonderfall ist.

Für ganz kleine Szenarien empfehle ich zu prüfen, ob ggf. ein Raspberry Pi mit USB-Stick als Player oder Streaming-Server genutzt werden kann. Als Client kann zum Beispiel ein Android-Tablet genutzt werden. Es muss lediglich ein WLAN-Router beide Systeme verbinden. Multischalter, Mehrfach-LNB etc. könnten somit entfallen.

Zu den Senderlisten von Astra folgende Hinweise:

tvheadend_Astra_Senderliste

Über die Sortierung nach Frequenzbelegung ist am Beispiel von ARTE Deutschland HD, Das Erste HD, SWR Fernsehen BW HD und SWR Fernsehen RP HD zu sehen, dass alle über die gleiche Frequenz 11494 MHz verfügbar sind.

tvheadend_Astra_Senderliste_11494

Die Tuner-Karten können hierbei pro Eingang eine Frequenz mit den spezifischen Empfangsdaten gleichzeitig, mit den jeweiligen Programmen, empfangen. Somit stehen bei Verwendung der Frequenz 11494 MHz vier Sender gleichzeitig zur Verfügung. Je nach Frequenz und Standard-Technologie (SD, HD oder Radio) sind zusätzliche Programme pro Frequenz möglich.

Mit dem in Deutschland verfügbaren „kleinen“ Programm werden in etwa acht Frequenzen benötigt, die gleichzeitig zur Verfügung stehen müssen, um die entsprechende Programmvielfalt in etwa nutzen zu können. Das bedeutet, wenn wir acht Eingänge nutzen, dass wir acht Frequenzen gleichzeitig mit allen Programmen nutzen können, unabhängig ob wir zwei, vier, oder 60 Clients im Netzwerk verwenden. Alle Sender der acht Frequenzen würden uns gleichzeitig zur Verfügung stehen. Wichtig ist hierbei, dass zum Beispiel über ein Multischalter, für die acht Frequenzen, die Signale jeweils zur Verfügung stehen.

Bei Verwendung einer einfachen TV-Tuner-Karte mit zwei Eingängen bedeutet jedoch, dass wir maximal zwei Frequenzen mit allen Sendern nutzen können. Bei Verwendung von drei Clients gleichzeitig stehen somit nur 8 bis 12 Programme, je nach Frequenz, zur Verfügung. Werden nur zwei Clients gleichzeitig genutzt, sind wieder alle Programme möglich. In diesem Fall ist es sogar möglich zusätzliche Frequenzen zu hinterlegen. Zum Beispiel für das englischsprachige Programm.

In einem Haushalt mit maximal vier Personen und maximaler Verwendung von vier Clients mit Kodi ist somit eine Lösung mit mindestens vier Eingängen notwendig.

Bei Szenarien mit mehr als acht Clients gleichzeitig würde ich daher eine Lösung mit acht Eingängen verwenden und pro Eingang lediglich eine Frequenz zur Nutzung zuordnen. Bei einer Verwendung von lediglich zwei Eingängen und maximal zwei Clients würde ich alle Frequenzen pro Eingang zuordnen (auch mehr als der acht Frequenzen). Solange die Anzahl kleiner acht ist, würde ich immer mindestens die entsprechende Anzahl an Eingängen verwenden. Hierdurch ist der maximal mögliche Ausbau ohne Einschränkung der Frequenzen möglich. Bei einer Anzahl Clients größer der Anzahl an Eingängen würde ich maxmial eine Frequenz pro Eingang zuordnen. Somit wird der Fall vermieden, dass eine Meldung erscheint, dass der Adapter bereits in Verwendung ist.

In meinem Fall sind es mehr als acht Clients und ein nicht privater Einsatzbereich. Daher werden pro Eingang immer nur eine Frequenz zugeordnet.

Installation Debian 8.4 im Minimalzustand:

Debian 8.4.0 über netinst – CD mit:

  • SSH Server
  • Standard Systemwerkzeugen

installiert. Anschließend über die Kommandozeile das Netzwerk auf static geändert:

nano /etc/network/interfaces

debian_network_static_sample

Hinweis: ^ steht für die STRG-Taste. Somit mit STRG+o wird gespeichert und anschließend mit STRG + x wird nano beendet.

und ssh-Zugriff für root aktiviert.

nano /etc/ssh/sshd_config

wo wir PermitRootLogin without-password mittels # auskommentieren und PermitRootLogin yes einfügen.

debian_activate_ssh_root_user_sample

Behebung Zeitprobleme für EPG [Update zum 27. Mai 2016 und 2. Juni 2016]

Nach Abschluss der hier beschriebenen Installation musste ich feststellen, dass die Zeiten für den EPG im Kodi nicht korrekt waren. Auffällig für mich waren neben den Abweichungen EPG und laufendem Programm im Kodi, dass im Log des Servers die Zeit in der Zukunft lag und der Progress-Balken im Electronic Program Guide für kurze Sendungen nie zu sehen war. Zum Vergleich ein Beispiel mit Auswahl arte als Sender, wie es korrekt ist.

tvheadend_time_problem_epg

Nach mehreren Versuchen konnte ich eine entsprechende Lösung finden.

 

Behebung Zeitprobleme für EPG

Wir prüfen zur Installation des Servers die Zeitzone auf dem Server mit:

cat /etc/timezone

Zum Setzen der Zeitzone geben wir den folgenden Befehl ein:

dpkg-reconfigure tzdata

und legen mit Europa und Berlin die Zeitzone fest.

Ausgabe-Beispiel:

Current default time zone: 'Europe/Berlin'
Local time is now:      Fri May 27 13:15:15 CEST 2016.
Universal Time is now:  Fri May 27 11:15:15 UTC 2016.

 

Anschließend prüfen wir die Zeit im Debian und die der Hardware:

root@TVHeadend:~# date
Fr 27. Mai 13:25:16 CEST 2016
root@TVHeadend:~# hwclock --show
Fr 27 Mai 2016 13:26:14 CEST  -1.004662 seconds

In meinem Fall lag eine Zeitverschiebung der Local Time von einer Stunde zur „realen“ Zeit vor, die ich manuell korrigiert habe:

date 05271236
Fr 27. Mai 12:36:00 CEST 2016

Zur Info zu date: 05 ist der Monat, 27 der Tag, 12 die Stunde und 36 die Minute.

Alternativ kann auch ntp unter Debian aktiviert werden:

apt-get install ntp

Dann prüfen wir auf die verfügbaren Server:

ntpq -p

Ausgabe-Beispiel:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 cloud.a-schieb. .INIT.          16 u    -   64    0    0.000    0.000   0.000
 gingey.oranged. .INIT.          16 u    -   64    0    0.000    0.000   0.000
 s1.kelker.info  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 lite.computer   .INIT.          16 u    -   64    0    0.000    0.000   0.000

Zusätzlich kann ein bestehender Server im eigenen Netzwerk (mit aktivem NTP-Dienst) durch anpassen der Datei /etc/ntp.conf genutzt werden, wo wir unterhalb

#server ntp.your-provider.example

eine Zeile mit:

server <zu hinterlegende Server-IP>

einfügen.

Danach starten wir den Dienst neu:

/etc/init.d/ntp restart

Wir prüfen erneut auf verfügbare Server:

ntpq -p

Hierbei sollte ein zusätzlicher Server zu Beginn zu sehen sein. Zum Forcieren der Übernahme der Zeit geben wir ein:

ntpd -s <hinterlegte Server-IP> -x

Mit

date

prüfen wir erneut, ob die Zeit nun korrekt ist.

 

Anschließend empfiehlt es sich die Hardware-Zeit an die vom PC zu synchronisieren. Dies erfolgt über:

hwclock --systohc

 

Installation der Treiber für TVTuner-Karte Cine S2 V6.5 DuoFlex S2v4

Sofern ein Proxy zur Installation genutzt werden muss, bitte folgenden Proxy-Einstellungen für hg, apt, wget und System setzen. Siehe hierzu: https://lichtschattenblog.wordpress.com/2016/04/21/proxy-unter-linux/

Ansonsten Ausgabe von:

uname –r

In meinem Fall: 3.16.0-4-amd64

direkt hinter:

apt-get install mercurial build-essential libproc-processtable-perl linux-headers-

setzen:

apt-get install mercurial build-essential libproc-processtable-perl linux-headers-3.16.0-4-amd64

und ausführen.

tvheadend_01_install_media_build_experimental

Ausgabe am Ende:

tvheadend_02_abschluss_install_media_build_experimental

Danach ins Verzeichnis /usr/src wechseln.

cd /usr/src

und Paketdateien herunterladen.

hg clone http://linuxtv.org/hg/~endriss/media_build_experimental/

Anschließend Treiber bauen und installieren:

cd media_build_experimental
make download
make untar
make
make install

Die Ausgaben am Ende sollten in etwa wie folgt aussehen:

tvheadend_05_abschluss_make_untar

tvheadend_06_abschluss_make

tvheadend_07_abschluss_make_install

Die Ausführung von make dauert recht lange. Einfach warten. 10 Minuten sind realisitisch. Ggf. sogar länger. Danach einen Neustart mit init 6 durchführen (war bisher immer notwendig – modprobe ngene und modprobe ddbridge führten nicht zum gewünschten Ergebnis ).

Installation TVHeadend:

Bei Verwendung eines Proxy und dem zuvor durchgeführten Neustart muss ggf. erneut der Befehl für den Proxy zum System gesetzt werden!

Schlüssel hinterlegen:

apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 379CE192D401AB61

Notwendige Paketquellen für apt hinterlegen:

echo "deb https://dl.bintray.com/tvheadend/deb jessie stable" | tee -a /etc/apt/sources.list

tvheadend_08_apt_sources

Bei Verwendung einer anderen/späteren Debian-Version ggf. jessie mit der korrekten Variante aktualisieren. Zum Vergleich einfach in die /etc/apt/sources.list den typischen Eintrag:

deb http://ftp.de.debian.org/debian/ <name> main

suchen und den Eintrag in <name> verwenden. Anschließend Paketquellen aktualisieren:

apt-get update

In meinem Fall musste zusätzlich

apt-get install apt-transport-https
apt-get update

ausgeführt werden. Anschließend tvheadend installieren:

apt-get install tvheadend

tvheadend_09_apt_install_tvheadend.jpg

Während der Installation werden Benutzer und Passwort abgefragt. Nach der Information bzgl. späterem Aufruf über http://<serverip&gt;:9981 zunächst die Installation abschließen. Zur Ausgabe creating user ist es eine längere Wartezeit typisch.

tvheadend_10_username

tvheadend_11_accessinfo

Einrichtung TVHeadend:

Nach Abschluss der Installation prüfen wir über einen Webbrowser (in meinem Fall Mozilla Firefox) die Installation durch Aufruf via http://servername:9981 und wechseln nach Eingabe von Benutzername und Passwort, welche wir zur Installation hinterlegt haben, in den Aktenreiter Configuration, dann DVB Inputs und anschließend zu TV adapters. Im Ergebnis sollte ein ähnliches Bild wie hier zu sehen sein.

tvheadend_12_config_dvbinputs_tvadapters

Spätestens jetzt müssen an den Eingängen die notwendigen Kabel korrekt angeschlossen werden.

Wichtige Einstellungen zu Beginn:

  • Debug-Logging aktivieren
  • Meldungen in der unteren Leiste ausgeben
  • Adapter aktivieren !!!

Zum Aktivieren des Debug-Logging wechseln wir in den Aktenreiter Configuration und anschließend zu Debugging. Hier aktivieren wir Debug to syslog und speichern die Auswahl über Apply configuration (run-time only). Anschließend aktivieren die Ausgabe der Meldungen in der unteren Leiste durch das doppelte Dach-Symbol rechts unten.

tvheadend_13_enable_debugging

Anschließend kann über die Console / putty-Sitzung über den folgenden Befehl das Logging ausgegeben werden.

tail -f /var/log/syslog | grep 'tvheadend'

Jetzt wechseln wir erneut in den Aktenreiter Configuration, dann DVB Inputs und anschließend zu TV adapters. Hier wählen wir auf der linken Seite die jeweilige Karte aus und aktivieren auf der rechten Seite unterhalb Basic Settings Enabled und speichern anschließend mit Save (ganz unten).

tvheadend_14_enable_adapter

Am Ende prüfen wir, ob wirklich alle aktiv sind. Alle weiteren Funktionen greifen auf dieser Einstellung und es werden keine Fehler etc. ausgegeben.

Über den Aktenreiter Configuration, dann DVB Inputs und und Networks wählen wir über Add und dem anschließenden Auswahldialog: DVB-S Network.

tvheadend_15_Add_Network

In Network Name vergeben wir einen sinnvollen Namen zum Einsatzzweck passend. Da ich hart die Netzwerke nach Frequenz trenne, wähle ich als Namen eine Kombination von Netzwerktyp und einer fortlaufenden Nummer. Da ich gezielt die Frequenzen zuordne, muss das Häckchen bei Network Discovery entfernt werden. Wer jedoch alle verfügbaren Sender sehen möchte, sollte dies weiterhin aktiv haben. Das System versucht dann alle verfügbaren Frequenzen zu ermitteln. Kleiner Hinweis: Erst an einer späteren Stelle werden die verfügbaren Kanäle zur entgültigen Bereitstellung gemappt. Anschließend Create auswählen.

tvheadend_16_Add_Network_Settings_dvbs01

Wichtig ist jetzt, da wir die korrekte Zeitzone auf unserem Server aktiviert haben, dass EIT Local Time bei allen Netzwerken NICHT aktiv ist.

Hinweis: EIT Local Time darf nur aktiv sein, wenn am Server als Zeit UTC aktiviert wurde und die Serverzeit der aktuellen Uhrzeit entspricht.

troubleshooting_tvheadend_kodi_epg_01

 

In meinem Fall habe ich für viere Eingänge ein jeweils eigenes Netzwerk erstellt:

tvheadend_17_Add_Network_dvb-s01-04

Wir wechseln erneut in den Aktenreiter Configuration, dann DVB Inputs und anschließend zu TV adapters. Hier wählen wir jeweils die Karte links aus und ordnen auf der rechten Seite der Reihe nach jeweils ein Netzwerk zu.

tvheadend_17b_Set_Network.jpg

Anschließend wechseln wir in den Aktenreiter Configuration, dann DVB Inputs und anschließend zu Muxes. Hier öffnen wir über Add den Dialog zur Hinterlegung der gewünschten Frequenzen. Zunächst wählen wir ein Netzwerk aus.

tvheadend_18_Add_Muxes_dvbs01

Dann hinterlegen wir für eine Sendergruppe die Frequenz und weitere Parameter. In meinem Fall waren dies:

  • 10744 MHz – Arte, Eins Plus, … (SR 22000, Polarisation: H, FEC 5/6)

die ich aus der Astra-Senderliste für SD-Standard übernommen habe. Für alle mit großen Endgeräten empfiehlt sich jedoch hier HD.

tvheadend_19_Add_Muxes_Arte

Im Ergebnis für die erste Frequenz:

tvheadend_20_Result_Add_Muxes_Arte

Anschließend erfolgt ein automatioscher Scan durch das System, ob zu den hinterlegten Informationen entsprechende Sender vorliegen. Wenn alles in Ordnung ist, werden die Sender unterm den Aktenreiter Configuration, dann DVB Inputs und anschließend Services aufgeführt. Werden keine Sender gefunden, dann zunächst prüfen, ob Eingaben fehlerhaft waren. Zusätzlich sollte bei Korrektur der Scan-Status auf Active gesetzt werden, da sonst ggf. kein erneuter Scan erfolgt.

 

tvheadend_21_Result_Services

Folgende weitere Frequenzen habe ich hinterlegt:

  • 11836 MHz – Das Erste, HR, WDR, … (SR 27500, Polarisation: H, FEC 3/4)
  • 11954 – ZDF, Kika, … (SR 27500, Polarisation: H, FEC 3/4)
  • 12110 – MDR, NDR, RBB, … (SR 27500, Polarisation: H, FEC 3/4)

tvheadend_22_Result_Muxes

Wodurch ich folgende Senderliste erhalten habe, bei der ich nicht gewünschte abwählte und anschließend über Save speicherte:

tvheadend_23_Result_Services.jpg

Anschließend müssen wir die verfügbaren mappen, damit diese später uns auf den Clients zur Verfügung stehen können. Dies machen wir über Map All …

tvheadend_24_Services_Map_All.jpg

… und Map.

tvheadend_25_Services_Map_All_Menu

Das Ergebnis sehen wir anschließend unterm Aktenreiter Configuration, anschließend Channel / EPG und dann Channels:

tvheadend_26_Channel

Damit anschließend die Programme über Clients genutzt werden können, muss ein entsprechender Benutzer mit entsprechenden Rechten hinterlegt werden. Hierzu wechseln in den Aktenreiter Configuration und anschließend Access Entries. Über Add öffnen wir den entsprechenden Dialog und hinterlegen Username, Password und aktivieren Streaming, Advanced Streaming und HTSP Streaming. Für die Nutzung in Kodi über das TVHeadend Addon muss HTSP Streaming aktiviert sein!

tvheadend_27_Add_User_Kodi

Im Ergbnis sieht es so aus.

tvheadend_28_Add_User_Kodi_Result.jpg

Tipps und Tricks:

  • Wenn nichts passiert, dann als erstes prüfen ob unter Configuration, DVB Inputs, TV Adapters diese wirklich aktiv sind. Dies war bisher immer mein Fehler, da die Option gut versteckt ist.
  • Bei Korrektur von Frequenzen immer Scan Status auf Active setzen:
    tvheadend_tipps_01_Scan_Status
  •  Aktualisierung über das Aktualisierungssymbol erzwingen:tvheadend_tipps_02_Refresh
  • Deaktivierung nicht benötigter Channel Tags, wie SDTV, im Aktenreiter Configuration, dann Channel / EPG und anschließend Channel Tags:tvheadend_tipps_03_ChannelTag_disable
    Dadurch wird später im Kodi verhindert, dass bei Wahl der Senderliste über links und rechts nicht zwischen den Gruppen gewechselt werden kann.
  • Bei Verwendung unterschiedlichster Übertragungswege und Clients kann es ggf. von Vorteil sein, bewusst Channel Tags zu hinterlegen. Zum Beispiel, in einem privaten Haushalt mit vier Eingängen am System und vier Clients bei gleichzeitiger Nutzung. Hier können alle Sender für HD und SD eingerichtet werden. Anschließend werden zwei Channel Tags definiert und ja nach Standard die Sender nur einer Gruppe zugeordnet. Zusätzlich deaktivieren wir den Standard-Channel Tag TV channels. Im Kodi kann dann über rechts und links zwischen den Sendergruppen, in der Senderliste, gewechselt werden. So kann zum Beipsiel im Garten, bei schlechter WLAN-Verbindung, trotzdem der Client genutzt werden.

Installation und Einrichtung von Kodi 16.1 (Stand 25.04.2016):

Zunächst laden wir die notwendigen Installationsdateien herunter oder führen ja nach System die Installation durch.

https://kodi.tv/download/

kodi_16_1_tvheadend01

Unter Windows wird der Installer heruntergeladen und anschließend gestartet. Nach dem ersten Next und I Agree wählen wir zunächst die PVR Add-ons ab und nur das gewünschte Tvheadend HTSP Client an. Wer zusätzlich wie ich mobil Kodi bei Freunden etc. nutzt kann zusätzlich den PVR IPTV Simple Client mitinstallieren. Durch die Abwahl der nicht gewünschten PVR Add-ons entfallen später automatische Aktualisierungen zum Start von Kodi.

kodi_16_1_tvheadend02

kodi_16_1_tvheadend03

Unter Linux müssen ggf. zu Kodi die PVR Add-ons zusätzlich installiert werden. Unter Android sind diese durch die Installation bereits verfügbar.

Nach dem ersten Start von Kodi wechseln wir zu System, dann Settings und anschließend zu Add-ons. Dann wechseln wir in das Verzeichnis My add-ons und anschließend zu PVR Clients.

Jetzt wählen wir Tvheadend HTSP Client mittels ENTER-Taste …

kodi_16_1_tvheadend04

dann Configure

kodi_16_1_tvheadend05

und tragen Namen oder IP-Adresse, sowie Benutzername und Passwort in den Dialog ein und schließen das Fenster über OK (Hinweis: Zur Sicherheit die Eingaben anschließend prüfen. Hier hatte ich 1x das Problem, dass meine Eingaben nicht übernommen wurden).

kodi_16_1_tvheadend06

Jetzt wählen wir in der Add-on Information Enable aus …

kodi_16_1_tvheadend07

und schließen die Ansicht 1x mit ESC-Taste. Jetzt empfiehlt es sich erneut mit ENTER in die Add-on Information zu wechseln, da ggf. Enable noch nicht aktiv ist (Bug über mehrere Kodi-Versionen). Sollte dies so sein, dann bitte erneut Enable auswählen. Anschließend mit 2x ESC-Taste wechseln wir wieder in das Settings Menü und wählen dann TV aus. Hier wählen wir auch Enabled aus …

kodi_16_1_tvheadend08

unmittelbar danach werden die Daten von TVHeadend importiert (siehe rechts oben).

kodi_16_1_tvheadend09

Bei Problemen wird in der Statusleiste eine entsprechende Information ausgegeben. Wenn dies entsprechend vorliegt, sollten zunächst Benutzername, Passwort, IP / Servername im Add-on geprüft werden. Zusätzlich prüfen, ob beim Add-on und TV beides auf enabled gesetzt sind. Im Log vom TVHeadend sind entsprechende Informationen zu sehen (sollte vorab im Webbrowser geöffnet sein).

tvheadend_29_kodi_connected

oder in einer Shell auf dem Server:

tail -f /var/log/syslog | grep 'tvheadend'

tvheadend_30_kodi_connected

Weitere Möglichkeit bei Problemen: Dem Benutzer im TVHeadend wurde nicht das Recht für HTSP Streaming zugeteilt.

Wenn alles in Ordnung ist, sehen wir spätestens jetzt (nicht bei allen Skins von Kodi verfügbar) im Hauptmenü TV und Radio.

kodi_16_1_tvheadend10

Bei Auswahl von TV sehen wir zum Beispiel:

kodi_16_1_tvheadend11

Mit der Taste e können wir auch in die EPG-Ansicht mit einer Tastatur wechseln. Es gibt jedoch weitere Möglichkeiten.

kodi_16_1_tvheadend12

Bei Auswahl eines Programms zum Beispiel im Vollbild:

kodi_16_1_tvheadend13

Mit der Taste c (im Vollbildmodus) wird die Kanalliste eingeblendet. Hier kann, wie bereits beschrieben durch rechts und links, die Ansicht durch die Channel Tags geändert werden (bitte im ersten Bild rechts oben All channels und im zweiten Bild TV channels beachten – in meinem Fall gibt es keine Abweichungen).

 

kodi_16_1_tvheadend14

kodi_16_1_tvheadend15

Wenn am Ende alles funktioniert, dann empfiehlt es sich das Debug-Logging in TVHeadend zu deaktivieren, unter Configuration und dann Debugging.

Troubleshooting – EPG, Serverzeit und Zeitzone:

Wer zur Installation ggf. eine falsche Zeitzone hinterlegt hat, hat anschließend das Problem, dass die Zeiten im EPG vom Kodi verschoben sind.

Wir prüfen hierbei zunächst ob die Zeiten und die Zeitzone am Server korrekt sind:

cat /etc/timezone
date
hwclock --show

Wenn nicht, dann bitte erneut im oberen Teil Behebung Zeitprobleme für EPG beachten.

Zusätzlich überprüfen wir am jeweiligen Client ob die Zeit und die Zeitzone korrekt ist.

Dann prüfen wir die Einstellung EIT Local Time für jedes Netzwerk im TVHeadend, dass diese Option nicht aktiv ist:

troubleshooting_tvheadend_kodi_epg_01

Zusätzlich empfiehlt es sich auf dem Server die EPG-Datenbank zu löschen. Dies erfolgt über:

cd /home/hts/.hts/tvheadend
service tvheadend stop
rm epgdb.v2
service tvheadend start

troubleshooting_tvheadend_kodi_epg_02

Nach einigen Sekunden wird eine neue epgdb.v2 erstellt.

Jetzt löschen wir zusätzlich im Kodi-Client die Datenbank für den PVR-Dienst über Einstellungen -> PCR-Dienst -> Allgemein -> Daten löschen.

troubleshooting_tvheadend_kodi_epg_03

 

Epilog:

Zusammenfassend empfinde ich persönlich die Installation und Einrichtung der TVTuner-Karten unter Debian 8.4 mittlerweile als recht einfach. Ebenso auch die Installation von TVHeadend. Vor ein paar Jahren war dies noch anders und recht kompliziert. Durch die Verwendung von Kodi auf diversen Clients ist es recht einfach auf sehr vielen Endgeräten Radio und TV zu empfangen

Für Radio direkt gibt es jedoch auch auch innerhalb Kodi ein sehr gutes Add-on.

Wer zum Beispiel in seinem Gartenhaus via Satellit oder DVB-T lediglich für ein Endgerät eine Möglichkeit benötigt, der kann auch einen Raspberry Pi mit geeignetem USB-Stick als Streaming-Server verwenden. Hier muss jedoch beachtet werden, dass nur wenige Sticks funktionieren. Ich kann derzeit auch keine entsprechende Variante empfehlen, da ich über keinen geeigneten USB-Stick verfüge.

Quellen und weitere Links:

 

Proxy unter Linux

Anbei eine kleine Zusammenfassung von notwendigen Anpassungen für die Hinterlegung eines Proxy-Servers unter Linux (getestet unter Debian und Ubuntu). Teilweise werden über entsprechende Skripte zur Installation diverser Programme unterschiedliche Varianten benötigt.

 

Variante für Paketinstallation via apt-get …

nano /etc/apt/apt.conf

Acquire::http::Proxy "http://username:password@servername:port";

 

Variante für git:

nano /etc/gitconfig

[http]
proxy = http://username:password@servername:port

 

Variante für hg clone …

nano /etc/mercurial/hgrc

[http_proxy]
host=servername:port
passwd=password
user=username

debian_proxy_hgrc

 

Variante für perl:

perl -MCPAN -e shell
o conf init /proxy/

debia_proxy_perl

o conf commit
exit

 

Variante für wget …

nano /etc/wgetrc

https_proxy = http://servername:port/
http_proxy = http://servername:port/
ftp_proxy = http://servername:port/
use_proxy = on
proxy_user=username
proxy_password=password

debian_proxy_wgetrc

 

Variante fürs System (direkt in der Console), zum Beispiel für apt-key adv … :

export http_proxy=http://<username>:<password>@<proxy>:<port>
export https_proxy=http://<username>:<password>@<proxy>:<port>

 

Bloggen auf WordPress.com.

Nach oben ↑