|
|
|
Archiv der News von 2011
| Keine Nutzung von externen Diensten für geschäftliche Daten |
Oktober 2011 |
Der IT-Sicherheitsbeauftragte
der Universität weist in einem Rundschreiben vom 17.10.2011 alle Mitarbeiter an,
keine externen Dienste für die Speicherung von dienstlichen Daten zu benutzen.
Eine Speicherung von vertraulichen dienstlichen Daten außerhalb der Universität
sei nicht gestattet.
Dies betrifft u.a.:
- Die Weiterleitung von vertraulichen dienstlichen E-Mails zu externen
Anbietern
- Die Nutzung von Online-Speichern wie DropBox, iCloud
oder ähnlichen Diensten für vertrauliche dienstliche Daten
- Die Nutzung von Cloud-basierten Office-Lösungen wie z.B. Google
Docs oder Microsoft Office 365
Informationen über die Nutzung der TechFak-, CIT-EC- und CoR-Lab-Mailaccounts
sind in der Rubrik
Rechnernutzung / E-Mail auf unserer Webseite zu finden.
Bei weiteren Fragen und Problemen sind wir selbstverständlich per E-Mail an
support oder per Telefon unter
der Durchwahl 2900 erreichbar.
(sf)
|
| Neue Tastaturen und Mäuse für V2-234 und V2-240 |
Oktober 2011 |
Dank einer Spende aus 30 neuen Tastaturen und Mäusen von der Sparkasse Bielefeld
können wir die beiden Räume mit den momentan ältesten Rechnern auffrischen.
Damit haben wir in allen Räumen des GZI einheitlich deutsches Tastaturlayout.
Außerdem ist die Haptik der neuen Tastaturen deutlich angenehmer (die alten Tasturen
haben einen linearen Druckpunkt, was viele Benutzer als unangenehm empfanden).
Raum V2-234 ist bereits damit ausgestattet; V2-240 wird in dieser Woche folgen.
(sf)
|
| Keine Nutzung der TechFak-Dienste aus dem WLAN des HRZ |
Oktober 2011 |
![]() |
![]() |
Es kommen in fast regelmäßigen Abständen Anfragen von verschiedenen NutzerInnen,
einige TechFak-Dienste aus dem WLAN des Hochschulrechenzentrums erreichbar zu
machen.
Dies ist leider aus verschiedenen Gründen nicht möglich.
Eine Erklärung vorweg: das Hochschulrechenzentrum (HRZ) betreibt das allgemeine
WLAN in allen Gebäudeteilen der Universität. Das WLAN ist für alle da: Studierende,
MitarbeiterInnen aller Fakultäten und Gäste.
Damit sollte bereits jedem klar sein: ein großer Teil der WLAN-Benutzer ist gar nicht
berechtigt, Dienste der Technischen Fakultät zu nutzen.
Ausserdem haben wir keinerlei Kontrolle und Möglichkeit einen Störer
schnell und effektiv zu sperren.
Dazu kommt noch die Tatsache, dass leider viele Benutzergruppen des WLANs ihre
Software weniger gut und regelmäßig warten als es unsere NutzerInnen mit
technischem Hintergrund machen. Dies ist keine Vermutung, sondern Realität:
SSH-Brute-Force-Angriffe auf unsere Loginserver aus dem IP-Bereich des WLANs
sind nicht selten.
Wir bitten daher alle NutzerInnen - soweit möglich - das Kabelbebundene Laptopnetz
der Technischen Fakulät einzusetzen. Leichte Einschränkungen der Mobilität und der
nutzbaren Geräteklassen (Drucken vom iPad wird z.B. nicht möglich sein) müssen
damit leider hingenommen werden.
Aus dem WLAN sind alle Dienste, die auch aus dem Internet erreichbar sind, wie
z.B. E-Mail, viele Webdienste und unsere SSH-Login-Server, selbstverständlich
nutzbar.
(sf)
|
| Automatische Druckerkonfiguration für mobile Clients |
Oktober 2011 |
![]() |
![]() |
Gerade NutzerInnen von Notebooks hatten immer wieder Schwierigkeiten bei der
Benutzung der Drucker. Weil die korrekte Konfiguration für das Drucken über unseren
zentralen CUPS-Server realtiv kompliziert ist, haben viele Nutzer einfach den
gewünschten Drucker direkt angesprochen. Dies war möglich, da unsere Firewall
den direkten Zugriff auf die Drucker erlaubt hatte. Diese Methode birgt
allerdings einige Nachteile und Risiken: zum einen ist eine Zugriffskontrolle
so nicht realisierbar, weil kaum ein Druckertyp dies unterstützt und falls doch
ist die Konfiguration dezentral, fehleranfällig und nicht wartbar.
Zum anderen brachte eine falsche Konfiguration eines Laptops die Drucker immer
wieder zum Absturz (nur durch einen Hard-Reset zu beheben).
Damit alle NutzerInnen unseren zentralen Druckdienst auch nutzen, haben wir die
automatische Konfiguration über Zeroconf (Bonjour unter OS X) eingeführt.
Wir setzen dabei auf die "Wide Area"-Variante, welche die Publizierung der
Drucker und ihrer Fähigkeiten über das "normale" Unicast-DNS erlaubt.
Ein OS X-Nutzer bekommt somit alle freigegebenen Drucker automatisch angezeigt
und braucht nur noch seinen bevorzugten Drucker auswählen. Die Einrichtung
erfolgt dann vollkommen automatisch.
In einigen Fällen ist noch ein wenig Hand anzulegen, weil wir die Ausstattung
der Drucker (Papierfächer, Auflösungen, Qualitätsstufen) nicht immer genau kennen.
Dort sind wir auf die Mithilfe der Rechnerbeauftragten angewiesen.
Update: Hier kam gerade die Frage rein, ob man dann auch mit dem iPad
(und auch iPhone) drucken könne: ja das geht. Aber nur theoretisch. Rein
technisch ist das kein Problem; das habe ich heute mal ausprobiert, aber das
geht rein praktisch nicht, weil das Drucken aus dem WLAN des HRZ nicht
möglich ist. Ich konnte das Testen, weil wir hier einen WLAN-Test-Accesspoint,
mit dem wir unser Forschungs-WLAN für mobile Roboter testen, haben.
(sf)
|
| Das Wetter für den Forschungsneubau: bewölkt |
Oktober 2011 |
![]() |
![]() |
Das Wort ist momentan Buzzword Nummer eins in der IT-Welt: die Cloud.
Virtualisierung setzen wir seit Xen 2.0 ein. Erst für unsere eigenen Server
und jetzt haben wir schon fast 120 virtuelle Maschinen. Bald werden es bereits
200 sein - das sagen die Ergebnisse der letzten Anforderungserhebung.
Nicht nur im Speichersektor wird sich für uns einiges ändern müssen, sondern
auch beim Thema Virtualisierung.
Momentan betreuen wir einen Pool von Virtualisierungshosts - Servern
verschiedenster Hersteller und Ausstattung: einige mit langsamen, aber
großen SATA-Festplatten, andere mit wenig Massenspeicher, aber schnellen
15krpm-SAS-Laufwerken, Maschinen mit viel Arbeitsspeicher und andere
mit weniger. Einie Maschinen sind sehr gut ausgelastet - manchmal ein
wenig zu gut - und andere könnten deutlich mehr Last vertragen, haben aber
zu wenig Speicher dafür. Alle Maschinen haben lokalen Massenspeicher.
Virtuelle Maschinen kann man daher nicht zwischen den verschiedenen Hosts
live (ohne sie abschalten zu müssen) migrieren. Dies macht das Installieren
von Updates und Routinewartung an der Hardware sehr kompliziert: es müssen
alle VMs auf dem Host abgeschaltet werden. Dazu muss ein Termin gefunden
werden, wo dies möglich ist - ohne großartig viele Benutzer damit zu
stören. Ein Ding der Unmöglichkeit. Der Verwaltungsaufwand ist auch
nicht zu unterschätzen.
Diese Sache muss ebenfalls einheitlicher, flexibler, ausfallsicherer und
performanter werden. Daher planen wir als Ersatz einzelner, autonomer und
unflexibler Virtualisierungs-Hosts die "private Cloud" des
Forschungsneubaus. Sie soll aus Knoten einheitlicher, deutlich performanterer
Hardware bestehen, Block-Storage aus der Storage-Cloud beziehen und in
Sachen Bedienbarkeit und Wartungsfreundlichkeit deutlich besser sein als die
aktuelle Lösung.
Storage-Cloud? Richtig gelesen: das von uns favorisierte Massenspeichersystem
bietet auch hierfür eine Lösung. Neben der NAS-Funktionalität bietet es
auch die Möglichkeit Blockspeicher für die virtuellen Maschinen zur Verfügung
zu stellen.
Live-Migration, Provisioning, Monitoring und Management sind nur einige
Must-Have-Key-Features der neuen Lösung.
(sf)
|
| Evaluierung einer neuen Storageumgebung für den Forschungsneubau |
Oktober 2011 |
![]() |
![]() |
Seit einigen Wochen haben wir eine ganze Menge zu tun - und dann muss
noch ein komplett neues Massenspeicherkonzept erarbeitet und geplant
werden.
Vor rund vier Jahren war die IT der TechFak noch überschaubar:
ein paar Server für Netzwerkdienste, ein paar SunRay-Server und ein
kleines SAN, bestehend aus fünf Fibre-Channel-Arrays mit einer
Gesamtkapazität von run 10 Terabyte und drei Fileservern.
Dann kam der große Knall: erst machte uns ein Bug im Filesystemcode arge
Probleme und liess einen Fileserver ständig abstürzen und dann brachte
uns ein Fehler in der Firmware eines RAID-Controllers schleichende
Datenkorruption. Irgendwann mussten die Arbeitsgruppen ihre Arbeit
temporär mehr oder weniger komplett einstellen, da die fehlerhaften
Fileserver und Arrays ein vernüntiges Arbeiten zu verhindern wussten.
Die Lösung war schnell parat und umgesetzt: statt teure FC-Arrays und
nur drei Fileserver für die TechFak, das CoR-Lab und das CIT-EC wurden
mehrere - pro Arbeitsgruppe einer - Fileserver mit Direct-Attached-Storage
(mit Festplatten direkt in der Maschine), bestehend aus x86-Standard-Komponenten,
angeschafft. Die Vorteile lagen auf der Hand: der Ausfall einer Komponente
oder eines Servers betraf nun nicht mehr die gesamten Benutzer (oder einen
großen Teil davon), sondern nur eine Arbeitsgruppe. Außerdem stieg die
Performance somit um ein vielfaches an und ein Performance- oder
Plattenplatzsünder konnte nun nur noch die Kollegenen seiner eigenen
Arbeitsgruppe stören. Das allerbeste daran: mein morgendliches Ritual,
nach dem Aufstehen den einen Fileserver per Remote-Management-Console
neuzustarten oder besser gesagt zu resetten, war nicht mehr! Ich
habe das "Advanced Lights Out Management" der Sun Fire V240
vermisst!
Nun sind drei Jahre vergangen und das Konzept hat sich durchaus sehr
gut bewährt: keinen einzigen Hardware-Ausfall (bis auf defekte
Festplatten)!
Und die Schwächen? Ja, die gibt es auch. Vor drei bis vier Jahren
füllte der gesamte Datenbestand der TechFak nur 10 Terabyte.
Jetzt sind es zwischen 120 und 150 Terabyte. So war das aber damals
nicht geplant! Aus den anfänglich sieben Fileservern sind inzwischen
20 geworden. Und man merkt so langsam: dieses Konzept skaliert für
die nun vorhandenen Datenmengen und Benutzerzahlen und neuen
Forschungswerkzeuge (wie z.B. High-Speed-Kameras) nicht mehr.
Auch ein High-End-RAID-Controller mit 24 Festplatten kommt bei
60 bis 70 Power-Usern, die alle gleichzeitig schreiben und lesen
wollen, ganz gehörig aus dem Takt: gerade das CIT-EC führte zu
größerer Zusammenarbeit zwischen den Arbeitsgruppen. Früher kamen die
Zugriffe auf den Fileserver einer Arbeitsgruppe fast ausschließlich aus
dieser selbst und nun ist das anders. Es gibt inzwischen AGs, die
mit Massendaten, wie z.B. HD-Video-Aufnahmen und Motion-Capturing
arbeiten. Und es gibt natürlich auch mehr Benutzer. Eine ganze
Menge mehr Benutzer.
In den nächsten Jahren ist nochmal mit weiterem großen Wachstum
zu rechnen. Es müssen 400 Terabyte her. Das ist Minimum. Mit
unserem aktuellen Konzept einzelner Fileserver ist das nicht
mehr zu stemmen. Der Verwaltungs- und Betreuungsaufand wäre
enorm hoch und die zu erwartende Performance einiger Hotspots
lächerlich und inakzeptabel.
Der Forschungsneubau des CIT-EC ist daher die perfekte Chance für
einen Neuanfang. Ein Neuanfang mit einer Technologie, die den
Erwartungen und Bedürfnissen der Forscher für die nächsten Jahre
gerecht wird. Niemand soll sich über ein Schneckentempo ärgern und
niemand soll genötigt sein unhandliche USB-Festplatten einsetzen zu
müssen, weil nicht genug Speicherplatz auf dem Server vorhanden ist.
Und so bestand unsere Tätigkeit der letzten Wochen aus Recherche und
dem Folgen von Verkaufsvorträgen der verschiedensten Firmen von
Speicherösungen. Wir haben die unterschiedlichsten Kozepte und
Lösungen kennengelernt. Alle haben eine Eigenschaft gemeinsam:
Sie sind teuer. Verdammt teuer. Was allerdings noch viel erschrekender
für uns war: die meisten davon passen nicht für uns. Was sollen wir
mit einem Speichersystem, das zwar in Sachen Speicherplatz
erweiterbar ist, aber die Performance nicht mitwachsen kann, da
es nur zwei Fileserverköpfe gibt, die irgendwann (für unsere
Verhältnisse viel zu früh) performancetechnisch am Ende sind?
Was sollten wir mit einem System, bei dem Speicherplatz fest
zu Volumes partitioniert werden muss? Das wär also unsere aktuelle
Lösung, nur als Big-Block. An der einen Stelle fehlt Speicherplatz
und an der anderen Stelle ist alles frei. Dazu kommen bei einigen
Herstellern noch ganz tolle Begrenzungen: 15 Terabyte pro Volume und
dann ist Schluss. Wie bitte? Gehts noch? Wir sind Forscher der
Informatik, Robotik und Biologie und kein Büroladen mit 600
Office-Rechnern.
Dann kommt die Frage nach der Redundanz. Keinen Single-Point-of-Failure
soll es geben. Das heisst bei den meisten Lösungen Replikation.
In Grunde genommen alles zwei mal kaufen und die Daten dann spiegeln.
So hatten wir uns das nicht gedacht.
Zum Glück haben wir dennoch eine Lösung gefunden, die nicht nur alle
Anforderungen der Benutzer erfüllt, sondern uns sogar auch noch gut
gefällt: diese Lösung arbeitet wie ein Cluster: man hat eine Menge
von Storagenodes (mindestens drei), wovon jeder eine doppelte
10GB-Anbindung an das Netzwerk bekommt und ein ultraschnelles
Infiniband-Backend-Netzwerk mit je zweimal 40GBit/s für die Kommunikation
der Nodes untereinander hat. Der Speicherplatz steht dank eines
speziellen Filesystems an jedem Punkt komplett zur Verfügung. Ohne
Partitionierung. Ein Filesystem ohne die typischen Nachteile.
Das System kann aus Nodes mit verschiedenen Speichertypen bestehen:
große SATA-Festplatten, schnelle SAS-Laufwerke und ultraschnelle
Solid-State-Disks. Die Daten werden dann je nach Zugriffshäufigkeit
automatisch auf die Speicherklassen verteilt. Ein Quellcode-Repository,
auf das besonders viele Benutzer gleichzeitig zugreifen, wird so
auf den schnellen SSDs vorgehalten und eine große Videodatei, die
hautsächlich sequentiell gelesen und geschrieben wird, liegt dann
auf dem preisgünstigen SATA-Pool. Ändert sich das Nutzungsverhalten
von einer Datenmenge, so wird diese vollautomaitsch migriert.
Die Erweiterung von Speicherplatz ist denkbar unkompliziert: einfach
einen oder mehrere weitere Nodes einbauen, an das Netzwerk anklemmen
und mit einem Hangriff in den Cluster aufnehmen. Und damit hat man
nicht nur an Speicherplatz gewonnen, sondern auch mehr Performance
zur Verfügung - weil jeder Node ein eigener Server mit eigenen
Prozessoren, Speicher (als Cache genutzt) und einer eigenen
Netzwerkanbindung ist.
Außerdem ist eine perfekte Integration in unsere komplizierte
und UN*X-orientierte Benutzerverwaltung möglich.
Aber das beste an dem System: es basiert auf Standard-Hardware und
benutzt als Unterbau FreeBSD. Damit ist weniger extrem pervers
teuer als so manch anderes System. Und man darf sich sogar als
root einloggen auf den Nodes ;) Ohne dafür extra zahlen zu
müssen (ich denke gerade an einen großen Netzwerkausrüster...).
Das schafft vertrauen.
In den nächsten Wochen werden wir uns die Meinungen von anderen
großen Hochschulen und Instituten einholen, welche dieses System
bereits produktiv einsetzen.
(sf)
|
| Erleichterung bei der Firewall-Verwaltung |
Oktober 2011 |
![]() |
![]() |
Seit einigen Wochen ist die Verwaltung der Firewall für eingehende
Verbindungen für uns deutlich unkomplizierter und entspannter geworden:
Bis dahin mussten wir als "Kunde" des Hochschulrechenzentrums jede
IP-Adresse, die aus dem Internet erreichbar sein sollte, einzeln in der
HRZ-Firewall freischalten lassen - und das obwohl die TechFak seit
Anbeginn eine eigene Firewall betreibt. Dieser zusätzliche Schritt hatte
enorm viel Zeit gekostet, weil die Benutzerverwaltung des HRZ mit der
großen Anzahl der Einträge der TechFak zu kämpfen hatte. Für die Freischaltung
von 20 IP-Adressen brauchte Carsten fast eine Stunde. Dies war aber nur die
halbe Miete: der Antrag musste noch ausgedruckt, unterschrieben und zum
HRZ gebracht werden.
Zum Glück konnte der komplette Netzbereich der TechFak auf einmal
und auf Dauer freigeschaltet werden, so dass wir nur noch unsere eigene
Firewall administrieren müssen ;)
Damit haben wir auch ein ganzes Stück Flexibilität gewonnen: ab jetzt
können wir Anfragen schneller bearbeiten und dies auch außerhalb der
Geschäftszeiten des HRZ.
(sf)
|
| DynDNS im Laptopnetz eingeführt |
Oktober 2011 |
![]() |
![]() |
Wir haben in der letzten Zeit immer wieder Anfragen nach der Möglichkeit,
feste IP-Adressen an bestimmte Laptops, Roboter oder embedded-Geräte im
Laptopnetz zu vergeben, erhalten, damit diese über einen festen Hostnamen
ansprechbar sind.
Leider ist dies aus verschiedenen Gründen nicht möglich, da der IP-Bereich
für die dynamische Vergabe von IP-Adressen vorgesehen ist und feste Adressen
den Pool von IP-Adressen für die dynamische Vergabe unnötig verkleinern.
Um dennoch eine Möglichkeit zu bieten, bestimme Geräte mit einem bestimmten
DNS-Namen ansprechen zu können, haben wir DynDNS (dynamic DNS) für das
Laptopnetz eingeführt. Ein Gerät kann dem DHCP-Server einen Wunschnamen
mitteilen. Ist dieser frei, wird automatisch ein DNS-Eintrag für diesen
Namen unter der Domäne "DHCP.TechFak.Uni-Bielefeld.DE." erzeugt.
Ein Laptop mit dem Namen "foobar" ist damit automatisch unter der FQDN
"foobar.DHCP.TechFak.Uni-Bielefeld.DE." erreichbar.
Hier ist aber Vorsicht geboten: es gibt keine Garantie, dass ein Gerät
seinen Wunschnamen erhält oder dass ein anderes Gerät diesen Namen bereits
hat. Daher ist immer sicherzustellen, dass bei Benutzung des Namens auch
der korrekte Host adressiert wird (z.B. bei SSH durch Kontrolle des
SSH-Host-Key-Fingerprints).
Im Gegensatz zu der ehemaligen Implementierung des HRZ von DynDNS in den
Flächen-VLANs haben alle unsere IP-Adressen im Laptopnetz primär feste
DNS-Einträge und die dynamsichen Namen werden nur zusätzlich vergeben.
(sf)
|
| DNSSEC eingeführt |
April-Oktober 2011 |
![]() |
![]() |
Seit letztem Monat sind alle von der RBG betriebenen Domänen digital
signiert.
DNSSEC ist eine Erweiterung des Domain-Name-Systems (DNS) um einige
Sicherheitsfunktionen. Weil fast alle IT-Dienste vom DNS Gebrauch machen
und oder über einen Domainnamen erreichbar sind, wirken sich die Schwachstellen
des DNS daher auf fast alle Dienste aus. Mittels Angriffsmethoden wie z.B.
Cache-Poisoning kann ein potentieller Angreifer den Datenverkehr beliebiger
Dienste umleiten und ggf. den Datenverkehr mitschneiden und Passwörter
abhören, indem dem Benutzer eine gefälschte Webseite "untergeschoben" wird.
Mittels DNSSEC können gefälschte oder veränderte DNS-Antworten erkannt
werden, weil dem Angreifer die passenden digitalen Schlüssel zum erzeugen
der korrekten Signatur fehlen.
Einen Wermutstropfen hat unsere Implementierng dennoch: um eine sichere
Authentifizierung zu erreichen, muss eine Vertrauenskette von unserer Domäne
(Zone) bis zum Wurzelknoten existieren - d.h. alle Glieder der Kette (Zonen)
müssen DNSSEC einsetzen. Im Falle der Domäne "techfak.uni-bielefeld.de."
wären die einzelnen Glieder "techfak" (signiert, von uns verwaltet),
"uni-bielefeld" (vom HRZ verwaltet, leider nicht signiert), "de"
(signiert) und die Wurzel (signiert). Weil das Hochschulrechenzentrum
noch kein DNSSEC anbietet, haben wir die öffentlichen Teile der Schlüssel
unserer Domänen in der DNSSEC Lookaside Validation registry (DLV) des
Internet Systems Consortium (ISC) hinterlegt.
Neben der Signierung aller unserer Zonen sind natürlich auch alle unsere
DNS-Resolver in der Lage, DNSSEC-signierte DNS-Antworten zu validieren.
(sf)
|
| IPv6-Migration fast abgeschlossen |
2010-Oktober 2011 |
Die RBG betreibt seit 2003 eine IPv6-Testinstallation und hat seit einigen
Jahren einen Nameserver im Dual-Stack-Betrieb.
Vor gut zwei Jahren haben wir damit begonnen, IPv6-Adressen in den
Arbeitsgruppennetzen per Autoconfiguration (SLAAC) auszugeben.
Die sorgfältige Planung und Vorbereitung hat sich ausgezahlt: es gab
weniger als eine Handvoll Problemreports.
Diese Aktion diente uns als Grundlage, erste interne Dienste ebenfalls
per IPv6 anzubieten. So sind unser LDAP-Dienst, unsere DNS-Resolver, unser
HTTP-Proxy und einige andere Dienste seit fast zwei Jahren erfolgreich
im Dual-Stack-Betrieb (IPv6 zusätzlich zu IPv4) erreichbar.
Ein weiterer großer Schritt erfolgte in den letzten Monaten. Heute sind
fast alle IT-Dienste der TechFak - auch von außerhalb aus - per IPv6
erreichbar: SMTP, IMAP, HTTP, WebDAV, SVN, SSH, usw.
Die Migration der restlichen Webdienste wird in den nächsten Wochen und
Monaten weiter vorranschreiten...
(sf)
|
|
RBG Rechnerbetriebsgruppe der Technischen Fakultät · Universität Bielefeld 