Getagged : Hardware

Problem durch die Zukunft

Mich ereilte vor Feierabend heut ein dringender Ruf eines Kunden (ältere Generation). Die Anmeldung an seiner Arbeitsstation, welche sich in einer Domäne befindet, war ihm nicht möglich. Über Fehlermeldungen schwieg der Kunde sich aus, dennoch sollte sich jemand unbedingt jetzt sofort und am besten schon vor 5 Minuten dem Problem annehmen.

Da eh fast Feierabend war (Elternzeit) fuhr ich auf dem Weg nach Hause bei dem Kunden vorbei, startete den Rechner und bekam nach versuchter Anmeldung die Meldung, dass auf Grund unterschiedlicher Zeiten zwischen dem Client und dem Server eine Anmeldung nicht möglich sei.

Ich schaute den Kunden an und fragte, ob er die Systemzeit des Rechners geändert hätte. Wie zu erwarten bekam ich die Antwort: “Selbstverständlich nicht!”. Ich startete den Rechner erneut und begab mich ins BIOS und dort zur Abteilung Datum/Uhrzeit und ich erblickte 18.06.2009!

Ich: “Arbeiten Sie gern in der Zukunft?”
Kunde: “Wieso?”

Ich: “Da die Zeit des Rechners auf in 4 Monaten gesetzt ist …” – speicherte die Konfiguration mit korrektem Datum ab und startete den Rechner neu.

Kunde: “Wie passiert denn das?”
Ich: “Was haben Sie denn beim letzten Mal getan?”

Kunde: “Ich habe Termine koordiniert – dazu klicke ich immer rechts unten auf die Uhrzeit und schaue nach, an welchem Wochentag der Termin stattfindet.”
Ich: “Und dann?”

Kunde: “Wenn der Termin bestätigt wird, trage ich ihn in den Kalender in Outlook und schließe danach das Fenster mit ‘OK’.”
Ich: “….”

Ich: “Und hatten Sie rein zufällig gestern einen Termin vereinbart für den 18.06.2009?” 
Kunde: “Ja, wieso?”

Ich: “Weil Sie damit die Systemzeit des Rechner geändert haben …”
Kunde: “…..”

Ich habe ihm dann noch schnell erklärt, wieso diese Art der Methode nicht sonderlich die Beste ist, um Termine abzustimmen und zeigte ihm, dass er auch ruhig den Kalender in Outlook nutzen könne, um herauszufinden, an welchem Tag welcher Wochentag ist. Zusätzlich bekommt er auch die Information, ob er an diesen Tag bereits Termine hat. Somit würde er auch nicht mehr versehentlich die Uhrzeit und das Datum des Rechners ändern.

Der Kunde war fassungslos – über sein unbedarftes Verhalten. Ich beruhigte ihn, da ja nichts passiert wäre. 

Kunde: “Sie sind aber deswegen extra zu uns gekommen … wegen so einen Fehler meinerseits …”
Ich: “Auch das ist mein Job – und wie Sie sehen, können wir auch einige Probleme durch die Zukunft lösen …” ;-)

Ich: “Übrigens – ich wünsche einen schönen Feierabend und selbstverständlich geht diese Runde aufs Haus – versteht sich von selbst …”

Hintergrund: Ursache des Problems liegt in den unterschiedlichen Datumseinstellungen des Servers und des Client innerhalb einer Domäne. Bei Versuch der Anmeldung des Clients am Server wird ein Kerberos Ticket erzeugt. Dies beinhaltet auch, dass ein Zeitunterschied zwischen beiden Systemen nicht mehr als 5 Minuten (laut Erinnerungsstand) betragen darf. Ist dies dennoch der Fall, dann ist das Ticket ungültig und der Nutzer (auch der Domänenadministrator) kann sich nicht anmelden.

Man kann nun sich als lokaler Admin anmelden und das Datum ändern – man kann aber auch, wenn man Zugriff auf das BIOS hat, das Datum im BIOS ändern. Danach sollte eine Anmeldung an der Domäne funktionieren. Wenn nicht, dann sollte man die Einstellung bezüglich Sommer-/Winterzeit beachten (herausnehmen, bzw. setzen). Mir ist es bisher zweimal untergekommen, dass einer der beiden Parteien (Server bzw. Client) den Haken gesetzt hatte, der andere nicht. Somit bestand trotz augenscheinlich gleicher Zeit und Datum eine einstündige Diskrepanz, welche ergo auch dahingehend führt, dass der Server die Anmeldung des Client verweigert.

 

Der Verdammnis entronnen

Ich gräme mich schon einige Tage damit, dass bestimmte Bouquets des hiesigen Kabel-Betreibers RFT kein Bild mehr lieferten. Laut Anzeige von EyeTV war Signal vorhanden und das auch noch zu 100% Qualität, aber es kam kein Bild, geschweige denn überhaupt Ton. Lediglich die Meldung “Dieser Sender ist zur Zeit nicht verfügbar” wurde mir mittels EyeTV mitgeteilt. Es funktionierten ansonsten alle Frequenzen, außer die, der angeprangerten Sender.

Heute hatte ich den Kanal sprichwörtlich langsam voll, denn die Sender waren immer noch nicht erreichbar, meine Aufnahmeliste schwoll ins Unerdenkliche auf jenen Sendern an und diesen Schwall des Grams, der nicht funktionierenden Aufnahmen und der Gedanken höllischer Natur wollte ich erneut dem Support überhelfen, als ich sicherheitshalber meine beiden DVB-C Empfänger von Digital Everywhere vom Strom nahm. Ebenso trennte ich vom Mac mini die Firewire-Verbindung.

Resultat? Die Sender gehen … mir persönlich nicht begreiflich, wieso 2 Frequenzen nicht gingen, aber die anderen doch .. aber alle Sender funktionieren nun wieder. Irgendeine Logik? Ich denke nicht.

Zumindest ist RFT der Verdammnis entronnen … diesmal!

Genaue Fehlerbeschreibung

Zum Glück hatte ich heute nichts Wichtiges vorgenommen, denn ansonsten hätte der Kunde !heute! alt ausgesehen. Um 19.00 Uhr bimmelt mein Telefon, während wir uns gemütlich eine Folge Babylon 5 ansehen. Ein Angestellter des Hotels lässt verlauten, dass ein Rechner, der mitunter wichtig ist (wie alle Rechner), ständig die Netzwerkverbindung trennt und wieder aktiviert und somit ein Arbeiten im Netz, sprich mit über das Netz laufende Betriebsanwendungen, nicht möglich ist. Somit sind die Buchungen, Bestellungen, Reservierungen usw. – sprich der gesamte Hotelablauf nicht möglich.

Auf meine Frage, ob es nur diesen Rechner betrifft, erhalte ich ein definitives “JA”. Das schränkte für mich das Problemfeld auf den Rechner ein – ergo Kabel oder Netzwerkkarte. Ich rückte also von zu Hause in die Firma raus, um Netzwerkkarten und Werkzeug zu holen und hottete dann zum Kunden. Dort angekommen wollte ich gerade mich ans Werk machen, begutachtete schon das Problem (welches sich ohne Vorführeffekt auch mal zeige), als ich noch einmal sicherheitshalber nachfragte, ob das Problem wirklich nur an diesem Rechner auftritt.

Natürlich erhielt ich dann die Aussage, dass sich das Problem auch auf andere Rechner ausgeweitet hätte. Dieses Problembild ist natürlich vollkommen anders und schließt als Erstes ein Problem mit einer Netzwerkkarte eines Rechners aus – Murphy schlägt nicht ohne Weiteres so schlimm zu. Es ging daraufhin in den Keller, denn mir schwante schon Übles. Ich begutachtete die Switche eine Weile und an einem Port fiel mir auf, dass dieser alle paar Minuten komplett dunkel wurde, bis er darauf wieder mit voller Last kommunizierte. Wenige Augenblicke später war die LED des Ports wieder aus und so weiter und so fort.

Ich verfolgte das Kabel, welches auch prompt ins Nirvana verschwand. Die Kabeldokumentation war schlichtweg nicht existent und ich hatte schon den Switch in Verdacht. Ich spielte das Ganze gedanklich, als auch verbal durch und der Angestellte meinte darauf hin, dass oben unter dem Tisch nachträglich auch so ein Switch angeschlossen wurde.

Also wieder hoch und quer durch das Hotel gestiefelt und den “neuen” Switch dort unter die Lupe genommen und siehe da: dieser meinte alle paar Minuten einen Reset durchzuführen, welcher dazu führte, dass die Rechner ihre Verbindung zum Netzwerk verlierten. Klasse Sache! Er war übermäßig heiß und das Problembild und die Begleiterscheinungen passten wie die Faust aufs Auge.

Auf ins Auto, zurück in die Firma und einen passenden Switch gesucht und in Windeseile wieder zurück, angeschlossen und alles funktioniert wieder. Fertig war ich dort kurz vor 22.00 Uhr. Die Hin- und Herfahrten und das “falsche” Suchen des Problems forderten ihre Zeit. Aber wäre die später zugetragene Info, dass alle Rechner in einem Bereich davon betroffen sind, früher gekommen, hätte ich schon vorher einen passenden Switch mitgebracht. Das hätte knappe 50 Minuten Zeit einsparen können. Interessant war dann zu erfahren, dass sie schon knappe 2 Wochen das Problem hatten. Nur kristallisierte sich es in Form von Programmaussetzern, temporären Datenfehlern oder allgemeinen Problemen bei Netzwerkzugriffen.

In diesem Sinne – ein schönes und “arbeitsfreies” Wochenende!

Darum Dell …

Keine Gefahr, da verboten

Welche Drogen muss man genommen haben, um in meinen Augen, massive Sicherheitslücken so wischiwaschi mit nichtssagenden Sprachblasen aus der Welt schaffen zu wollen?

Das DECT Forum  die Kerle, die den DECT Standard für schnurlose Telefone “entwickelt” haben, hatte eine Stellungnahme zur gelungenen Abhörmöglichkeit von Gesprächen veröffentlicht. Ich fasse mal zusammen: Da das Abhören von Telefongesprächen eine Straftat darstelle, sei es nicht möglich, Telefongespräche zufällig abzuhören. Nur Personen, die mit krimineller Energie und Absicht handeln sowie über detaillierte technische Kenntnisse und Ausstattungen verfügen, sind überhaupt in der Lage, Gespräche abzuhören.

Was hat das Eine mit dem Anderen zu tun? Zufällig passiert dort eh nichts und wer Mithören will, der schreckt auch vor der Strafe nicht zurück. Wenn mein Nachbar das technische Know-How besitzt und einfach Spaß dran hat mitzulauschen, dann wird er es auch tun. Da muss nicht einmal gesonderte kriminelle Energie dahinterstecken – Neugierde reicht aus. Das Risiko erwischt zu werden ist doch eh bei null. Und was mit detaillierte technische Ausstattung gemeint wäre, verstehe ich auch nicht, wenn das Forscherteam dahinter eine einfache kostengünstige Laptop-Karte und Linux einsetzte.

Wenn ich mir das Ganze durchlese, dann ist im DECT-Standard eine Menge faul. Aber es besteht ja keine Gefahr belauscht zu werden – schließlich ist es ja verboten. Politsprech in Perfektion auf dem Weg in die Wirtschaft und alle Welt glaubt es …

 

HomeNAS

Nachdem nun die halbe Sippschaft der allgemeinen und speziellen GGRS (gelbglänzende Rüsselseuche) heimgefallen ist, war hier und da am Wochenende Zeit, mich dem Thema NAS erneut zu widmen.

Ich habe unterschiedliche Distributionen getestet. Zum einen Ubuntu Server, welches aber umgehend wieder von der Platte verschwand. Zum anderen testete ich FreeBSD. Mit Hilfe guter Anleitungen und dem Wiki von FreeBSD, ist es mir binnen kurzer Zeit gelungen die Basis eines NAS nachzubilden. Mit Hilfe von Samba und AFP (via Netatalk) hatte ich mein HomeNAS von außen zugriffig.

Nachdem ich aber Stunden damit verbracht hatte, mittels CUPS den bei uns herum oxidierenden Drucker bereitzustellen, habe ich frustriert das Handtuch geworfen und somit die Grundbedingung Druckdienste verworfen. Die Folge war, dass ich mich weiter umgesehen hatte: wieder hin zu FreeNAS. FreeNAS bietet von Haus aus all das, was für ein NAS benötigt wird. Damit ich nach meinen Tests nicht erneut alles über den Haufen werfen musste, da ich noch nicht die endgültige Konfiguration im HomeNAS bewerkstelligt hatte, zog ich die Fertigstellung der Finalkonfiguration vor. Weiter lesen …