Zugschlusbeobachtungen - Hosting und Internet

Domain, Zone, Web- und Nameserver, Ägypten?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 18 Oct 2012 07:00:00 +0200

Aus aktuellem Anlass hier ein aus den wegen dummer Software derzeit unerreichbaren “Zugschlus’ manchmal nützlichen Antworten” schnell reingepasteter Artikel

Ungenaue Terminologie wird im Internet oft von Leuten verwendet, die zwar ungefähr wissen, wie die Dinge funktionieren, sich aber nicht im hinreichenden Maße mit den Hintergründen beschäftigt haben. Dies erschwert die Kommunikation und ist oft dafür verantwortlich, dass ein Auftragnehmer nicht das ausführt, was sein Auftraggeber eigentlich möchte.

Ein besonders von diesem Problem geplagter Bereich der Internet-Technik ist der Domain Name Service (DNS), da hier in besonderem Maße die Kommunikation zwischen verschiedenen Leistungsträgern in unterschiedlichen Unternehmen notwendig ist.

Mit diesem Text will ich versuchen, etwas Klarheit in die Terminologie zu bringen.

Was ist ein Nameserver?

Nameserver sind im Internet erreichbare Computer, die an der Namensauflösung beteiligt sind. Diese Rolle können die Rechner in verschiedenen Formen wahrnehmen:

Ein für eine Domain authoritativer Nameserver kann Anfragen für diese Domain authoritativ, also mit endgültiger Sicherheit, beantworten, weil er die Informationen für die Domain selbst vorliegen hat und sich hierbei nicht auf die Antworten anderer Nameserver verlassen muss.

Ein authoritativer Nameserver, der als Master (auch als “primary” bezeichnet) konfiguriert ist, ist ein Nameserver, der die Informationen für seine Domains von ausserhalb des Domain Name System erhält. Gängig sind hier beispielsweise Zonefiles oder Datenbanken. Ein Master, an den die Zone selbst nicht delegiert ist , wird als “hidden master” bezeichnet und kommt vor allen Dingen dort zum Einsatz, wenn der Domaininhaber zwar die Zone selbst unter eigener Kontrolle haben möchte, aber nicht hinreichend gut angebunden ist, um die Zone selbst zu sich delegieren zu lassen.

Ein authoritativer Nameserver, der als Slave konfiguriert ist, erhält die Informationen für seine Domains mit DNS-Mechanismen (Zone Transfer, AXFR oder neumodische IXFR) von einem als Master konfigurierten authoritativen Nameserver, der in der Konfiguration des Slaves festgelegt ist. Der Slave holt sich die aktuellen Daten für die Domain in regelmässigen Abständen oder auf explizite Anforderung vom Master und kann fortan auch dann für “seine” Domains authoritative Auskünfte erteilen, wenn der Master gerade nicht erreichbar ist. Wenn der konfigurierte Master für eine bestimmte Zeit nicht erreichbar war, stellt der Slave die Erteilung authoritativer Auskünfte für die betreffende Domain ein.

Erhalten die DNS-Server ihre Daten über andere Wege (z.B. über eine replizierte SQL-Datenbank), ist auch der Server, dessen DNS-Server auf einen SQL-Slave als Datenquelle zugreift, im DNS-Sinne ein Master.

An einen authoritativen Nameserver ist eine Zone delegiert, wenn dieser Nameserver in einem auf diese Zone zeigenden NS-Record in der “Parent Zone” auftaucht. Die in der Parent Zone eingetragenen NS-Records müssen mit denen in der Zone selbst übereinstimmen.

Ein Full Resolver oder auch Recursor ist ein Nameserver, der auch Anfragen entgegennimmt, für deren Domains er nicht authoritativ ist. Er bemüht sich dann, die benötigten Informationen aus dem DNS herbeizuschaffen und liefert eine nicht authoritative, “best effort” Antwort an den Anfragenden aus.

Die Nameserver, die ein Endbenutzer in seinem Rechner eintrögt oder (z.B. per PPP, DHCP oder DNSSD) zugewiesen bekommt, sind Full Resolver. Die von Endbenutzern beim Full Resolver ankommenden Anfragen sind sogenannte “rekursive” Anfragen.

Anstelle des Begriffs “Full Resolver” sind auch die Begriffe Full Service Resolver, Recursive Server, Recursive Resolver und Forwarder in Verwendung. Im Zusammenhang mit dynamischen Updates geniesst der Begriff Forwarder aber eine Sonderbedeutung, so dass dieser Begriff im Allgemeinen nicht korrekt verwendet wird.

Oft findet man bei kleineren Installationen die Funktionen eines authoritativen Nameservers und eines Full Resolvers auf einer Maschine vereint. Für die dort liegenden Zonen wird dem gesamten Internet authoritativ Auskunft erteilt, und zusätzlich werden rekursive Anfragen aus dem “eigenen” Netz beantwortet.

Diese Vereinigung von Aufgaben ist nach meiner Meinung nur in den seltensten Fällen sinnvoll, da sie nichts miteinander zu tun haben, die sachgerechte Konfiguration des Nameservers unnötig verkomplizieren und im Falle von Konfigurationsfehlern sehr leicht dazu führen können, dass die Benutzer des fehlkonfigurierten eigenen Nameservers eine andere Sicht auf das Internet haben als der Rest der Welt.

Was ist eine Domain, was ist eine Zone?

Der DNS ist eine verteilte, hierarchische Datenbank, in der die Namen und IP-Adressen aller im Internet sichtbaren Systeme hinterlegt sind. Ein Beispiel für die Hierarchie sieht man in der Abbildung.

Jeder Knoten im abgebildeten Baum ist eine Domain. Eine Domain, die im Baum unterhalb einer anderen Domain liegt, wird eine Subdomain genannt. Die Blläter des Baumes sind ebenfalls Domainnamen, wobei dieser Sonderfall auch als Hostname bezeichnet werden kann. mail.at.example.com ist also ein Hostname, eine Domain und eine Subdomain von at.example.com.

Die Wurzel des Baumes wird in der Literatur als “.” bezeichnet; die direkt darunter liegenden Domains (z.B. de, com, net, org) als “Top-Level-Domains” oder “First-Level-Domains”. Die “höchsten” Domains, die man als Unternehmen oder Privatmensch mit vertretbarem Aufwand selbst registrieren kann, sind die “Second-Level-Domains” wie zum Beispiel example.com.

Manche First-Level-Domains vergeben sogenannte "generische Second-Level-Domains". In diesen First-Level-Domains kann man dann erst Third-Level-Domains selbst registrieren lassen, die dann wie zum Beispiel in Grossbritannien unterhalb von co.uk oder or.uk liegen können.

Glücklicherweise ermöglicht der DNS, die Verteilung der Daten etwas von der Hierarchie unabhängig zu gestalten. Das ist insbesondere dann praktisch und wichtig, wenn Subdomains einer Domain unter unterschiedlicher Verwaltung stehen oder auch nur ihre Größe ungleichmäßig verteilt ist. Die Einheit für die Verteilung der Daten ist die Zone. Im Beispiel ist die Domain example.com und ihre Subdomains auf zwei Zonen verteilt. example.com ist an die im Beispiel rechts eingezeichnete Zone delegiert, die die Resource Records für www.example.com, at.example.com und die Domains unterhalb von at.example.com direkt selbst enthält. de.example.com ist an die im Beispiel links eingezeichnete Zone delegiert, die auf einem ganz anderen Nameserver liegen kann und von anderen zuständigen Personen verwaltet werden kann. Bei der weit verbreiteten Nameserver-Software bind liegen die Daten einer Zone stets in einer Datei, dem sogenannten Zone File.

Im Zone File werden schlussendlich die eigentlichen Einträge gemacht, die den DNS mit Leben füllen. Diese Einträge erfolgen in Form von Resource Records (RR), die einen Domainnamen mit Informationen verschiedenster Art verknüpfen. Wegen der Wichtigkeit dieses Stoffes wird es hierfür einen eigenen ZMNA-Artikel geben.

Der Weg vom Registrar zum Webserver

Eigentlich ist das alles ganz einfach. Gehen wir Schritt für Schritt vor für den üblichen Fall, dass K unter dem Namen www.example.com eine Webseite ins World Wide Web stellen möchte:

K bittet seinen Provider P, für ihn die Domain example.com zu registrieren.
P legt auf seinen Nameservern N1 und N2 eine Zone an, die die gewönschten Nameservice-Daten für die Domain example.com enthält.
P sucht sich einen der für die von K gewählte Top-Level-Domain (hier: .com) zuständigen Registrare R heraus und registriert über diesen die Domain example.com.
R trägt K als kaufmännischen Ansprechpartner (admin-c) und P als technischen Ansprechpartner (tech-c, zone-c) in der Domainregistrierungsdatenbank ein und sorgt dafür, dass in den für com zuständigen Nameservern die Zone für example.com an N1 und N2 delegiert wird.
Somit ist P nun in der Lage, weltweit sichtbare Resource Records für die Domain example.com im DNS bekannt zu machen.
P legt einen Webserver W für www.example.com an und gibt K die Möglichkeit, auf diesen Webserver die gewünschten Inhalte zu hinterlegen.
P trägt in der Zone für example.com die passenden Resource Records (hier: einen A- oder einen CNAME-Record) an, damit die IP-Adresse von W mit dem Domainnamen www.example.com verknüpft sind.

Von der Idee bis zum benutzbaren Webserver führten also die folgenden Schritte:

Registrierung der Domain.
Vorbereitung der Nameserver.
Delegation der Domain.
Vorbereitung des Webservers
Hinterlegung der Inhalte auf dem Webserver
Eintragung des Hostnamens www auf dem Nameserver

Diese Schritte können in den verschiedenen Geschäftsmodellen auf unterschiedliche Beteiligte verteilt werden. Oben beschrieben ist eine der üblichsten Vorgehensweisen, bei der der Kunde sowohl die Domain selbst, den DNS und den Webserver beim gleichen Liferanten bestellt.

Was für Einträge brauche ich in meiner frisch delegierten Zone?

Die Antwort auf diese Frage ist wie so häufig “es kommt darauf an”, nämlich darauf, was man mit der Zone eigentlich machen möchte.

Eine Zone muss immer und zwingend mindestens zwei Einträge enthalten: Einen SOA- und mindestens einen NS-Eintrag. Die NS-Einträge müssen mit den Einträgen in der “Parent Zone” (z.B. .com für .example.com) übereinstimmen.

Weitere Einträge sind nur dann notwendig, wenn die Domain wirklich benutzt werden soll:

Wenn die Domain im E-Mail-Verkehr verwendet werden soll, so sind MX-Records notwendig, die den Mailservern draussen im Internet bekannt geben, wo Mail an die Domain abzuliefern ist.
Hier sind wiederum andere Dinge zu beachten:
- Ein MX-Record sollte immer nur auf einen Rechnernamen zeigen, der wiederum als A-Record eingetragen sein muss. Insbesondere funktionieren hier keine IP-Adressen, und auf CNAMEs zeigende MX-Records sind mindestens umstritten.
- Ein MX-Record ist mit einer Priorität versehen. Ein externer Mailserver wird zuerst versuchen, Mail für die Domain bei dem Rechner abzuliefern, auf den der MX-Record mit der kleinsten Priorität zeigt. Erst wenn dieser nicht erreichbar ist, kommen die mit höherer Priorität zum Zuge.
- Ein Mailserver muss dafür konfiguriert sein, Mails für eine Domain anzunehmen. Blosses Eintragen eines MX-Records funktioniert in aller Regel nicht.
- In vielen Fällen soll eine Domain nicht am Mailverkehr teilnehmen. In diesen Fällen ist es zweckmässig, den MX-Record einfach wegzulassen. Einen MX-Record auf 127.0.0.1 oder auf einen anderen beliebigen Host zu setzen, der keine Mail für die Domain annehmen kann, ist unhöflich und sollte unterbleiben.
- Mail an einen Domainnamen, für den ein A-Record, aber kein MX-Record eingetragen ist, wird an die IP-Adresse zugestellt, die im A-Record genannt ist. Dieses Verhalten ist eine Altlast aus längst vergangenen Zeiten, in denen jeder Rechner sein eigenes unabhängiges Mailsystem hatte und ist heute in vielen Fällen ist dies unerwünscht.
  
  Besonders lästig ist es in dem Fall, in dem eine Domain nicht am Mailverkehr teilnehmen soll, aber ein Webserver ohne vorangestelltes www erreichbar sein soll. Somit werden nämlich Mails an die Domain beim Webserver zugestellt, was heutzutage in den meisten Fällen nicht sinnvoll ist. Dieses Problem ist wirklich befriedigend nicht zu lösen. Unter Umständen ist es ratsam, einen MX-Record auf einen Mailserver zu setzen, der Mails für den Domainnamen mit "550 no e-mail service for this recipient domain" ablehnt.
Die allermeisten Domains werden registriert, um einen Webserver anzubieten. Hierfür hat sich eingebürgert, den Hostnamen “www” in der registrierten Domain zu wählen, was zu Hostnamen wie “www.example.com” führt. Um dies zu erreichen, wird im Zonefile ein A-Record eingetragen, der den Hostnamen “www” mit der IP-Adresse des Webservers verknüpft. Die explizite Reservierung einer weiteren Domain ist hierfür nicht notwendig; der Inhaber einer Domain hat die Kontrolle über alle Domain- und Hostnamen unterhalb dieser Domain.

Allerdings ist es nicht zwingend notwendig, für einen Webserver den Hostnamen “www” zu verwenden. Webserver können unter beliebigen Hostnamen angelegt werden, und es ist selbstverständlich auch möglich, innerhalb einer Domain oder innerhalb einer Zone mehrere Webserver anzulegen. Sie müssen nur unterschiedliche Namen haben, damit sie unterschieden werden können.

Die gängigsten Terminologiefehler im DNS

"Lieber Provider, bitte registriere für mich die Domain www.example.com."

Das kann der Provider nicht tun. Der Kunde will in diesem Fall die Domain example.com registriert haben, und in der Zone für diese Domain einen Eintrag “www”, für den der Provider zusätzlich zum Domainnamen auch noch eine IP-Adresse braucht.
"Lieber Provider, ich möchte bitte die Zugangsdaten, um die Webseiten auf meine Domain www.example.com hochzuladen."

Diese Anfrage ist Unsinn. Eine Domain ist ein Begriff aus dem DNS. Im DNS gibt es weder Webseiten noch Zugangsdaten. Was der Kunde möchte, sind die Zugangsdaten zu dem Webserver, der in der Domain example.com mit dem Hostnamen www eingetragen ist.
“Lieber Provider, meine Domain www.example.com ist nicht erreichbar.”

Auch hier meint der Kunde meist, dass anstelle der Domain sein Webserver nicht erreichbar ist. Das kann eine Störung im Netz, eine Störung im Webserver, oder wirklich eine Störung im Domain Name Service sein. Dies korrekt zu diagnostizieren, überfordert die meisten Netzteilnehmer, und führt den Support des Providers in die Irre, weil jeder, der täglich mit Internetsystemen zu tun hat, bei einer gemeldeten Domainstörung immer zuerst und sofort den Nameserver prüfen wird, wenn auch die häufigsten Ursachen für die hier besprochenen Störungen nicht dort zu finden sind.
"Lieber Provider, bitte route die Domain www.example.com auf die IP-Adresse a.b.c.d"

Diese Anfrage ist - wie so oft - aus der Verwechslung zwischen Domain und Webserver entstanden, gemischt mit dem Halbwissen, dass IP-Adressen geroutet werden. Das ist natürlich auch terminologisch falsch.

Mit diese Anfrage möchte der Kunde dem Provider in aller Regel mitteilen, dass er auf der IP-Adresse a.b.c.d einen Webserver bereitgestellt hat, der in der Lage ist, http-Anfragen für Webseiten unter http://www.example.com/ zu beantworten. Der Provider soll nun, damit dieser Webserver auch über den Namen erreichbar wird, einen A-Record im DNS eintragen, der den Namen www.example.com mit der IP-Adresse a.b.c.d verknöpft.

Das ganze hat mit Routing noch weniger zu tun als mit Domains.

fail2ban andersrum

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 30 Aug 2008 15:36:08 +0200

Auf einem Webserver möchte ich nicht, dass phpmyadmin, das Dokumentations-Wiki und das awstats von überall verfügbar sind. Andererseits möchte derjenige, der das CMS auf eben dieser Maschine betreut, genau diese Webapplikationen jederzeit und von überall benutzen können. Was tun?

Die erste Idee ist, dem Webmenschen auf der Shell des Servers ein Script bereitzustellen, dass den virtuellen Host für die Utilities per sudo aktiviert und ihn aus dem cron regelmäßig wieder zu deaktivieren. Dann kommt mir die Idee, das ganze beim Login aus dem ~/.profile zu automatisieren. Und wenn wir schon dabei sind, sollen die Utilities auch nur für den Host freigegeben werden, von dem sich der Benutzer gerade eingelogged hat.

Das #!/usr/bin/perl -w, use strict ist schon geschrieben und ich mache mir gerade Gedanken darüber, wie ich das auth.log zur Gewinnung der Quell-IP-Adresse des Logins am besten durchforsten kann (denn dieses File kann potenziell groß sein), da kommt mir der Geistesblitz. Wir haben doch schon einen Daemon, der beim (gehäuften) Auftreten eines bestimmten Logeintrags eine Aktion durchführen kann und diese nach einiger Zeit auch automatisch wieder rückgängig macht: fail2ban macht dies, mit der Intention, eine IP-Adresse zu blockieren, sobald von dieser Adresse zu oft fehlerhafte Loginversuche ausgehen.

Diesmal wollen wir es gerade umgekehrt: Wir wollen einen Dienst für eine IP-Adresse temporär freigeben, sobald ein erfolgreicher Login von dieser Adresse verzeichnet werden konnte. fail2ban widersetzt sich dieser, seiner eigentlichen Intention diametral entgegengesetzten Aufgabe kaum, so dass mit der folgenden Konfiguration das Ziel erreicht wird:

/etc/fail2ban/jail.local:

[ssh-success]

enabled = true
port    = https
filter  = sshd-success
logpath  = /var/log/syslog/auth.log
maxretry = 1
action = iptables-allow[name=%(_name_)s]
bantime = 7200

/etc/fail2ban/action.d/iptables-allow.conf:

[Definition]
actionstart = iptables --new-chain fail2ban-<name>
              iptables --append fail2ban-<name> -j DROP
              iptables --insert INPUT -m state --state NEW --protocol   --dport <port> -j
fail2ban-<name>
actionstop = iptables --delete INPUT -m state --state NEW -p <protocol> --dport
<port> -j fail2ban-<name>
             iptables --flush fail2ban-<name>
             iptables --delete-chain fail2ban-<name>
actioncheck = iptables --list INPUT | grep -q fail2ban-<name>
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j ACCEPT
actionunban = iptables -D fail2ban-<name> -s <ip> -j ACCEPT

[Init]
name = default
port = https
protocol = tcp

/etc/fail2ban/filter.d/sshd-success.conf:

[Definition]
failregex = Accepted publickey for \w+ from  port \d+ ssh2$
ignoreregex =

Dabei kommt mir zu gute, dass ich die Utilities als einzige https-Dienste auf dem System angeboten werden und ich somit radikal mit dem Port arbeiten kann. Theoretisch könnte ich mir aber vorstellen, dass das Verfahren auch dazu geeignet ist, eine .htaccess-Datei mit den entsprechenden allow-Klauseln zu füllen bzw. diese nach einiger Zeit wieder zu entfernen.

Das einzige, was etwas verwirrend ist, ist die Terminologie von fail2ban, das in Konfigurationsdateien und Logs natürlich davon ausgeht, nach fehlgeschlagenen Zugriffen eine Sperre durchzuführen und nach dem Ablauf der Zeit wieder aufzuheben, während es in der Praxis auf einen erfolgreichen Zugriff mit einer Freigabe reagiert:

2008-08-30 11:46:01,544 fail2ban.actions: WARNING [ssh-success] Ban 85.214.68.41
2008-08-30 11:46:08,553 fail2ban.actions: WARNING [ssh-success] Ban 92.227.69.188
2008-08-30 13:46:02,041 fail2ban.actions: WARNING [ssh-success] Unban 85.214.68.41
2008-08-30 13:46:09,049 fail2ban.actions: WARNING [ssh-success] Unban 92.227.69.188

Wenn man sich einmal an die verwirrende Sprache gewöhnt hat, macht fail2ban auch seinen umgekehrten Job ganz gut.

ping ist boese?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 31 Mar 2007 20:17:47 +0200

Vermieter von dedizierten Mietservern sind offensichtlich nicht daran interessiert, dass ihre Kunden im Störungsfall in der Lage sind zu diagnostizieren, wo die Störung liegt. Denn sonst wäre es nicht so üblich, auf den Coreroutern nicht auf ICMP echo requests zu antworten. Das ist doof, denn so erzeugt mein Nagios viel mehr Alarme als er müsste.

Bleibt also nur, im Störungfall stets sofort den Anbieter zu nerven - denn er will es offensichtlich so.

P.S. Ich will ein Nagios-Plugin das traceroutes auswerten kann. TTL exceeded verschicken die Corerouter der Serveranbieter nämlich immer.

DSL and E-Mail providers

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 29 Mar 2007 16:16:00 +0200

Daniel, why do you insists on having your e-mail service with the ISP who serves your home IP connection? In my opinion, it would be a much better idea to separate IP and mail services to different companies - it is much easier to change one of them if no other services depend on it.

And, btw, it is a pain to have an uncommentable blog.

First Dedicated Power Server S Limited Edition

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 20 Mar 2007 22:02:21 +0100

Ich habe damals entgegen meiner Ankündigung meinen Hetzner DS1000 nicht gekündigt und das System als torres.zugschlus.de in Betrieb genommen. Dabei wäre es geblieben, wenn nicht Hetzner zum 1. April 2007 den Preis für den DS1000 von 19,90 auf 29,90 Euro erhöhen würde.

Das habe ich zum Anlass genommen, einkaufen zu gehen und bin diesmal bei First Dedicated gelandet. Dort gibt es - nach Anwendung eines Einkaufstricks - einen Celeron 2400 mit 512 MB und 80 GB Platte für 19,90 Euro im Monat. Das ist eine ganz ähnliche Maschine wie der Strato-Powerserver, für den ich 29 Euro im Monat bezahle. Für zehn Euro weniger Geld gibt es auch eine ganze Menge weniger Leistung. You get what you pay for.

Bei der Webhostlist ist der Power Server S Limited Edition für 19,90 Euro im Monat aufgeführt; auf der Webseite von First Dedicated kostet dieser Server ohne “Limited Edition” 29,00 Euro, und die Limited Edition finde ich nicht. Kurzes googeln nach “site:firstdedicated.de power server limited edition” findet das Neunzehn-Euro-Angebot dann doch, und ich bestelle für eine Vertragslaufzeit von 18 Monaten bei Null Euro Einrichtungsgebühr.

Als Mobilfunknummer, auf deren Eingabe das System besteht, gebe ich die Nummer von Frank geht ran ein, was sich kurz danach als Fehler erweist: Das Bestellsystem schickt einem per E-Mail einen Link, und auf der verlinkten Webseite muss man einen Aktivierungscode eingeben, den man per SMS zugestellt bekommt. Hmpf.

Also schnell beim Callcenter angerufen (01805, gut erreichbar, kompetent, hilfsbereit) und versichern lassen, dass ein nicht bestätigter Auftrag sich selbst automatisch rückstandsfrei entsorgt. Dann das ganze nochmal mit richtiger Mobilfunknummer.

Schon eine knappe Stunde später ist der Server betriebsbereit übergeben. Alle Passworte, inklusive dem nicht veränderbaren Passwort für das Rescuesystem, kommen in einer einzigen Mail.

Hardware

Der Rechner ist ein Celeron 2,4 GHz mit 128 KB Cache. Er hat 512 MB Speicher und eine per PATA angebundene 80-GB-Platte. Als Netzwerkinterface ist ein VIA Rhine II eingebaut, der mit dem via-rhine Modul neuerer Kernel funktioniert. Das ganze ist meinem Strato PowerServer S nicht unähnlich.

Webinterface

Das Webinterface ist eher spartanisch: Es ist nur per http erreichbar, und außer der Systemauswahl (“Normal”, “Rettungssystem”, “Eigener Kernel”), dem Resetknopf, dem Eingabefeld für den Reverse DNS und dem Knopf für die automatische Neuinstallation kann man nicht mehr viel einstellen.

Standardimage

Das im Default auf dem System installierte Image habe ich - wie üblich - vergessen anzugucken. Nur, dass ich die Maschine so schnell in den Produktivbetrieb prügeln müsste, dass leider auch keine Zeit war, es zur Begutachtung nochmal aufzuspielen. Was ich gesehen habe, war ein sarge direkt aus der Box, mit einem 2.4-Kernel. Nun denn.

Bemerkenswert ist vielleicht, dass das Firstdedicated-System auch im Normalbetrieb den Kernel aus dem Netz bootet. Auf dem System liegt ein viel älterer Kernel als der, der dann wirklich läuft. Das bedeutet auch, dass man im Webinterface “Eigener Kernel” auswählen muss, wenn man ein eigenes System installiert hat - denn der Kernel aus dem Netz passt wirklich nur zum vorinstallierten System.

Netzwerkkonfiguration

Der Server steht mitten in einem /24 und wird ohne Klimmzüge direkt per DHCP konfiguriert. Das bedeutet allerdings auch, dass es mit der Sicherheit nicht so weit her ist: Da alle Server dieses IP-Netzes in derselben Broadcastdomain liegen, ist es relativ einfach, Man-in-the-Middle zu spielen und die IP-Adresse eines Nachbarn zu übernehmen oder durch ARP-Tricks dessen Traffic mitzulesen. Zum Test konfiguriere ich eine weit entfernte, aber frei scheinende IP-Adresse als zweite Adresse auf meinem Interface, und kann meine Maschine sofort erreichen. Nicht schön, das ist nicht mehr zeitgemäß und bietet einige fiese Einfallstore. Dass diese auch schon in der Vergangenheit ausgenutzt wurden, zeigt, dass mein Host im IRCnet restricted ist, und das System somit nicht zum uneingeschränkten Chatten geeignet ist.

In diesem Punkt kommt First Dedicated also nochmal eine Nummer schlechter weg als Hetzner im letzten Herbst, die inzwischen auch bezüglich ihrer Netzarchitektur nachgebessert haben.

Rescuesystem

Das Rescuesystem ist zweifellos einer der Tiefpunkte im Produkt von First Dedicated. Es handelt sich hierbei um ein sehr arg abgespecktes Debian, das auch wieder nur einen 2.4-Kernel hat. Der Kernel kommt aus dem Netz, und /usr wird - read/write! - per NFS eingehängt. Der Versuch, Software nachzuinstallieren, scheitert jedoch an “read-only file system”. Da ist also wohl noch ein Sicherheitsmechanismus dazwischen. Trotzdem sind manche Dinge, die man im Rescuesystem macht, persistent - so bleibt zum Beispiel das Home-Directory des root-Accounts über Rescuesystem-Aufrufe hinweg enthalten. Das ist gut, denn der PATH enthält im Default keins der sbin-Verzeichnisse, so dass meine Scripte erst nach Installation einer .bashrc laufen, die einen für root angemessenen PATH setzt.

Da im Userspace des Rescuesystems jegliche LVM-Tools fehlen, installiere ich zunächst einen normalen zgserver in die Partition, die später swap werden soll. Das dabei auftretende Fußschußpotenzial nutze ich voll aus: Man kann eine Partition mit Partitionstyp “Linux swap” zwar problemlos mit einem ext3-Filesystem formatieren, mounten und mit Daten betanken, grub legt sich dann aber bei der Installation erstmal königlich auf die Schnauze. Weiterhin möchte man - siehe oben - den Kernel im Webinterface wirklich auf “Eigener Kernel” setzen, denn sonst geht gar nichts.

Nachdem diese Unwägbarkeiten umschifft sind, kann ich endlich den LVM bauen. Eine erneute Installation meines zgservers kann ich mir sparen, denn die neue Maschine soll ein bereits existierendes und derzeit auf einem Strato-Server laufendes System übernehmen, damit meine torres von dem derzeitigen Hetzner-Server auf den dann freiwerdenden Strato-Server umziehen kann. Ich verbringe also den guten Teil des Resttages damit, einem 30-GB-rsync mit vielen Maildirs zuzugucken.

Nachdem das neue System erstmal nicht starten will, stelle ich fest, dass die auf einer LVM-LV liegenden Systemlogs aus dem Firstdedicated-Rescuesystem nicht einsehbar sind und rate eine mögliche Fehlerursache: udev. Kurzer Blick nach /etc/udev/rules.d/z25_persistent-net.rules bestätigt den Verdacht: Der Name eth0 ist noch von der MAC-Adresse des “alten” Interfaces belegt, so dass das einzig vorhandene Interface der “neuen” Maschine auf eth1 landet - für das keine Konfiguration in der /etc/network/interfaces vorhanden ist. Ein beherztes rm /etc/udev/rules.d/z25_persistent-net.rules und folgender Reboot löst das Problem und das System kommt brav ans Netz.

Fazit

Ein billiges Angebot. Mit Haupt- (Netzwerkstruktur) und Nebenleistungen (Rescuesystem) weit unter dem Durchschnitt. Aber dem Preis angemessen. Ich werde mein Entwicklungs- und Testsystem, das sowieso fast ausschließlich nur verschlüsselt und kryptografisch authentifiziert mit der Außenwelt kommuniziert, auf der First-Dedicated-Hardware betreiben. Einen Server bei der derzeitigen Preisentwicklung für 18 Monate für 19 Euro im Monat zu haben, kann praktisch sein.

Es bleibt die Hoffnung, dass im Netz von First Dedicated irgendwann mal so viel Missbrauch geschieht, dass man dort freiwillig anfängt, eine zeitgemäße Netzwerkstruktur auszurollen. Bis dahin muss man halt aufpassen, was man tut, und sich darüber im Klaren sein, dass manche Dienste nicht verfügbar sind.

New DNS setup getting productive

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 03 Jan 2007 21:43:44 +0100

For nearly two years, I have been pondering about a good and failure-resilient DNS setup to implement for my own domains. In the last days, I have set the first prototype into use.

No, I haven’t dared to touch zugschlus.de, my most important domain, yet. This is planned for the weekend. So, if you experience difficulties in accessing any of my Internet services, please inform me and allow me to fix the issue.

However, zugschl.us, marc-haber.de and a number of less important test domains have already been moved to the new, svn-driven Scheme and delegation has been changed to the new DNS servers, dns1.nosuid.net, dns2.notwork.de and dns3.mxonly.de. q.bofh.de, my old main DNS server, continues to run as a slave for a transition period, and it continues to feed the slave servers run by various commercial and non-commercial entities that have kindly been serving the zones in the last years.

The new servers are all run by myself. dns1 and dns2 are dedicated servers (“real” machines that both have other duties as well) located at two different ISPs/hosters located in different parts of Germany, while dns3 is a vServer located in the US (which only does DNS due to its rather severely limited amount of memory). The three domains the servers are located in are in two different top level domains, are registered through two different registrars and are not used for anything besides DNS (and providing the host name for ivanova.notwork.de, one of the DNS servers and the machine hosting this blog).

The two .de-Domains mxonly.de and notwork.de are MX only domains, which means that they are not delegated outside of the .de zone but their resource records are directly written to the .de TLD zone. This reduces the chance of the domains becoming unavailable due to failures in the delegated servers (because there are none), and we depend on .de being available anyway. A downside of MX only domains is that the number of registrars that support them through their automatisms is rather limited.

The .net zone is served by the registrar’s name servers since .de is the only TLD I know of that has reasonable prices and offers MX only domains. One can argument that the .net zone is a weak point here, but I suspect that I’m reasonably safe with the MX only .de domains that the .net domain is only a paranoid safety catch anyway.

Domaintransit

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 07 Nov 2006 11:01:37 +0100

Bei der Einstellung der Dienste von Alturo kommt eine neue kleine Falle auf die ehemaligen Kunden zu: Die Domains wurden von Alturo in den Transit-Status gegeben.

Ich ging in meinem Domainhalbwissen davon aus, dass Transit bedeutet, dass die Domains an DENIC zurückgegeben werden und dort, wenn man nicht innerhalb von n Tagen den Transfer zu einem anderen ISP auslöst, verfallen. Genauso wollte ich mit den beiden zu meinen Ex-Alturo-Servern gehörenden Domains verfahren, die ich niemals genutzt habe und eigentlich auch nicht haben wollte.

Gestern kam jedoch ein Brief (Snailmail! keine E-Mail!) von DENIC, in dem ich über die wahre Natur des Transferstatus aufgeklärt wurde: Wenn ich die Domains nicht innerhalb von 30 Tagen zu einem anderen ISP schiebe oder explizit durch eigene Aktion lösche (Link und Passwort anbei), werde ich Kunde von DENIC Direkt und darf die Domain (die nackte Domain, ohne Webspace und DNS-Service) für den günstigen Preis von EUR 58,00 pro Jahr weiterbezahlen.

Das mag zwar sicher in den DENIC-Bestimmungen so stehen, ich bin davon aber überrascht. Nun, ich habe geklickt und bin die Domains nun los, aber wieviele der ehemaligen Alturo-Kunden werden in diese Falle reintappen?

Und warum tippe ich immer DENIX, wenn ich DENIC tippen will?

Hetzner DS 3000

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 07 Oct 2006 10:52:00 +0200

kju hat mir netterweise einen Server von Hetzner zum Test zur Verfügung gestellt. Der DS 3000 ist ein Athlon 64 3700+ mit 1 GB RAM und zwei 160 GB-SATA-Platten inklusive 6 IP-Adressen, 50 GB Backupspace und einer Trafficflatrate. Das Spiel kostet 99 Euro Einrichtungsgebühr, 39 Euro im Monat und ist monatlich zu kündigen.

Der Server wurde problemlos am 2006-09-30 abends (also schon nach dem Beginn des großen Alturo-Runs) bestellt und am 2006-10-05 gegen 22.00 Uhr geliefert. Den Bestellprozess habe ich bei diesem “gespendeten” Server natürlich nicht selbst durchlaufen. Zum Produkt gehörende Features wie Zusatz-IP-Adressen, Backupspace und Servierüberwachung müssen gesondert nachbestellt werden. Es gibt keinen “Firlefanz” wie Bestätigungsrückrufe, zum Anbieter zu faxende Papierdokumente etc.

Hardware

Der gelieferte Rechner hat einen ein mit 2.2 wirklichen GHz getakteten Prozessor und entspricht der Spezifikation. Zwei baugleiche Samsung-Platten hängen per SATA an einem VIA-Chipsatz; als Netzwerkkarte dient eine RTL-8169, die aber nur mit 100 Mbit am Switch hängt. Letzteres hat ein Geschmäckle, da das Gigabit-Ethernet-Interface in der Serverbeschreibung ausdrücklich und deutlich beworben wird.

Webinterface

Das Webinterface ist wenig überraschend. Trafficauswertung, Auftragsschnittstelle, Resetservice, Rescuesystem, alles da was man braucht (wenn auch nicht unbedingt an der Stelle, wo man die einzelnen Menüpunkte erwarten würde). Die Reaktion von Reverse DNS und Reset sind schnell; die Aktionen finden sofort statt. Beim Reverse DNS kann man beliebige Werte eintragen; eine Prüfung wie bei der Konkurrenz findet nicht statt. Das finde ich angenehm, weil es die Migration erleichtert, bietet natürlich aber dem Anfänger jede Menge Möglichkeiten um sich selbst in den Fuß zu schiessen.

Aus dem Rettungssystem kann man per Shellkommando die Neuinstallation anstoßen. Dabei kann man zuerst aus einer recht reichhaltigen Auswahl wählen, welches System man installieren möchte und wird dann in einen Editor geworfen, in dem man per Textdatei auf das zu installierende System Einfluss nehmen kann. So kann man auch beeinflussen, wie die Platte zu partitionieren ist. Hübsch, wenn es ein bisschen fehlertoleranter wäre: Gleich mein erster Versuch mit Partition 2 als root und “so groß wie möglich” und 10 GB in Partition 3 für /home geht mit fiesen Scriptfehlern daneben. Im nächsten Versuch wähle ich dann Debian 3.1 64 bit und belasse die Einstellungen beim Default; diesmal funktioniert es.

Standardimage

In der Defaultkonfiguration besteht das System aus einer großen ext3-Partition, auf der das 328 MB große System installiert ist. Der einzige nach außen offene Port ist tcp/22; Webserver, Mailserver etc sind nicht installiert. An überflüssigen Packages finde ich die komplette Suite von Packages für PPP und PPPoE, die auf diesem System sicher überflüssig sind, hotplug, Tools für CD-ROM- und Floppylaufwerk, rdate, ein dhcp2-client, einige überflüssige Libraries sowie Teile des gcc verschiedener Versionen. Als root-passwort ist das Passwort des Rescue-Systems gesetzt. Ein Teil der instalierten Packages ist “kept back”.

Das 32-bit-Image ist genauso.

Der einkonfigurierte Debian-Mirror ftp.uni-erlangen.de ist aus dem Nürnberger Rechenzentrum via Frankfurt und Hannover erreichbar.

Netzwerkkonfiguration

Die Netzwerkkonfiguration ist statisch in der /etc/network/interfaces eingetragen. Im System kommt die folgende Konfiguration (anonymisiert) an:

# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:16:17:98:42:d7 brd ff:ff:ff:ff:ff:ff
    inet a.b.c.208/27 brd a.b.c.223 scope global eth0
    inet6 <snip>/64 scope link
       valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
# ip route
a.b.c.192/27 via a.b.c.193 dev eth0
a.b.c.192/27 dev eth0  proto kernel  scope link  src a.b.c.208
default via a.b.c.193 dev eth0
#

Die IP-Adressen sind aus 88/8. Wir stellen fest, dass das System in einem /27 liegt, wobei durch eine extra eingetragene Netzwerkroute der Traffic innerhalb des /27 auch über das Defaultgateway geschoben wird. Wie ich später feststelle, ist das System auch ohne diese Sonderroute uneingeschränkt konnektiert. Das später zugewiesene /29 ist aus einem anderen /24.

Ein tcpdump auf dem Interface zeigt schnell, dass hier wie in einem “normalen” LAN verschiedene Kundensysteme in einer Broadcastdomain liegen: Ich sehe ARP-Requests für “fremde” IP-Adressen und sogar vereinzelte Pakete mit Nutzdaten. Darüber bin ich sehr erschreckt, denn ein solches Setup mit vielen verschiedenen, potenziell bösartigen Systemen ist schon seit Jahren nicht mehr zeitgemäß. Aus dem später beauftragten /29-Netz sind nur fünf IP-Adressen nutzbar, da unnötigerweise Netz-, Broadcast- und sogar eine Gatewayadresse weggeschnitten sind.

Netzsicherheit

Was ich in diesem Kapitel erwähne, habe ich nicht selbst ausprobiert, da mein Gastgeber mich gebeten hat, derartige Experimente zu unterlassen. Die Experimente wurden aber von einem anderen Hetzner-Kunden durchgeführt, dem ich unbedingt vertraue.

Bei Hetzner liegen mehrere Kundensysteme innerhalb einer Broadcastdomain. Es ist durch einfache Konfiguration einer fremden IP-Adresse auf das Interface möglich, diese IP-Adresse zu benutzen. Sprich: Will man einen Nachbarn belauschen, braucht man ihn nur aus dem Netz zu flooden, seine IP-Adresse zu übernehmen und schon hat man seinen Datenverkehr auf dem Silbertablett. Mit den gängigen ARP-Angriffen dürfte es möglich sein, dies auch unbemerkt durch das eigentliche Opfer durchzuführen. Sehr unschön.

Vor diesem Hintegrund wundert mich nicht, dass Hetzner ständig Ärger mit den Betreibern der großen IRC-Netze hat. Hetzner hat in seinem Netz den Port tcp/6667 gesperrt, um Botnetze zu verhindern, und behält sich weitere Portsperren in seinen AGB vor. Trotzdem sind die Netze von Hetzner in vielen IRC-Netzen mit einer K-Line von der Teilnahme ausgeschlossen. Das wundert mich wenig, da ich von IRC-Experten erfahren habe, dass es wohl inzwischen Bot-Tools gibt, die größere Netzbereiche rund um die eigene IP nach freien IP-Adressen durchsuchen und dann diese IP-Adressen für weitere Connections ins IRC-Netz missbrauchen. Das funktioniert natürlich in einem so simpel designten Netz wie bei Hetzner hervorragend.

Da sind die anderen Anbieter im Markt besser, die üblicherweise wenigstens die IP-Adresse statisch mit der MAC-Adresse verknüpfen, so dass simple ARP-Angriffe oder simple Übernahmen unautorisierter IP-Adressen nicht erfolgreich sind. Strato und UI gehen sogar so weit, dass die einzelnen Kundensysteme nur /32-“Netze” zugewiesen bekommen und nicht mit anderen Systemen in einer Broadcastdomain liegen. Damit kann man nicht einmal durch die Übernahme einer fremden MAC-Adresse andere Systeme beeinflussen. So gehört sich das. Die einzige von mir wahrgenommene Sicherheitsmaßnahme ist die oben erwähnte Sonderroute auf den Systemen selbst, die aber natürlich wirkungslos ist, da sie einfachst entfernt werden kann.

Per Mail auf diesen Mißstand hingewiesen, reagierte Hetzner sinngemäß mit “Ja, das ist in unserem Netz möglich. Wir kriegen das aber raus und ergreifen dann disziplinarische Maßnahmen.”. Muß ich extra dazu schreiben, dass ich diese Politik unangemessen finde?

In das sehr zweifelhafte Bild passt dann auch noch das von Hetzner angebotene User-Web-Forum. Grundsätzlich nehme ich ein solches Angebot als sehr positiv wahr. Allerdings sind im Hetzner-Forum auch etliche Leute mit mehr oder weniger gesundem Halbwissen und umgekert proportionaler Überzeugung von der eigenen Kompetenz unterwegs. Es muss echt nicht sein, dass auf die Frage, warum von einem extra zugewiesenen /29 nur fünf Adressen nutzbar sind, ein Mitglied mit dem Status “Lebende Foren Legende” sinngemäß antwortet mit “Ja, so ist das beim Subnetting halt. Das sollte man als Rootserverbetreiber wissen”. Ich verlange von einem Rootserverbetreiber jedenfalls nicht das Wissen, dass man bei einem ordentlich designten Netz durchaus alle acht Adressen eines /29 für Dienste nutzen kann, wenn eine andere IP fürs Routing zur Verfügung steht (was hier ja der Fall ist). Natürlich kam dann auch noch ein “Haudegen” dazu, der eine Aufnahmeprüfung für Rootserverkunden verlangte. Was in diesem Forum passiert, ist jedenfalls nicht schön. Ob der im Forum aktive Hetzner-Supporter wirklich so wenig von IP weiß wie man aus seinen Beiträgen vermuten möchte, kann ich freilich nicht beurteilen - ich mache erst seit fünfzehn Jahren IP.

Installation des zgserver-Standardimages

Das klappt problemlos im zweiten Versuch, nachdem der erste Versuch daran gescheitert ist, dass ich zwar daran gedacht hatte, einen Kernel mit SATA-Unterstützung zu bauen, diesen aber dann nicht installiert hatte. Mein Standardimage ist allerdings nur i386, also 32 bit, und somit auf diesem Rechner nicht empfehlenswert verwendbar.

Fazit

Ein großer Server zu einem verträglichen Preis. Leider ist das Netzdesign auf dem Stand von 1999 stehen geblieben, so dass ein Hetzner-Server aus meinem Standpunkt unter der Berücksichtigung des entstehenden Sicherheitsrisikos derzeit nicht für sicherheitsrelevante Dinge wie DNS oder Mail empfehlenswert ist. Ob die Connectivity für private Streaming- oder Gameserver gut genug ist, vermag ich nicht zu beurteilen.

Ich denke aufgrund dieser Testergebnisse derzeit darüber nach, meinen eigenen DS 1000, der bis heute nicht geliefert ist, grad wieder zu kündigen.

STRATO Power-Server S

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 28 Sep 2006 16:03:00 +0200

Als Ersatz für mein Entwicklungssystem nechayev habe ich einen STRATO Power-Server S aus der Alturo-Aktion bestellt. Da seit meinem letzten Test eines STRATO-Rootservers schon wieder fast ein Jahr vergangen ist, nutze ich die Gelegenheit, meinen Test von damals zu wiederholen und den Testbericht entsprechend anzupassen.

Bestellprozess

Der Power-Server S ist ein nicht hyperthreadingfähiger Celeron mit 2.4 GHz, 512 MB RAM und einer 80-GB-Festplatte. Der am Sonntagabend um 20.00 Uhr bestellte Server wird nach Klick auf einen per E-Mail übermittelten Verifikationslink und Eingabe einer auf Mausklick von einem Telefonroboter übermittelten PIN innerhalb von fünf Stunden kurz nach Mitternacht betriebsbereit bereitgestellt. Eindrucksvoll.

Vorinstallierte Systeme

Hier hat man deutlich modernisiert gegenüber früher und bietet nun SuSE 9.3 Professional und Debian 3.1 in jeweils zwei Versionen an; einmal mit “ServerAdmin Pro” und einmal “für Profis” (also vermutlich ohne Webfrontend). Zusätzlich gibt es SuSE 10.0 OSS und Fedora Core 3 “für Profis”. Die Neuinstallation mit Debian 3.1 für Profis dauert eine knappe Stunde.

Vorinstalliertes Debian

Das Debian sarge kommt auf drei Partitionen (hda1 = /boot, hda2 = swap, hda3 = /) und ist gegenüber dem im letzten Jahr gesehenen woody in viel besserem Zustand. Die Packageliste ist bis auf im Zuge von Securityupdates entfernte, aber nicht gepurgete Kernel-Images sauber. Die sources.list ist sauber konfiguriert; allerdings ist das System auf dem Security-Update-Stand von vor vier Monaten. So ist zum Beispiel ein root privilege escalation bug in passwd nicht gefixt und wartet darauf, dass der lokale Admin manuell die aktuellen Security-Updates installiert. Bei der Installation der Updates entfährt mir spontan ein “Igitt, das ist ja Deutsch!”

Auch auf diesem System verstehe ich nicht, wo die Hostroute für das Defaultgateway herkommt. Im IRC verrät man mir, dass der dhcpcd automatisch eine Hostroute für das Defaultgateway generiert, um es erreichbar zu machen. Dieses Verhalten überrascht mich, aber da ich dhcpcd nicht kenne, glaube ich das mal. Weitere Tests habe ich mit dem System nicht gemacht.

Rescue-System

Am Rescue-System hat sich leider nichts gebessert: Kein LVM-Support und sehr spartanische Umgebung dank Linux from Scratch. Ebenso dauert der Start des Rescue-Systems sehr lange. Abzug.

Migration von Alturo

Die Migration vom Alturo-Server zum neuen Strato-System läuft ähnlich wie die damalige Installation meines Standard-Images: Grundsystem mit LVM-Support in die Swappartition installiern, dort LVM und Filesysteme bauen und mounten, und die Daten vom alten System herüber-rsyncen. Dann das “richtige” System bootfähig machen (und in die üblichen Fallen “serielle Konsole mit unüblicher Baudrate” und “DHCP-Client” fallen).

Fazit

Der Strato Power-Server S ist ein gegenüber dem damals getesteten Server vorsichtig modernisiert worden. Die größte Macke, das viele Wünsche offen lassende Rescuesystem, besteht nach wie vor; die von mir angemäkelten Ungereimtheiten beim vorinstallierten System wurden größtenteils behoben.

Alturo-Ersatz

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 24 Sep 2006 21:07:32 +0200

Alturo macht dicht. Das dürfte sich unter den Mietserverbetreibern inzwischen herumgesprochen haben. Laut der Pressemitteilung und Kündigung meiner Verträge (die Alturo nach seinen AGB mit einer Frist von 30 Tagen aussprechen zu dürfen meint), wendet sich die Zielgruppe zunehmend den Markenprodukten zu.

Ich habe ja eher den Verdacht, dass die Marktverdrängungsstrategie, die United Internet mit seiner Billigmarke Alturo offensichtlich ausprobiert hat, nicht so ganz aufgegangen ist: Zu wenig Konkurrenten haben versucht, dem Alturo-Serverangebot (z.B. ein Pentium mit 1200 MHz und 256 MB für fünfzehn Euro im Monat) nachzuziehen; dementsprechend ist kaum einer von Marktrelevanz pleite gegangen. Also macht Alturo zu.

Die Sonderkonditionen, die Alturo den Bestandskunden beim Wechsel zu 1und1 anbietet, haben zwischen den Zeilen in großen Lettern “geh woanders hin” stehen. Was ich gerne tue, auch und gerade weil die Konzernschwester 1und1 sich vor einigen Monaten mit ihren asymmetrischen Kündigungsfristen vor Gericht einen Dämpfer eingefangen hat und die Billigschwester trotzdem dieselbe Masche immer noch fährt.

Interessant finde ich, was die Konkurrenz nach der Ankündigung der neuen Alturo-Strategie macht. Netdirekt versucht, aus den Neukunden noch etwas Geld herauszupressen und erhöht den monatlichen Preis des eigenen Billigangebots von fünfzehn auf achtzehn Euro; Strato im Gegensatz fährt eine spezielle Alturo-Wechsel-Aktion und verbilligt den vierundzwanzig-Euro-Server für die erste Vertragslaufzeit auf neunzehn Euro. Hetzner führt unterhalb des bisherigen Einstiegsprodukts DS3000 zwei kleinere Produkte ein, wobei der DS1000 in etwa mit dem kleinen Alturo-Server vergleichbar ist. Ob hundert Gigabyte Traffic im Monat nicht etwas arg geizig sind, mag der Kunde entscheiden.

Über den Netdirekt-Server habe ich bereits geblogged, einen Stratoserver habe ich vor zehn Minuten bestellt und auf die Freischaltung eines Hetzner-DS1000 warte ich bereits seit der Bestellung vom Donnerstag abend.

Sollte der “neue” Stratoserver maßgeblich von der in Nochmal Rootserver, diesmal Strato getesteten Maschine abweichen, werde ich das hierzublog selbstverständlich berichten. Jedenfalls ist zu empfehlen, den Server sofort fristgerecht zum Ende der ersten Vertragslaufzeit zu kündigen, denn nach den 18 Monaten wird der Server um zehn Euro im Monat teurer und wenn man die Kündigung (Ein Monat zum Ende der Laufzeit) verpennt, hängt man nochmal 12 Monate drin.

Über den Hetzner-Server werde ich natürlich berichten, sobald er freigeschaltet und getestet ist.

Call for Server

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 11 Sep 2006 13:36:57 +0200

Nachdem ich letzte Woche den dritten Testbereicht eines mietbaren Internetservers mit root-Zugang gepostet habe, kam weitgehend positives Feedback. Deswegen möchte ich gerne die Testreihe fortsetzen.

Um weitertesten zu können, brauche ich allerdings Systeme, die ich testen kann. Deswegen möchte ich Euch bitten, mir zu helfen und mir Serversysteme zum Testen zur Verfügung zu stellen.

Dabei gilt folgendes:

Ich teste sowohl Systeme, die von “richtigen” Kunden gemietet sind als auch Systeme, die von den Anbietern zum Test zur Verfügung gestellt werden.
Für den Test zahle ich kein Geld.
Der Test ist nur bei Systemen möglich, für die es ein vom Anbieter gepflegtes auf Linux basierendes Rescue-System gibt, dessen Leistungsumfang mit in den Test eingeht.
Für den Test benötige ich Zugriff auf das Administrator-Webinterface (das ist das Webinterface, in dem man das System resetten und ins Rescue-System booten kann), da sein Umfang Bestandteil des Tests ist.
Wenn der Bestellprozess mitgetestet werden kann, verliere ich dazu auch das eine oder andere Wort.
Im Rahmen des Tests installiere ich den Server zwei- bis dreimal komplett neu. Deswegen sollen keine wichtigen Daten auf dem Server abgelegt sein. Bevorzugt hätte ich gerne Systeme, die frisch angemietet sind und auf denen noch keine Benutzerdaten liegen.
Der Test selbst dauert etwa drei bis vier Stunden, wobei er sich in meine sonstige Arbeit einfügen muss. Es ist deswegen davon auszugehen, dass ich für ca. zwei Tage die Verfügungsgewalt über das System benötige.
Manche Anbieter erlauben dem Kunden keine Änderung des Passworts für das Webinterface. In solchen Fällen habe ich theoretisch nach dem Test weiterhin Zugriff, sage aber zu, diesen nicht mehr zu verwenden.
Die Rückgabe erfolgt mit frisch installiertem Anbieter-Image.

Wer einen Server testen lassen will, möchte sich bitte mit mir in Verbindung setzen.

dedizierter Low-Cost-Rootserver von Netdirekt

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 07 Sep 2006 15:02:32 +0200

Es ist mal wieder an der Zeit für einen Rootservertest. Was ich zu den Produkten von Strato und dem inzwischen nicht mehr neu bestellbaren Produkt von Alturo (das allerdings große Ähnlichkeit zu den Produkten der anderen United-Internet-Firmen hat) geschrieben habe, findet man in den referenzierten Artikeln.

Im heutigen Test geht es um den für fünfzehn Euro im Monat erhältlichen 733-MHz-Server von Netdirekt.

Netdirekt bietet einen kleinen Server mit 733-MHz-Prozessor, 256 MB Hauptspeicher und 10 GB Festplatte zusammen mit 500 GB Transfervolumen zum Preis von EUR 15,00 bei 12 Monaten Laufzeit an. Will man monatliche Kündigungsfrist, zahlt man pro Monat fünf Euro mehr. Backupspace gehört nicht zum Angebot; dafür gibt es auf Anforderung bis zu drei IP-Adressen und ein 99.5%-SLA. Netdirekt sagt zu, defekte Hardware innerhalb von zwei Stunden zu tauschen - ohne Beschränkung auf die Geschäftszeiten. Sportlich und mutig.

Bestellprozess und Lieferzeit

Ich bestelle Mitte August per Webinterface und bekomme wenig später den Link zu einem PDF-Dokument, das ich unterschrieben an Netdirekt faxen soll. Nochmal wenig später kommt am 18. August per Mail die Bestätigung, dass der Server bis spätestens 04. September freigeschaltet wird. Hm. Über zwei Wochen Lieferzeit? Das geht sicher besser.

Hardware

Der Server wird auch tatsächlich erst am 04. September “geliefert” und ist ein wenig größer als die ursprünglich angebotene Maschine: 866 MHz hat der Prozessor und die Platte 15 GB. Als Netzinterface gibt es einen e100.

Kaufmännisches

In der “Fertigmeldung” steht auch einiges zur kaufmännischen Abwicklung: Netdirekt liefert auf offene Rechnung und empfiehlt die Anlage eines Dauerauftrags oder einer Einzugsermächtigung. Finde ich fair, dem Benutzer auf diese Weise die Wahl zu lassen. Unschön, dass sich das aus dem Webinterface herunterladbade Formular nicht als Einzugsermächtigung, sondern als Abbuchungsauftrag entpuppt. Auch schade, dass die als PDF versandte Online-Rechnung keine Signatur hat und es auch keine Möglichkeit gibt, sich die Rechnung gegen Aufpreis zusenden zu lassen. Also nix mit Vorsteuer ziehen.

Webinterface

Das Webinterface ist schnörkellos und funktional. Man sieht dort - im Gegensatz zu UI und Strato - eine grafische Trafficauswertung und kann Trafficwarnungen konfigurieren und die Zusatz-IPs ordern. Reset und Rescuesystem findet man hier genauso wie die Einstellung für den Reverse-DNS. Die kostenlos im Angebot enthaltene Neuinstallation des Ursprungs-Images stößt man per Konsolenkommando des gebooteten Rescuesystems an. Dort steht ein Minimal-Debian, ein Debian mit Admin-Webfrontend, Fedore Core 4 minimal, SuSE 9.3 minimal sowie - ausdrücklich als “Beta Test” gekennzeichnet - CentOS und Ubuntu zr Verfügung. Danach kann man dem System in der Konsolensession beim Download und Auspacken des Images zugucken.

Standardimage

Das vorgegebene Standardimage belegt 709 MB auf der nur in einer großen Partition hda1 bestehenden Platte und lässt mich nicht in Begeisterung ausbrechen. Die Packageauswahl ist freundlich gesprochen extrem konservativ, unfreundlich gesprochen nicht mehr zeitgemäß: apache 1.3, proftpd, sendmail, qpopper, portmapper, mysqld, rpc.dracd (für smtp-after-pop) sind installiert und lauschen alle auf 0.0.0.0; außerdem ist wie auch bei der Konkurrenz ein gcc installiert. Die im Laufe der Evolution des Systems herausgeworfenen Packages wurden nur removed und nicht gepurged. So kann man problemlos sehen, dass auf dem Mastersystem schonmal ein exim4, ein courier-mta und ein postfix installiert waren. Vom Courier ist sogar die Konfiguration noch vorhanden; die von exim und postfix hat man manuell abgeräumt.

Deutlich besser ist das minimale Debian-Sarge-Image. Hier kommt als MTA der Default exim4 zum Einsatz, der dank eines Tippfehlers in der /etc/exim4/update-exim4.conf.conf unkonfiguriert auf 0.0.0.0 läuft (siehe auch Debian Bug #386554). Auch hier hat man viele Packages nicht gepurged, und auch hier ist der gcc installiert. Das Minimalsystem belegt 476 MB.

Rescue-System

Der Aufruf des Rescue-Systems ist anders gelöst als bei den beiden großen. Wählt man den entsprechenden Menüpunkt an, bekommt man eine Mail, in der das neue Rootpasswort steht. Dieses Passwort muss man dann nochmal im Webinterface eingeben, damit der Reboot ins Rescuesystem eingeleitet wird. Dabei operiert das Webinterface stateless. Sprich: Ein aus dem Rescuesystem ausgelöster Reboot führt zwingend wieder ins Produktivsystem zurück; wenn man nur das Rescuesystem rebooten möchte (damit es z.B. Veränderungen an der Partitionierung sicher aufgreift) muss man wieder ins Webinterface.

Dieses Verfahren finde ich weniger schön als den rein webbasierten Prozess von Strato und UI. Denn auf diese Weise werden Passworte unverschlüsselt über das Netz gepustet (der ausgehende Mailserver von Netdirekt benutzt kein TLS), und man kann die Administration des Servers nicht delegieren.

Das für meinen Server zur Verfügung gestellte Debian-basierende Rescuesystem hatte einen Designfehler, der LVM unbenutzbar machte: Zum Kernel 2.6 war nur die Userspace-Package für LVM 1 installiert. Also ein Grund um den Support zu testen, der den Test mit Bravour bestand: Es dauerte nicht einmal 80 Minuten, bis der Fehler im Rescuesystem behoben und LVM 2 nachinstalliert war. Dabei fand ich heraus, dass das Rescuesystem nicht wie bei den anderen aus dem Netz kommt, sondern dass der Server wirklich ein physikalisches CD-ROM-Laufwerk hat, in dem eine echte CD liegt. Der Rechner bootet grundsätzlich von CD; über ein Keyboard-Dongle wird dann entschieden, ob von CD oder von Festplatte weitergebootet werden soll.

Die Authentifikation per ssh-Key funktioniert ohne Überraschungen; die Netzwerkkonfiguration fällt “vom Himmel”. Die /etc/network/interfaces des Rescuesystems enthält nur den Abschnitt für lo.

Installation des zgserver-Standardimages

Die Installation meines Standardimages läuft wie erwartet problemlos, wobei - wie schon erwartet - die Netzkonfiguration Ärger macht: Auch bei Netdirekt muss man zuerst eine Netzwerkroute für das nicht im lokalen IP-Netz liegende Defaultgateway setzen, bevor man die Defaultroute setzt. Allerdings arbeitet Netdirekt nicht per DHCP, so dass die /etc/network/interfaces manuell konfiguriert werden muss - was scheitert, wenn man die normale “gateway”-Klausel verwendet (da zu dem Zeitpunkt, zu dem die Defaultroute gesetzt wird das Gateway noch nicht erreichbar ist). So:

auto eth0
iface eth0 inet static
        address 84.16.252.249
        netmask 255.255.255.255
        broadcast 84.16.252.249
        up ip route add to 217.20.117.0/28 dev eth0
        up ip route add default via 217.20.117.1

funktioniert es jedenfalls.

In der Nacharbeit zu diesem Artikel verrät mir Netdirekt, wie man ein Standardimage installiert. In diesem ist das Netz ganz straightforward mit der IP-Adresse des Servers in einem /24 mit Gateway auf der .1 konfiguriert; ich hätte mir also den ganzen Zirkus sparen können. Nun ja, hinterher ist man immer schlauer

Fazit

Der Server von Netdirekt hat nach dem Abgang von Alturo ein sehr gutes Preis-Leistungs-Verhältnis. Die minmalen Abstriche, die man machen muss, liegen im “you get what you pay for” Bereich. Besser als ein vServer ist dieses “richtige Blech” allemal.

Dieser Artikel wurde nach Eingang einer ausführlichen Stellungnahme von netdirekt überarbeitet. Vielen Dank dafür an den netdirekt-Support.

Alturo-Service gemessen am Preis Top

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 18 May 2006 18:00:00 +0200

Nach dem neulich beobachteten Fehlalarm hatte mein erster Alturo-Server nechayev in den letzten Tagen eine wirkliche Störung. Unter hoher CPU-Last gab es Kernel-Oopses und Segfaults.

Mit dem Alturo-Service bin ich gemessen an dem, was ich dem Anbieter bezahle, völlig zufrieden. Für professionellen Einsatz will man allerdings Ausfallsicherungsmaßnahmen vornehmen.

Da nechayev meine Testmaschine mit Debian unstable und einem “blutende Kante” Kernel ist, war der erste Gedanke natürlich ein Fehler im lokalen System. Ich habe deswegen die Maschine in das von Alturo bereitgestellte Rescuesystem gebootet, die Platte gemounted und meine Standardübung “bzip2 eines unkomprimierten Kernel-tars” angeworfen. Kernel-Oops und segfault des bzip2-Prozesses. Damit ist ein Hardwarefehler Verdachtsmoment Nummer Eins.

Diesmal spare ich mir die 0900-Hotline, sondern sende gleich über die Alturo-Webseite eine Nachricht. Das Webinterface für Supportnachrichten ist arg versteckt unter “Support”, “Fragen zur Technik”. Dort muss man dann eine der vier unpassenden Kategorien (“E-Mail”, “Domain”, “FTP-SSH-FrontPage” oder “PHP-Perl-MySQL” - andere gibt es nicht) auswählen und kann dort dann unter “keine Antwort gefunden?” eine Nachricht hinterlassen.

Am nächsten Tag meldet sich ein Techniker per Mail, der für einen Lasttest einen relativ offenen root-Zugang auf dem System haben möchte. Das Rescue-System reicht nicht aus, aber md5sum, wget, bzip2 und screen sind akzeptabel. Root-Login per Passwort muss von überall her möglich sein, und das Passwort muss auf das im Alturo-Webfrontend unveränderbar vorgegebene Masterpasswort gesetzt sein. Dabei ist mir überhaupt nicht wohl, aber wenn das der Prozess ist, muss man da mitspielen.

Ich mache ein rsync-Backup auf torres und nehme mir vor, den Rechner nach Behebung der Probleme neu zu installieren. Schließlich öffne ich den Server wie gewünscht und melde Vollzug.

Das Ticket wird einmal am Tag angefasst, und zwar immer vom gleichen Techniker. Ich habe etappenweise den Verdacht, es hier mit einer Art “Jennifer Römer” zu tun zu haben. Die Turnaround-Zeit von 24 Stunden verzögert die Sache dann doch erheblich.

Schließlich beginnt Alturo mit dem angekündigten Lasttest, der aus je drei im Screen gestarteten tar-bzip2-prozessen von /mnt nach /dev/null und drei md5sum-Prozessen über das Gesamtsystem besteht. Der Supporter kommt dabei von einem ganz normalen t-ipconnect.de-Zugang, also vermutlich einem 1und1-DSL-Zugang. Den Lasttest hält der Server gerade mal eine Stunde durch und verabschiedet sich dann ganz komplett.

Am nächsten Tag kommt dann die Mail, dass der Fall an den Vor-Ort-Service weitergegeben wurde, und am gleichen Tag werde ich informiert, dass “die Hardware rund um die Festplatte” komplett getauscht wurde. Was in dieser Mail nicht drin steht ist, dass nach solchen Arbeiten der Server grundsätzlich im Rescue-System stehen gelassen wird, damit der Kunde selbst entscheiden kann, wann das System in den Wirkbetrieb zurückkehrt. Ich interpretierte das “System steht im Rescuesystem und ich hab das Passwort nicht” fälschlicherweise als “es wird noch gearbeitet” und hole mir noch einmal die Bestätigung ab, dass ich das System wieder übernehmen kann. Diese Bestätigung kommt schon nach einer Stunde.

Ich spiele daraufhin das Backup zurück, fixe die dabei entstandenen verdrehten uids und gids und kehre in den Wirkbetrieb zurück. Der Server arbeitet seitdem wieder im Rahmen der normalen Parameter, ist aber leider nach wie vor “nur” ein 1200-MHz-Celeron mit 256 MB und entspricht somit der Produktbeschreibung.

Alturo hat diesen Supportfall vorbildlich behandelt. Defekte Hardware wurde als defekt erkannt, ohne zu versuchen, dem Kunden die Schuld in die Schuhe zu schieben. Der Tausch ging problemlos und schmerzfrei ohne Datenverlust von sich. Kritikpunkte bleiben die lange Turnaroundzeit im Mailverkehr und die Forderung, gefährliche Sicherheitslöcher im System aufzureißen um den Lasttest zu ermöglichen. Diese Kritikpunkte sind aber vor dem Hintergrund, dass es sich um ein Billigprodukt der untersten Preisklasse handelt, vernachlässigbar.

Alles über alles hat die Behebung der Serverstörung drei Arbeitstage gebraucht. Auch das ist vor dem Hintergrund des Produktpreises völlig in Ordnung. Wenn auf einem Server wichtige Funktionen laufen, sollte man einen zweiten in der Hinterhand haben, um die Dienst kurzfristiger wieder online zu bekommen.

Rootserver-Anbieter drehen an der Preisschraube

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 20 Apr 2006 10:51:15 +0200

Bei Alturo sind die Billigserver “ausverkauft” - es klebt ein entsprechendes Banner über den Angeboten. Strato hat den “richtigen” Billigserver noch besser versteckt und einen neuen, großen VServer für 24 Euro im Monat ins Programm genommen.

Mietserverkomfort auf echter Hardware ist somit ein gutes Stück teurer geworden. Hoffen wir mal darauf, dass Alturo bald wieder ein paar Racks alter Server findet. Grund zur Hoffnung gibt es: Mein Anfang April ausgelaufener Alturo-Server ist bis jetzt noch nicht wieder in Betrieb gegangen. Jedenfalls nicht unter der alten IP-Adresse.

Update: Der Artikel wurde korrigiert. kju hat mich netterweise darauf hingewiesen, dass Strato den Server doch noch anbietet, nur an besser versteckter Stelle.

Ein halbes Gigabyte!

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 26 Mar 2006 20:50:00 +0200

Nachdem auf Strato oder Alturo ein Hoffnung machender Kommentar kam, hab ich schließlich den Weg des geringsten Risikos gewählt und habe die neue torres bei Alturo bestellt. Der Testanruf kam schon nach einer halben Stunde, und zwei Stunden später war der Server verfügbar und eingerichtet. Und, wie bei El Loco ist meine neue torres ebenfalls ein Pentium III 1.26 GHz mit 512 MB RAM. Das ist mehr als von Alturo versprochen, und für die geplante Anwendung mit Spamassassin mehr als ausreichend. Ich bin begeistert. Danke, Alturo!

Den Sonntag habe ich dann damit verbracht, mein Install-Script zu modularisieren und zu perfektionieren, um torres damit zu installieren. Bald ist es soweit, dass man es veröffentlichen kann - ich wurde oft danach gefragt, bezweifle aber, dass es anderen Leuten was bringt.

Wermutstropfen ist natürlich, dass das Bestellfrontend von Alturo nur eine Bankverbindung pro Kunden zulässg und ich die neue torres auf demselben Vertrag bestellt habe, in dem auch nechayev, mein erster Alturo-Server (Debian sid) untergebracht ist. Und nechayev wird eigentlich von meiner Mutter bezahlt. Wurde, denn ich musste nach meinem fehler mit torres natürlich die Bankverbindung ändern und lasse nun das Geld für beide Server von meinem Konto abbuchen.