Montag, 28. April 2008
Vor einigen Tagen wurde ich zu einem Kunden gerufen, der Probleme mit seinem "Server" hatte. In anführungszeichen deshalb, weil es sich um einen Arbeitsplatz-Rechner handelte, der in der Ecke stand und ein paar Freigaben im Netz publiziert hat.
Die Probleme des Servers waren schnell erkennbar, die ersten Sektoren der Festplatte waren komplett hinüber. Da sowieso eine neue Festplatte und damit eine Neuinstallation nötig war, habe ich gleich vorgeschlagen, das bisher eingesetzte Windows durch einen einfachen Linux-Server zu ersetzen. Windows-Dateifreigaben sind damit auch kein Problem und die Backups auf den im "Server" verbauten DVD-Brenner zu sichern dürfte mit K3B keine Probleme bereiten.
Ich entschied mich für Ubuntu 6.06 LTS. Das ist zwar schon etwas älter, wird aber noch eine Weile supported. Ich denke mal, in einigen Tagen kann ich dann gleich auf die neue 8.04 LTS aktualisieren. ich warte noch, weil ich denke dass es bestimmt noch Migrations-Probleme geben kann.
Dort arbeitet jetzt also seit etwa einer Woche ein Ubuntu-Server mit Samba und KDE/K3B zum Brennen von DVDs. Die Festplatte wurde durch einen Software-RAID-1-Verbund ersetzt, damit ein Platten-Ausfall erstens schneller bemerkt werden kann und zweitens vielleicht reparabel bleibt.
Der Kunde hat jetzt noch ein wenig Spaß, die knapp 40.000 Dateien, die von der Datenrettungs-Software des PC-Fachhändlers knallhart durchnummeriert zurück kamen inhaltlich zu bewerten und zu sortieren.
Mit dem Linux-PC ist der Kunde allerdings zufrieden, auch wenn es in seinem Tagesablauf keinen nennenswerten Unterschied zu vorher gibt.
Heute fiel mir eine sehr unschöne Sache bei .org-Domains auf. Registriert man eine solche Domain und setzt Nameserver-Einträge, die ebenfalls unter .org laufen, dann ruft die .org-Registry die IP-Adressen dieser Nameserver ab und speichert die. Diese werden dann zusammen mit der NS-Antwort als "Additional Section" an den anfragenden Client übertragen.
Das Ganze ist eine eigentlich nette Service-Leistung und klingt auf den ersten Blick plausibel.
Das Problem beginnt allerdings dann, wenn sich die IP-Adressen der Nameserver ändern. Bei uns wurde einer der drei Name-Server vor über einem halben Jahr entfernt und ein zweiter letzte Woche. Die .org-nameserver liefern aber noch immer unbeeindruckt die alten Adressen aus. Das führt dazu, dass unsere .org-Domains ohne unser Wissen jetzt nicht mehr nur schlecht sondern sogar sehr schlecht erreichbar waren.
Durch eine Änderung der Nameserver kann man erreichen, dass diese IP-Adressen neu angefragt werden. Wie man diesen Vorgang für die einmal irgendwann eingetragenen DNS-Server-Namen macht, ist mir schleierhaft.
Ich hatte mir heute den Tag über Gedanken über ein mögliches DoS-Angriffs-Szenario gemacht, aber kein wirkliches gefunden. Ich hab aber immer noch das Gefühl, dass man das DoS'en kann.
Dienstag, 29. Januar 2008
Wer einen Account auf einem Server hat, dem kommt ab und zu das Verlangen, sich in der Fremde einfach mal dort einzuloggen um eine vertraute Umgebung vorzufinden. Seit es um den perfekt konfigurierten »mutt« zu benutzen, schnell im »screen« dem laufenden »irssi« zu zu schauen oder einfach um eine vorher dort hinterlegte Datei zu lesen.
Praktisch ist es natürlich gefährlich, sich von einem nicht vertrauenswürdigen Rechner auf einem Server einzuloggen. Bei der Eingabe des Passwortes auf einem fremden Rechner besteht immer die Gefahr, dass ein böswilliger Admin, ein Schäuble oder die Werbeindustrie einfach alle Tastendrücke aufzeichnet und damit sehr einfach das Passwort für den sicher geglaubten Account erhält.
Um diesem Problem generisch, also für alle fremden Rechner brauchbar zu begegnen, gibt es Einmalpasswörter. Mit diesem Verfahren (das in etwa den TANs vom PIN/TAN-Onlinebanking nahe kommt), gibt es eine Liste von Passwörtern, die jeweils nur einmal gültig sind. Sind die verbraucht, sind sie ungültig.
Unter unixoiden Systemen hat sich dafür das S/Key-System einen Namen gemacht. Es läuft auf den meisten Plattformen und lässt sich sauber z.B. mit PAM einbinden. Das Verfahren ist sehr transparent und die Einmalpasswörter lassen sich mit dem challenge, das vom Server beim Login genannt wird auch extern berechnen. So braucht man keine Papier-Liste mitnehmen sondern kann z.B. mit einem Java-fähigen Handy die Einmalpasswörter (auf einem vertrauenwürdigen Gerät) errechnen lassen.
Sehr edel das ganze, daher haben wir das auch gleich auf schokokeks.org eingebaut. Als Anleitung verweise ich hier mal auf unseren Wiki-Artikel zu Einmalpasswörtern.
Sei noch erwähnt, dass es mehrere Möglichkeiten gibt, S/Key unter SSH zu benutzen. SSH bringt eine solche Funktionalität selbst mit (Gentoo-USE-Flag skey) und es gibt alternativ dazu das PAM-Modul pam_skey.
Wir haben uns für letztere Variante entschieden, da die SSH-Lösung für den Benutzer weniger transparent ist. Bei SSH wird erst nach dem normalen Passwort gefragt und wenn dies leer oder falsch ist, dann wird nach dem S/Key-Einmalpasswort gefragt.
Bei pam_skey dagegen wird, sofern der Benutzer skey für sich aktiviert hat, gleich nach »S/Key response or system password« gefragt. Ist skey für den Benutzer nicht aktiviert, wird das PAM-Modul einfach übergangen und das normale Passwort abgefragt.
Mittwoch, 2. Januar 2008
Mit unserer Firma bin auch ich direkt von der Vorratsdatenspeicheurng betroffen. Bei allem Aktivismus und berechtigter Kritik an der ganzen Sache, darf man aber meines Erachtens trotzdem die geltenden Gesetze nicht einfach ignorieren sondern jetzt, da das alles gilt, muss man es auch erst einmal beachten. Natürlich in der Hoffnung, dass das Bundesverfassungsgericht das alles wieder kippt.
Ich habe heute ungelogen einen Tag damit verbracht, das "Gesetz zur Neuregelung der Telekommunikationsüberwachung und anderer verdeckter Ermittlungsmaßnahmen sowie zur Umsetzung der Richtlinie 2006/24/EG vom 21. Dezember 2007" zu finden, zu lesen, die Bezüge zu recherchieren, herauszufunden was uns als E-Mail-Provider betrifft und das alles zu verstehen.
Ich möchte gerne die stellen aus den Gesetzen zitieren, die ich persönlich als einschlägig betrachte. ausdrücklich möchte ich darum bitten, dass jeder, der irgend etwas anders verstanden hat, also denkt, ich hätte etwas falsch aufgefasst oder übersehen, mir das bitte mitteilt. Zudem ist hoffentlich klar, dass von mir zu diesem Thema gegebene Kommentare jeglicher juristischer Sachkunde entbehren und die Gesetzes-Auszüge sich nicht eignen um sich darauf zu verlassen. das ist hier keine Rechtsberatung und so, klar.
ich verlinke an einigen Stellen zu www.gesetze-im-internet.de. Dort ist jetzt momentan noch die alte, nicht mehr gültige Version der Gesetze zu begutachten, das eignet sich aber gut um das Fließtext-Diff in oben verlinkter PDF-Datei darauf anzuwenden.
"Vorratsdatenspeicherung als E-Mail-Provider" vollständig lesen
Samstag, 10. Februar 2007
In einem hier nicht näher zu nennenden Web-Forum bin ich grade auf diesen Artikel gestoßen.
Suche managed Server
ca. 150 GB Webspace
linux-Confix
unlimidet Domains oder Accound einschaltbar
Unlimidet Subdomains
Traffic inklusive
unlimidet E-Mail-Postfächer
unlimidet MySQL DB
alles was Mann für Hosting braucht vor installiert. (Php,Mysql,usw.)
unkompliziert über 3. Namen (Ausländische) Domain registrierbar.
unter unlimidet verstehe ich auch genügend !!!
bis zu. 100 €
Samstag, 20. Januar 2007
Ja, Hanno sammelt grade Spam um statistische Analysen machen zu können damit unser Keks-Spamfilter besser optimiert werden kann.
Spammer finden dort viele neue Adressen.
[Kommentare sind hier deaktiviert, Feedback ggf. bei Hanno]
Montag, 4. Dezember 2006
Letzte Woche ist mir im Server meiner Eltern (Fax- und Dateiserver sowie Router und noch ein bisschen Kleinkram) die Festplatte gestorben und hat alle Daten darauf in die ewigen Festplatten-Jagdgründe genommen (Ja, ein nicht topaktuelles Backup war vorhanden).
Da ich also dann sehr schnell ein neues System gebraucht. Vorher war Gentoo installiert, aber da habe ich mich schon seit geraumer Zeit daran gestört, denn die Upgrades waren immer so heikel, da ich keinen physikalischen Zugriff darauf habe. Also wurde als Feldversuch der Server mit der Serverversion von Ubuntu-Linux eingerichtet. Installation war Ubuntu-Typisch in wenigen Minuten vorbei.
Die kranke Installationsprozedur von DJBdns war mir bekannt und hat mich folglich auch nicht so sehr schockiert. :)
Größtes Problem war, dass beim Aufstellen am späteren Einsatzort das NFS sich ganz komisch verhalten hat. Mozilla-Firefox und -Thunderbird ließen sich nicht starten weil sie angeblich schon laufen (nein, an den Lock-Files lag es nicht), KMail brachte wahllos Zugriffsfehler beim IMAP-Cache und ein sofort eingerichtetes Backup per rsync auf einen anderen Rechner führte oft zu der Meldung »stale NFS handles« und danach gab es nurnoch »permission denied« in dem Verzeichnis. Ein heraus und wieder hineinwechseln behebt das Problem kurzfristig.
Nach etwa einem Tag erfolgloser Suche und vielen Fragen an viele andere ratlose Leute, bin ich zufällig an diesen Bugreport herangestolpert.
Der dort vorgeschlagene Workaround hat bei mir funktioniert: Die Option »no_subtree_check« in alle exports-Einträge aufnehmen.
Bisher traten bei mir keine derartigen Probleme mehr auf.
Sonntag, 8. Oktober 2006
Neulich hat Hanno bei uns das MediaWiki auf eine neue Version geupdatet. Es war von 1.4.15 auf 1.6.8. Daraufhin war die Datenbasis mysteriös kaputt. Genauer gesagt haben manche Seiten gefehlt, manche waren steinalt und manche noch aktuell.
Zur Sicherheit habe ich dann von neuem die Update-Prozedur nochmal mit einem alten Backup der Datenbank nachgestellt und kam zu exakt demselben Ergebnis.
Nach einiger Zeit an Recherche in den Untiefen der Datenbank von MediaWiki habe ich festegstellt, dass sich einiges am Datenbank-Schema geändert hat. Bisher waren die Tabellen 'old' und 'cur' für die Inhalte zuständig, dort wurden die alten resp. die aktuellste Version jeder Seite aufbewahrt.
Im neuen Schema gibt es jetzt (eigentlich logischer) die Tabellen 'page', 'revision' und 'text', die Informationen zu den Unterschiedlichen Seiten, deren Versionen und den entsprechenden Texten speichern. 'page' verlinkt dabei immer auf die aktuelle Revision einer Seite.
Das Debugging hat nun ergeben, dass der update-Wizzard von MediaWiki aus irgendwelchen unerfindlichen Gründen die Datenbank nicht korrekt konvertiert hat. Es wurden Seiten vergessen oder alte Versionen als aktuell markiert.
Als Lösung habe ich ein Programm geschrieben, das die alte 'cur'-Tabelle ausliest und im neuen Datenbank-Schema eine neue Version jeder Seite mit dem Inhalt aus der alten Tabelle erstellt.
Der Einfachkeit halber konvertiere ich nur Artikel im Namespace 0, also normale Artikel.
"Spass mit dem MediaWiki-Upgrade" vollständig lesen
Dienstag, 29. August 2006
Ich habe einen LaserJet 5M, wie schon irgendwann mal hier erwähnt. Der gute ist per PostScript an mein Netzwerk angeschlossen und wird per CUPS benutzt.
Schon seit kurz nach dem Kauf habe ich das Problem, dass der Drucker manchmal und, wie ich fand, nicht reproduzierbar, den Job einfach abgebrochen hat ohne, dass im CUPS-Logfile oder am Druckerdisplay irgend ein Grund zu finden war. Ein kurzes "Processing Job" und dann der Rücksprung auf "Ready".
Wenn ich die Postscript- oder PDF-Datei dann auf den Server kopiert habe und dort ein "lpr" getätigt habe, hat es geklappt. Vielleicht war dies der Grund warum ich der Sache nicht so eifrig nachgegangen bin. Heute jedoch hat das Phänomen bei Nici auch Einzug gehalten als die Datei vom Server gedruckt werden sollte.
Einige Debug-Sessions später hatte ich (mit dem selben Postscript-Ausgangsmaterial) im Cups plötzlich einen Unterschied, der die Misere erklären konnte. Und zwar wurde bei Nici immer die PostScript-Option "Duplex=None" mitgegeben, bei mir nicht.
Die Frage war nun, warum ist das so und wer setzt diese Option. Per User!?
Antwort: ~/.lpoptions
Dort stand Duplex=None hinter dem Drucker-Eintrag. Hat KDE gesetzt.
Leider scheint der Drucker ohne Duplex-Einheit mit allem außer "Duplex=Notcapable" Probleme zu haben. Vielleicht verwirft er es, da die Duplex-Einheit diese Befehle auswerten müsste.
Jedenfalls lag es daran und ich hoffe, dass ich in diesem Eintrag genug Suchbegriffe eingestreut habe, sodass andere mit diesem Problem meine Lösung finden.
Freitag, 28. Juli 2006
yetzt hat mich grade netterweise an das da erinnert.
Danke. Und Bitte. Gern geschehen. :)
|