Falk Dübbert IT

7.12.18
von Falk Dübbert
1 Kommentar

Neues aus dem Testlab: Storage

Gelber Storage.
Ich habe meinen Frei-Tag genutzt um einerseits etwas Sport zu treiben und andererseits mein Testlab voran zu treiben. "Richtiger" Storage ist leider außerhalb meiner finanziellen Möglichkeiten. Dennoch wollte ich Block-Storage haben und jetzt nicht für das Lab einen Linux-Server mit einem NFS-Share aufsetzen. Nachdem ich eine Tüte von Open- und Closed-Source-Storages durch hatte fiel meine Wahl auf "ESOS(ESOS - Enterprise Storage OS)": https://www.esos-project.com als Grundlage.

Die Hardware besteht aus einem Dell R310 mit 16GB RAM und einem Xyratex-FC-Diskshelf, das normalerweise zu einer F-Class 3Par gehören würde.

Showstopper waren eigentlich nur festzustellen, solange ich auf einen Emulex- statt auf einen QLogic-FC-HBA gesetzt habe um die Verbindung zwischen Server und Diskbox herzustellen.
Insgesamt macht ESOS einen wirklich ausgereiften und robusten Eindruck. In meinen Augen ist das ein zu Unrecht unbekanntes Projekt. Die Konfiguration über eine Textkonsole ohne jegliche Assistenten mag etwas spröde sein, aber sie ist in jedem Fall responsiver als eine Weboberfläche, die auf ein in Ungnade gefallenes Framework wie Silverlight oder Flash setzt.

15.10.18
von Falk Dübbert
Keine Kommentare

Webserver makeover

image

 

Ich habe am Webserver rumgespielt. Primär habe ich den Cache erhöht und mehr Logs in die RAMdisk umgeleitet.

Auf Platte wird erst mit dem Logrotate geschrieben, wobei auch die Besucherdaten verschleiert werden. GoAccess (Bild oben) und Webalizer greifen aber auf die RAMdisk zu. Da werde ich DSGVO-mäßig noch mal ranmüssen, weil gerade im Webalizer noch ein paar ReverseDNS zu eindeutig sind, selbst wenn man die letzten acht Zeichen randomisiert. 

Die Test-VMs waren auch schon mal verdockert. Die Seafile-Instanz macht aber noch ein bisschen viel Ärger, weil SDFS-Volumes aus Docker-Containern heraus sind… sagen wir mal nicht die beste Idee. Im Grunde macht es aber gar keinen Sinn einen Server, der nur eine Aufgabe hat, zu verdockern. Die Inhalte haben eh andere Schnittstellen.

Und – es klingt wieder ein bisschen Anti – aber ich habe meinen Git-Server mit Rechtsklick “… löschen” heimgesucht. Git und ich werden für meine Projekte keine guten Freunde. Auch wenn SVN an einigen Stellen etwas mehr Schminke auftragen muss und an anderen Stellen nach Verwesung riecht, fahre ich mit SVN besser. Nächste Woche kommt das SVN in eine VM beim Hoster und ich ziehe beim Aufräumen die Äste gerade.

20.05.18
von Falk Dübbert
Keine Kommentare

Der Herr Backupexperte hat VOLL versagt!

Einige werden bemerkt haben, dass ein paar Artikel schwupps gegangen sind. Das liegt daran, dass ich zwei Tage in die Vergangenheit fliegen musste, weil ich um eine Kleinigkeit zu fixen meine Header-Datei in die Grütze manövriert habe. Da zeigte sich, dass ich ein Backup-Experte aber kein Restore-Experte bin. Weil der pending commit schon länger in der Datenbank rumlag, war der letzte lauffähige Stand der Freitag. Die fehlenden Artikel habe ich aus dem Editor hochgeladen.

Der Hintergrund war, dass ich dachte, dass ich im Zuge der DSGVO-Anpassungen irgendwie das Laden des Top Menüs zerbrochen hatte. Das war bislang typischerweise eine offene oder zuviel geschlossene Klammer oder eine TXP:else in einer TXP:IF, die nicht sauber geschlossen wurde. Aber selbst mit Hochladen der Stände von Freitag war da nix zu wollen. Wie sich herausstellte, war das Problem ganz woanders und lag mal wieder an partial cache-updates.

Jetzt sollte das Menü aber wieder zu 66% angezeigt werden.

Nebenbei habe ich das Textpattern auf Version 4.7.0 angehoben und LOG, TEMP und CACHE des NGINX auf eine Ramdisk verlegt. Roaring!

Das neue Textpattern geht mit CSS-Templates anders um, so dass ich vielleicht das eher krude von Wordpress portierte und 6 Jahre alte Yoko-Template loswerden kann. Wenn ich mal Zeit habe.

5.05.18
von Falk Dübbert
Keine Kommentare

Zu kurz!

Heute hat mein Testrack-Projekt kurz mal den Boden getroffen. Mein Rack ist, wie alle allten IT-Schränke zu kurz. Also muss ich was bauen. 

Boden: 2 Bretter OSB 
Front und Rückseite: Zwei Bretter je etwa 8cm breit
Deckel: Ein Brett OSB

Die senkrechten Kanten bekommen noch eine Latte (aus Holz!).

Dazu kommen noch Rollen und zwei Griffe. 

Die Maße lege ich nach, wenn ich die Rackprofile habe.  

3.05.18
von Falk Dübbert
Keine Kommentare

Testumgebung: Naming Scheme

Die vier (ja VIER) ESXi-Hosts werden die folgenden Namen haben:

  • 11-EX6H-Fire
  • 11-EX6H-Earth
  • 11-EX6H-Water
  • 11-EX6H-Air

Sollten es mehr werden, stelle ich auf Planeten (mit Pluto!) um.

Die Netze werden so benannt: 

  • Niflheim (NIF rot, VLAN 1 [native VLAN!!!]) - Internetseite der FW 
  • Muspelheim (MUS orange, VLAN 10) - DMZ 
  • Asgard (ASG blau, VLAN 11) - VSphere, Monitoring und Management
  • Midgard (MID grau VLAN 12) - internes Netz dauerhafter VMs und Systeme
  • Jotunheim (JOT grün, VLAN 13) - filebasierter Storage [NFS, SMB] und ISCSI für Midgard, Vanaheim, Alfheim und Svartalfheim
  • Vanaheim (VAN viollett, VLAN 100 bis 149) - Testumgebungen für Automatisierung etc.
  • Alfheim (ALF gelb, VLAN 150 bis 199) - Testumgebungen Management-Systeme 
  • Svartalfheim - (SVA braun, VLAN 200 bis 255) - Allgemeine Testumgebungen
  • Helheim - (HEL schwarz, VLAN 14) filebasiertes und highlevel Backup aus Midgard

Trunks werden mit weißen Kabeln übertragen. 

Die IPv4-Adressbereiche werden 10.VLAN.0.0 umfassen.
Planung bislang: Diese Adressen lege ich eiskalt auf mein IPv6-Prefix um, wobei ich allerdings jeder Karte quasi 10 Adressen gebe, damit ich für Down und Up getrennte Adressen erhalte. 

Firewallregeln werden dann Qellnetz-Zielnetz-Port-Protokoll-Grund als Namen haben: 

Zum Beispiel "MID001.012-NIF-443+8531-Windowsupdate" wäre die Portfreischaltung für die VM mit der IP 10.12.1.12 in MIDgard ins Internet. Außer in in den zweistelligen VLANs bekommen alle Rechner einen zusammengesetzten Namen aus

VLAN - Betriebssystem - Art des Systems - Nr als Chemisches Element.

OS-KürzelOS NameKürzelArt des Systems
WVPWindows Vista ProAPhysische Appliance z.B. eine Firewall
W07Windows 7PPhysischer Server
W10Windows 10DPhysischer Desktop
W08Windows Server 2008 R2SPhysischer SAN-Storage
W12Windows Server 2012 R2RPhysischer Einplatinencomputer
W16Windows Server 2016XPhysischer Switch
W03Windows Server 2003NNotebook oder Tablet
WXPWindows XPOVirtuelle Appliance
WESWindows 7 for Embedded SystemsVVirtuelle Maschine
W19Windows Server 2019QSmarthome oder IoT-Device
DEBDebian ab SqueezeMIndustrie4.0 Gerät oder Anlage
DE7 Debian bis WheezyUKamera, Alarmanlage 
COLCentOS Linux  HHost 
RH7RedHat 7   
RH6RedHat 6   
FB1Free BSD 11   
FB2Free BSD 12   
OB4Open BSD 4.x   
OB5Open BSD 5.x   
PFSpFsense   
ORLOracle Linux   
SE2Suse Enterprise 12   
EX5VMware ESXi 5   
EX6 VMware ESXi 6   
LNXanderes Linux   
ANDAndroid   
QT5QT5 z.B. in einer Busybox  
WITWindows 10 for IoT    
    
    
    
    
    
    
    
    
    

123W12V-Hydrogen wäre z.B. die erste VM im VLAN 123. 

In den zweistelligen VLANs sind die VMs und Geräte permanent und bekommen die Systeme Namen von nordischen Göttern in englischer Schreibweise. Ich kann ja schlecht in Asgard irgendwelche Griechen rumrennen lassen. 

IPv4-Bereiche teilte ich immer wie folgt:

octet + 1: Standardgateway / Firewall (ich bin von der "Gateway at the bottom"-Fraktion)

octet + 2...9: Netzwerkgeräte - VPN Gateway

octet + 10: DHCP + DNS; bei Windows: der Schemenmaster / erste DC

octet + 11...hälfte des Netzes: allgemeine Server

danach: Clients

Mit IPv6 ist die Sache DEUTLICH komplizierter. Ein Problem ist, dass IPv6 so etwas wie ein "privates Netzwerk" erst nicht, dann halbherzig und nun geflickschustert vorsieht. 
Die Netzkonzepte, die auf eine Perimeter-Zone setzen wie Edge-Core-Network oder Direct-Access, sind in IPv6 kaum oder nicht abbildbar.  

So nun zu den Fragen, die noch keiner gestellt hat:

Ich baue das Testrack nicht nur zum Testen und Lernen, sondern auch um PoCs abbilden zu können. Das geht zum Teil auch auf dem MacBook, aber mal so eben eine kleine Firma mit Schemenmaster, Fileserver und ERP mit Datenbanken abzubilden wird mit 16GB RAM schnell eng. 

Mit einer "richtigen" Lösung, die sich ISO-ähnlichen-Regeln unterwirft und deren VMs ausprechbare Namen haben, habe ich auch gleich sprechende Namen in den Screenshots ohne auf die Peanuts-Charaktere, ACME Corp oder die Contoso GmbH zurückgreifen zu müssen.    

Die Testumgebungen in Vanaheim, Alfheim und Svartalfheim werden sicher nicht alle parallel betrieben. Genaugenommen wird vermutlich immer nur eine oder zwei zur Zeit laufen. Die nächsten VMs ziehe ich dann im nächsten VLAN hoch. Gesichert wird aus den Testumgebungen nichts. Es sei denn, Backup ist Teil des Tests. Alle Skripte landen im GIT.

11.03.18
von Falk Dübbert
Keine Kommentare

Neu-Bestückung Testrack

Bislang habe ich mir beim Testen mit alten Notebooks und einem N54L beholfen. Sowas stößt natürlich schnell an seine Grenzen, wenn es darum geht eine ganze Serverlandschaft oder kompliziertere Setups und Prozesse zu testen. Das Testrack bzw. dessen Neubau steht schon länger auf der ToDo. Der Schrank hat 24Höheneinheiten und ist 86cm tief. 

Meiner alten Doktrin, möglichst wenige Sorten zu haben, sind alle Server HPE DL360 Generation 8 (Allerdings sind 3 Stück -p mit SFF und 2 Stück -e mit LFF), die ich trotz der Nachteile mit normalen U-DIMMs bestücke. Die Hosts haben, abweichend von einem produktiven Aufbau, lokalen Storage und nur Gigabit-Ethernet. 

Die Virtualisierung wird zunächst mit einer VSphere passieren, aber ich werde eine Möglichkeit einbauen, ein oder zwei Hosts auf Openstack umzuschalten oder nested Openstack-Hosts als VM laufen zu lassen. 

testrack

Folgende Dinge will ich mit dem Rack testen / lernen / ausprobieren: 

  • Defensive Computing
    Normalerweise ist ein Testrack nicht der Ort für defensives Computing, aber ich möchte das Testrack so betreiben, dass ich die Praktiken von dort jederzeit auf die produktiven Fragestellungen meiner Kunden abbilden kann. 
    Ich profitiere viel von meiner Erfahrung als Admin, Retter, Macher, Techniker und von meinem Ingenieur-Studium und kann meist gut einschätzen welchen Kompromiss man bei der Gestaltung von IT-Strukturen eingehen kann. Aber mittlerweile bin ich mir sehr sicher, dass man in der IT nicht mehr "pfuschen" kann. Der Haufen "Technical Debt", den man mit Pfusch ansammelt, hat die unangenehme Eigenschaft, dann zu brechen, wenn man es am allerwenigsten gebrauchen kann. IT-Abteilungen und ihre Budgets werden immer kleiner und Applikations-lastiger - damit wird man sich mit Blech, Storage oder Backup und Restore nicht befassen müssen wollen und sie dürfen einfach keine Probleme machen.
  • High-Efficiency Computing
    Das ist, wenn man Footprint-Minimalisierung im positiven Sinn auf die Spitze treibt. Also so arbeitet, wie man in den Achtzigern Computerspiele gemacht hat. Ich sehe, genau wie Tim O'Reilly den baldigen Peak Digital voraus. Alles wird komplexer, bis es einfacher wird. Aktuell haben wir enorm komplexe IT-Umgebungen. Durch die Clouds sind tausende Systeme beteiligt. Bislang ist es so, dass diese Komplexität nur selten bis zum Endkunden durchdringt, aber genau, wie wir bei der Mobilität über CO2 und Stickoxide nachdenken, wird man den Footprint von allem in der IT in den Griff bekommen müssen. 
  • Docker-Automation, Service-Bereitstellung mit Docker unter VMware
    Ich will mehr mit Automation im High-Level-Bereich testen. Meiner Ansicht nach, wird eine interne IT in Zukunft eher wie ein Hoster sein und die Anwendungsentwickler je nach Schutz-Bedarf, Last oder Lebensdauer des Services entscheiden, ob dieser On-Premise oder in einer Cloud gestemmt wird. Dabei ist dann entscheidend, dass diese Entscheidung nicht von einer fehlenden Schnittstelle eingeschränkt wird. 
  • Patching und Updates durch Erzeugen der VMs von gepatchten Templates und schnellen Deployment der Services. 
    Ich bin großer Anhänger von disposable IT. Wenn man das Vernichten seiner gesamten Struktur zum Teil des Prozesses macht, hat man zwangsläufig auch alle Prozesse im Blick. Wenn man zum Beispiel die Betriebssysteme neu erzeugt und anschließend automatisiert die Services darauf wiederherstellt, fällt die Pflicht zum Systembackup.  
  • Orchestrator-Skripte am Ticket-System
  • 360°-Monitoring inkl. Failover-Automation (ist mehr was zum Vorführen) 

Das Hauptproblem wird sein, dass, wenn das Rack fertig ist, es auf dem Dachboden zu heiß für dessen Betrieb ist. 

25.11.17
von Falk Dübbert
Keine Kommentare

008

image


Eben gerade rutschte mir ein wenig das Herz gen Boden. Alle möglichen Adressen meines Front-Web-Servers warfen mir auf allen Notebooks 403-Fehler entgegen.


Da sich in den letzten Tagen eh schon seltsames in den Logs tat, hatte ich schon befürchtet, er wäre übernommen worden. 


Der Grund war aber einfacher. In meiner Du-kommst-hier-nicht-rein-Liste war ein Eintrag “008”, weil ein Bot mit diesem Useragent auf den Kommentar-Plugins der auch hier gehosteten anderen Blogs runhämmerte. Es ist dann aber geradezu doof, wenn man auf Vivaldi 1.94.1008.32 aktualisiert.


Ich werde im Dezember eh auf andere Mechanismen zur Härtung des Webservers setzen.