Erweiterte Suche


Cisco hat eine wunderschöne Werbung zum Thema "IPv4 ist alle" veröffentlicht. Das Video ist sehenswert, es spielt in bester Hollywoodmanier durch, was im nächsten Jahr passieren soll.

Selbstverständlich erreichen Sie über uns sowohl das Video als auch die Cisco Webseite über IPv6. Warten Sie nicht bis zur letzten Sekunde ...

Für die Massenterminierung von PPPoX Verbindungen gab es die Empfehlung, MPD zu nehmen. Das braucht FreeBSD. Ich habe mir ehrlich gesagt wenig Gedanken gemacht, ob die geplante Hardware im Detail passen wird oder nicht. Das war ein Fehler. Man kann leider bei vielen Betriebssytemen (Mainstream oder nicht) immer wieder erleben, daß aktuelle oder alte Hardware nicht unterstützt wird.

Mit dem stabilen FreeBSD 9.0 bootet das System bis in den Installer, der dann keine Festplatten sieht. Der Adaptec RAID 6805 Controller wird nicht unterstützt. Dies ist ein besonders dummer Fall, weil es die Installation grundsätzlich verbietet. Hat man ein System erstmal auf der Platte, findet sich i.d.R. immer ein Weg, fremde Treiber auf- oder Sourcecodeanpassungen vorzunehmen. Aber ohne Platte?

Adaptec bietet einen Treiber für FreeBSD 8.2, der aber nicht auf den Installationsmedien liegt. In Foren finden sich verschiedene Vorschläge, den Treiber auf anderen Medien bereitzustellen, sei es per FreeBSD formatiertem USB (hab ich nicht) oder FAT formatiertem USB mit zwei CDs (ich hab nur ein Laufwerk und das auch nur via BMC).

Das Installmedium

Was liegt näher, als sich selbst ein individuelles Installationmedium zu bauen? Linux Kenntnisse sind ja glücklicherweise vorhanden:

$ wget ftp://ftpv6.plusline.net/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.3/FreeBSD-8.3-RELEASE-amd64-disc1.iso
$ mkdir install-cd
# mount -o loop -t iso9660 FreeBSD-8.3-RELEASE-amd64-disc1.iso install-cd
$ tar -C install-cd -cf - . | (mkdir cd.adaptec; tar -C cd.adaptec -xvpf -)

Eine Kopie des Images steht nun zur Verfügung. Die muß nun modifiziert werden.

$ wget http://download.adaptec.com/raid/aac/unix/aacraid_freebsd_b18668.tgz
$ tar -xzf aacraid_freebsd_b18668.tgz freebsd8/
$ cp -a freebsd8/aacu64.ko cd.adaptec/boot/kernel/
$ chmod u+w cd.adaptec/boot/defaults/loader.conf
$ vi cd.adaptec/boot/defaults/loader.conf 

Damit ist der Treiber an der richtigen Stelle und ja, es funktioniert auch mit FreeBSD 8.3. In der loader.conf muß nun der Treiber auch aktiviert werden. Der Editor ist schon offen, fehlt also noch der Patch.

--- install-cd/boot/defaults/loader.conf        2011-02-17 03:19:19.000000000 +0100
+++ cd.adaptec/boot/defaults/loader.conf        2012-09-17 14:22:48.000000000 +0200
@@ -455,6 +455,7 @@
 ###  Other modules  ##########################################
 ##############################################################

+aacu64_load="YES"              # Adaptec RAID
 aio_load="NO"                  # Asynchronous I/O
 bktr_load="NO"                 # Brooktree Bt848/Bt878 TV/Video Capture Card
 ispfw_load="NO"                        # Qlogic ISP Firmware

Nun noch das bootfähige Medium bauen.

$ mkisofs -R -no-emul-boot -b boot/cdboot -o FreeBSD-8.3-Adaptec-disk1.iso cd.adaptec/

Und davon booten.

Die Scheckminuten

Es bootet. Der Loader läd den Kernel. Er läd das Modul. Die Freude ist groß.

FreeBSD/i386 bootstrap loader, Revision 1.1
 
Loading /boot/defaults/loader.conf /kernel text=0x277391 data=0x3268c+0x332a8 ...
Loading /boot/kernel/aacu64.ko text=0x100042321

Der Loader ist da:

boot-loader-menu

Und dann steht alles. De Zähler ist auf Null. Das Rädchen steht. Absturz.

Versuche mit der 8.2 und anderen Medien blieben erfolglos. Immer ein Absturz, wenn der Loader weiter booten soll.

Und weiter geht's

Irgendwann erwischte mich ein Telefonanruf eines Kunden an dieser Stelle. Ich war eine gute Viertelstunde weg.

Und als ich wieder da war, grinste mich der Installationschirm an. Dieser blöde Loader tut einige Minuten(!) lang gar nichts Sichtbares. Dann geht's plötzlich weiter. Und die Platte steht zur Verfügung. Hurra!

Nach mehreren Fehlversuchen, die durch Kleinigkeiten verursacht wurden, ist das System auf der Platte:

Bei der Automatic-Partitionierung erschienen mir 16G /var und 300G /usr im Mißverhältnis. Also beide Partitionen löschen und neu anlegen. Allerdings ist die zweite Partition immer "Partition to big?". Erst viel später habe ich mitbekommen, daß beim Löschen von /var vor der /tmp Partition eine 16G Lücke reißt, die nicht trivial sichtbar ist. Ich hatte mir die Platte fragmentiert und Platz zwischen den Partitionen verbrannt. FreeBSD schlägt eben nicht, wie dokumentiert, den größten zusammenhängende Bereich vor, sondern den gesamten Restplatz.

Bei dem Anlegen der Nutzeraccounts schlug das System /home/<user> als Verzeichnisbaum vor. Stop! Das liegt auf Root. Da gehört eine extra Partition rein. Also nochmal von vorn.

                         FreeBSD Disklabel Editor

Disk: aacd0     Partition name: aacd0s1 Free: 0 blocks (0MB)

Part      Mount          Size Newfs   Part      Mount          Size Newfs
----      -----          ---- -----   ----      -----          ---- -----
aacd0s1a  /            1024MB UFS2     Y
aacd0s1b  swap         4096MB SWAP
aacd0s1d  /var        32768MB UFS2+S   Y
aacd0s1e  /tmp         1024MB UFS2+S   Y
aacd0s1f  /usr        32768MB UFS2+S   Y
aacd0s1g  /home         208GB UFS2+S   Y

Zum Schluß rebootet das System und endlich läuft alles von der Platte.

Nochmal Adaptec

Unglücklicherweise bootet das System von der Platte ohne den Adpatec Treiber und bleibt so nach dem Kernelladen hängen. Verdammt!

Also nochmal von CD gebootet, und im loader mit "set rootdev=disk1s1a:" (nicht /dev/aacd1s1a) von der Platte weiter gebootet. Dann eingeloggt und via Netzwerk (wie hieß gleich der Treiber, der vom BMC virtualisierte CD Laufwerke erkennt?) das Kernelmodul geholt, loader.conf angepaßt ... Fertig.

Jetzt bootet das System wie gewünscht. Es gibt zwar immer noch die Gedenkminute nach dem Loader, aber ich erschrecke nicht mehr.

Wer eine IPTV Plattform anbietet, muss sie auch überwachen. Nur ist das nicht ganz so einfach, wenn nicht alle Komponenten aus einer Hand kommen. Wir standen vor der Aufgabe, an einer Zwischenstelle am Transportweg, die Qualität der Aussendung monitoren zu müssen.

Kurze Ausfälle

Das eigentliche Problem beim Fernsehen besteht darin, dass jeder auch noch so kurzfristige Ausfall vom Kunden bemerkt wird und instantan zu Störungsmeldungen führt.

Um schnellstmöglich von einem Problem zu erfahren, sollte also das Ausbleiben von Multicast-Paketen für eine bestimmten Sender nach wenigen Sekunden zu einem Alarm führen. Die Hotline muss also beim Entgegennehmen der Störungsmeldung bereits wissen, welcher Sender gerade kein Bild liefert. Dafür hat sie maximal fünf Sekunden Zeit.

Was wir also getan haben, ist einfach: Auf einem altersschwachen Rechner werden sämtliche Kanäle abonniert (macht nicht ganz ein Gigabit voll) und notiert, welcher Sender zuletzt ein Datenpaket abgeliefert an. Fehlen Daten für mehr als die definierten fünf Sekunden, wird protokolliert wie lange schon von welchem Streamer die Daten fehlen. Das füttert direkt das Alarmsystem. Und natürlich kann man dies auch auf malen (logarithmisch, um die kleinen Ausfälle nicht zu übersehen):

iptv-missing-channels

Ein zweites Ergebnis dieses Monitorings ist die Erkenntnis welcher Streamer noch wie viele Kanäle ausliefert. Fällt dieser Wert auf Null, ist dringender Handlungsbedarf gegeben, weil offenbar eine Komponente total ausgefallen ist. Man kann also sofort eine SMS an die Bereitschaft verschicken.

Details

Es stellt sich aber heraus, dass die Qualität eines Fernseh-Erlebnisses nicht allein von der Existenz eines Bildes abhängt (und vom Programminhalt), sondern auch von den Störungen, die das Bild überlagern oder unbrauchbar machen.

Die Software wurde also um die Fähigkeit erweitert, in die MPEG-TS Daten hineinzuschauen. Dies gibt eine Menge von interessanten Informationen:

Datenstrom liegt von a.b.c.d an.

Statistik über 3 Sekunden:
 Empfangene UDP Pakete      3446   Paket zu kurz                 0
 Verarbeitete MPEG Pakete  24122   Fehlende Sync-Markierung      0

Statistiken pro Datenstrom (MPEG-Programm)
 Programmkennung (PID)      6630 6610 6622 6620 6621 6600    0   32
                            19e6 19d2 19de 19dc 19dd 19c8 0000 0020
 Empfangene Pakete           56721738  865  494  377   29   28   24
 verschluesselte Daten         021366  829  448  331    0    0    0
 Ansetzpunkte, FullFrames      0    5   18   23   23    0    0    0
 priorisierte Daten            0    5    0    0    0    0    0    0
 Signalstoerung am Streamer    0    0    0    0    0    0    0    0
 Taktstoerung am Streamer      0    0    0    0    0    0    0    0
 Sequenzfehler(CC)             0    0    0    0    0    0    0    0

     Abweichungen vom Synchronisationstakt 19d2 (absoluter Jitter)
26%  ||                                                                   
20%  ||                                                                   
14% ||||                                                                  
 8% ||||||                                                                
 2% ||||||                                                                
   +----------------------------------------------------------------------
 ms 0123456789012345678901234567890123456789012345678901234567890123456789
    0         1         2         3         4         5         6         

     Abweichungen der Paketankunftszeiten (relativer Jitter)
66% |                                                                     
52% |                                                                     
37% |                                                                     
22% |                                                                     
 7% ||  ||||                                                              
   +----------------------------------------------------------------------
 ms 0123456789012345678901234567890123456789012345678901234567890123456789
    0         1         2         3         4         5         6         

Kanal ist durch Kunden im Moment abonniert.

Wie für einen HDTV Kanal üblich ist die Datenrate hoch und der Jitter klein. Beim einem Radioprogramm sieht das anders aus:

Datenstrom liegt von a.b.c.e an.

Statistik über 3 Sekunden:
 Empfangene UDP Pakete        43   Paket zu kurz                 0
 Verarbeitete MPEG Pakete    301   Fehlende Sync-Markierung      0

Statistiken pro Datenstrom (MPEG-Programm)
 Programmkennung (PID)       851    0  850
                            0353 0000 0352
 Empfangene Pakete           282   13    6
 verschluesselte Daten         0    0    0
 Ansetzpunkte, FullFrames      0    0    0
 priorisierte Daten            0    0    0
 Signalstoerung am Streamer    0    0    0
 Taktstoerung am Streamer      0    0    0
 Sequenzfehler(CC)             4    0    4

     Abweichungen vom Synchronisationstakt 0353 (absoluter Jitter)
59%                                                                      |
46%                                                                      |
33%                                                                      |
19%                                                                      |
 6% |    |     | |     |     ||   ||             ||   |      || |        |
   +----------------------------------------------------------------------
 ms 0123456789012345678901234567890123456789012345678901234567890123456789
    0         1         2         3         4         5         6         

     Abweichungen der Paketankunftszeiten (relativer Jitter)
15%         |                                                             
11%         |                                                             
 8%       | | |        |                                                  
 5%     | | | |  |  | || |                                                
 1%  | || ||| ||||||||||||  ||  | |                |                      
   +----------------------------------------------------------------------
 ms 0123456789012345678901234567890123456789012345678901234567890123456789
    0         1         2         3         4         5         6         

Kanal ist durch Kunden im Moment nicht abonniert.

Ein MPEG-Transportstrom (ein Programm im Fernseh-Sinne) besteht aus vielen Programmen (im MPEG-TS Sinne), die oben alle tabellarisch aufgelistet sind. Das Programm 0000 ist ein Indexkanal, der festlegt, welcher anderen Programme die Sendung ausmachen und wie sie zusammen spielen. Aber auch ohne diese Detailkenntnis kann man erraten, dass der höchstbandbreitige Anteil die Bildinformation sein wird. Weitere Programme sind Teletext, Untertitel, EPG, einer oder mehrere Audiokanäle. Besonders viele dieser Programme hat ZDF-HD.

Statistik

Diese kurzen Einblicke kann und sollte man auch graphisch aufbereiten, denn oft ist es erst nach dem Vorfall (wie oben aufgezeigt) möglich, sich um die Ursachen kurzer Ausfälle kümmern zu können. dazu braucht man historische Daten.

Um nicht zu viele Daten zu generieren, wird aktuell über eine Minute summiert und so pro Minute und Programm (im MPEG-TS Sinne) ein Messwert generiert. Diese lassen sich dann plotten.

Zuerst einmal die Datenrate als Pakete * Datengröße / Zeit. Man sieht schön, wie das Bildsignal eines HD-Kanals die Bandbreite dominiert.

iptv-history-data-rate

Interessant ist der Einbruch zwischen 17:30 und 20:00. Das Signal war kurz weg, kam dann mit halber Bandbreite wieder. Eine mögliche Erklärung ist, daß der Sender hier eine Sendung in SDTV eingeschoben hat, die aus einer Fremdquelle konvertiert wurde.

Einige Sender, vor allem die dritten Programme übernehmen zeitweise den kompletten Datenstrom von der ARD. Man sieht deutlich den Wechsel der Programm-Nummer.

iptv-history-kanaluebernahme

Zurück zum Fehler an dem bewussten Abend. Die Anzahl der Full-Frames, also der Wiederaufsetzpunkte für das Bild bzw. die anderen Kompressionsverfahren gibt Aufschluss, ob eine Störung im Netz oder beim Sender vorliegt. Eine Netzkomponente wird üblicherweise nicht das Signal transkodieren und eigenständig Aufsetzpunkte einstreuen:

iptv-history-fullframes

In dem fraglichen Zeitraum hat also der Sender immer wieder versucht, sein Signal zu resynchronisieren. Natürlich auf einem wesentlich niedrigerem Level als wenn ein HD-Datenstrom abliegen würde. Interessant ist aber auch, wie andere Programme mit erheblich mehr Aufsetzpunkten versorgt werden.

Es kann natürlich sein, dass der Streamer selbst kein Signal anliegen hatte. In dem Fall signalisiert er diese Information mit, um eine komplette Neusynchronisierung des MPEG Programms zu erzwingen.

iptv-history-signal-streamer

Es ist deutlich zu erkennen, dass der Streamer zu Beginn der Störung nicht ausreichend neue Information erhalten hat. Die Effekte, die sich dann hinzogen sind aber nicht mehr an dieser Stelle zu suchen.

Eine zweite Fehlerquelle liegt auf Seiten der Sendeanstalt. Die Programme sind untereinander mit einem 33MHz Takt synchronisiert. Dies stellt sicher, dass Bild und Ton nicht auseinander laufen. Der hohe Takt eignet sich auch zur Taktregeneration und -kalibrierung an der Empfangsstelle, wenn dort keine stabilen Quarze vorhanden sein sollten. Trotzdem muss ab und zu dieser Taktquelle getauscht werden. Dann sendet die Anstalt eine entsprechende Markierung, um auch diese Synchronisation neu zu erzwingen.

iptv-history-takt-streamer

Auch hier ist deutlich, dass diese Taktinformation schon senderseitig zu den Ausfallzeiten auftrat. Ein Fehler auf Seiten der Netzplattform ist damit eigentlich auszuschließen.

Was aber im Netz auftreten kann sind Paketvertauschungen und -verluste. Diese äußern sich in Fehlern an den Sequenznummern (die allerdings nur zyklisch von 0 bis 15 laufen).

iptv-history-cc-error

Interessant an diesem Bild sind die kleinen CC-Fehler im Bereich nach 18 Uhr. Hier werden die Datenpakete immer wieder mit Verlusten oder vertauscht beobachtet. Ein Grund könnte sein, dass die Programme vom Sender immer wieder neu synchronisiert werden. Dann kann auch der Sequenzzähler zurückgesetzt werden, was hier offenbar der Fall ist.

Zum Schluss noch ein Blick auf den mittleren Jitter.

iptv-history-jitter

Keine weiteren Fragen.

Fazit

Man kann einige hundert Sender ohne extra teure Technik monitoren. Man muss es nur tun.

Ich hatte kürzlich geschrieben, wie man die DSGVO als Blogger umsetzen kann. Der Text ist ziemlich abstrakt geworden, weil ich einen generellen Leitfaden beibehalten wollte. Nun also mal konkret für meine eigene Webseite.

Analyse

Ich schrieb: Man nehme sich seine Webseite her, und schau im Entwickler-Modus des Browsers erst einmal nach, welche Datenquellen die Webseite so alles einbindet.

Bei Firefox drücke ich F12 für den Entwickermodus und wähle den Reiter Netzwerk aus. Dann lade ich die Seite erneut mit F5.

2018-05-22-102920_715x381_scrot

Es fällt auf, das bei allen Zugriffen das Schlosssymbol aktiv ist. Das bedeutet die Zugriffe erfolgen über HTTPS. Wenn möglich sollte man HTTPS benutzen, besonders aber, wenn man Formulare benutzt. Den Punkt habe ich also schon mal erfüllt, es extra aufzuschreiben ist aber nicht nötig.

Als nächstes sticht ein Zugriff auf einen externen Server ins Auge: Ein Stylesheet wird fonts.googleapis.com nachgeladen. Das werde ich dokumentieren müssen.

Weiter mit der Faktensammlung: Wie schaut's mit Cookies aus? Unter Einstellungen - Privacy findet sich der Punkt Cookies.

2018-05-22-110102_973x407_scrot

Ohja. Das ist eine ganze Menge. Allerdings bin ich aktuell auch als Bearbeiter im Backend angemeldet und das ist keine öffentliche Funktion. Löscht man alle diese Cookies und versucht es nochmal (z.B: von einem anderen Rechner aus), so bleibt die Liste leer. Wie schön.

Die grundlegende Analyse ist damit schon abgeschlossen. Bleiben nun die gewollten Eigenschaften der Webseite, also die Dinge, die ich bewußt entwickelt, eingeschaltet und aktiviert habe. Die findet man natürlich nicht automatisch, sondern die weiß man als Autor. Im Zweifel hilft ein Blick über die verschiedenen Bereiche der eigenen Webseite, um das Gedächtnis aufzufrischen.

Was ist denn nun besonders an der Seite? Achja, Kommentare. Und da kann man sich tatsächlich einen Cookie setzen lassen, der die Angaben des Formulars automatisch vorab ausfüllt. Den wird man erwähnen müssen. Dabei fiel mir auf, daß das Formular den Cookiebutton automatisch aktiviert hat. Das habe ich gleich mal umgestellt.

Des weiteren habe ich interaktive Inhalte auf der Seite. Auf die will ich nicht verzichten, also muß ich sie beschreiben.

Und damit ist die Analyse schon beendet.

Eigner Server

Jetzt geht's ans Eingemachte: Was tut eigentlich mein Webserver so?

Ich weiß, daß er Logfiles führt. Die lese ich zwar nur bei Bedarf (und den hatte ich schon) und mache keine Statistik damit.

Und dann gibt's noch Logfiles für verschiedene Fehlerzustände. Die sind verdammt umfangreich, denn ich will wissen, was genau den Fehler ausgelöst hat.

Bleibt noch die Frage, wie lange die Logfiles liegen bleiben: Aha, eine Woche. Das scheint mir angemessen, denn ich brauche diese Zeit vor allem nach einem langen Wochenende.

Schreiben wir's auf:

Beim Zugriff auf diese Webseiten übermittelt der Browser des Besuchers
automatisch Daten über die gewünschte Ressouce, die IP-Adresse, an die
die Daten übermittelt werden sollen, gegebenenfalls auch spezifische Daten
aus vorherigen Anfragen (Cookies, Referer, Formulare, etc.).

Ein Teil dieser Daten wird automatisch geloggt, um den technischen Betrieb
sicherstellen zu können. Diese Daten werden grundsätzlich nur zur manuellen
Post-Mortem-Analyse herangezogen anderenfalls automatisch nach sieben
Tagen gelöscht.

Fertig.

Cookies

Meist ein heißer Punkt. Aber auch hier habe ich Glück, denn normalerweise setze ich keine Cookies, da ich auf Anmeldungen verzichte.

Nicht-angemeldete Nutzer erhalten grundsätzlich keine Cookies seitens des Webservers.

Und der Cookie bei Formularen?

Auf explizite Aufforderung des Nutzers werden die Angaben für Stammdaten
des Kommentarfeldes per Cookie im Browser gespeichert. Dieses dient dazu,
bei späterer Nutzung des Kommentarfelds diese Daten schon initial einzutragen.
Dieser Cookie wird vom Browser spätestens nach einem Jahr gelöscht,
eine manuelle Löschung ist jederzeit vom Nutzer selbst in seinem Browser möglich.
Eine Speicherung des Cookies auf Serverseite erfolgt nicht.

Der Teil mit der Anmeldung zwecks Bearbeitung betrifft nur mich allein. Aber der Vollständigkeit halber schreibe ich es auf. Es schadet ja nicht.

Mit dem Beginn einer Anmeldung oder Registrierung wird ein Session-Cookie
gesetzt, der dazu dient, den Nutzer bis zur Abmeldung wieder zu erkennen.
Dieser Cookie wird automatisch gelöscht, wenn der Browser geschlossen wird.
Eine Speicherung des Cookies auf Serverseite erfolgt nicht.

Für angemeldete Nutzer können weitere Cookies gesetzt werden,
um verschiedene Workflows technisch umzusetzen. Eine Speicherung dieser
Cookies auf Serverseite erfolgt nicht.

Nur für administrative Aufgaben ist eine Anmeldung notwendig,
die normale Nutzung erfolgt generell ohne Anmeldung. 

Und schon wieder fertig.

Externe Server

Warum mache ich das eigentlich? Weil ich es allein kann. Ich bin schlicht nicht in der Lage, abertausende von Besonderheiten von Browsern in verschiedenen Konfigurationen korrekt mit einem gewünschten Style zu beliefern. Ich kann das auch nicht mal eben kopieren, weil die Auslieferung ja browserabhängig ist. Und selbst wenn ich kopieren könnte, darf ich das überhaupt? Ganz zu schweigen davon, daß ich es nicht aktuell halten könnte. Deswegen binde ich diese Inhalte ja extern ein, von jemanden der es kann.

Grundsätzlich werden alle Inhalte direkt vom Server ausgeliefert.

Eine Einbettung externer Inhalte erfolgt automatisch dann, wenn die Inhalte
technisch nicht lokal bereit gestellt werden können. Dies betrifft generell die
browserabhängige Bereitstellung von Javascript/CSS/Font-Daten für eine
einheitliche Darstellung der Webinhalte. Typischerweise werden diese Daten
vom Browser gecached und nur einmal direkt geholt. Eine Korrelation zwischen
den einzelnen Webseiten-Besuchen und dem Nachladen dieser Ressourcen
ist also nicht zwingend gegeben.

Soweit so klar. Was ist mit Videos? Ich nehme gern mal ein Video auf und lasse es von YouTube streamen. Warum? Weil ich es lokal nicht kann. Der Aufwand wäre unverhältnismäßig.

Fallweise können auch Videos einbettet sein, um auf die nur extern
vorhandenen Streamingressoucen zugreifen zu können. 

Warum ist das alles überhaupt erwähnenswert? Weil es den Nutzer dazu bringt, evtl. Daten an Dritte weiter zu reichen.

In all diesen Fällen sendet der Browser des Besuchers selbst
entsprechende Daten an den jeweiligen externen Server.

Fertig.

Interaktive Inhalte

Jetzt ist meine Spielwiese dran. All die schönen Tools.

Es wäre sinnfrei, jedes Tool im Detail zu erklären. Dazu kommt, daß die meisten Tools komplett im Browser des Nutzers ablaufen. Schließlich will ich die Last ja nicht auf meinem Server haben.

Auf der Webseite können interaktive Inhalte angeboten werden.
Diese werden – soweit technisch möglich – als Javascript im Browser des Nutzers ausgeführt.

Unglücklicherweise kann Javascript nicht beliebige Dinge im Browser machen und braucht externe Informationen, die es nur vom ausliefernden Server bekommen kann (Same-Origin-Policy). Diese Zugriffe sind zu dokumentieren. Sie unterscheiden sich aber nicht wesentlich von normalen Zugriffen.

Werden bestimmte Inhalte dynamisch auf der Serverseite ermittelt,
so wird grundsätzlich kein weiteres Log über diese Aktionen geführt.
Beim Auftreten von Verarbeitungsfehlern können zur Fehlersuche
beliebig detaillierte Logs geführt werden. Diese werden automatisch
nach sieben Tagen gelöscht.

Und dann habe ich noch Scantools, die selbst aktiv nach außen greifen.

Einzelne aktive Inhalts können auch selbst Zugriffe auf andere
externe Ressourcen durchführen, z.B. einen Sicherheitsscan über
vom Nutzer definierte Netzbereiche.

Fertig.

Kommentare

Was gibt es persönlicheres an Daten als nutzergenerierte Inhalte? Die will ich haben, denn die machen die Würze eines Blogs aus.

Es ist grundsätzlich möglich, bereit gestellte Inhalte zu kommentieren.
Diese Kommentare sind öffentlich einsehbar und werden
von Suchmaschinen indiziert.

Wenn man einen Kommentar schreibt, will man diskutieren und agiert als handelnde Person. Welche Persönlichkeit man darstellen will, ist dabei egal. Darüber hinaus habe ich aber auch mit Mißbrauch und Rückfragen zu tun. Da möchte ich neben dem öffentlichen Kommentar auch direkt kommunizieren können. Und anhand der IP, der einzigen Information die man nicht beliebig wählen kann, möchte ich auf schweren Mißbrauch reagieren können.

Bei der Erstellung eines Kommentars wird der Nutzer gebeten,
seinen Namen und seine E-Mail-Adresse anzugeben.
Die Angabe eines Weblinks ist optional.

Der angegebene Name und die optionale URL werden zusammen
mit dem Kommentar angezeigt. Dies dient der Verbesserung
der Kommunikation, da dies die Zuordnung der Beiträge in einer
Diskussion ermöglicht. Der Name und die URL werden nicht validiert.

Die E-Mail-Adresse wird nicht angezeigt. Sie dient ausschließlich
der Kontaktaufnahme mit dem Kommentator zu administrativen
Zwecken. Sie wird bei der Eingabe nicht validiert.

Die IP Adresse des Kommentators wird automatisch erfaßt und wie
die anderen Angaben zusammen mit dem Kommentar gespeichert.
Dies dient dazu, einen Kommentar zweifelsfrei einer Quelle zuzuordnen.
Diese IP wird herausgegeben, wenn Strafverfolgungsbehörden anfragen.
Darüber hinaus wird die IP herangezogen, um automatisch
Kommentarspam zu blockieren.

Da hier nun erstmals und im engeren Sinne personenbezogene Daten verarbeitet werden, sollte man auch über Korrektur- und Löschmöglichkeiten informieren.

Es besteht kein Anspruch auf Veröffentlichung von Kommentaren.
Kommentare werden administrativ gelöscht, wenn sie störend oder
themenfremd sind. Eine manuelle Löschung von Kommentaren ist möglich,
wenn die Löschanfrage mit der passenden E-Mail-Adresse abgesendet wurde
und die Löschung nicht einen thematischen Zusammenhang zerstört.

Klingt schräg? Mag sein, aber ich lasse mir nicht vorschreiben, was ich bei mir zu veröffentlichen habe. Des weiteren habe ich auch einen dicken Hals bei Personen, die Geschichtsklitterung betreiben wollen. Da müssen dann schon ernsthaft triftige Gründe her, um die Abwägung zugunsten einer Änderung oder Löschung ausschlagen zu lassen.

Beschwerde

Da man sich schlecht bei mir selbst über mich beschweren kann, stellt sich die Frage, wer mir denn auf die Finger schauen darf.

Für einen eigenen Datenschutzbeauftragten bin ich … Hallo? Vergeßt es.

Trotzdem muß ich herausfinden, wer für mich zuständig ist. Denn das kann man im Fall einer Beschwerde kaum dem Nutzer überlassen. Er wird sonst von Pontius zu Pilatus geschickt und kommt nie an der richtigen Stelle an.

In meinem Fall ist das einfach: Der Landesdatenschutzbeauftragte.

Bei Beschwerden wenden Sie sich bitte an den Thüringer Landesbeauftragten
für den Datenschutz und die Informationsfreiheit (TLfDI).

Den werde ich dann noch bei meiner zuständigen Aufsichtsbehörde (TLfDI) formgerecht melden.

Noch Fragen?