jtb.blog

Seit Sonntag bin ich nun in Tokio. Nach zwölf Stunden Flug zuzüglich acht Stunden Zeitumstellung, eine Stunde Schnellzug und einer eher langen Suche bin ich im Hotel ins Bett gefallen. Tokio hat zwei Flughäfen: Haneda und Narita. Letzterer ist weiter draußen und liegt eigentlich in einer anderen Präfektur. Dank Schnellzug (Narita Express - oder kurz N'EX) kommt man aber mit unter einer Stunde Fahrtzeit gut nach Tokio.
Natürlich gibt es auch andere Alternativen (Bus, Skyliner), aber ich habe mich für den N'EX entschieden. Neben der Fahrtzeit hielt er auch an einer Station in Nähe zu meinem Hotel. Zusammen mit dem N'EX Ticket habe ich die Suica Karte geholt. Dies ist im wesentlichen eine RFID-Karte für das Nahverkehrssystem. Dank Handy mit RFID kann ich diese sogar auslesen und jede einzelne Fahrt inkl. deren Preis angezeigt bekommen. Ein echt nettes System - zumal man dadurch schneller durch die Ticketgates kommt. Ansonsten müsste man entweder ein Tagesticket kaufen oder für jede Fahrt ein Ticket kaufen - und das kann ein wenig umständlich werden.


Zuerst fällt einem in Tokio die schiere Größe der Bahn/Metrostationen auf. Nicht den richtigen der teilweise über 30 Ausgängen genommen? Tja, dumm gelaufen - dann muss man lange Strecken zurück laufen. Wer denkt, dass Stationen in Frankfurt wie die Hauptwache/Konstablerwache groß ist: diese sind im Vergleich teilweise echt klein. An den meisten Metro Wegweisern wird ausgeschildert wie weit der Bahnsteig für eine bestimmte Linie weg ist - 500m oder mehr sind keine Seltenheit. Auch kann es vorkommen, dass man aus einem Ausgang raus geht und auf der anderen Straßenseite ist immer noch die Station und wieder ein Eingang. Interessant wird es auch wenn es eigentlich zwei Stationen sind und auch unterschiedliche Namen haben, aber unterirdisch miteinander verbunden sind.

Getoppt wird es nur vom Eindruck der Größe mancher Straßenkreuzungen. Shibuya Crossing ist - sobald die Ampeln umspringen - ein wirrer Menschenhaufen. Dennoch funktioniert das Chaos und man kommt auf die andere Straßenseite. An vielen öffentlichen Plätzen werden dann noch die Menschenmassen gelenkt - viele Treppen sind eingeteilt in einem Bereich für "hoch" und einen für "runter". Ansonsten würde auch das ganze System nicht funktionieren. Ich glaube, ich werde zurück in Deutschland die meisten Plätze und Bahnen als leer empfinden... Gerade wenn man denkt, der Zug ist aber voll, pressen sich an der nächsten Station nochmal etliche Leute rein. Ich bin gespannt wie es aussieht, wenn ich in ein paar Tagen Tokio verlasse und mich erst nach Kyoto/Osaka oder Hakone aufmache.

Ich habe ab Ende März ein wenig Urlaub und da ich seit langem mal wieder verreisen werde, habe ich mir vorgenommen ein wenig zu berichten. Vielleicht gibt es ja sogar noch Leser hier

Los geht es am 22. März - ankommen am Ziel werde ich aber erst am 23. März. Viel Spaß beim Mitlesen. Und sollte ich es dennoch vergessen, haut mich einfach an.

Ich wurde vor ein paar Tagen auf das "Elektronisches Gerichts- und Verwaltungspostfach" (auch kurz EGVP) von einem Anwalt angesprochen. Details zum EGVP von Wikipedia.

Eben habe ich bei der Welt einen Artikel darüber gelesen, dass die hessischen Sozialgerichte nun flächendeckend damit arbeiten. Und wenn die Gerichte damit arbeiten, müssen die Anwälte es wohl auch.
Das kleine Zitat aus dem Artikel weckte dann meinen "Spieltrieb":

"Die dazu nötige Software ist kostenlos im Netz verfügbar", sagte Uwe Möller, ebenfalls vom Sozialgericht Darmstadt.

Eine kleine Suche ergab, dass die Software unter http://www.egvp.de/ verfügbar ist. Man beachte hier das fehlende https. Der Server ist offensichtlich nicht über SSL zu erreichen. Wer die Software runterladen will, muss also da drauf vertrauen, dass sich gerade niemand als so genannter Man-in-the-middle-Angreifer dazwischen setzt und einem einfach andere Software "unterjubelt".

Aber es kommt noch schlimmer: die Software kann im Download-Bereich heruntergeladen werden. Die Installation erfolgt über Sun Java Web Start (oder sollte ich besser sagen Oracle Jaca Web Start). Da ich schon ein Java installiert habe (Version 7), überspringe ich den Teil das JRE herunterzuladen und starte direkt den Download der Client-Software. Diese ist über folgende URL erreichbar: http://egvp.bremer-service.de/produktiv/egvpclient.jnlp

Dumm nur, dass der dann folgende Installer ein abgelaufendes Zertifikat nutzt:




The application's digital signature has expired.

Die Ursache ist eigentlich einfach: wie schon erwähnt habe ich Java 7 installiert. Dies führt dazu, dass bei Sun ein alter Installer geladen wird. Selbst wenn man die Sicherheitswarnung ignoriert, führt es dann zum Fehler - die Anwendung ist nicht lauffähig. Der Hersteller hat das zwar auf der Seite dokumentiert, dennoch hinterlässt schon der Anfang der Software - ihre Installation - einen Beigeschmack bei mir.

Hervorzuheben ist jetzt noch, dass Java 6 demnächst nicht mehr von Oracle supportet wird (siehe den Heise-Artikel dazu).
Das ist dem Hersteller auch bewusst und er schreibt dazu in der Installationsanleitung:

Achtung: Oracle stellt vorauss. zum Februar 2013 den Support für Java 6 SE ein und wird dann keine Sicherheitspatches mehr bereitstellen.
Dieser Umstand kann die für eine Signaturanwendungskomponente geforderte hohe Sicherheit gegen potenzielle Bedrohungen beeinträchtigen.
Soweit keine Sicherheitslücken bekannt werden, kann Java 6 weiterhin im EGVP genutzt werden.

Das heißt: auf etlichen Anwaltsrechnern in Hessen wird nun Java 6 installiert - obwohl es längst veraltet ist.

Wenn ich nicht gerade meine Master-Thesis schreiben würde, hätte ich wohl viel zum forschen, aber man muss Prioritäten setzen. Vielleicht gibt es ja andere da draußen, die sich EGVP anschauen wollen.
Und es gibt noch mehr. Versenden von PDFs? Die dann womöglich beim Richter oder Anwalt der Gegenseite ausgedruckt werden? Wie wäre es mit einem PDF, welches die Firmware vom Drucker ändert?

Seitdem ich im letzten Blogeintrag über den Bug in der Cisco ASA Software berichtet habe, ist einiges geschehen. Seitweise lief die Firewall auf eine Developer-Version (100.7(6)95). Jetzt läuft sie mit einem regulären Release (8.4(4)11) und zeigt sich wieder stabil.

Ursache war wohl ein fehlgeschlagener FIPS-Test. Dieser verwendete scheinbar eine ungültige Syslog-ID und damit verabschiedete sich die aktive Box.

Jetzt kämpfe ich nur noch mit Zertifikatsfehlern unter Linux und MacOS X wenn man die neuste Anyconnect-Version verwendet

Gruml, manchmal ist man richtig froh, dass man ein Cluster hat..

Da kann die eine Firewall (Cisco ASA 5585-X) gemütlich husten und rebooten und die andere übernimmt einfach..
Erst dachte ich es liegt an einem defekten Netzteil (offensichtlich ein Lüfterschaden), aber nachdem dann auch die andere Firewall mal aktiv war und abstürzte, ist es wohl offensichtlich ein anderes Problem

sh crashinfo meint:

Message #175 : assertion "cp_syslog_from_dp_context" failed: file "syslog.c", line 256

Jetzt ist erstmal der Support am Zug...

In einem Monat finden die mrmcd 2012 am Fachbereich Informatik der Hochschule Darmstadt statt.

Das genaue Programm kommt erst in ein paar Tagen, eine Preview findet sich schon online.

Der Eintritt für Studierende der Hochschule übernimmt das Zentrum für Angewandte Informatik e.V. Somit ist für unsere Studierenden der Eintritt kostenlos. Ihr müsst euch nur im Vorverkauf ein Ticket reservieren.

In den letzten Wochen hat sich was neues im Bereich ärztlicher Atteste an der Hochschule getan.

Zuerst einmal haben die Studierenden des Fachbereichs Informatik eine Diskussion im Fachbereichsrat angestossen. Dort wurde das Thema hitzig besprochen - wohl hitziger als von einigen erwartet

Kurz danach tagte der Senat. Dort brachte der AStA eine Resolution ein, die erfolgreich verabschiedet wurde:

Der Senat fordert in der Resolution, eingebracht durch der AStA, die Fachbereiche auf, zukünftig das Einfordern patientenbezogener Daten zu unterlassen. Weiterhin müssen ärztliche Atteste mit der Aussage "prüfungsunfähig" im Krankheitsfall zur Anerkennung ausreichen. In begründeten Einzelfällen kann ein amtsärztliches Attest eingefordert werden.

Quelle: www.asta-hochschule-darmstadt.de

Rückblickend war die Aktion im Fachbereichsrat also erfolgreich - manche Senatsmitglieder aus dem Fachbereich Informatik sind durch die vorherige Diskussion gut vorbereitet in den Senat gegangen

Über den Tellerrand seines eigenen Fachbereichs als Studierende zu schauen kann aus vielen Gründen hilf- aber auch lehrreich sein.

In den letzten Wochen kocht ein Thema immer mehr hoch - wie ein Fachbereich an der Hochschule Darmstadt bzw. dessen Prüfungsausschuss die Studierenden behandelt. Offensichtlich nach dem Wechsel des Prüfungsausschussvorsitzenden hat dieser den Ablauf beim Einreichen von einem Attest neu zusammengefasst online gestellt:

Sehr geehrte Studierende,

mit dieser Mitteilung will ich Sie über die Möglichkeiten und Grenzen eines nachträglichen Rücktritts von Prüfungen aufgrund von Krankheit informieren und Ihnen die Anforderungen insbesondere an ärztliche Atteste zum Nachweis der Prüfungsunfähigkeit aufzeigen.

Mein Vorgänger als Prüfungsausschussvorsitzender Prof. Dr. P. hatte hierzu schon Hinweise zur Vorlage ärztlicher Atteste an Sie gegeben und auf unserer Homepage veröffentlicht. Die angehängte Datei fasst nun alle alten Hinweise zusammen, ergänzt und ersetzt damit diese.

Eigentlich ist eine solche Festlegung ja eine schöne Sache. Der Studierende hat Sicherheit wie er sich ordentlich zu einer Klausur krankmelden kann. Natürlich stellt sich nun die Frage: warum spezifiziert das ein Fachbereich für sich? Gibt es dafür keine hochschulweite Regelung? In den allgemeinen Bestimmungen für Prüfungsordnungen (aktuelle Version) ist folgendes geregelt:

§ 16 Versäumnis, Rücktritt, Täuschung, Ordnungsverstoß
[..]
(2) Der für das Versäumnis, den Rücktritt oder das Nichteinhalten der Bearbeitungszeit geltend gemachte Grund muss dem Prüfungsausschuss unverzüglich schriftlich angezeigt und glaubhaft gemacht werden. Im Falle des Rücktritts oder des Nichteinhaltens der Bearbeitungszeit ist der Grund zunächst der aufsichtsführenden Person mitzuteilen und wird von dieser in den Prüfungsakten vermerkt. Im Krankheitsfall ist unverzüglich ein ärztliches Attest unter Angabe der voraussichtlichen Dauer der Prüfungsunfähigkeit einzuholen und vorzulegen. In Zweifelsfällen kann die Hochschule ein amtsärztliches Attest einfordern. Wird der geltend gemachte Grund anerkannt und die Prüfungsunfähigkeit seitens der Hochschule festgestellt, so wird ein neuer Prüfungstermin bestimmt; bereits erbrachte Leistungen können berücksichtigt werden. Ablehnende Entscheidungen des Prüfungsausschusses sind der Kandidatin oder dem Kandidaten unverzüglich schriftlich mitzuteilen, zu begründen und mit einer Rechtsbehelfsbelehrung zu versehen.

Und genau hier liegt das Problem. Wenn man diesen Punkt der ABPO mit der vorherigen Version vergleicht, erkennt man den Zusatz:

Wird der geltend gemachte Grund anerkannt und die Prüfungsunfähigkeit seitens der Hochschule festgestellt, so wird ein neuer Prüfungstermin bestimmt [..]

Dieser Zusatz kam übrigens auf Empfehlung der Justiziarin in den Entwurfsprozess und ist danach wohl nicht angezweifelt worden. Nach diesem Blick auf die ABPO wird die Entwicklung vielleicht deutlicher und fügt sich besser ins Gesamtbild ein.

Kurz zusammengefasst: der Prüfungsausschuss am Fachbereich Bauingenieurwesen glaubt pauschal keinem ärztlichen Attest mehr. Insbesondere die medizinische Auslegung, ob jemand Prüfungsunfähigkeit ist, wird nun von der "Prüfungsbehörde" vorgenommen. Aus den Erläuterungen:

Prüfungsunfähigkeit ist ein Rechtsbegriff, dessen Vorliegen von der Prüfungsbehörde festzustellen ist. Der Prüfling muss seine Prüfungsunfähigkeit ausreichend darlegen und beweisen.
Er alleine trägt die Darlegungs- und Beweislast. Es genügt somit nicht, ein ärztliches Attest mit der Aussage „arbeitsunfähig“ oder „prüfungsunfähig“ einzureichen.

Aber es wird noch toller:

Vielmehr muss das patientenbezogene, formlose tagesaktuelle ärztliche Attest die Gründe und Umstände aufzeigen, die es der Hochschule ermöglichen, über die Prüfungsunfähigkeit des Prüflings zu entscheiden. Der Prüfling ist hierbei verpflichtet alle Tatsachen darzulegen, die die Annahme einer Prüfungsunfähigkeit begründen können. Gegebenenfalls muss er hierzu die Ärztin / den Arzt von der ärztlichen Schweigepflicht entbinden.

Diese Aussagen muss man erstmal setzen lassen. Jeder Arbeitgeber hätte sofort eine Klage am Hals wenn er generell ärztliche Atteste nicht mehr glauben würde. Oder noch viel schlimmer: ein medizinischer Laie sich anmaßt Prüfungsunfähigkeit festzustellen. Die ärtzliche Schweigepflicht ist aus gutem Grund ein hohes Gut und sollte nicht für geradezu Trivialitäten verletzt werden. Aber hier ist es ja noch besonders - was gewinnt ein Studierender wenn er ein Attest einreicht? Er "gewinnt" einen Prüfungsversuch und gleichzeitig meistens ein Semester dazu. Hier argumentiert der Prüfungsausschuss mit der Chancengleichheit der Studierenden. Aber wo ist die Chancengleichheit beeinträchtigt wenn man sich sowieso ein paar Tage vor der Klausur abmelden kann? Wenn ein Studi es für nötig hält ein Attest zu besorgen um einen Versuch zu sparen, dann betrügt er sich im Ende nur selbst.
Natürlich ist es eine andere Situation wenn es um den letzten Versuch geht - aber ich persönlich halte es für untragbar, dass eine Hochschule ihre Studierende unter Generalverdacht stellt. Derzeit ist es ein Fachbereich, der die Tendenzen in der neue ABPO umsetzt. Es ist offen welche Fachbereiche noch folgen werden.

Zurückkommend auf den Tellerrand: der Fachbereich Informatik hat hier in meinen Augen schon 2005 eine faire und studierendenfreundliche Entscheidung getroffen:

Sind Studierende zu einer PL angemeldet und erkrankt, so reicht die unverzügliche Vorlage eines privatärztlichen Attests zusammen mit dem Wiederholungsantrag. Unverzüglich bedeutet, daß Antrag und Attest spätestens am auf den Prüfungstag folgenden Werktag durch den zu Prüfenden selbst oder eine Person seines Vertrauens abzugeben sind.

Ist der/die Studierende bei darauffolgenden Wiederholungsterminen derselben PL wieder erkrankt, so wird verlangt, dass ein amtsärztliches Attest zusammen mit dem vorgeschriebenen Antrag unverzüglich vorgelegt wird.

Hier sind in meinen Augen die Interessen ausgeglichen. Es bleibt zu hoffen, dass diese Regelung so bestehen bleibt.

Für die hochschulweite Regelung heißt es nun abwarten. Die Einsetzung einer Untersuchungskommission im Senat ist im ersten Anlauf "gescheitert". Nach dem Hinweis auf ein laufendes Gerichtsverfahren wollte man erst dieses abwarten. Nach meiner Meinung ein fataler Fehler: das Gericht prüft nur die rechtliche Komponente, aber nicht die moralische: den Generalverdacht aller Studierender einer Hochschule.

Noch vor ein paar Tagen war es Thema im Studierendenparlament, nun halte ich den Brief zur Sozialerhebung selbst in den Händen

Ein guter Anlass um ein wenig Werbung für die Sozialerhebung zu machen. Immerhin bezahlen alle Studis an der Hochschule Darmstadt (und auch an der TU Darmstadt) für eine detailliertere Auswertung..

Wofür die Sozialerhebung da ist, kann man unter www.sozialerhebung.de nachlesen - allerdings sind dort nicht die "Nebenwirkungen" erwähnt. Der AStA sowie das Studierendenparlament können die über die Erhebung erfassenden Informationen für ihre Entscheidungen nutzen. Brauchen wir mehr politischen Druck gegen die Wohnunsnot? Reicht das Bafög? Wieviele Studis müssen arbeiten gehen?

Im Endeffekt hat mich die Befragung 15 Minuten gekostet. Die Daten sind aber für alle beteiligten - vom Studentenwerk, zu der Studierendenschaft und auch den Hochschulen - sehr wertvoll. Also wenn ihr eine Einladung bekommt, dann füllt sie auch bitte aus
Falls die Fachschaften übrigens die Daten auch nutzen können: einfach beim AStA nachfragen

Ab und zu schaut man ja mal über die Grenzen des eigenen Fachbereichs - in der Vergabekommission der zentralen QV-Mittel (Mitteln für die Qualitätsverbesserung der Lehre und Studienbedingungen ) zu sitzen ist da echt hilfreich

Vor einiger Zeit haben wir Gelder für eine automatisierte Montageanlage genehmigt - vor ein paar Wochen war die feierliche Eröffnung und nun gibt es "Werbe"-Videos, die das Projekt vorstellen
Interessant ist nicht nur, was man mit QV-Mitteln erreichen kann, sondern auch, dass zwei Fachbereiche hier zusammen arbeiten. EIT für die Montagestraße an sich und der Fachbereich MN mit den Optotechnikern für die visuelle Überprüfung von Bauteilen.


AutFab: Automated Assembly Line
Launch of AutFab: Automated Assembly Line

Wie ich Ende des letzten Jahres schon geschrieben habe, war die Firewall des Fachbereichs in den Knien.
Seit nun ein paar Wochen ist die neue Firewall produktiv im Einsatz: eine Cisco ASA 5585-10.

Wie man an dem Lastgraph erkennen kann, gehört das alte Problem der Überlast nun endlich der Vergangenheit an.
Auf einmal gibt es keine Beschwerden mehr - das NFS hängt nicht mehr und auch die Softwareverteilung für die Labore führt nicht mehr zu spürbaren Nebenwirkungen

Der bisherige Rekorddurchsatz lag bei über 1,5 Gbit/s - und es ist noch Luft nach oben. Im Moment bremsen erstmal die Netzwerkkarten - bzw. bei der Softwareverteilung die Festplatten in den Desktopkisten.

... ist gestorben. In der letzten Woche ging meine erste SSD über den Jordan.
Gemerkt habe ich dies nur, weil ich zufälligerweise meine Backupprotokolle zuhause überprüft habe (das automatische Backupsystem hab ich damals nach dem letzten Festplattenausfall im Notebook eingerichtet).

Auf jedenfall waren die Meldungen nicht erfreulich:

rsync: read errors mapping "/usr/lib/x86_64-linux-gnu/libQtUiTools.a": Input/output error (5)
ERROR: usr/lib/x86_64-linux-gnu/libQtUiTools.a failed verification -- update discarded.
rsync: read errors mapping "/usr/lib/x86_64-linux-gnu/libQtUiTools.a": Input/output error (5)
rsync: read errors mapping "/usr/share/locale/pt_BR/LC_MESSAGES/vlc.mo": Input/output error (5)
ERROR: usr/share/locale/pt_BR/LC_MESSAGES/vlc.mo failed verification -- update discarded.
rsync: read errors mapping "/usr/share/locale/pt_BR/LC_MESSAGES/vlc.mo": Input/output error (5)

Der Kernel äußerte sich dazu wie folgt:

[121107.356700] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[121107.356703] ata1.00: irq_stat 0x40000008
[121107.356705] ata1.00: failed command: READ FPDMA QUEUED
[121107.356709] ata1.00: cmd 60/08:00:2e:67:22/00:00:01:00:00/40 tag 0 ncq 4096 in
[121107.356710] res 41/44:00:30:67:22/00:00:01:00:00/40 Emask 0x409 (media error)
[121107.356712] ata1.00: status: { DRDY ERR }
[121107.356713] ata1.00: error: { UNC ABRT }
[121107.357198] ata1.00: configured for UDMA/100
[121107.357206] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[121107.357208] sd 0:0:0:0: [sda] Sense Key : Aborted Command [current] [descriptor]
[121107.357212] Descriptor sense data with sense descriptors (in hex):
[121107.357213] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[121107.357219] 01 22 67 30
[121107.357221] sd 0:0:0:0: [sda] Add. Sense: No additional sense information
[121107.357224] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 01 22 67 2e 00 00 08 00
[121107.357229] end_request: I/O error, dev sda, sector 19031854
[121107.357241] ata1: EH complete

Sobald klar war, dass die SSD wirklich schuld ist und nicht etwa der SATA-Port an meinem Notebook, waren die nächsten Schritte einfach.
Zuerst einmal mussten die Daten (nochmals) gesichert und dann gelöscht werden - ein verschlüsseltes Home-Verzeichnis entspannt zwar, aber einmal Nullen drüber schreiben beruhigt noch mehr

Danach führte mich mein Weg zum Laden in der Stadt - ich kaufe solche Sachen absichtlich in einem lokalen Computerladen. Zwar muss dieser auch die SSD nun einschicken aber ich kann mit jemanden reden. Und bei 2-4 Wochen Dauer war die Entscheidung eine neue SSD zu kaufen recht einfach.. Somit hat der Ausfall auch ein gutes: die neue SSD ist doppelt so groß (und kostete nebenbei noch weniger als die alte).

Laut S.M.A.R.T. lief die SSD unter 8.000 Stunden mit knapp 2.000 Power-Cycles - recht stattlich für 21 Monate Lebenszeit. Ich frag mich nur wann SMART angefangen hätte aktiv zu warnen. Eigentlich wird dieses Feature ja immer als Schutz angepriesen. Bei über 20.000 reallocated Sektoren schon sehr komisch.

Am Donnerstag gab es die Möglichkeit einer Mensabesichtigung in der Schöfferstraße - das konnte ich mir natürlich nicht entgehen lassen. Eingeladen war der AStA, die studentischen Mitglieder im Verwaltungsrat sowie deren Anhang (sprich: weitere Interessierte)
Mit dabei war die Geschäftsführerin vom Studentenwerk Darmstadt, der stellv. Leiter für alle Mensen sowie die Mensaleitung Schöfferstraße. Ich durfte glücklicherweise mit Fotokamera rein - alle Fotos finden sich wie immer in der Fachschaftsgallery: Mensa-Besichtigung 2012.


Zu der Mensa habe ich nun eine gespaltene Meinung. Ich gehe eigentlich nicht so gern in die Mensa. In den Stoßzeiten ist die Mensa voll und man wartet. Der Vorteil, dass durch den kurzfristig höheren Durchsatz das Essen an der Ausgabe wärmer ist, wird vom Nachteil der langen Schlangen an den Kassen und dem somit schnell abkühlendem Essen kaputt gemacht.

Wenn man dann mal hinter die Kulissen schaut, merkt man aber was im Hintergrund abläuft. Zu erst einmal war ich überrascht wie klein der ganze Küchenbereich ist:

Schon die paar Besucher führen dazu, dass ein Koch kaum noch durchkommt - man passt quasi zu zweit nebeneinander in einen der Gänge.

Gesteigert wird das ganze nur noch durch die seperate Waschküche:


Man muss bei den Bildern bedenken, dass das alles nach einem erfolgtem Umbau ist. Und selbst jetzt muss man z.B. für den zweiten Fluchtweg in der Waschküche unter dem Laufband durchkrabbeln..

Interessant war auch zu erfahren wie einzelne Essen produziert werden. Für Pommes und andere frittierte Produkte gibt es zwei große Fritteusen. Die Pommes werden geschnitten im 10kg Pack geliefert - und zwar nicht als Tiefkühlfrost.
Bedingt durch den eingeschränkten Platz werden die Essen schon früh gekocht. Danach wird geputzt und in derselben "Großpfanne" das nächste Essen gekocht.

Neben dem Wissen wie es hinter den Kulissen aussieht, gab es aber noch andere positive Ergebnisse. Zum einen wird die Situation mit den Kassen geprüft - derzeit wird erst als dritte Kasse eine bargeldlose eröffnet. Dadurch entstehen natürlich die normalen Verzögerungen durch das Wechselgeld etc.
Zum anderen kann das Problem der Fachschaft eventl. gelöst werden: maschinenlesbare Mensa-Essenspläne. Derzeit wird die Webseite vom Studentenwerk mit einem Skript geparst um beispielsweise die Essensanzeige auf der Webseite der Fachschaft zu realisieren.
Auch erwähnenswert ist das Projekt die Feedbackpapierrollen in den Mensen zu ersetzen. Vorerst in Dieburg wird eine internetbasierte Feedbackmöglichkeit demnächst erprobt

Eine lange Ewigkeit kam ich nicht mehr dazu ein wenig zu bloggen. Dabei gab es eigentlich genug Themen, nur nicht genug Zeit - beziehungsweise keine Muse mich hinzusetzen und zu schreiben.
Mal sehen ob ich es in der nächsten Zeit kompensieren kann - vielleicht ist es aber auch egal weil keiner mehr mitliest

Beim Lesen ist mir fast das Mittagessen wieder hochgekommen. Ich habe folgenden Gastkommentar gelesen: Netzgemeinde, ihr werdet den Kampf verlieren! Wie kann einer unserer Volksvertreter auf dem Standpunkt sein, dass man heutzutage noch alles Wissen im Kopf haben kann? Ohne Google und Wikipedia wäre ich im Studium an einigen Stellen aufgeschmissen gewesen.

Versteht mich nicht falsch - ich mag auch "gebundene Bücher" aber diese sind für die Wissensvermittlung nicht mehr konkurrenzfähig. Da fragt man sich was des Pudels Kern des lieben Bundestagsabgeordneten ist. Sicherung des Wissensmonopols? Bürger sollen nur zitieren? Ist das nicht gerade Web 2.0? Selbst Inhalte schaffen und kollaborativ an einem Projekt mitwirken?

Ja, jeder soll auch mit geistigen Eigentum sein Leben bestreiten können, aber triviale Ideen zu schützen oder gar als Kinder/Enkel noch vom geistigen Schaffen der Eltern profitieren zu können, geht zu weit.

Ich stelle mir gerade die Analogie zum Buchdruck vor. Eine Erfindung, die es plötzlich ein Wissens- und Entwicklungssprung ermöglichte. Wie wäre wohl der "Gastkommentar" von unseren Politikern damals gewesen?

Aber wenigstens sieht er den Untergang schon kommen:

Jetzt haben wir noch die Zeit, diesem Treiben Einhalt zu gebieten.

Schon allein zu meinen, dass man die Welt in digital und real trennen kann, zeigt das grobe Missverständnis des Internets. Die Masse der Menschen sollen Dinosaurier sein? Bitte - zeigt dem Herrn doch mal Statistiken wie sehr das Internet genutzt wird. Vielleicht merkt er dann sein verzerrtes Weltbild - vielleicht umgibt er sich ja nur mit Dinosauriern...

Für wen ein Ausfall zentraler Komponenten keine Option ist, betreibt solche Systeme üblicherweise in irgendeiner Art High-Availability mit Failover.

Dass der Betrieb eines solchen HA-Systems mitunter nicht trivial ist, weiß jeder, der schon mal ein solches System betrieben hat. Probleme wie Split-Brain Situationen wo beide Systeme denken sie müssten aktiv sein, können spaßig sein.

Aus diesem Grund ist es gerade wichtig, dass die Administration möglichst einfach ist. Auf meiner Arbeit bin ich für ein Cisco ASA Active/Standby HA System verantwortlich.
Eigentlich weiß ich ja, dass Cisco nur die Konfiguration synchronisiert. Gerade beim Aufspielen von neuen Software-Versionen merkt man, dass der Flashspeicher nur lokal ist und nicht repliziert wird. Nicht schlimm - man hat sich im Rahmen des Upgrades dran gewöhnt jede Box einzeln zu versorgen.

Dummerweise verwende ich seit einigen Wochen ein neues Feature: Anyconnect VPN. Dies ist ein schöner VPN-Client, der die üblichen Probleme von IPsec (und damit verbunden: IKE) löst. Neben der neueren IKE-Version gibt es auch die Möglichkeit den Traffic über den https Port zu schicken - dadurch kommt das Anyconnect VPN durch viele Firewalls durch.

Nun zum eigentlichen Problem: im Gegensatz zu vielen weiteren Features legt dieses Feature die Konfiguration als Dateien im Flash-Speicher ab. Die GUI zum Verwalten der ASA legt diese Dateien natürlich nur auf der aktiven Box ab. Das ganze funktioniert dann eine Weile gut - bis es aus irgendeinem Grund zu einem Failover kommt. Sofort werden keine Anyconnect-Verbindungen mehr von der neuen aktiven ASA akzeptiert und die Benutzer beschweren sich.

Unangenehm - und vor allem vermeidbar. Eigentlich ist es nicht so aufwändig Dateien im Megabyte-Bereich synchron zu halten. Gerade wenn solche Auswirkungen entscheiden, frage ich mich was den Hersteller hindert solch ein nützliches Feature einzubauen

Der Fachbereich Informatik der h_da betreibt seit letzter Woche eine Sensor Node zum "Messen" des Internets. Das RIPE NCC (Réseaux IP Européens Network Coordination Centre) verteilt seit kurzem kleine Geräte die auf ersten Blick wie ein USB-LAN-Adapter aussehen. Nur ist der USB-Port nur dafür da die Stromversorgung für einen kleinen Baustein mit LAN-Anschluss der einen kompletten Linux-Server darstellt: ein XPort Pro.
Durch die Masse an s.g. Probes im RIPE Atlas Projekt ergibt sich ein genaueres Bild der Verfügbarkeit diverser Internetinfrastrukturdienste wie beispielsweise die weltweiten DNS-Rootserver.

Der ganze Ansatz ist besser als immer eine eigene Überwachungsinfrastruktur aufzubauen. Ich hätte beispielsweise in der Vergangenheit gerne eine externe Überwachung des Netzwerks gehabt. Auch die Hardware wäre kein Problem gewesen, aber ich hätte immer irgendwo Hosting einkaufen müssen.
Mit der RIPE Probe löst sich das Problem: ich trage nur die Stromkosten und muss Netzwerk für die kleine Box bereitstellen. Derzeit in der Betaphase ist ein neues Feature: User definied measurements. Damit kann ich angeben was bei mir überwacht werden soll - neben den Standards-Checks. Durch ein Credit-System wird gewährleistet, dass es ausgewogen bleibt. Überwachungen über die Probes der anderen durchführen kann nur derjenige, der selbst seine Probe zur Verfügung stellt.

Ich bin jedenfalls gespannt welche Features da noch kommen werden. Mit einer hohen Anzahl an verteilten Probes kann man irgendwann von einer Internet Sensor Cloud sprechen. Schon der aktuelle Versionsstand gibt neue Einblicke. Die Verfügbarkeit eines Servers weltweit? Weltweite Unterschiede zwischen IPv4 und IPv6 Latenz? Alles grafisch auf Google Maps dargestellt

Ein paar Tage nach der Installation zeigte sich schon der erste Nutzen: ich saß zuhause und stellte fest, dass ich die Hochschule nicht erreichen konnte. Bevor ich eine lange Analyse anfing, konnte ich einfach bei RIPE nachgucken und feststellen, dass unsere Node offline war. Ein paar Sekunden später konnte ich das Problem an den Provider der Hochschule weitergeben

Die letzten Tage habe ich mir Bulletstorm in Steam gekauft. Nach dem umfangreichen Download von knapp 7 GB kam ich heute endlich mal dazu das Spiel zu starten. Wie man es von Steam ja schon gewöhnt ist, kommt erstmal die Installationsroutine von benötigten "Anhängseln" der Spiele. DirectX, PhysX etc - nur Games for Windows - Live Client war mir neu. Gehört hatte ich davon schon mal, aber da ich keine Xbox360 besitze und ansonsten kein Spiel davor dies benutzte habe ich sowas nie benötigt.
Gleichzeitig zeigte mir Steam dann noch die Seriennummer für das Spiel an - leider immer ein schlechtes Zeichen, da dies in meinen Augen eine schlechte Integration in die Steam-Umgebung bedeutet.

Kaum war das Spiel gestartet, der nicht überspringbare Trailer ertragen, poppte anstatt des Spielmenüs eine Meldung auf man sollte sich doch mit seiner Live-ID anmelden. Da ich im Microsoft-Umfeld früher schon aktiv war, hatte ich natürlich eine Live-ID (früher Passport) parat. Sobald ich mich aber erfolgreich angemeldet hatte, Seriennummer eingegeben (glücklicherweise war Copy&Paste möglich) und mit dem Spielen loslegen wollte, kam die Meldung, dass der Live-Client aktualisiert werden müsste. Eigentlich hatte ich den doch gerade frisch installiert, also warum nochmal updaten? Da ich ansonsten nicht spielen konnte, müsste ich die Update-Prozedur über mich ergehen lassen. Ich solle doch bitte das Spiel schließen, damit das Update erfolgreich fortgesetzt werden könne, hieß es dann aber.. So langsam wurde meine Laune schlechter. Mein Gaming-Rechner hat keine SSD - hat somit längere Ladezeiten und ich war mir sicher, dass ich den Trailer wieder nicht überspringen kann.
Das Update lief nun durch und ich startete das Spiel erneut. Wie üblich wollte Steam die gerade erst frisch installierten Abhängigkeiten erneut installieren - ich frage mich ernsthaft warum die so lange brauchen einen solchen Bug endlich mal zu fixen. Also diesen Installationsdialog abgebrochen und das Spiel starten lassen.
Als ich dann im Spiel war (natürlich musste der Trailer angeschaut werden), versuchte ich mich erneut anzumelden. Obwohl ich das Häkchen bei Logindaten speichern gesetzt hatte, musste ich meine email-Adresse erneut eingeben - um dann festzustellen, dass das Passwort doch noch da ist. Nur das Häkchen "Automatisch anmelden" musste erneut gesetzt werden.
Daraufhin erschien die Meldung, dass meine Live-Id nicht mit einem Gamer-Tag verbunden sei und ich jetzt entweder abbrechen (sprich: nicht Spielen) oder die Anwendung einen Browser öffnen könnte, in dem ich mich dann registrieren sollte. Was lässt man nicht alles über sich ergehen um ein wenig Zocken zu können. Eigentlich will ich ja gerade zocken um den IT-Alltag zu entgehen und nicht um mich weiter damit aussetzen zu müssen. Glücklicherweise blieb das Spiel im Hintergrund offen... Schnell Vorname und Geburtstag eingetragen sowie das Default-Häkchen für Werbung weggeklickt und ich hatte nun einen Gamer-Tag. Zurück im Spiel musste ich mich erneut einloggen und wurde prompt wieder auf den Desktop zurückgeworfen:

In den "problem details" war dann zu lesen:

Problem Signature 09: System.DllNotFoundException

Den Fehlerbericht habe ich dann noch abgesendet, aber "No new solutions found". Natürlich erkannte das Spiel dies gleich als Problem und wurf mich auf den Title-Bildschirm zurück. Glücklicherweise konnte ich danach einfach in das Hauptmenü des Spiels gelangen und darf nun meine Aggressionen auslassen. Dies ist nun auch dringend notwendig.

Der geneigte Leser könnte nun sagen, ich solle einfach nicht mehr auf dem PC spielen und lieber die Spielekonsole nutzen. Während ich meine Wii gerade ausgeliehen habe, steht auf der PS3 auch schon wieder ein Systemupdate an...

Am heutigen Tag hat die "kleine" Cisco ASA 5520 gezeigt, dass sie nicht mehr unseren Netzwerkanforderungen am Fachbereich gerecht wird.

Einige Neuerungen am Fachbereich und steigende Erstsemesterzahlen sorgen für immer mehr Traffic. Der zentrale Fileserver am Fachbereich wird nun endlich intensiv genutzt und die Imageverteilung per Fog für Windows sowie FAI/Gosa für Linux sorgen für ordentliche Auslastung. Unser Hauptgebäude wurde in den Semesterferien mit neuen WLAN-Access Points ausgestattet und auf einmal sind die Sorgen aus den vergangenen Semester bezgl. lahmen WLAN vergessen. Durch die zusätzlichen Studierenden und den damit einhergehenden engeren Stundenplan (früher waren die Praktika schön verteilt, nun sind in den Hauptzeiten alle Labore gleichzeitig belegt) steigt die Last nur zusätzlich.

Glücklicherweise konnte ich mich vor einigen Monaten durchsetzen, Gelder beantragen und darf nun eine größere ASA bestellen. Schon beim ersten neuen Backbone-Switch mit 10Gb-Interface wurde ich fragend angeschaut. Nun kommt die 5585-10 mit 10Gbit-Interface (ok, die reine Firewallleistung liegt wohl bei 2-4 Gbit/s) dazu und auf einmal er gibt meine Planung hoffentlich für alle einen Sinn
Jetzt heißt es nur noch abwarten und die nächsten Wochen bis zur Lieferung durchhalten.

Irgendwie scheinen sich Cisco-Komponenten nicht so ganz mit VMWare zu vertragen.
Wer so ganz der Schuldige ist, weiß ich noch nicht. Jedenfalls scheint VMWare (zumindestens der Player) selbst bei einer Bridge-Netzwerkverbindung in die Pakete reinzupfuschen. Genauer: DHCP-Pakete werden modifiziert.
Während normalerweise bei einer Bridge die MAC-Adresse der virtuellen Maschine verwendet wird, wird das DHCP-Discover-Paket mit der MAC-Adresse des Hosts versendet. D.h. die MAC-Adresse auf Layer 2 stimmt nicht mit der Client-Adresse im DHCP-Paket auf Layer 7 überein. Eigentlich nicht so schlimm, wenn da nicht die Cisco-Geräte übel drauf reagieren würden.

Problem Nr 1
Die Cisco ASA meldet eine ARP Request collision:

Message: Received ARP request collision from x.y.45.150/0024.d700.0001 on interface WLAN with existing ARP entry x.y.45.150/000c.2900.0002

Allerdings ist alles korrekt - die virtuelle Maschine mit der MAC 000c.2900.0002 hat vom DHCP die x.y.45.150 zugeteilt bekommen und der Host (0024.d700.0001) eine völlig andere per DHCP.
Dieses Problem könnte man fast noch ignorieren - wenn nicht die Warnsysteme anschlagen würden und ein Ticket automatisch öffnen

Problem Nr 2
Das nächste Problem ist noch viel schlimmer. Diesmal ist nicht die Cisco ASA sondern ein Cisco Catalyst C3560-E die "störende" Komponente. Ohne DHCP-Snooping funktioniert alles wunderbar. Sobald man aber aus Sicherheitsgründen DHCP-Snooping aktiviert, bekommen virtuelle Maschinen keine DHCP-Antworten mehr. Das ganze völlig ohne Log-Eintrag oder irgendwelchen Hinweis vom Switch!

Erst Debugging vom DHCP Snooping zeigte mir den Fehler:

Nov 4 10:15:07.524: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/49)
Nov 4 10:15:07.524: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Gi0/49, MAC da: ffff.ffff.ffff, MAC sa: 0024.d700.0001, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 000c.2900.0002
Nov 4 10:15:07.524: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (1402)
Nov 4 10:15:07.533: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/6)
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: client address lookup failed to locate client interface, retry lookup using packet mac DA: ffff.ffff.ffff
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 000c.2900.0002
Nov 4 10:15:07.533: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Gi0/6, MAC da: ffff.ffff.ffff, MAC sa: 001d.a2AA.BBCC, IP da: 255.255.255.255, IP sa: x.y.45.254, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: x.y.45.150, DHCP siaddr: 0.0.0.0, DHCP giaddr: x.y.45.254, DHCP chaddr: 000c.2900.0002
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: client address lookup failed to locate client interface, retry lookup using packet mac DA: ffff.ffff.ffff
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 000c.2900.0002
Nov 4 10:15:07.541: DHCP_SNOOPING: can't find output interface for dhcp reply. the message is dropped.

Man erkennt hier wunderbar, dass die MAC-Adresse beim DHCP-Discover unterschiedlich ist. Das Antwortpaket wird aber korrekterweise an 000c.2900.0002 geschickt. Diese MAC-Adresse ist dem Switch aber unbekannt, da ja bislang kein Paket mit der Absender-MAC am Switch einging...


Jetzt ist nur noch die Frage wie Cisco auf die beiden Bugs reagiert...