Wir haben ein Monster geschaffen!

Inspiriert durch Isotopps Artikel Ich habe ein Monster geschaffen! gibt es hier auch mal wieder einen techniklastigen Artikel von mir.

Unser bisheriger Backup-Server im Datacenter war ein betagter Proliant DL380 G3 und sollte durch etwas aktuelleres ersetzt werden, vorzugsweise mit mehr Plattenplatz als nur 6x 300GB im RAID10.

Aus wirtschaftlichen Gründen (es ist “nur” ein Backupserver) haben wir uns gegen einen Server von HP entschieden, nicht zuletzt weil die 1TB SATA-Platten von HP mit 299€/Stück einfach jenseits von gut und böse liegen im Vergleich zu aktuellen Preisen für nicht-HP SATA-Platten im regulären Handel.

Bei der Wahl des Chassis hatten sich mein Azubi und ich relativ schnell für das Chieftec UNC-410F-B entschieden – 4U, 10 5,25″-Einschübe und damit genug Platz für Platten. Außen an das Gehäuse kommt eine Schiene RSR-260 zwecks Rackmontage und fertig ist das Chassis.

Den Saft für den Server liefert das redundant ausgelegte 500W-Netzteil MRG-6500P, das mit seinen 8 Molex- und 2 SATA-Steckern vorläufig genug Anschlüsse liefert.

Beim Mainboard haben wir uns an das von Kris verbaute Asus P5Q Premium gehalten, mussten aber leider während der Testphase feststellen, dass von den 10 SATA-Ports nur 8 sinnvoll nutzbar sind und haben deshalb auch noch eine Adaptec 1430SA nachgekauft.

Auf dem Mainboard findet anschließend eine Intel Core2Quad Q9550 Boxed (C1) CPU, 4x 2GB RAM und eine beliebige Grafikkarte Platz.

Bei der Suche nach passenden Backplanes wurden wir bereits auf der Zubehörseite des Chassis fündig: 3 Backplanes SST-2131SAS verstauen insgesamt 9 Western Digital Caviar WD15EARS.

2 Backplanes bilden mit ihren je 3 Platten ein Software-RAID5 auf dem dann LVM mit einem striped Logical Volume aufsetzt – quasi ein RAID50, durch LVM aber komfortabler zu managen.

Debian Lenny 64-bit ist per PXE-Boot, USB-Stick oder USB-CDROM innerhalb von 10 Minuten installiert, anschließend installieren wir BackupPC und übernehmen die Config-Files vom alten Server.

Beim Partitionieren der Platten sollte man die Sektorgröße von 4kB beachten – “normales” Partitionieren, so wie es der Linux-Sysadmin gewohnt ist, lässt die Schreibperformance auf diese Partitionen auf wenige MByte/s einbrechen.

Wie man es richtig macht findet man im Wiki von brain4free: WD “Advanced Format” HD mit LINUX.

Mittels pvs -o+pe_start stellt man sicher, dass die Nutzdaten des LVM-Layers auf einem Vielfachen der Chunksize des RAID5 beginnen:

PV         VG     Fmt  Attr PSize PFree 1st PE
/dev/md1   debian lvm2 a-   1.36T 1.36T 192.00K
/dev/md2   data   lvm2 a-   2.73T    0  192.00K
/dev/md3   data   lvm2 a-   2.73T    0  192.00K

Da meine Chunksize 64kB beträgt, passt der Beginn der Daten an Stelle 192kB also:

md2 : active raid5 sdd1[0] sdf1[2] sde1[1]
2930152704 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md3 : active raid5 sdg1[0] sdi1[2] sdh1[1]
2930152704 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

lvs -o+stripes,stripesize,devices

LV       VG     Attr   LSize #Str Stripe Devices
backuppc data   -wi-ao 5.46T    2 64.00K /dev/md2(0),/dev/md3(0)

Wer an dieser Stelle stutzig wird, hat offenbar schon mehrfach mit Software-RAID zu tun gehabt:

Bei einem RAID5 aus 3 Platten mit einer Chunksize von 64kB müsste die optimale Stripesize für das darüberliegende Logical Volume 128kB sein. Verschiedene Benchmarks haben aber zu meiner Verwunderung ergeben, dass die Write-Performance mit der 64kB Stripesize um 10-15 MByte/s höher lag als bei der rechnerisch optimalen Stripesize von 128kB.

Das auf dem LV liegende ext3 FS sollte ebenfalls passend angelegt werden: Mit dem mkfs.ext3 RAID stride calculator ergibt sich bei einem RAID0 über 2 “Platten” mit einer Stripesize von 64kB und einer FS-Blocksize von 4kB folgendes mkfs-Command:

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/data/backuppc

Damit erfolgen Schreiboperationen auf das Dateisystem nun in optimaler Weise.

Weitere Stellschrauben:

Das Optimieren der stripe-cache-size der 2 RAID5-Bricks von default 256kB auf 4096kB hat bei uns die lineare Writeperformance auf das LV von 180 MByte/s auf 300 MByte/s gesteigert; recht beachtlich, wie ich finde.

Update: ext3- und xfs-Benchmarks mit bonnie++ auf dem LV.

Update: Smart-Werte (sda+sdb = System, sdc = Spare, sdd-sdi = Daten)

Anleitung zum Ersetzen des 1&1-Rootserver-Kernels auf openSUSE-11-Installationen

Wie bereits im Heise-Forum von mir zum Heise News-Artikel openSuse-Kernel auf 1&1-Root-Servern möglicherweise veraltet angemerkt, lässt sich der 1&1-eigene Kernel, der offenbar Sicherheitslücken aufweist und sich über die Paketverwaltung nicht aktualisieren lässt, relativ einfach durch den Standard-Kernel von openSUSE ersetzen.

Die folgende Anleitung wurde erfolgreich auf 3 Root-Servern bei 1&1 getestet (1&1 Root-Server S64 mit Athlon64 Single- oder Dual-Core-CPU, 1GB RAM, NVIDIA-Chipsatz (lspci.txt)).

Wie immer bei Anleitungen aus dem Internet gilt auch hier:

Verwendung der Anleitung auf eigene Gefahr. Zu Risiken und Nebenwirkungen fragen Sie Ihren kompetenten Systemadministrator!

Wir aktualisieren die lokale Datenbank des Paketmanagers und schauen uns an, wieviele Updates darauf warten, eingespielt zu werden:

zypper refresh && zypper patch-check

Die letzte Zeile der Ausgabe könnte z.B. so aussehen:

4 patches needed (2 security patches)

Das Release bzw. die Versionsnummer des aktuell laufenden Kernels lassen wir uns mit

uname -r

anzeigen:

2.6.27.31rootserver-20090819a

Durch den Zusatz “rootserver” können wir erkennen, dass hier der von 1&1 selbstgebackene Kernel läuft, den wir gerne ersetzen wollen.

Wir installieren den openSUSE-Standard-Kernel mittels

zypper install kernel-default

Wie ich durch eigene Tests herausgefunden habe, stört sich der SUSE-Kernel an dem Boot-Parameter ro (das Root-FS wird dadurch read-only gemountet, openSUSE mountet dies während der Boot-Phase offenbar selbst nicht read-write).

Ob wir davon betroffen sind, verrät uns

grep kernel /boot/grub/menu.lst

Die Ausgabe könnte z.B. so aussehen:

kernel /boot/vmlinuz-2.6.25.20-0.5-default root=/dev/md1 ro console=tty0 console=ttyS0,57600
kernel /boot/vmlinuz-2.6.25.20-0.5-default root=/dev/md1 showopts ide=nodma apm=off acpi=off noresume edd=off x11failsafe console=tty0 console=ttyS0,57600

Falls bei Euch das ro in der Zeile auftaucht, die mit kernel beginnt, solltest Du mit Deinem Lieblingseditor (z.B. vim oder nano) die Datei /boot/grub/menu.lst bearbeiten und das ro entfernen.

Die Angabe root=/dev/md1 ist darüber hinaus ein Indiz, dass im Server ein Software-RAID eingerichtet ist.

Überprüfen lässt sich das mit

cat /proc/mdstat

Tauchen hier ein oder mehrere md-Devices (md1, …) auf, so ist ein Software-RAID eingerichtet.

Bei den von mir aktualisierten 1&1-Root-Servern war die Datei /etc/mdadm.conf nicht vorhanden.

Diese Datei sollte unbedingt vorhanden sein und die aktuellen RAID-Einstellungen widerspiegeln, wenn man den SUSE-Kernel booten will:

test -e /etc/mdadm.conf && mv /etc/mdadm.conf /etc/mdadm.conf.backup
mdadm –detail –scan > /etc/mdadm.conf

Wichtig: Das initrd-Image muss neu gebaut werden, damit dies die mdadm.conf enthält:

mkinitrd

Die Fehler bzgl. des 1&1 Kernels ignorieren wir.

Anschließend via

reboot

den Server rebooten.

An dieser Stelle empfiehlt es sich, sich zu Diagnose-Zwecken über den seriellen Konsolen-Server von 1&1 mit dem Server zu verbinden – damit ist man in der Lage, dem Kernel beim Booten zuzusehen und eventuelle Unregelmäßigkeiten zu erkennen. Die Zugangsdaten zum Konsolen-Server findest Du im 1&1 Control-Center unter dem Menüpunkt Server-Verwaltung/Serielle Konsole.

Sobald der Server wieder erreichbar und Du per SSH eingeloggt bist, kannst Du mit

uname -r

prüfen, dass nun der SUSE-Kernel geladen wurde. Der aktuelle SUSE-Kernel (Stand 26.11.2009) für openSUSE 11.0 ist:

2.6.25.20-0.5-default

Damit ist das Update des Kernels abgeschlossen.

Ouch

Freitag, 10 Uhr

Betreff: Reboot Core-Switche morgen früh zwischen 5:30 und 5:45 Uhr

Guten Morgen die Herren,

wir haben am WE Supportwochenende und müssen hier vorher unsere Core-Switche booten.

Der Reboot erfolgt im Abstand von 15 Minuten.

Es sollten keine Störungen auftreten, da die Architektur als HA ausgelegt ist.

Falls es doch zu Störungen kommt bitte ich im Vorfeld um Entschuldigung.

Samstag, 18:15 Uhr

Betreff: Re: Reboot Core-Switche morgen früh zwischen 5:30 und 5:45 Uhr

Hallo,

leider ist aus dem automatisierten Reboot ein Totalausfall geworden.

Einer der Core-Switche im Backbone ist ein Totalausfall und wir waren gezwungen, Teile der Infrastruktur umzubauen.

Die ist soweit wiederhergestellt und die Dienste stehen ohne Einschränkung wieder zur Verfügung.

PROBLEM: anakin is DOWN

Um genau 4 Minuten vor Mitternacht macht sich der Emailclient auf dem E90 lautstark bemerkbar:

PROBLEM: anakin is DOWN

kann man in großen Lettern lesen. Absender: Nagios.

Per Remote-Management kann man sich das Logfile des Servers anschauen, welches um 23:55 Uhr lapidar verzeichnet:

Server power removed

Leider ist ein Grund für diese nächtliche Unterbrechung nicht verzeichnet.

Der Versuch, den Server aus der Ferne zu Starten ist leider nicht von Erfolg gekrönt, auch wenn das Logfile etwas anderes vermuten lässt:

Host server powered ON by: pinky.

Es bleibt leider bei einem alles andere als befriedigenden Ergebnis:

power: server power is currently: Off

Da vom Ausfall des Servers keine vitalen Services betroffen sind, entscheide ich mich für

Acknowledge this host problem

und wende mich wieder meinem abendfüllenden Film mit Will Smith in der Hauptrolle zu.

Gute Nacht.

Broadcom Corporation BCM4312 802.11b/g [14e4:4315]

Nach dem Sieg des Spieltriebs über die Vernunft musste sich der Adminblogger auch eines dieser neumodischen Netbooks zulegen – die Entscheidung fiel auf ein Lenovo IdeaPad S10e, welches ich bereits vor einigen Tagen bei einem Arbeitskollegen begutachten konnte.

Out of the box funktioniert eigentlich alles – außer WLAN – unter grml 2008.11 sowie openSUSE 11.0.

Das WLAN-Device von Broadcom gibt sich als [14e4:4315] zu erkennen:

# lspci -nn | grep Broadcom

02:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express [14e4:1713] (rev 02)
05:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)

Das intern per USB angeschlossene WLAN-Device lässt sich leider weder per bcm43xx-Modul noch dessen Nachfolger b43/b43-legacy zum Leben erwecken.

Allerdings wurde von Broadcom vor kurzem ein Treiber veröffentlicht mit dem WLAN funktioniert, ohne auf NDISwrapper angewiesen zu sein.

Wie bei You’re Special, Just Like Everybody Else im Blog zu lesen, lässt sich der Treiber relativ einfach einbinden.

Zuallererst stellt man sicher, dass ihr die Header-Dateien für Euren Kernel installiert habt. Je nach Distribution gelingt das mittels

(openSUSE) # zypper ref ; zypper in kernel-source linux-kernel-headers
(debian/grml) # apt-get update ; apt-get install linux-headers-$(uname -r)

Nun besorgt man sich von der oben erwähnten Broadcom Webseite die aktuelle Version des Treibers für seine Architektur, z.B.

hybrid-portsrc-x86-32_5_10_27_11.tar.gz

Es folgt das übliche Prozedere bei Archiven unter Linux:

tar xfz hybrid-portsrc-*.tar.gz

Das Modul sollte sich nun problemlos mittels

(openSUSE) # make -C /lib/modules/$(uname -r)/build M=$(pwd)
(debian/grml) # make -C /usr/src/linux-headers-$(uname -r) M=$(pwd)

übersetzen lassen. Anschließend noch ein

mkdir /lib/modules/$(uname -r)/extra
cp wl.ko /lib/modules/$(uname -r)/extra
depmod -a
modprobe -rv bcm43xx b43 b43legacy
modprobe -v wl

und es sollte nun ein neues Interface auftauchen, auf meinem Lenovo Ideapad mit openSUSE 11.0 z.B. eth1.

# dmesg | tail

müsste in etwa folgende Ausgabe produzieren:

ieee80211_crypt: registered algorithm ‘TKIP’
wl: module license ‘unspecified’ taints kernel.
eth1: Broadcom BCM4315 802.11 Wireless Controller 5.10.27.11

Das sollte es gewesen sein. Nach einem Reboot sollte das WLAN-Device nun automatisch auftauchen, eventuell müssen von Euch die bcm43xx- und b43-Module geblacklisted werden.

Viel Spaß mit Linux auf dem Ideapad S10e.

Feierabend

Wenn man im Datacenter Hardware tauschen muss weil es auf einem Link Fehler hagelt und man anschliessend in der Firma einen Springbrunnen in der Toilette beobachten kann während es draussen wie aus Kübeln schüttet – dann … ja dann ist es Zeit Feierabend zu machen :)

Schlechte Erreichbarkeit

Gestern Abend gab es scheinbar ein Problem im Netz unseres Datacenters, so daß die Erreichbarkeit unserer Seiten dementsprechend schlecht war. Bisher gibt es noch kein offizielles Statement vom Datacenter zu dem Vorfall, aber das wird sicher noch kommen.

In Cacti sah man die Traffic-Einbrüche mehr als deutlich :-(

Traffic am 26.03.2007

Update

Inzwischen ist bei mir auch ein offizielles Statement eingetrudelt – so hat es am Montag wohl einen Hardwaredefekt gegeben, der die Probleme verursacht hat.

NC7170 Gigabit Server Adapter

Für die Migration unseres Firmennetzwerks bauche ich für unseren zukünftigen Linux-Router (HP Proliant DL360 G4 mit 2x GBit-NICs onBoard) noch eine weitere Netzwerkkarte.

Unser lokaler Hardware-Dealer hatte leider keine PCI-X 64bit Netzwerkkarten vorrätig, weshalb ich mich kurz entschlossen an den Support des Datacenters gewandt habe.

Nach ein paar Telefonaten war klar, daß der Vertrieb zwar auch keine Netzwerkkarten vorrätig hat (Stichwort Just in time), aber eine Karte bis zum nächsten, spätestens übernächsten Werktag bestellen könnten.

Zur Wahl standen eine HP NC7771 (Single-Port, Kupfer, Broadcom 5703) und eine HP NC7170 (Dual-Port, Kupfer, Intel 82546EB).

Nach ein wenig Recherche im Netz fand sich die PCI-ID der NC7170, nach denen man dann in den Kernel-Sourcen greppen kann – und siehe da, die NC7170 mit dem Intel 82546EB Chip wird scheinbar vom e1000 Modul unterstützt:

# grep 0x1010 e1000*
e1000_hw.h:#define E1000_DEV_ID_82546EB_COPPER 0x1010
e1000_main.c: INTEL_E1000_ETHERNET_DEVICE(0x1010),

Nach der NC7771 mit Single-Port habe ich garnicht weiter geschaut, da die Preisdifferenz nur 30 Euro betrug und man in einem Router eh nie genug Netzwerk-Ports haben kann.

In eigener Sache: Titelgrafik fürs Blog

Dieses Blog hat nun endlich auch eine Titelgrafik *froi* :).

Als Vorlage für das Bild musste einer unserer Switche herhalten:

adminblogger.de Titelbild
(Bild anklicken für große Ansicht)

Entstanden ist der Header für das Blog nach etwas Spielerei mit den Filtern in GIMP – man braucht nicht immer Photoshop.

Meinungen? Anregungen? Kommentare?

32°C im Serverraum ist zu viel des Guten

Die Woche fing gerade erst an (es war wohl so so gegen halb 10), ich hatte noch nicht einmal die morgendliche Koffein-Dosis intus, da bekundete ein Mitarbeiter mir gegenüber, daß sein Thunderbird immer in einen Timeout laufe und er auf sein IMAP-Postfach nicht zugreifen könne.

Kurz mal einen Ping abgesetzt und Tatsache – der Server war entweder mit einer ordentlichen Kernel-Panic abgeraucht oder das Kabel/der Switchport oder die NIC waren im Ar^Wkaputt. Keine 2 Minuten später erreichte mich die Nachricht, daß ein weiterer Produktiv-Server ausgefallen sei – nun wurde ich langsam leicht nervös.

Eine Maschine: kann mal passieren.
Zwei Maschinen, gleichzeitig tot: Zufall? Nicht mit mir.

Also Laptop-Tasche mit all den kleinen nützlichen Utensilien geschnappt, ins Auto geschwungen und bei geöffnetem Fahrer- und Beifahrerfenster (es war sonnig und für die Tageszeit schon sehr warm) und lauter Mukke zum Datacenter gedüst.

Kaum angekommen und einem der Datacenter-Mitarbeiter erzählt, wir hätten da Probleme mit 2 Maschinen … Antwort: “Ja, wissen wir.”

Dabei denkt man sich noch nichts – schließlich sind das dort alles Profis und gucken laut SLA auch regelmäßig an unseren Racks vorbei um uns zu informieren, wenn Server mit ihren LEDs um Aufmerksamkeit betteln. Im weiteren Gespräche wurde allerdings schnell klar, daß die Sache etwas heikler war als ich ursprünglich dachte:

Brauche dringend Urlaub

Da stehe ich am Dienstag fast 10 Minuten am Laptop im Rechenzentrum um ein Backup von meinem Server auf den Laptop zu ziehen und nichts geht.

Dazu muss man wissen, daß ich in meinem Köfferchen neben dem Subnotebook und diversem Kleinkram nur ein Patchkabel und 2 RJ45-Adapter habe:

Ethernet Linkchecker

Der Loopback-Checker ist ein nützlicher Helfer im Rechenzentrum – auf ein im Switchport steckendes Patch-Kabel gestöpselt sorgt er dafür, daß die Link-LED des entsprechenden Ports leuchtet.

Crossover Adapter

Der Crossover-Adapter macht, wie man bereits am Namens erahnen kann, aus einem Patchkabel ein Crossover-Kabel und umgekehrt. Ebenfalls sehr nützlich, da man nicht 2 verschiedene Kabel mit sich rumschleppen muss.

Zurück zum Dienstag – da stehe ich nun wie blöde am Laptop und Server, fummle mit ifconfig an der IP-Config an beiden Rechnern rum, checke mit iptables die Regeln und Chains auf dem Server und vergewissere mich mit ethtool, daß auch ein Link zwischen Laptop und Server besteht.

Da das alles wunderbar in Ordnung aussah, fängt man dann langsam aber sicher an, an sich zu zweifeln.

Man denkt, man habe an alles gedacht, alle Zeichen stehen auf “sollte gehen” und trotzdem will der Scheiß die Datenübertragung nicht funktionieren. :sad:

Nach einem Kaffee und ein paar Momenten des Fluchens kam mir dann in den Sinn, trotz der Aussage “Link detected: yes” von ethtool nochmal nach dem Kabel zu sehen … und dann fiel es mir auf einmal wie Schuppen von den Augen:

Zwischen Laptop und Patchkabel steckte der Link-Tester anstatt des Crossover-Adapters. *argh* *fluch* :mad:

Das passiert mir garantiert kein zweites Mal… ;)

Serverumzug erfolgreich

Der Serverumzug ist erfolgreich abgeschlossen.

Es macht sich übrigens bezahlt, vor dem Umswitchen der DNS-Einträge schon einmal das komplette Filesystem auf den neuen Server zu kopieren, so daß nach dem Stop der Dienste auf dem alten und dem Hochfahren der Dienste auf dem neuen Server nur noch die Änderungen via rsync übertragen werden müssen.

Die TTL aller betroffenen Domains hatte ich bereits vor einer Woche von 86400 auf 1800 und am Tag des Umzugs auf 300 Sekunden gesetzt.

Rein theoretisch sollte also die Nichterreichbarkeit der Dienste maximal 5 Minuten betragen haben.

Umzug II

Momentan laufen diese Seite sowie alle meine anderen Projekte auf einem dedicated Mietserver bei Strato. Preislich ist das mit 39,- für Celeron 2.4GHz, 512MB RAM, 80GB Platte, 80GB FTP-Backup, serieller Konsole und 400GB Traffic inklusive sowie einer IP ganz in Ordnung.

Dennoch werde ich meine Projekte die nächsten Tage auf einen eigenen Server umziehen, der zwecks Serverhousing im selben Datacenter unterkommen wird, das bereits schon die von mir administrierten Server meines Arbeitgebers beherbergt.

Ein Grund für den Umzug auf einen eigenen Server ist z.B. ein möglicher Plattendefekt – wie lange brauchen die Techniker bei Strato wohl, um die Platte zu ersetzen?

Da ich demnächst auch mit meinem Hab und Gut umziehen werde und es dann nur noch ein Katzensprung zum Datacenter ist, kann ich so z.B. schnell auf Hardwaredefekte reagieren.

Weitere Vorteile sind z.B.

  • Zugang zum Server theoretisch jederzeit ohne Extrakosten
  • Nette und kompetente Leute im Datacenter sowie guter Kaffee
  • 1GB RAM Infineon CL2 anstatt 512MB “irgendwas”
  • RAID1 dank zweier Platten
  • Dual Pentium III 1,3 GHz
  • Tyan Server-Mainboard anstatt Asrock LowCost Mainboard bei Strato
  • Möglichkeit, jederzeit Hardware aufzurüsten
  • IP-Adressen nach Bedarf anstatt nur einer (sehr nützlich)

Einzig und allein beim Preis kann das Serverhousing mit Strato leider nicht mithalten – aber für mich überwiegen eindeutig die Vorteile. Zumal ich den Server von meinem Chef als Gegenleistung für eine Menge Überstunden bekommen habe (nochmal Danke an dieser Stelle) :)

3 kleine Telekomiker

Ich war gerade im Rechenzentrum mit einem unserer HP-Server beschäftigt, als 3 Leute, die ich vorher noch nie dort gesehen hatte, den Serverraum betraten. Einer der Drei hatte ein kleines Päckchen unter dem Arm – im ersten Moment dachte ich, der Packetblogger würde vorbeischauen ;)

Als die Drei dann an mir vorbeistiefelten verblitzte ich mir beinahe meine Augen an dem rosaroten Panther Logo auf der Rückseite der Jacke des Päckchenträgers.

Kurze Zeit später kam einer der RZ-Mitarbeiter mit einem breiten Grinsen auf den Lippen vorbei und meinte, während er eine unauffällige Kopfbewegung in Richtung Päckchen erkennen ließ:

“Die Drei sind von der Telekom und bauen einen DSL Router für einen Kunden ein. Drei: Einer packt aus, der Zweite gibt Anweisungen und der Dritte dübelt das Ding ins Rack.”

Der Mitarbeiter war sichtlich amüsiert über solche Überkapazitäten Fachkräfte bei der Telekom.