18
Server Dokumentation (Was sollte rein?)
Hallo,
nach dem ich im vergangenen Jahr zwei größere Ausfälle hatte, ist bei mir das Thema Dokumentation wieder weiter nach oben auf die ToDo gerückt.
Ich habe hier eine undokumentierte bestehende Infrastruktur übernommen. Beim aufarbeiten der Doku habe ich bisher erhoben:
Für die Dokumentation setze ich gegenwärtig auf i-Doit (Standort, Alter, Seriennummern, Rechnungen, ...) und Dokuwiki (oben genannte Punkte).
Als ich gerade (Software RAID auf größere Platten umziehen) Probleme mit einem RAID hatte, wurde auch noch mal auf das Thema Serverdokumentation hingewiesen.
Welche Bereiche landen bei euch in der Doku?
Ist es Sinnvoll jeden manuell installierten/konfigurierten Dienst aufzuführen und dessen Konfiguration zu dokumentieren?
Ich freue mich auf eure Rückmeldungen.
nach dem ich im vergangenen Jahr zwei größere Ausfälle hatte, ist bei mir das Thema Dokumentation wieder weiter nach oben auf die ToDo gerückt.
Ich habe hier eine undokumentierte bestehende Infrastruktur übernommen. Beim aufarbeiten der Doku habe ich bisher erhoben:
- Kurzbeschreibung des Servers
- DNS (hostname, cnames)
- Netzwerk (Interfacekonfiguration)
- Hardware (HW oder VM, Board, HBA, Platten mit SN, UUIDs bei RAID, …)
Für die Dokumentation setze ich gegenwärtig auf i-Doit (Standort, Alter, Seriennummern, Rechnungen, ...) und Dokuwiki (oben genannte Punkte).
Als ich gerade (Software RAID auf größere Platten umziehen) Probleme mit einem RAID hatte, wurde auch noch mal auf das Thema Serverdokumentation hingewiesen.
Welche Bereiche landen bei euch in der Doku?
Ist es Sinnvoll jeden manuell installierten/konfigurierten Dienst aufzuführen und dessen Konfiguration zu dokumentieren?
Ich freue mich auf eure Rückmeldungen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 348225
Url: https://administrator.de/contentid/348225
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
18 Kommentare
Neuester Kommentar
Hallo,
Ich habe bis dato noch nie Dienste konfigurieren müssen?!?
Grundsätzlich die beste Lösung ist meiner Meinung nach, vor der Inbetriebnahme die "Best practice" des Herstellers zu recherchieren und diese gnadenlos umzusetzen. In dem Fall ist die Dokumentation des Herstellers die Dokumentation des eigenen Systems
Gruß,
Jörg
Ist es Sinnvoll jeden manuell installierten/konfigurierten Dienst aufzuführen und dessen Konfiguration zu dokumentieren?
Ich habe bis dato noch nie Dienste konfigurieren müssen?!?
Grundsätzlich die beste Lösung ist meiner Meinung nach, vor der Inbetriebnahme die "Best practice" des Herstellers zu recherchieren und diese gnadenlos umzusetzen. In dem Fall ist die Dokumentation des Herstellers die Dokumentation des eigenen Systems
Gruß,
Jörg
Zitat von @117471:
Hallo,
HalloHallo,
Ist es Sinnvoll jeden manuell installierten/konfigurierten Dienst aufzuführen und dessen Konfiguration zu dokumentieren?
Ich habe bis dato noch nie Dienste konfigurieren müssen?!?
Kommt darauf an. bei manchen Diensten macht es Sinn, etwa wenn ein Dienst sofort wieder neu gestartet werden soll, wenn er abgestürzt ist.Grundsätzlich die beste Lösung ist meiner Meinung nach, vor der Inbetriebnahme die "Best practice" des Herstellers zu recherchieren und diese gnadenlos umzusetzen. In dem Fall ist die Dokumentation des Herstellers die Dokumentation des eigenen Systems
Gruß,
Jörg
Gruß,
Jörg
Eine pauschale Antwort kann man auf die Frage des Beitragserstellers nicht geben.
Was ich in der Systemdokumentation immer mit aufnehme, ist
- Releasestand Betriebssystem (Patchlevelstand)
- Releasestand installierter Software
- Konfiguration der Software
- Betriebssystemvariablen, welche zusätzlich zum Standard hinzugefügt wurden
Das ist die Systemdokumentation. Dann gibt es je nach Unternehmen noch die Anwendungsdokumentation, Betriebshandbuch, Standard Operating Procedure)
Gruss Penny
Hi,
die Antwort ist eigentlich ganz einfach:
In diese Doku muss alles rein, was Du selbst vorzufinden wünscht, wenn Du Dich über einen "fremden", "unbekannten" Server informieren willst. Alles, was Du für eine Übernahme (der Verantwortung) benötigt würdest. Alles, was Dir für eine Fehleranalyse hilfreich wäre. Alles, was Dir für eine Restauration nach Totalausfall (Brand, Diebstahl) hilfreich wäre.
E.
Edit:
Oder anders ausgedrückt:
Alles was in einer von einem Dritten erstellten Doku drin sein müsste, damit Du nicht von
die Antwort ist eigentlich ganz einfach:
In diese Doku muss alles rein, was Du selbst vorzufinden wünscht, wenn Du Dich über einen "fremden", "unbekannten" Server informieren willst. Alles, was Du für eine Übernahme (der Verantwortung) benötigt würdest. Alles, was Dir für eine Fehleranalyse hilfreich wäre. Alles, was Dir für eine Restauration nach Totalausfall (Brand, Diebstahl) hilfreich wäre.
E.
Edit:
Oder anders ausgedrückt:
Alles was in einer von einem Dritten erstellten Doku drin sein müsste, damit Du nicht von
eine undokumentierte bestehende Infrastruktur
sprechen würdest.
2
Hi
wir sind auch erst "einfach" angefangen, Name, technische Daten usw. zu dokumentieren. Mittlerweile haben wir alle Seriennummern der Festplatten erfasst, die gesamten Buchhaltungsdaten sind hinterlegt, alle Wartungs- und Serviceverträge, die technische Dokumentation, Standort im Rack, Verlinkung zum Monitoring, Ansprechpartner, Anschlusspunkte (Netz, SAS, FC, LAN ....). Das ist ein haufen Arbeit ja, aber wenn man "größere" Umgebungen hat macht das durchaus Sinn wenn man auch die Firmwarestände der einzelnen Komponenten dokumentiert ....
Automatisiert schön und gut, damit sind wir angefangen alles möglich über XML, CSV, SQL .... zu importieren, machen wir mittlerweile nicht mehr, da wir recht homogene Hardware haben konnten wir uns entsprechende Vorlagen erstellen und diese dann jeweils anpassen.
Wir setzen auch I-DOIT ein, fangen gerade an die Dienste zu implementieren um so eine Abhängigkeitsstruktur zu haben, daraus resultiert dann der "Wert" eines Ausfalls (praktisch für die Risikobewertung).
Bisher sind wie (sogar) ohne Anpassungen ausgekommen, dass was wir zusätzlich an Infos benötigen kann man sich mit dem Tools schnell selbst einstellen und die Ansichten um die Punkte reduzieren die nicht relevant sind.
Gruß
@clSchak
wir sind auch erst "einfach" angefangen, Name, technische Daten usw. zu dokumentieren. Mittlerweile haben wir alle Seriennummern der Festplatten erfasst, die gesamten Buchhaltungsdaten sind hinterlegt, alle Wartungs- und Serviceverträge, die technische Dokumentation, Standort im Rack, Verlinkung zum Monitoring, Ansprechpartner, Anschlusspunkte (Netz, SAS, FC, LAN ....). Das ist ein haufen Arbeit ja, aber wenn man "größere" Umgebungen hat macht das durchaus Sinn wenn man auch die Firmwarestände der einzelnen Komponenten dokumentiert ....
Automatisiert schön und gut, damit sind wir angefangen alles möglich über XML, CSV, SQL .... zu importieren, machen wir mittlerweile nicht mehr, da wir recht homogene Hardware haben konnten wir uns entsprechende Vorlagen erstellen und diese dann jeweils anpassen.
Wir setzen auch I-DOIT ein, fangen gerade an die Dienste zu implementieren um so eine Abhängigkeitsstruktur zu haben, daraus resultiert dann der "Wert" eines Ausfalls (praktisch für die Risikobewertung).
Bisher sind wie (sogar) ohne Anpassungen ausgekommen, dass was wir zusätzlich an Infos benötigen kann man sich mit dem Tools schnell selbst einstellen und die Ansichten um die Punkte reduzieren die nicht relevant sind.
Gruß
@clSchak
Zitat von @emeriks:
In diese Doku muss alles rein, was Du selbst vorzufinden wünscht, wenn Du Dich über einen "fremden", "unbekannten" Server informieren willst. Alles, was Du für eine Übernahme (der Verantwortung) benötigt würdest. Alles, was Dir für eine Fehleranalyse hilfreich wäre. Alles, was Dir für eine Restauration nach Totalausfall (Brand, Diebstahl) hilfreich wäre.
In diese Doku muss alles rein, was Du selbst vorzufinden wünscht, wenn Du Dich über einen "fremden", "unbekannten" Server informieren willst. Alles, was Du für eine Übernahme (der Verantwortung) benötigt würdest. Alles, was Dir für eine Fehleranalyse hilfreich wäre. Alles, was Dir für eine Restauration nach Totalausfall (Brand, Diebstahl) hilfreich wäre.
Top, kurz und knackig!
Hallo TrialAndError,
Richtig, weil du bei einem Ausfall möglichst schnell die Neuinstallation exakt nach der damaligen Ablauf nachvollziehen willst.
Damit ist doch eigentlich alles klar.
Auf die Infrastruktur bezogen, gehört dann alles rein, was ein neuer Kollege benötigt, um sich sofort zurechtfinden zu können.
grüße vom it-frosch
Welche Bereiche landen bei euch in der Doku?
Warum erstellst du eine Doku?Richtig, weil du bei einem Ausfall möglichst schnell die Neuinstallation exakt nach der damaligen Ablauf nachvollziehen willst.
Damit ist doch eigentlich alles klar.
Auf die Infrastruktur bezogen, gehört dann alles rein, was ein neuer Kollege benötigt, um sich sofort zurechtfinden zu können.
grüße vom it-frosch
Zitat von @runasservice:
Top, kurz und knackig!
Zitat von @emeriks:
In diese Doku muss alles rein, was Du selbst vorzufinden wünscht, wenn Du Dich über einen "fremden", "unbekannten" Server informieren willst. Alles, was Du für eine Übernahme (der Verantwortung) benötigt würdest. Alles, was Dir für eine Fehleranalyse hilfreich wäre. Alles, was Dir für eine Restauration nach Totalausfall (Brand, Diebstahl) hilfreich wäre.
In diese Doku muss alles rein, was Du selbst vorzufinden wünscht, wenn Du Dich über einen "fremden", "unbekannten" Server informieren willst. Alles, was Du für eine Übernahme (der Verantwortung) benötigt würdest. Alles, was Dir für eine Fehleranalyse hilfreich wäre. Alles, was Dir für eine Restauration nach Totalausfall (Brand, Diebstahl) hilfreich wäre.
Top, kurz und knackig!
Yupp, volle Zustimmung.
Hallo Fa-jka
Ich habe noch nie nen Apache, OTRS/KIX, Bareos, Windows Print Server, ... out of the Box verwendet. In der Regel sind bei diesen Diensten doch immer irgend welche Anpassungen relevant, die das System einzigartig machen oder?
Ich habe bis dato noch nie Dienste konfigurieren müssen?!?
Ich habe noch nie nen Apache, OTRS/KIX, Bareos, Windows Print Server, ... out of the Box verwendet. In der Regel sind bei diesen Diensten doch immer irgend welche Anpassungen relevant, die das System einzigartig machen oder?
@emeriks
Und genau an dieser Stelle hab ich ein Problem. Ich weiß nicht was ich brauchen würde.
Kleines Beispiel: Ich hatte in meiner Doku die Festplatten, Seriennummern, Slots der Disks und interne "Namen" (sdx) aufgenommen. Nach meinen Problemen mit dem RAID habe ich jetzt noch die Konfiguration der mdx hinzugenommen und die UUIDs der einzelnen Partitionen ergänzt.
Ich habe ja nichts dagegen aus Fehlern zu lernen. Aber es hatte doch sicherlich auch schon der ein oder andere Admin Probleme bei denen er sich gewünscht hat, dass er Detail xy vorher dokumentiert hätte.
Alles was in einer von einem Dritten erstellten Doku drin sein müsste, damit Du nicht von
eine undokumentierte bestehende Infrastruktur
sprechen würdest.Und genau an dieser Stelle hab ich ein Problem. Ich weiß nicht was ich brauchen würde.
Kleines Beispiel: Ich hatte in meiner Doku die Festplatten, Seriennummern, Slots der Disks und interne "Namen" (sdx) aufgenommen. Nach meinen Problemen mit dem RAID habe ich jetzt noch die Konfiguration der mdx hinzugenommen und die UUIDs der einzelnen Partitionen ergänzt.
Ich habe ja nichts dagegen aus Fehlern zu lernen. Aber es hatte doch sicherlich auch schon der ein oder andere Admin Probleme bei denen er sich gewünscht hat, dass er Detail xy vorher dokumentiert hätte.
Hallo @clSchak,
ich kratze noch an der Oberfläche von diesem Wunderwerk. Allerdings macht mir die Finanzierungspolitik Probleme. Auch wenn i-doit das anders sieht sind deren Lizenzen nicht wirklich günstig. Nutzt ihr die open oder die supportete Version?
Führt ihr eure gesamte Doku nur in i-doit oder zusätzlich auch noch in einer externen Anwendung, einem Wiki oder Excel, Word, ...?
Man kann ich i-doit Dienste abbilden? Gut zu wissen.
Wir setzen auch I-DOIT ein
ich kratze noch an der Oberfläche von diesem Wunderwerk. Allerdings macht mir die Finanzierungspolitik Probleme. Auch wenn i-doit das anders sieht sind deren Lizenzen nicht wirklich günstig. Nutzt ihr die open oder die supportete Version?
Führt ihr eure gesamte Doku nur in i-doit oder zusätzlich auch noch in einer externen Anwendung, einem Wiki oder Excel, Word, ...?
, fangen gerade an die Dienste zu implementieren um so eine Abhängigkeitsstruktur zu haben, daraus resultiert dann der "Wert" eines Ausfalls (praktisch für die Risikobewertung).
Man kann ich i-doit Dienste abbilden? Gut zu wissen.
@it-frosch
Das ist nur bedingt richtig.
Ich brauche eine Doku, die mir im Fehlerfall (z.B. nach einem Update) hilft den Mist wieder zum laufen zu bringen.
Ein Desaster Recovery ist nur sehr sehr selten notwendig. In dem Fall würde mir ein clean Setup warscheinlich auch nur wenig helfen, da allein der Import unserer LDAP (um mal ein großes Beispiel zu nennen) mindestens 48 Stunden benötigt. (Diese Info steht jetzt z.B. nach meinem letzten Versuch in der Doku)
Mein Problem ist, dass ich nicht weiß was relevant ist und es eventuell werden könnte. Ich weiß aber, dass es super unübersichtlich wird, wenn ich z.B. den Setup jedes einzelnen Dienstes auf jedem Host (unterscheidet sich ja meist zumindest durch abweichende IP oder DNS Einstellungen) dokumentiere.
Angenommen du würdest bei uns anfangen. Was würdest du erwarten, dass es in der Doku steht?
(Ich selbst habe noch nie eine gute Doku gesehen. Hatte aber bisher Kollegen, die besser waren als jede Doku)
weil du bei einem Ausfall möglichst schnell die Neuinstallation exakt nach der damaligen Ablauf nachvollziehen willst.
Das ist nur bedingt richtig.
Ich brauche eine Doku, die mir im Fehlerfall (z.B. nach einem Update) hilft den Mist wieder zum laufen zu bringen.
Ein Desaster Recovery ist nur sehr sehr selten notwendig. In dem Fall würde mir ein clean Setup warscheinlich auch nur wenig helfen, da allein der Import unserer LDAP (um mal ein großes Beispiel zu nennen) mindestens 48 Stunden benötigt. (Diese Info steht jetzt z.B. nach meinem letzten Versuch in der Doku)
Mein Problem ist, dass ich nicht weiß was relevant ist und es eventuell werden könnte. Ich weiß aber, dass es super unübersichtlich wird, wenn ich z.B. den Setup jedes einzelnen Dienstes auf jedem Host (unterscheidet sich ja meist zumindest durch abweichende IP oder DNS Einstellungen) dokumentiere.
Damit ist doch eigentlich alles klar.
Auf die Infrastruktur bezogen, gehört dann alles rein, was ein neuer Kollege benötigt, um sich sofort zurechtfinden zu können.
Auf die Infrastruktur bezogen, gehört dann alles rein, was ein neuer Kollege benötigt, um sich sofort zurechtfinden zu können.
Angenommen du würdest bei uns anfangen. Was würdest du erwarten, dass es in der Doku steht?
(Ich selbst habe noch nie eine gute Doku gesehen. Hatte aber bisher Kollegen, die besser waren als jede Doku)
Hi
wir "migrieren" unsere Word / Excel / usw. Daten alle Richtung I-DOIT, die Anbindung an OTRS soll auch noch in diesem Jahr erfolgen. Leider hat das Tool keine Schnittstelle zu PRTG (zu Nagios allerdings schon).
Mit den einzelnen Diensten, Services, Hardware usw. bekommt man gute Ansichten über beteiligte Dienste, die dann in etwa so aussehen:
Ist noch nicht ganz fertig, aber so kann sich auch ein Kollege der im Helpdesk sitzt ein Bild davon machen wenn es irgendwo hackt.
wir "migrieren" unsere Word / Excel / usw. Daten alle Richtung I-DOIT, die Anbindung an OTRS soll auch noch in diesem Jahr erfolgen. Leider hat das Tool keine Schnittstelle zu PRTG (zu Nagios allerdings schon).
Mit den einzelnen Diensten, Services, Hardware usw. bekommt man gute Ansichten über beteiligte Dienste, die dann in etwa so aussehen:
Ist noch nicht ganz fertig, aber so kann sich auch ein Kollege der im Helpdesk sitzt ein Bild davon machen wenn es irgendwo hackt.
@TrialAndError,
Installationsdoku + Änderungsdoku + Knowhow Übersicht für jedes System
So versuchen wir seit einiger Zeit die Doku zu pflegen.
Das das alles andere als trivial ist weiß ich.
Wir bleiben auch hinter unseren Ansprüchen zurück.
Ich dokumentiere sehr viel in ZIM. Dann kann ich die Doku auch schnell einem Kollegen schicken,
der sie in seinen ZIM einhängt oder über den WEBServer zu Lesen freigeben.
grüße vom it-frosch
Angenommen du würdest bei uns anfangen. Was würdest du erwarten, dass es in der Doku steht?
Systemübersicht (wie spielt was zusammen?)Installationsdoku + Änderungsdoku + Knowhow Übersicht für jedes System
So versuchen wir seit einiger Zeit die Doku zu pflegen.
Das das alles andere als trivial ist weiß ich.
Wir bleiben auch hinter unseren Ansprüchen zurück.
Ich dokumentiere sehr viel in ZIM. Dann kann ich die Doku auch schnell einem Kollegen schicken,
der sie in seinen ZIM einhängt oder über den WEBServer zu Lesen freigeben.
grüße vom it-frosch
Zitat von @TrialAndError:
Hallo Fa-jka
Ich habe noch nie nen Apache, OTRS/KIX, Bareos, Windows Print Server, ... out of the Box verwendet.
Hallo Fa-jka
Ich habe bis dato noch nie Dienste konfigurieren müssen?!?
Ich habe noch nie nen Apache, OTRS/KIX, Bareos, Windows Print Server, ... out of the Box verwendet.
Achso. Ich dachte, Du fummelst an Windows-Diensten herum.
In deinem Beispiel (Apache usw. usf.) ist die lokale Konfiguration die Dokumentation - zumindest, solange sie nach der "Best practice" erfolgt ist.
Eine "externe" Dokumentation würde letztendlich darauf hinauslaufen, dass man eine Kopie der Konfiguration wegspeichert. Und das heißt bei mit "Backup"
Ernsthaft: Wenn jemand einen Fehler in einem Apache2 sucht, erwarte ich schon, dass der "apache2ctl -S" eingibt. Ansonsten ist da meines Erachtens nach der falsche Mann am falschen Ort.
Gruß,
Jörg
Wie @it-frosch schon anmerkt, welche Informationen benötigst DU, um ein System wieder zum laufen zu bringen.
Hierbei könne wir nur Anregungen und Tipps geben.
DU musst wissen, welche Informationen DU benötigst, um ein System / Anwendung, was-auch-immer wieder zum laufen zu bekommen.
Und Du solltest berücksichtigen, die Informationen sollten Deinem (evtl.) neuen Kollegen behilflich sein.
Denn der kennt Eure Umgebung nicht.
P.S.
Gruss Penny
Hierbei könne wir nur Anregungen und Tipps geben.
DU musst wissen, welche Informationen DU benötigst, um ein System / Anwendung, was-auch-immer wieder zum laufen zu bekommen.
Und Du solltest berücksichtigen, die Informationen sollten Deinem (evtl.) neuen Kollegen behilflich sein.
Denn der kennt Eure Umgebung nicht.
Das das alles andere als trivial ist weiß ich.
Wir bleiben auch hinter unseren Ansprüchen zurück.
Das bleibt unter Umständen nicht aus, wenn zu wenig Ressourcen vorhanden sindWir bleiben auch hinter unseren Ansprüchen zurück.
P.S.
- Dokumentation LEBEN. D.h. Die Dokumentationen müssen von Zeit zu Zeit überarbeitet / angepasst werden.
- Die Dokumentationen, welche ich den Kollegen überlasse, enthalten alle nötigen Informationen.
- Die Dokumentation, speziell Installationsverfahren enthalten 2 Varianten
- Kurzfassung für IT Pros
- Ausführliche Fassung
- Allgemeinverständlich
- Revisionssicher
Gruss Penny
Naja, die vielen Apache Installationen sind schon eher das "kleinste" Übel. Wobei hier auch jeder Server anders aussieht. Und gibt es da wirklich EINE "Best pracitce"? Irgend wie hat doch wieder jedes System seine eigenheiten. Seien es auch nur irgend welche nervigen PHP oder Java CGI Geschichten.
Die Idee finde ich gut. Das Backup würde ich jetzt zwar eher nicht als Doku verwenden wollen aber die Konfigurationsdateien wegschreiben und kommentieren ist ein einfacher erster Schritt.
Eine "externe" Dokumentation würde letztendlich darauf hinauslaufen, dass man eine Kopie der Konfiguration wegspeichert. Und das heißt bei mit "Backup"
Die Idee finde ich gut. Das Backup würde ich jetzt zwar eher nicht als Doku verwenden wollen aber die Konfigurationsdateien wegschreiben und kommentieren ist ein einfacher erster Schritt.
Grade im Hinblick auf Datensicherung (Backup) ist eine Dokumentation sinnvoll. Nicht nur die Installation und Konfiguration der Backupumgebung selbst, sondern in Hinblick der Datensicherungen (Schedules, Sicherungen (was, wo => Disk, Band, usw.).
Grade wenn man einen Überblick über die Sicherungs- und Laufzeiten haben will, bietet sich eine Timeline (Zeitstrahl) an.
Gruss Penny
Grade wenn man einen Überblick über die Sicherungs- und Laufzeiten haben will, bietet sich eine Timeline (Zeitstrahl) an.
Gruss Penny
Hallo,
Man sollte mal darüber nachdenken, wo ein Kollege als Erstes sucht, wenn er ein Problem hat.
Wichtig ist, dss die Suche endlich ist. D.h., es muss irgendwann ein Punkt erreicht sein an dem man sagen kann: "Ich habe diese Information nicht gefunden - also existiert sie noch nicht".
Gruß,
Jörg
Zitat von @TrialAndError:
Das Backup würde ich jetzt zwar eher nicht als Doku verwenden wollen aber die Konfigurationsdateien wegschreiben und kommentieren ist ein einfacher erster Schritt.
Das Backup würde ich jetzt zwar eher nicht als Doku verwenden wollen aber die Konfigurationsdateien wegschreiben und kommentieren ist ein einfacher erster Schritt.
Man sollte mal darüber nachdenken, wo ein Kollege als Erstes sucht, wenn er ein Problem hat.
Wichtig ist, dss die Suche endlich ist. D.h., es muss irgendwann ein Punkt erreicht sein an dem man sagen kann: "Ich habe diese Information nicht gefunden - also existiert sie noch nicht".
Gruß,
Jörg
