Veni, Vidi, VISA

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*

So hat mir das $Admin erklaert und mir auch gleich ein non-working example gezeigt:

$ pkg_add -v php5-core

parsing php5-core-5.2.6

Dependencies for php5-core-5.2.6 resolve to: libiconv-1.12, libxml-2.6.32p1, gettext-0.17 (todo: libxml-2.6.32p1)

php5-core-5.2.6:parsing libxml-2.6.32p1

Dependencies for libxml-2.6.32p1 resolve to: libiconv-1.12

found libspec c.48.0 in /usr/lib

found libspec iconv.5.0 in package libiconv-1.12

found libspec m.3.0 in /usr/lib

found libspec z.4.1 in /usr/lib

php5-core-5.2.6:libxml-2.6.32p1: complete

[...]

Error: truncated archive

php5-core-5.2.6: complete

can't open /usr/local/lib/php/libphp5.so: No such file or directory at /usr/libdata/perl5/OpenBSD/md5.pm line 27.

Mein Vorschlag war das er einfach PKG_PATH auf einen anderen Server setzen soll, aber das hat er kurz ueberlegt und sich dran erinnert das er das auch schon versucht hat und es nicht geholfen hat. Komich, denn

$ export PKG_PATH="http://artfiles.org/openbsd/4.4/packages/i386"

$ pkg_add -v php5-core

parsing php5-core-5.2.6

Dependencies for php5-core-5.2.6 resolve to: libiconv-1.12, libxml-2.6.32p1, gettext-0.17

found libspec c.48.0 in /usr/lib

found libspec crypto.14.0 in /usr/lib

found libspec iconv.5.0 in package libiconv-1.12

found libspec intl.4.0 in package gettext-0.17

found libspec m.3.0 in /usr/lib

found libspec pthread.11.0 in /usr/lib

found libspec ssl.11.0 in /usr/lib

found libspec stdc++.45.0 in /usr/lib

found libspec xml2.10.0 in package libxml-2.6.32p1

found libspec z.4.1 in /usr/lib

installed /var/www/conf/php.ini from /usr/local/share/examples/php5/php.ini-recommended****************************************************************                                                    | 72%

installed /var/www/conf/modules.sample/php5.conf from /usr/local/share/examples/php5/php5.conf

php5-core-5.2.6: complete

--- php5-core-5.2.6 -------------------

To enable the php5 module please create a symbolic

link from /var/www/conf/modules.sample/php5.conf

to /var/www/conf/modules/php5.conf.



ln -s /var/www/conf/modules.sample/php5.conf \

        /var/www/conf/modules



The recommended php configuration has been installed

to /var/www/conf/php.ini.



Don't forget that the default OpenBSD httpd is chrooted

into /var/www by default, so you may need to create support

directories such as /var/www/tmp for PHP to work correctly.

$ php --version

PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 12 2008 12:07:27) 

Copyright (c) 1997-2008 The PHP Group

Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

    with Suhosin v0.9.20, Copyright (c) 2002-2006, by Hardened-PHP Project

sieht fuer mich so aus als wuerde das das Problem beheben.
War wahrscheinlich schlechtes Karma seinerseits..

Seit heute ist OpenBSD 4.4 offiziell auf den Servern verfuegbar. Und nicht minder wichtig ist die Tatsache das die Kommentare jetzt wieder problemlos funktionieren sollten. Schuld daran war anscheinend das sich das Spamschutz-Plugin von S9Y nicht mit Akismet verbinden konnte. Danke an den besten Webhoster wo das es gibt

Was ich hier machen wollte, hab ich schon fast alles erledigt. Ein eigener Mirror spart sogar noch mehr Zeit/Arbeit als ich gedacht haette, zumal ich auf meinem Mirror-Server auch noch andere Projekte spiegle und wenn man wie ich sehr haeufig neue Packages installiert/installieren muss, dann merkt man es doch sehr deutlich:

$ time sudo pkg_add -v -i w3m-0.5.2

parsing w3m-0.5.2

Dependencies for w3m-0.5.2 resolve to: gettext-0.14.6p0, libiconv-1.9.2p3, boehm-gc-7.0 (todo: boehm-gc-7.0)

w3m-0.5.2:parsing boehm-gc-7.0

w3m-0.5.2:boehm-gc-7.0: complete

found libspec c.41.0 in /usr/lib

found libspec crypto.13.0 in /usr/lib

found libspec curses.10.0 in /usr/lib

found libspec gc.2.0 in package boehm-gc-7.0

found libspec iconv.4.0 in package libiconv-1.9.2p3

found libspec intl.3.0 in package gettext-0.14.6p0

found libspec m.2.3 in /usr/lib

found libspec ssl.11.0 in /usr/lib

found libspec z.4.1 in /usr/lib

w3m-0.5.2: complete

Real: 1.39s User: 0.70s System: 0.29s Percent: 71% Cmd: sudo pkg_add -v -i w3m-0.5.2

Hat auch den Vorteil das ich nur eine Kiste up to date halten muss und die restlichen Boxen damit synchronisieren kann.

In Ports vs. Packages habe ich eine kurze function() fuer die Shell gepostet, mit der man die Portcollection von OpenBSD schneller als wie mit make search key=suchstring durchsuchen kann. Es geht auch noch anders; naemlich mit dem Package databases/sqlports. Das steht seit OpenBSD 4.0 zur Verfuegung und ist auch in den FAQ erwaehnt, aber es kann mehr als nur das eine dort aufgefuehrte Beispiel und enthaelt auch mehr Variablen (welche genau steht in den Package Details von sqlports). Das hier sind einige Beispiele fuer die Anwendung:

# Anzahl der ports, die Perl nutzen

sqlite> SELECT COUNT(FULLPKGPATH) FROM Ports WHERE CONFIGURE_STYLE LIKE '%perl%';



# Ports in deren Beschreibung "statistics" steht

sqlite> SELECT COMMENT FROM Ports WHERE COMMENT LIKE '%statistics%'; 



# Die Beschreibung von allen Ports mit den Namen "zsh"

sqlite> SELECT FULLPKGPATH,COMMENT FROM PORTS WHERE FULLPKGNAME LIKE 'zsh%';



# Alle Ports die Gmake, aber nicht libtool benoetigen

sqlite> SELECT DISTINCT FULLPKGPATH FROM Ports WHERE USE_GMAKE=1 AND USE_LIBTOOL IS NULL;



# Die FLAVORS von vim anzeigen lassen

sqlite> SELECT FULLPKGPATH,FLAVORS FROM PORTS WHERE FULLPKGNAME LIKE 'vim%';

Wenn sich ein make eines x-beliebigen Ports mit

ftp: unknown option -- k

usage: ftp [-46AadEegimnptVv] [-P port] [-r seconds] [host [port]]

       ftp [-o output] ftp://[user:password@]host[:port]/file[/]

       ftp [-o output] http://host[:port]/file

       ftp [-o output] https://host[:port]/file

       ftp [-o output] host:[/path/]file[/]

verabschiedet, dann liegt das nicht daran das OpenBSD Scheisse ist, sondern ist PEBKAC. In OpenBSD 4.2 wurde eine keep-alive Option implementiert. Da bringt es auch nichts mir zu sagen das ich ein arrogantes Arschloch bin, das wahrscheinlich mit einem Unix-Buch auf die Welt gekommen bin. Das einzige was da hilft, ist ein

$ cd /usr/src/usr.bin/ftp

$ sudo make clean

$ sudo make depend

$ sudo make && sudo make install

Manchmal glaube ich wirklich das einige User geborene Masochisten sind. Anders kann ich es mir nicht erklaeren wie man auf die Idee kommt von 3.9 auf 4.0, von 4.0 auf 4.1 und anschliessend auf 4.2 upzudaten. Wahrscheinlich empfinden das einige einfacher als ${HOME}, /etc und die Ausgabe von pkg_info in eine Datei umzuleiten, anschliessend komplett neu installieren und die Packages neu zu einspielen.
Manchmal will ich wirklich nicht alles verstehen..

Heute musste ich kurz zu $FIRMA, weil diese Probleme mit Logins auf einem Server hatten, den ich erst vor kurzem aufgesetzt hatte. Das innerhalb der ersten zwei Minuten ~10 Mal "Ich hab wirklich nichts daran geaendert!" kam, muss ich nicht extra erwaehnen oder? Der "Hauptadmin" war letzte Woche nicht da, so dass sein Stellvertreter (21 Jahre und Sohn eines Anzugtraegers) seine Unfaehigkeit am Server unter Beweis stellen konnte. $FIRMA wollte das bestimmte lokale User keine richtige Loginshell mehr haben, damit diese nicht auf die Idee kommen, sich via ssh(1) einzuloggen, sondern brav mit ftp(1) arbeiten. Normalerweise kein Problem. vipw als root, /bin/false fuer alle User die es betrifft und der Fall hat sich. Ganz einfach.. theoretisch zumindest.
Der stellv. Admin war naemlich mit vipw(8) ueberfordert; das ist per Default bei OpenBSD naemlich vi(1). nvi(1) um genau zu sein; also nicht so komfortabel wie Vim. Nachdem er versucht hat (Betonung liegt auf "versucht") die Loginshells fuer die User zu aendern, enthielt die /etc/passwd ploetzlich Zeilen wie :q!^I, exit und was weiss ich noch alles. Ausserdem hat er fuer root /bin/bash als Shell angegeben. Kann man ja auch machen, allerdings sollte man dabei zwei Sachen beruecksichtigen:
1.) $PORTSDIR/shells/bash muss installiert sein und
2.) /usr/local/bin/bash muss in der /etc/shells stehen.
Abgebrueht ist er aber schon irgendwie. Den Scheiss hat er am Donnerstag fabriziert, sich am Freitag nicht mehr darum gekuemmert und ist dann in aller Seelenruhe ins Wochenende gefahren. Der Admin hat ihn heute mit blutunterlaufenen Augen angesehen und war kurz davor ihn zu lynchen, weil der Server vier Tage unbrauchbar war und laut den Logfiles knapp 8000 fehlgeschlagene Logins verzeichnet waren. Nachdem $OBERCHEF angetrabt kam und ich ihm erklaert habe was - und wie es - passiert ist, bezweifle ich ernsthaft das der stellv. Admin noch laenger in dieser Firma taetig ist. Ich geh jetzt erstmal ins Internetcafé und trink 'n Cappuccino.
Ich liebe solche Montage. Ehrlich!