Veni, Vidi, VISA

Am 05.05 (also vor einer Woche) hab ich eine Workstation als Server umfunktioniert, mit einem 8TB Raid 5 und einem 300W Netzteil bestückt. Dazu kamen ins. 8G RAM und eine AMD Phenom(tm) II X4 945 Processor, 3000.63 MHz CPU. Betriebssystem war OpenBSD mit Nextcloud und zum Schluss PHP, Lighttpd und PostgreSQL in der jeweils aktuellsten Version. Die Kiste lief eine Woche lang 24/7 und musste lediglich das Android, Laptop und das Tablet eines Users - nämlich meiner Wenigkeit - sync'en. Der durchschnittliche Stromverbrauch lag bei 53 Watt, was bei 24/7 ~463kWh im Jahr sind und die x0,28€ ~130€ kosten. Diese Werte sind allenfalls ein sehr grober Anhalt für mich, da ein relativ altes Netzteil verbaut ist. Die Grafikkarte incl. Monitor fallen jedoch weg, weil diese nur bei der Installation benötigt wurden; die Administration lief dann ausschließlich über SSH. Der Vorteil von dem ganzen ist, dass meine Daten verschlüsselt rechts neben dem Schreibtisch stehen, jedoch ist das mit sehr viel Arbeitsaufwand verbunden. Zum einen ist die Installation und Konfiguration der Cloud (in dem Fall Nextcloud) relativ aufwendig und zum anderen muss man das ganze aktuell halten und ggf. Sicherheitslücken beheben. Dazu kommt noch, dass gute Hardware (SSD, Netzteile, ..) relativ teuer ist und auch nicht ewig hält.

Die Frage, ob ich in Zukunft einen eigenen Cloud-Server baue, installiere und nutze, kann ich trotzdem mit "Ja." beantworten. Es gibt zwar fertige Systeme wie z. B. My Cloud von WD, allerdings benötigt man dafür Windows oder Mac. Dazu kommt noch das man "nur" eine Cloud hat und keine zusätzliche Software installieren kann (FTP, SMTP, PHP, ..). D. h. ich kann meine Unix-Kisten nicht darauf sichern, sondern muss auf externe Festplatten zurückgreifen. Jetzt werde ich mir erstmal Gedanken über die notwendige Hardware machen und die dann nach und nach besorgen, wobei die Festplatten erst ganz zum Schluss an die Reihe kommen.

Nachdem mir der httpd(8) von OpenBSD auf die Eier gegangen ist, habe ich ihn gegen Lighttpd ausgetauscht, was auch problemlos funktioniert hat. Anschließend habe ich just for fun DokuWiki installiert und beim Aufruf von install.php It seems your data directory is not properly secured. zu sehen bekommen. chmod/chown waren korrekt gesetzt, also konnte es daran nicht liegen. Lag es auch nicht. Nach kurzer Recherche habe ich dann folgendes gefunden: https://www.dokuwiki.org/security#deny_directory_access_in_lighttpd und siehe da.. nach dem Eintrag von

$HTTP["url"] =~ "^/dokuwiki/(data|conf|bin|inc)/+.*" {

    url.access-deny = ("")

}

in der lighttpd.conf und einem anschließendem Neustart war das mit de Warnhinweis auch Geschichte.

Mich hat jemand via Mail gefragt ob ich in dem Tutorial das ich bald schreibe (wusste ich zwar gar nichts davon, aber nun gut..) auch die Installation vom OpenBSD abgehandelt wird. öhm.. Nein. Wozu? OpenBSD ist ausreichend dokumentiert; wenn auch etwas unübersichtlich, aber ausreichend und so schwer ist die Installation nicht.

$ cd /tmp

# Ports, Sourcen vorladen, damit CVS schneller fertig ist

   $ wget https://ftp.spline.de/pub/OpenBSDD/6.3/ports.tar.gz https://ftp.spline.de/pub/OpenBSD/6.3/src.tar.gz https://ftp.spline.de/pub/OpenBSD/6.3/sys.tar.gz https://ftp.spline.de/pub/OpenBSD/6.3/xenocara.tar.gz

# User "jehova" ermöglichen ohne UID 0 unter xenocara und ports zu arbeiten (/usr/src ist rw- für wsrc)

   $ user mod -G wsrc jehova

   $ cd /usr

   $ mkdir -p   xenocara ports

   $ chgrp wsrc xenocara ports

   $ chmod 775  xenocara ports

# Sourcen entpacken

   $ cd /usr/src

   $ tar xzf /tmp/src.tar.gz && tar xzf /tmp/sys.tar.gz

# Ports und xenocara entpacken

   $ cd /usr

   $ tar xzf /tmp/ports.tar.gz && tar xzf /tmp/xenocara.tar.gz

# CVSROOT setzen 

   $ export CVSROOT=anoncvs@ftp.hostserver.de:/cvs

   $ cd /usr/src

# -STABLE holen

   $ cvs -q up -Pd -rOPENBSD_6_3

   $ cd /usr/ports

   $ cvs -q up -Pd -rOPENBSD_6_3

# Kernel kompilieren

   $ cd /usr/src/sys/arch/$(uname -m)/conf

   $ cp GENERIC FOOBAR

   < .. editieren >

   $ config FOOBAR

   $ cd /usr/src/sys/arch/$(uname -m)/compile/FOOBAR

   $ make && make install

   $ reboot

# Wenn der Kernel nicht bootet, am Bootprompt einfach boot /obsd eingeben

# Anschließend in die /etc/installurl den/die Mirror(s) eintragen (einer pro Zeile) und schon funktioniert ein

   $ pkg_add sudo zsh vim ...

Sodala.. Nextcloud 13.0.1, S9Y 2.1.2, DokuWiki 2017.02.19e und PostgreSQL 10.3 sind installiert und laufen; versorgt werden sie von httpd(8) und PHP 5.6. Alles nicht optimal konfiguriert und auch nicht auf dem neusten Stand, aber mir ging es erstmal nur darum, alles zum laufen zu bekommen. Android synchronisiert sich mit der passenden App bzw. DAVdroid. Momentan hat die Kiste 8G RAM, eine AMD Phenom(tm) II X4 945 Processor, 3000.63 MHzm, 300W Netzteil und 100MBit/s RJ-45, welches direkt an der Fritz!Box hängt. Gespeichert werden die ganzen Daten auf einem Raid 5 mit ins. 8TB Speicherplatz. Momentan ist das alles nur eine Spielerei, weil ich erstmal ein Energiemessgerät dazwischenhängen muss, damit ich mir einen Überblick über den Stromverbrauch machen kann. Sollte sich der in Grenzen halten, wird die Kiste gegen einen richtigen Rechner getauscht, welcher besser geeignetere Komponenten enthält.
Sollte ich mal viel Zeit und noch mehr Lust haben, werde ich die einzelnen Installationsroutinen zusammenschreiben und veröffentlichen. Jetzt is erstmal Feierabend angesagt und ich fahr zum Fischen.

OpenBSD hat seit.. öhm.. seit wann eigentlich.. die Optionen WS_KERNEL_* aus GENERIC verbannt, aber das bedeutet nicht das man sie nicht mehr nutzen kann. Während des Bootvorgangs werden die Messages in angenehmen Windows-Bluescreen-Farben (Blauer Hintergrund, weiße Schrift) angezeigt, jedoch stehen auch noch andere Farben zur Verfügung. Ein Blick in die /usr/src/sys/dev/wscons/wsdisplayvar.h (Zeile 85-99) listet die verfügbaren Farben und Attribute auf. Wenn man z. B. die Bootmessages in roter Schrift auf schwarzem Hintergrund haben will, schreibt man einfach

option WS_KERNEL_FG=RED

option WS_KERNEL_BG=BLACK

in die Konfigurationsdatei des Kernels und baut ihn neu. Dann hat sich das auch mit dem Augenkrebs beim Booten erledigt; auch wenn man nicht jedes Jahr neu bootet.

Ist noch gar nicht solange her das nach gut 20 Jahren (OpenBSD 2.irgendwas) Richtung FreeBSD gewechselt habe und auch - mehr oder weniger - zufrieden damit war. Ich wurde zwar nie wirklich warm damit, aber es hat seinen Zweck erfüllt.. mehr oder weniger. Also mehr weniger. Kein ASLR, PIEs, static PIE, IP ID Random und Ports die mir regelmäßig das Essen aus dem Magen treiben, weil ich zum Teil mit Blutgeschmack im Mund vor dem PC sitze und hoffe das make(1) mit $? == 0 beendet wird.
Also zurück zu OpenBSD auf meinem Testrechner (kommt höchstwahrscheinlich auch auf den Laptop). Wie im Titel schon steht, brauche/will ich einen eigenen Cloud-Server. Ich weiß das es bei Google.Drive 15G frei gibt und man aufstocken kann; kostet dann bei 1TB 10€ monatlich. Hetzner verlangt für 20GB Speicherplatz und genauso viel Traffic im Monat 2,96€ und das wäre mein bevorzugter Anbieter. Nur habe ich alles was ich für eine eigene Cloud brauche bereits hier; einen Big-Tower mit 650W Netzteil, 10/100/1000 MBit/s NIC und Tastatur. Soundkarte benötige genauso wenig wie eine Grafikkarte; das einzige was im Rechner enthalten ist, sind mehrere Festplatten im RAID und ausreichend RAM (64G DDR3). Der Stromverbrauch ist im Durchschnitt niedriger als die Kosten für eine gemietete Cloud und ich habe volle Kontrolle über meine Daten und kann den Rechner zudem noch als Backup-Host für meine Workstation und den Laptop verwenden.
Das ist das größere Projekt das in nächster Zeit ansteht; Software wird sein OpenBSD, NextCloud mit WebDAV, CalDAV, CardDAV auf Nginx in Verbindung mit MySQL/MariaDB oder PostgreSQL (evtl. auch nur SQLite3, aber das wird sich zeigen).

Ich habe..hatte seit einiger Zeit The void auf meinem Laptop laufen und war - bis auf Kleinigkeiten - mit denen ich leben konnte, ganz zufrieden damit. Das einzige was daran wirklich saugt, ist die Tatsache das es ein Linux ist. Ich nutze Linux jetzt seit 1993 (Slackware 1.irgendwas) und habe seitdem alle möglichen und unmöglichen Distributionen ausprobiert. Zum einen weil ich neugierig war und zum anderem weil ich jahrelang als freiberuflicher IT-Consulant gearbeitet habe und mich deswegen damit befassen musste. Damals lief auf meinem Laptop Debian, weil es eine Vielzahl von Binärpaketen enthielt und ich so "mal schnell was" installieren konnte. Auf meinen Desktops daheim lief {Free,Open,Net}BSD, welche mir schon immer bedeutend lieber waren. OpenBSD kenne und nutzte ich seit 2001 (und davor auch schon ein paar Jahre), aber da gab es dann doch einige Sachen die mich ziemlich gestört haben. Zu guter letzt hatte ich nur noch void Linux und FreeBSD auf meinen Kisten laufen; void auf dem Laptop und FreeBSD auf den anderen Kisten.
Was ich von Debian halte, habe ich in diesem Blog ja schon mehrmals geschrieben. void Linux gut und recht, aber die halbgare Lösung mit pkgsrc ist auf Dauer auch nichts. Ab und zu benötige ich auch auf meinem Laptop selbstgebaute Software, bzw. zusätzliche Parameter. Ergo ein Paketsystem, bei dem ich zwischen "aus den Sourcen bauen" und "Binärpaket einspielen" auswählen kann. Ja.. ich weiß das ich auch Pakete bauen kann, aber das ist eine Workstation und da will ich Arbeiten und keine unnötige Zeit verschwenden.
Was mich an Linux (dem Kernel! Nicht der Distribution(en)) stört, ist die Tatsache das der Umgang mit Sicherheitslücken an bodenlose Frechheit grenzt. Gefundene Fehler werden nur klammheimlich behoben oder ein paar Jahre ignoriert. Sowas kann ich auf einer Workstation bzw. einem Laptop nicht brauchen. Und der erste, der mit Mac ankommt, wird mit angeschliffenen Windows 10 - CDs beworfen! Das Thema Linux hat sich für mich in Zukunft erledigt. Ich werde es weiterhin auf einem Desktop installiert lasse, da ich einige gute Bekannte und Freunde habe, die mich immer wieder mal um Hilfe bitten, aber auf meinen Arbeitsrechner und Laptop kommt FreeBSD drauf. Ich habe von Linux die Schnauze voll!

Ich habe heute nach.. öhm.. k/a.. 20 Jahren - am 26.12.2001 lief bei mir 2.9 und davor hatte ich es schon drei, vier Jahre. Egal.. - auf FreeBSD 11.0 umgestellt. Gründe dafür gab es mehrere, aber die werde ich hier nicht aufzählen. Probleme gab es während/nach der Installation auch, aber keine gravierenden.

Der Bootloader hing nach dem Boot von DVD, aber nachdem ich das DVD im BIOS von AHCI auf IDE umgestellt hab, war das Thema erledigt. Firefox verabschiedet sich mit einem Segmentation fault

process 32946: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory

See the manual page for dbus-uuidgen to correct this issue.

  D-Bus not compiled with backtrace support so unable to print a backtrace

Redirecting call to abort() to mozalloc_abort

Wenn man dbus_enable="YES" in die /etc.rc.conf einträgt und service dbus start ausführt, funktioniert auch Firefox. c*mus hat mich mit einem

Error: selecting output plugin '': no such plugin

gefolgt von einem

Error: opening audio device: couldn't initialize required output plugin

begrüßt. Nach einem rm -rf ~/.cmus war er nicht mehr so aufmüpfig. Die Hotkeys meiner Cherry Stream 3.0 wurden nicht erkannt. Nichtmal gar nicht! Also auch xev(1) bleibt stumm. Eine Möglichkeit wäre uhidd (USB HID daemon) zu installieren, aber ich hab die Abkürzung genommen und einfach den mitgelieferten USB->PS/2 - Adapter verwendet und siehe da.. it works! Dazu kam dann noch, dass die Tasten PgUP/Down, Links/Rechts, .. zwar erkannt wurde, aber nicht funktionieren, aber das hat sich nach einem setxkbmap -model pc105 erledigt.
Mein Spamdirektaufdemserverlöschen-Programm Namens Mailfilter gibt es nicht in den Ports.. hab ich gedacht, aber siehe da:

# This port is filtermail, but the author called it mailfilter. To avoid a

#  clash with another port called mailfilter, we change all files

#  installed by this port from the form *mailfilter* to the form

#  *filtermail*, and similarly the names in the man pages.

Und so stand es geschrieben in /usr/ports/mail/filtermail und so sollst Du es verwenden. Wollte ich auch, aber

$ filtermail --filtermailrc=${HOME}/.filtermailrc --verbose=6

filtermail: Error: 

filtermail: Error: Could not compile regular expression (deny).

Ja.. nee.. is klar. Schätzungsweise muss ich die regex(7) anpassen, aber das mache ich morgen.. vielleicht..
NeoMutt ist auch in den Ports (Brav!) und nachdem man sie mit portsnap(8) aktualisiert hat, sogar in der aktuellsten Version. Das witzige ist nur, dass NeoMutt meckert weil in der ~/.mutt/mutt.colors illegal byte sequence enthalten sind.

... "\\~?\(/[-_.,a-zA-Z0-9{}äöüß]+\)+"

.... "\\<[-A-ZÖÜßÄ']{4,}\\>"

.... "...|escreveu|escribió|scripsit|[0-9]+\\]|\\.[a-z]{2,4}>).*:"

Witzig ist das deswegen, weil "lang" und "charset" in der ~/.login_conf korrekt gesetzt sind (UTF-8), aber die Sonderzeichen anscheinend falsch deklariert werden, aber auch das mache ich morgen. Jetzt muss ich erstmal bei Irssi prüfen was das Irssi: warning SSL handshake failed: Broken pipe soll oder ob der Server rumzickt.

Letzte Woche war ich bei $Firma und musste dort ins. vier Server neu aufsetzen. Also eigentlich sollte ich dort lediglich einen Server aufsetzen und auf den anderen drei nur die "Betriebssystembedingten Fehler" beheben.

Beim 1. Server mit OpenBSD 4.7 funktionierte kaum ein Port, weil "das wahrscheinlich ein Bug im Compiler ist". Der Compiler war auch schuld. Wieso zickt der rum nur weil man OpenBSD 4.7-STABLE hat und die Ports von -DEVEL einsetzt? Frechheit das!!11!
Server Nr. 2 mit Debian wheezy/sid (auf einer Produktionsplattform wohlgemerkt!) "verhält sich komisch" und hat nicht jeden Daemon gestartet. Naja.. wenn man unter /etc/default/* nicht ENABLE, ACTIVATE, .. anpasst, dann is das halt mal so. Immerhin macht das System das, zu was man es anweist und nicht das was man will.
Server Nr. 3 (ebenfalls wheezy/sid) war schon etwas hartnäckiger. Da konnte man sich nämlich nicht mehr als root einloggen. Als mir der Admin erklärt hat was er gemacht hat, hat es mich eher verwundert das die Kiste nicht gleich explodiert ist. Weil: Sich als root einloggen ist pöhse[TM]. Da hat er ja auch recht. Aber er wollte dafür sorgen das sich niemand mehr als root einloggen kann und hat die Loginshell für root auf /bin/false umgebogen und dafür die /etc/passwd editiert. Und weil er grad dabei war, hat er auch gleich die notwendigen User angelegt, die sich auf der Kiste einloggen können sollten (Ja. Ich weiß.. meine Grammatik saugt); das hat er ebenfalls mit einem Editor gemacht. Ich weiß zwar nicht wie man auf die Idee kommt - und das sauge ich mir jetzt nicht aus den Finger! - in der /etc/shadow die Passwörter für die User mit einem Editor einzutragen. Und zwar im Klartext!

Ich glaube ich muss eine neue Kategorie Namens "Best of pebkac" erstellen, weil langsam aber sicher nimmt das ungeahnte Ausmaße an.

$Admin hat OpenBSD installiert, da $Firma einen Mail (QMail)- und Webserver(Apache) fuer das Intranet benoetigt(e); beides lief einige Zeit problemlos, aber irgendwann konnten keine Mails mehr verschickt/empfangen werden und der Webserver reagierte nicht mehr. So auch als ich mich einloggen wollte. Aber Gott sei Dank gibt es ja Fehlermeldungen wie

/bsd: uid 0 on /var: file system full

Ein du -sh /var sagte mir dann das /var mit 105% ziemlich voll war; also unter /var/log/* die alten Logfiles geloescht und schon waren schonmal knapp 2G mehr Platz.
Zwei Stunden drauf kam $Admin wieder an und beschwerte sich bei mir das die gleiche Kiste schon wieder haengt. Also wieder runter, eingeloggt, unter /var/log/* nachgeguckt ob da noch grosse Dateien rumliegen, aber nada.. Als ich dann unter /var ein df -h * eingegeben hab, war klar wieso die Kiste sich staendig verabschiedet. $Admin hat sich an die Installationsanleitung von OpenBSD gehalten; faszinierenderweise hat er aber die Hinweise wie "wd0e: /var - 80 M. Wenn das ein Web- oder Mail-Server wäre, müsste diese Partition viel größer sein - aber das machen wir hier ja nicht.", "Für ein System, das eine Menge E-Mails oder Webseiten handhabt (die in /var/mail und /var/www gespeichert werden), solltest du deine /var-Partition bedeutend vergrößern oder lege sie auf separate Partitionen." und "Für ein Mehrbenutzersystem, das eine Menge Aufzeichnungen erzeugt, solltest du deine /var-Partition noch größer wählen oder eine separate Logpartition (/var/log) einrichten." ueberlesen.
Das hatte dann zur Folge das zum einen QMail /var/qmail/* nutzt und zum anderen Apache die Direktive ServerRoot auf /var/www setzt. Ist ja auch nicht weiter schlimm, aber wenn man sich strikt an die Installationsanleitung haelt und /var nur 80M Platz zuweist, dann ist das fuer QMail, Apache, S9Y und etliche SVN/CVS-Repos doch zu wenig (zumal die Logfiles ja auch unter /var rumliegen).
Zitat: Wieso schreiben die dann auch so 'n Scheiss in die Anleitung?!

Es gibt Tage im Leben, .. *sigh*