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

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.

 

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.

 

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:

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:

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:

 

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:

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:

 

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:

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.

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

Click here to enter OCS NG GUI

Als Ergebnis sehen wir:

 

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:

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:

 

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:

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)

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:

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

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

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

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

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:

 

ocsinventory:

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

Hier ändern wir PerlSetVar OCS_DB_PWD wie folgt:

 

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:

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.

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:

Anschließend sehen wir:

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:

 

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:

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

• SSLCerificateFile
• SSLCerificateKeyFile

an:

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):

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

-> Netzwerk-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

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):

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:

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.

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

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.

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

Speichern alles ins gleiche Verzeichnis:

Anschließend lassen wir die OcsPackage.exe generieren:

Als Ergebnis haben wir nun:

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:

Wählen die ocspackage.exe zum Upload aus:

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

Als Ergebnis bekommen wir:

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:

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.

Hinzufügen:

Ü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>

 

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>

 

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>

 

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:

• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:Newbie
• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:Administration
• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:Errors
• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:Ipdiscover
• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:Packager
• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:SNMP
• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:Teledeploy
• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:Teledeploy#Using_SSL_certificates_in_Package_deployment.
• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:UnixAgent
• http://wiki.ocsinventory-ng.org/index.php?title=Documentation:WindowsAgent
• https://github.com/OCSInventory-NG/OCSInventory-Server
• https://github.com/OCSInventory-NG/OCSInventory-ocsreports
• https://github.com/OCSInventory-NG/UnixAgent
• http://acacha.org/mediawiki/Ocs-inventory#.V-jLl_TileR
• http://acacha.org/mediawiki/Ocs-inventory#.V-kO4vTileR
• http://wiki.ocsinventory-ng.org/index.php?title=Howtos:Generate_SSL_cert_on_windows/fr
• https://www.sslshopper.com/article-most-common-openssl-commands.html