SR-InfoSys
Bitte lesen Sie die im Anschluß folgende Dokumentation durch, wenn Sie an SR-InfoSys interessiert sind.
In der Dokumentation sollte man alles wissenswerte über das Programm erfahren.
Referenzen:
Ich verwende SR-InfoSys Serverseitig auf einem SuSE Linux 9.3 Server mit einer BIND9 Version und dem
vsftp Server. Clientseitig sind es momentan 17 SuSE Linux 10.0 und 10.2 Server im einsatz als Internet
Router/Proxy/Firewall. Zusätzlich ist noch eine Web Filter Software
Time-For-Kids auf den Routern installiert,
die speziell für den Einsatz in Schulen gedacht ist. Es werden aber insgesammt 18 SR-InfoSys Clients werden.
Der SR-InfoSys Server ist selber auch ein Router/Firewall/Nameserver für ein kleines DSL Netzwerk. Zwar
ist der Einsatz von SR-InfoSys für Schulen bzw. für die Betreuer von Schulnetzwerken gedacht, natürlich
läßt sich die Software auch in jedem belibigen anderen Bereich einsetzen. Die einzige Voraussätzung ist,
das der Router, der die Einwahl in das Internet tätigt, ein Linux Server ist.
Getestet habe ich SR-InfoSys auf SuSE Linux ab der Version 9.2 und neuer, sowie auf Debian 3.0, 3.1 und 4.0.
Auch sollte Ubuntu und Kbuntu kein problem darstellen, das diese auch Debian Systeme sind.
Tests auf anderen System habe ich noch nicht durchgeführt. Es sollte aber ein i386 oder ein x86-64 System
sein. Denkbar ist aber auch ein Einsatz auf allen anderen Platformen die von Linux unterstützt werden.
Downloads:
- RPM Installationspaket für SuSE Linux
- SR-InfoSys.0.3-11.rpm
- SRPM Source Installationspaket für SuSE Linux
- SR-InfoSys.0.3-11.srpm
- DEB Installationspaket für Debian Linux
- sr-infosys.0.3-11.deb
- GZip Tar Source Archiv für Linux
- SR-InfoSys.0.3-11.tar.gz
SR-InfoSys
0.4
( SchulRouter - Information System )
Router Information und Erreichbarkeit
DOKUMENTATION
AUTOR
Idee, Programmierung und Umsetzung von „van GoDD“ 2005 – 2007 <van.godd@web.de>, mit einer Inspiration von „www.linuxfibel.de“ für die Umsetzung des kleines 'C' Programms „mycrypt“.
NAME
SR-InfoSys (SchulRouter - Information System)
BESCHREIBUNG

SR-InfoSys ist wie ein dynamisches DNS Client/Server Prinzip. Gedacht ist es in erster Linie, Router aus Schulen immer erreichbar zu halten um diese aus der Ferner administrieren zu können. SR-InfoSys überträgt nach einer eingestellten Zeit die aktuelle IP Adresse des Internet Gerätes und auch die des lokalen Netzwerkes an einen FTP oder SFTP Server, der wiederum entweder mit einer festen IP Adresse erreichbar ist, oder über einen dynamischen DNS Namen, wie z.B. über von der Firma dynDNS oder DynAccess.
Verwendet man SR-InfoSys, dann braucht man nur eine einzige dynamischen DNS Namen für den FTP/SFTP Server und kann quasi beliebig viele Router aus seinem Netzwerk erreichbar halten.
Die Router sind dann allerdings nur aus diesem eigenen Netzwerk erreichbar nicht jedoch aus dem Internet.
INSTALLATION
Die Installation von SR-InfoSys ist ganz einfach. Nach dem man sich die RPM Datei herunter geladen hat, kann man es mit dem Befehl:
~>rpm -ihv SR-InfoSys-{Version}-{Release}
Wenn schon eine Version von SR-InfoSys auf dem Rechner installiert ist, kann man das Programm ganz einfach mit dem Folgendem Befehl auf den neusten Stand bringen:
->rpm -Uhv SR-InfoSys-{Version}-{Release}
Wenn der Benutzer „wartung“ in System schon existiert, dann wird dieser nicht neu angelegt und das Konto wird so gelassen. Existiert dieser Benutzer noch nicht im System, dann wird dieser neu angelegt, mit einem leeren Homeverzeichnis. Der Benutzer ist erforderlich, da SR-InfoSys mit der Berechtigung dieses Benutzer läuft, wenn das Programm über das Startscript gestartet wird.
Standardmäßig wird SR-InfoSys in das Verzeichnis /opt/SR-InfoSys installiert. Die Konfigurationen findet man unter /etc/SR-InfoSys.conf und die Logs landen in der Datei /var/log/SR-InfoSys.log. Das Start- und Stoppscript ist unter /etc/init.d/SR-InfoSys zu finden.
Starten sollte man SR-InfoSys, ob den Client oder den Server immer über das init.d Script. Möchte man aus Testzwecken SR-InfoSys manuell starten, dann sollte man diese nach Möglichkeit nur als Benutzer „wartung“ tun, da es sonst zu ein paar üblen Datei Berechtigungsproblemen kommen kann.
SYNTAX
SR-InfoSys [Option]
OPTIONEN
-n, --nodaemon
Startet nicht als ein Daemon Programm
-d, --daemon
Startet als ein Daemon Programm im Hintergrund Startet als ein Daemon Programm im im Hintergrund. Das Programm kann dann nur ber den kill Befehl beendet werden, oder ober den Aufruf des Programmes mit der Option --stop dieses Programmes.
-s, --single
Startet das Programm, erstellt die Informationsdatei nur einmal und überträgt diese auch nur einmal
--stop
Beendet alle laufenden Prozesse des Programmes wenn dieses als ein Daemon Programm gestartet wurde
-v, --version
Ausgabe der Version diese Programmes
-h, --help
Der Hilfe Text
CLIENT BETRIEB
Der Client Betrieb ist für die Router in den Schulen oder Außenstellen gedacht. Der Router meldet sich dann in vorher bestimmten Zeit Rhythmen bei den Server, der auch über eine Feste IP Adresse oder einen Namen erreichbar sein muss.
Im Client Betrieb wird die IP-Adresse des Internet Gerätes ausgelesen und es wird eine Protokolldatei erstellt, welche dann auf den Server mittels FTP oder SFTP übertragen wird. In der /etc/SR-InfoSys.conf Datei kann man auch angeben, welche Informationen in der Protokolldatei stehen sollen und welchen Dateinamen diese Datei haben soll. Der Dateiname muss auch eindeutig sein und darf sich auch nicht mit den anderen SR-InfoSys Clients übereinstimmen. Auch darf es im Dateiname für die Protokolldatei keine Übereinstimmung mit dem Trimmer FL_TRIM der Datei geben, da es sonst zu Fehler kommt, wenn diese Datei weiter verarbeitet wird. Der Trimmer muss auch unbedingt bei allen Clients in den Schulen oder Außenstellen identisch sein, da das Einlesen sonst nur mit den Dateien funktionieren wird, wo der Trimmer Identisch mit dem Trimmer auf dem SR-InfoSys Server ist. Genau wie Sonder- und Leerzeichen haben in den Dateiname nichts verloren, dieses kann bei der späteren Verarbeitung zu großen Problemen führen. Wichtig für den Client Betrieb ist auch der Benutzername RH_USER, Passwort RH_PASS, der FTP/SFTP Server Name RH_NAME und auch das Verzeichnis in dem es abgelegt werden soll RH_ADIR.
Grundvoraussetzung für den Client Betrieb ist die Variable SRInfoSys_SRV die auf jedem Fall den Wert "nein" haben muss. Bevor man den SR-InfoSys Client in Betrieb nimmt, sollte man zuvor die Funktion und die Erreichbarkeit des FTP Servers überprüfen. Das mach man am besten auf der Konsole mit dem Befehl:
~>ftp ftp-benutzer@ftp-server
ftp-passwort
>ls
>pwd
>bye
Die Angaben sollten identisch sein wie in der Konfigurationsdatei, falls man einen anderen Benutzer mit einem anderen Passwort benutzen möchte, als bei der Installation von SR-InfoSys vorgegeben. Auch sollte man noch mal einen Blick auf das Ablageverzeichnis auf dem FTP Server RH_ADIR werfen, ob das Verzeichnis richtig angegeben ist oder überhaupt existiert.
Möchte man lieber aus Sicherheitsgründen über SSH die Protokolldatei übertragen, dann kann man den Klienten das mit RH_SERV mitteilen. Der Wert „SFTP“ teilt SR-InfoSys beim nächsten Start mit, das es anstatt des FTP Übertragungsprotokolls lieber das SFTP nehmen soll. SFTP ist kein Eigenes Übertragungsprotokoll, sondern eine SSH Verbindung, die aber FTP ähnliche Befehlssätze kennt. Aus diesem Grunde kann man sich nicht einfach automatisch über ein mitgegebenes Passwort einloggen, sondern es muß sich auf dem SFTP Server ein „Public Key“ von diesem Klienten befinden, ein quasi öffentlicher Fingerabdruck. Denn nur so kann man sich ohne Passwort auf einem bekannten SSH/SFTP Server einloggen. Wie man dieses realisieren kann, kann man aus dem Internet oder aus den Manpages zu SSH erfahren.
So kompliziert das mit den „Public Key“ auch sein mag, das testen der SSH/SFTP Verbindung ist um so einfacher. Das mach man am besten auf der Konsole mit dem Befehl:
~> sftp benutzer@sftp-server
Connecting to sftp-server...
sftp> dir
sftp> pwd
Remote working directory: /home/benutzer
sftp> bye
Auch hier sollten die Angaben identisch sein wie in der Konfigurationsdatei. Als Ablageverzeichnis RH_ADIR sollte man den vollen Pfad angeben, wie z.B. „/home/wartung“.
Zum testen startet man SR-InfoSys am besten direkt von der Konsole aus als Benutzer unter dem SR-InfoSys auch betrieben werden soll. Als Vorgabe bei der Installation wurde dafür der Benutzer „wartung“ angelegt.
~>su wartung
~>/opt/SR-InfoSys/SR-InfoSys
Beenden kann man das Programm wieder mit der Tastenkombination „STRG+C“. Die Logdatei /var/log/SR-InfoSys.log verrät vieles über den Ablauf des Programms. Dort kann man auch sehen, ob der FTP Upload der Protokolldateien auch erfolgt war. Zusätzlich sollte man die Existenz der Protokolldatei auf dem FTP/SFTP Server kontrollieren.
SERVER BETRIEB
Der Server Betrieb ist für die Hauptstelle gedacht, um die Router in den Schulen oder Außenstellen zu administrieren und zu überwachen. Der Server Betrieb wird wie der Client Betrieb über die Variable SRInfoSys_SRV gesteuert. Die Variable muss auf jedem Fall den Wert "ja" haben. Wenn SR-InfoSys dann gestartet wird, startet das Programm automatisch in dem Server Betrieb. Im Server Betrieb wird keine Protokolldatei erstellt und es wird auch nichts an einen FTP/SFTP Server übertragen. Der Server Betrieb arbeitet mit den schon übertragenen Protokolldateien, diese sollten sich dann auch alle in ein und den selben Verzeichnis befinden. Am einfachsten ist es, wenn der SR-InfoSys Server auf dem gleichen Rechner läuft wie der FTP/SFTP Server auch. SR-InfoSys finden seine Protokolldateien in dem Verzeichnis auf dem Rechner, welche in der Variable DNS_INFO_DIR angegeben wird. Es spielt dabei auch keine Rolle, ob das Verzeichnis mittels NFS gemountet ist oder lokal auf dem Dateisystem liegt. Der FTP/SFTP Server muss also nicht zwangsläufig der Selbe Rechner sein.
Weiterhin sollte es einen funktionsfähigen DNS Server in diesem Netzwerk geben, der für die lokale Domäne zuständig ist. Die IP Adresse muss als Wert in die DNS_SRV_ADRS Variable eingetragen werden. Sollte der DNS Server auch auf dem selben Rechner laufen wie SR-InfoSys, so muss man auch die Eigene IP-Adresse eintragen. Das ist wichtig, da man den DNS Server erlauben muss, einen definierten Rechner mit der IP-Adresse auf dem SR-InfoSys läuft, eine DNS Zone dynamisch aktualisiert zu können. Welchen Namen die DNS Zone für die Router bekommt, das bleibt Ihnen ganz alleine überlassen, nur sollte man die Domäne unbedingt auch in der Variable DNS_DOMAIN_S bekannt machen, z.B. DNS_DOMAIN_S="schule.lan". Zur Einrichtung der DNS Zone für die Router, sollte Sie lieber Ihren DNS Administrator zur Hilfe bemühen. Wenn Sie keine DNS Administrator haben, sollte man zu mindestens wissen, wie man einen funktionsfähige DNS Zone anlegt.
Der Server Betrieb arbeitet also wie folgt:
Nach einem Vordefinierten Zeit Rhythmus in der Variable DNS_UPD_ZEIT liest SR-InfoSys alle Protokolldateien ein, die im Verzeichnis stehen, welches in DNS_INFO_DIR eingetragen ist. Hat SR-InfoSys die Protokolldateien eingelesen und verarbeitet, führt SR-InfoSys ein dynamisches DNS Update auf die Zone, die unter DNS_DOMAIN_S eingetragen wurde, durch. Wenn der DNS Server nicht auf dem selben Rechner läuft wie SR-InfoSys, muss man darauf achten, das die Erlaubnis zum Update der DNS Zone auch die IP-Adresse des SR-InfoSys Rechners eingetragen wurde. Andernfalls, kann SR-InfoSys nicht die DNS Zone Updaten. Auch kann man die Ereignisse von SR-InfoSys in der Logdatei /var/log/SR-InfoSys.log verfolgen. Es wird ein Protokoll über das Update auf den DNS Server erstellt.
KONFIGURATIONSDATEI
Die Konfigurationsdatei findet man unter /etc/SR-InfoSys.conf, welche für jedes System angepasst werden muß. Die Sektionen 01 bis 15 sind für den Client Betrieb vorgesehen und die Sektionen 16 bis 21 für den Server Betrieb. Die Beschreibung der ein zu stellenden Variablen ist in der Konfigurationsdatei gut beschrieben und kann auch von dort entnommen werden.
WEITERE INFORMATIONEN
In den weiteren Information werde ich nicht in Detail darauf eingehen, wie man einen FTP Server installiert und konfiguriert, ich werde aber Tipps geben, worauf man bei der Konfiguration vom Server als auch SR-Infosys achte sollte. Das selbe geht natürlich für den DNS- und SFTP Server. Viele Information diesbezüglich bekommt man natürlich auch im WWW. Bitte lesen Sie die „Weiteren Information“ gut durch, so manche Fragen für den Betrieb von SR-InfoSys könne sich leicht von selber beantworten.
FTP-SERVER KONFIGURATION
Was Sie für einen FTP Server verwenden, das bleibt Ihnen ganz alleine überlassen. Ich habe das System mit einem „vsftp“ Server am laufen, der auch standardmäßig bei fast jeder Linux Distribution vorhanden sein sollte. Es ist aber eigentlich egal, welchen FTP Server Sie Einsätzen. Bei der Konfiguration des FTP Servers sollte man nur beachten, das der Benutzer den man für SR-InfoSys verwendet um die Protokolldateien zu übertragen, sich in einer Change Root Umgebung befindet. Mit anderen Worten, wenn sich dieser Benutzer über FTP anmeldet, dann ist sein Homeverzeichnis gleichzeitig sein Root Verzeichnis „/“. Möchte man die Protokolldateien weiterhin in einem Unterverzeichnis ablegen lassen oder man verwendet auch aus welchen Gründen auch immer keine Change Root Umgebung, so muß man auf den Clients in der Konfigurationsdatei die Variable RH_ADIR dementsprechend anpassen.
Läuft der FTP Server nicht auf dem selben Rechner wie der SR-InfoSys Server, dann muß man dem Rechner auf dem der SR-InfoSys Server läuft auch in irgendeiner einer Form die übertragenen Protokolldatei zur Verfügung stellen. Am besten mittels „ntp“.
SFTP-SERVER KONFIGURATION
Den SFTP Server selber kann man nicht viel konfigurieren. Ein laufender „SSH Daemon“ sollte hier völlig ausreichend sein. In der /etc/ssh/sshd_config Konfigurationsdatei sollte sich ein so ähnlicher Eintrag befinden:
---------------------------------------------------
# override default of no subsystems
Subsystem sftp /usr/lib64/ssh/sftp-server
---------------------------------------------------
(Das kann vom verwendeten System abeichen)
Dann sollte es auch mit „sftp“ gehen. Mehr braucht man nicht. Allerdings wird für SR-InfoSys vom Klienten ein „Punlic Key“ auf dem SFTP Server benötigt. Dieser wird mit dem Befehl „ssh-keygen -t dsa“ generiert. Welcher dann auf dem SFTP Server übertragen werden muß. Dieses zu beschreiben würde aber diesen Rahmen um einiges sprengen. Ich habe schon einmal einen Artikel „SSH Verbindung ohne eine Passwortabfrage und X11“ verfasst, in dem der ganze Weg wie er auch für SR-InfoSys benötigt wird beschrieben ist. Diesen kann ich jedem ans Herz legen, der SR-InfoSys gerne mit SFTP betreiben möchte, dieses aber noch nie gemacht hat und auch von der ganzen Materie keine Ahnung hat. Vielleicht kann man auch einen seiner Linux Administratoren zu Rate bemühen und diesen die Situation genau schildern, welcher Rechner mit wem kommunizieren muß usw.
Wenn man SR-InfoSys mit SFTP betreibt, kann man sich die Variable RH_PASS eigentlich ganz schenken. Am besten man löscht das dort stehende Passwort ganz heraus, so das nur noch RH_PASS=““ in der Konfigurationsdatei steht. Um so wichtiger ist bei SFTP aber die Variable RH_ADIR, vor allem dann, wenn man von FTP auf SFTP umgestellt hat. Man trägt dort gen genauen Pfad wie dieser auf dem SFTP Server zu finden ist ein. Ein „~“ für das Homeverzeichnis bewirkt nichts. Also sollte dort so etwas wie „/home/wartung“ oder ähnliches stehen, zumal es in SFTP nicht die Möglichkeit einer Change Root Umgebung gibt.
DNS-SERVER KONFIGURATION
Was für den FTP Server gilt, das gilt auch für den DNS Server. Welchen Sie verwenden oder vielleicht verwenden möchten, auch das bleibt Ihnen ganz allein überlassen. Getestet habe ich das nur mit einem BIND Server unter Linux. Ob es auch mit einem Microsoft Windows DNS Server funktioniert, das weiß ich auch nicht.
Als erstes sollte man auch eine Zonen Datei für die ganzen Schul-Router anlegen. Ich habe in meiner Konfiguration das Verzeichnis /var/lib/named/dyn/ gewählt und habe doch eine Zonendatei mit dem Namen schule.lan.zone angelegt. Es wird auch nur eine „Forward“ (Name zu Adresse) DNS Zone benötigt. Die Datei könnte wie folgt gestaltet sein:
$ORIGIN .
$TTL 38400 ; 10 hours 40 minutes
schule.lan IN SOA main.stadt.dsl. vangodd.stadt.dsl. (
2006012307 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
38400 ; minimum (10 hours 40 minutes)
)
NS dns.stadt.dsl.
$ORIGIN schule.lan.
In der Datei /etc/named.conf trägt man mit einem Editor ganz oben in der ersten Zeile folgendes ein:
acl SR {
192.168.1.1;
};
Anstelle der IP Adresse 192.168.1.1 trägt man die eigene Adresse des Rechners/DNS Server ein, auf dem der SR-InfoSys Server auch läuft. Ist der DNS Server auch der SR-InfoSys Server, so muss man trotzdem die IP Adresse des Rechners eingeben. Ist der SR-InfoSys ein anderer Rechner als der DNS Server, so muss man logischer weise die IP Adresse des Rechners nehmen, auf dem SR-InfoSys im Server Betrieb läuft.
Eines müssen wir aber noch machen, wir müssen die neue Zonendatei dem DNS Server auch bekannt machen. Das machen wir, indem wir auch in der /etc/named.conf unten bei den anderen Zonen unsere neue Zone bekannt machen. Das können wir am besten wie folgt erledigen:
zone "schule.lan" {
type master;
file "/var/lib/named/dyn/schule.lan.zone";
notify no;
check-names ignore;
allow-update {
sr;
};
};
Jetzt sollte man am besten gleich den DNS Server einmal neu starten:
~>/etc/init.d/named restart
Wenn der DNS Server jetzt sauber startet, dann haben wir es geschafft. Startet er nicht sauber, hat man bestimmt an irgendeiner Stelle einen Tippfehler eingebaut. Die Zonendatei /var/lib/named/dyn/schule.lan.zone sollte man aber auch nicht mehr bearbeiten, nicht mit dem Editor und auch nicht mit einem anderen Frontend Programm wie „yast“ oder „webmin“, da es sonst zu Inkonsequenzen kommen kann. Wenn SR-InfoSys einen Update macht, so geschieht das dynamisch. Die dynamischen Änderungen werden in der Binären Datei /var/lib/named/dyn/schule.lan.zone.jnl gespeichert. Beim beenden oder neu starten des DNS Server gleicht dieser die *.jnl Datei mit der Zonendatei ab. Tätigt man in der Zwischenzeit einen Änderung in der Zonendatei, dann wird diese beim nächsten Start des DNS Server nicht mehr geladen, mit der Folge, das weder die Schul-Router erreichbar sind, noch SR-InfoSys weiterhin die neuen IP Adresse eintragen kann. Ist so etwas schon passiert, braucht man nur den DNS Server einmal zu stoppen und die schule.lan.zone.jnl Datei löschen.
Ich werde hier nicht im einzelnen auf eine Konfiguration eines BIND DNS Servers eingehen, dieser ist schon eine Voraussetzung, ich werde lediglich eine Beispiel Konfiguration für die Integration von SR-InfoSys im Server Betrieb zeigen.
WWW BERICHT FUNKTION
Zusätzlich zum normalen Server Betrieb, kann man auch ein Web Protokoll aus seinen übertragenen Protrkolldateien erstellen lassen. Gesteuert wird der Web Bericht durch die Variable WWW_BERICHT. Steht in dieser der Wert „ja“, so wird nach jedem aktualisiert des DNS Servers ein Web basiertes (HTML) Protokoll erstellt. Es werden die gleichen Protokolldateien benutzt, die auch für das DNS Update verwendet werden, angegeben in der Variable DNS_INFO_DIR.
Grundvoraussetzung für den betrieb der WWW Bericht Funktion ist ein laufender Apache Server (oder andere http Server) mit einem im DocRoot eigens für SR-InfoSys angelegtes Verzeichnis, in dem der Benutzer unter dem SR-InfoSys betrieben wird (in unserem Fall standardmäßig Benutzer „wartung“) volle Schreib-Rechte besitzt. Den Pfad zum Ablageverzeichnis für den WWW Bericht muß man in WWW_ABLAGE eintragen. Ein Beispiel für den WWW Ablage Pfad könnte so aussehen „/srv/www/htdocs/SR-InfoSys“ aussehen. Nicht zu vergessen, das der Benutzer unter dem SR-InfoSys betrieben wird auch volle Schreib-Rechte haben muß.
Das Layout des WWW Berichtes kann man auch nach seinen eigenen Bedürfnissen anpassen. Zu diesem Zweck befinden sich im Programmverzeichnis von SR-InfoSys ein weiteres Verzeichnis Namens www, im dem sich zwei Vorlagendateien /opt/SR-InfoSys/www/index.html und /opt/SR-InfoSys/www/bericht.html befinden sowie drei CSS Dateien /opt/SR-InfoSys/www/styles.css, /opt/SR-InfoSys/www/styles_ie6.css und /opt/SR-InfoSys/www/print.css. Im Verzeichnis /opt/SR-InfoSys/www/images befinden sich vier kleine Grafiken (sr-server.png, sr-server_age.png, sr-server_agr.png und sr-server_aro.png), die auch für die Ampelfunktion benötigt werden, wobei man auch diese Grafiken ersetzen kann. In der index.html werden alle Server aufgelistet und mit dem Berichtdateien verknüpft, die für SR-InfoSys Server zur Verfügung stehen. In der bericht.html wird dann logischer weise der Bericht für den einzelnen entfernten Schul-Router aufgebaut. Die bericht.html wird nach dem generieren von SR-InfoSys im Ablageverzeichnis umbenannt und zwar nach folgendem Konventionen <client server name>.html. Alle anderen Dateien werden Namentlich so belassen wie sie lauten. In dem beiden HTML Dateien gibt es folgende Platzhalter für SR-InfoSys, die man verwenden darf:
Für die index.html
Dieser Platzhalter steht für die Liste der Verfügbaren Schul-Router. Die Liste wird mit Hilfe von Tabellen Tags (<tr> und <td>) aufgebaut, so sollte dieser Platzhalter für die Server Liste zwischen den beiden „<table>“ und „</table>“ Tags stehen. Was auch sehr wichtig ist, das dieser Platzhalten unbedingt in einer Zeile alleine steht, da alles was vor und hinter diesem Platzhalten steht, beim erstellen der Server Liste verloren geht.
<!-- SR-SERVER-AMPELAUFRUF -->
Dieser Platzhalten steht für das JavaScript, welches die Ampelfunktion zum austauschen der Grafiken aufruft. Die eigentliche Berechnung der Ampelfunktion wird von SR-InfoSys übernommen, dem JavaScript wird lediglich mitgeteilt, welche Grafiken ersetzt werden müssen (rot,grün,gelb). Auch bei diesem Platzhalter ist darauf zu achten, das er in einer Zeile alleine steht.
Für die bericht.html
Dieser Platzhalten steht für die Beschreibung des Schul-Routers. Hier erscheint das gleiche, was bei dem Klienten in der Konfigurationsdatei in der Variable ID_NAME eingetragen ist.
Dieser Platzhalten steht für den gesamte Bericht/Protokolldatei. Der ganze Inhalt der Datei wird hier ausgegeben und ist nicht formatiert.
Dieser Platzhalten steht für die IP Adresse des Client Schul-Routers. Der große Vorteil der IP Adresse ist der, das der Server der sich hinter der IP Adresse verbirgt auch von der ganzen Welt erreichbar ist, wenn der Webserver auch aus dem Interne ansprechbar ist. Die Namen, die in den DNS Server eingetragen werden stehen auch nur in dem lokalen Netzwerk zur Verfügung.
Dieser Platzhalten steht für den FullQualifidName des Client Servers, wie der auch im DNS Server eingetragen wurde.
Die beiden Variablen WWW_AMPEL_GELB und WWW_AMPEL_ROT bestimmt in SR-InfoSys die Zeitspanne, wann SR-InfoSys einen Client Server auf „gelb“ und wann auf „rot“ schaltet. Die Zeitangabe ist Grundsätzlich immer in Sekunden zu tätigen und zwar als reiner Zahlenwert, ohne „s“ oder „sec“ am ende, das SR-InfoSys andernfalls nicht mit den Werten rechnen kann und einen Fehler zurück gibt. Was hier nur zu beachten ist, das man den Wert für WWW_AMPEL_ROT größer setzt als den für WWW_AMPEL_GELB, da das System sonst nicht richtig funktionieren kann.
Kurz zum Verständnis:
Die Ampel zeigt GRÜN, wenn die Zeitspanne zwischen dem letztem ablegen der Protokolldatei des Client Server und dem Wert für die Gelbe Ampel liegt.
Die Ampel zeit GELB, wenn das ablegen der Protokolldatei des Client Server gleich oder größer ist wie für die Gelbe Ampel angegeben ist, aber auch noch kleiner ist, wie im Wert für die Rote Ampel. Mit anderen Worten kann man auch sagen, die Zeitspanne liegt zwischen dem Wert für die Gelbe und dem Wert für die Rote Ampel. Standardwert ist „3600“ (1 Stunde). Der maximal größter Wert der für die Gelbe Ampel gesetzt werden kann ist „9999“ (ca. 2,77 Stunden).
Die Ampel zeigt ROT, wenn die Zeitspanne des letzten ablegen der Protokolldatei des Client Server großer ist, wie im Wert für die Rote Ampel angeben ist. Weicht die Zeit aber generell ab, auch wenn die Zeit schon in der Zukunft liegt, zeigt die Ampel auch Rot. Standardwert ist „86400“ (24 Stunden). Der maximal größter Wert der für die Rote Ampel gesetzt werden kann ist „299999“ (ca. 3,5 Tage = ca. 83,33 Stunden).
Am allerbesten ist es, man spielt die ganzen Situationen einmal durch, so kann man sich visuell ein besseres Bild von der Ampel Funktion machen. Eine bessere Lösung ist mir hier nicht eingefallen, da ich die ganze Funktion so einfach wie möglich machen sollte, damit auch ein nicht technischer Mitarbeiter auf einem Blick sehen kann, das mit einem Server was nicht stimmt oder einer sich schon längere Zeit nicht gemeldet hat.
Written by van GoDD
Für weitere Tipps oder Verbesserungsvorschläge bin ich euch sehr dankbar. Ich halte meine Website aber nicht so super aktuell, bitte habt da etwas Nachsicht mit mir.