A duck is like a bicycle because they both have two wheels except the duck.
- Terry Lambert

15.10.2023

Beaglebone Black FreeBSD microSD auf eMMC kopieren

Gestern musste ich auf einem Beaglebone Black das FreeBSD auf 13.2 updaten, d.h. das Image herunterladen, per Balnea Etcher auf eine SD kopieren, rein in den SD Slot und booten des Beaglebone davon. Danach stellte sich wie üblich die Frage, wie ich jetzt das SD Image auf die interne eMMC des Beaglebone bekomme. Es gibt das copy2emmc.sh Script aus dem Crochet, das aber schon damals nicht so richtig funktionierte. Auf github ist das aktuelle Crochet verfügbar, aber das copy2emmc.sh Script tut's auch hier nicht. In den FreeBSD Foren tauschen sich auch ein paar Menschen über dieses Problem aus.

Hier unten gibts nun die Version, mit der ich das FreeBSD 13.2 derart auf die eMMC kopieren konnte, das es anschliessend von dort lauffähig ist:

- der MBR der eMMC wird gelöscht

- es wird eine "MSDOS FAT32 (LBA)" eingerichtet, derzeit 50MB

- es wird der MSDOS Teil komplett von der SD auf das Ziel kopiert

- es wird eine FreeBSD Partition angelegt, in diesem Falle ca. 3,4 GB

- fast die gesamte das FreeBSD 13.2 root partition der SD wird auf die eMMC kopiert

- mtree über bestimmte Bereiche laufen lassen

- versuch, auf dem Ziel ssh keys zu löschen

- eine fstab erstellen und auf dem Ziel installieren

- syncen, immer noch auf /mnt gemountet, bitte unmounten !

echo 'Erasing /dev/mmcsd1!'
dd if=/dev/zero of=/dev/mmcsd1 bs=64k count=1

echo
echo 'Creating MSDOS FAT32 (LBA) boot partition on eMMC'
gpart create -s mbr mmcsd1
gpart add -s 50m -t '!12' mmcsd1
gpart set -a active -i 1 mmcsd1
newfs_msdos -L 'EMMCBOOT' -F 32 -c 1 /dev/mmcsd1s1

echo
echo 'Copying boot files to eMMC boot partition'
mount_msdosfs /dev/mmcsd1s1 /mnt
cp -r /boot/msdos/* /mnt
echo 'loaderdev=disk1' >>/mnt/bb-uenv.txt
sync
umount /mnt

echo
echo 'Creating FreeBSD partition on eMMC'
gpart add -t freebsd mmcsd1
gpart create -s BSD mmcsd1s2
gpart add -t freebsd-ufs -a 32k mmcsd1s2
newfs /dev/mmcsd1s2a
tunefs -N enable -j enable -t enable -L 'eMMCroot' /dev/mmcsd1s2a
mount /dev/mmcsd1s2a /mnt

echo
echo 'Copying the system from SD to eMMC'

tar -c -f - -C / \
    --exclude usr/src \
    --exclude usr/ports \
    --exclude usr/obj \
    --exclude 'usr/swap*' \
    --exclude mnt \
    --exclude .sujournal \
    --exclude var/run \
    --exclude dev \
    . \
| tar -x -f - -C /mnt

echo
echo 'Cleaning up the copied system'
# Reset permissions, ensure the required directories
(cd /mnt ; mtree -Uief /etc/mtree/BSD.root.dist)
(cd /mnt/usr ; mtree -Uief /etc/mtree/BSD.usr.dist)
(cd /mnt/usr/include ; mtree -Uief /etc/mtree/BSD.include.dist)
(cd /mnt/var ; mtree -Uief /etc/mtree/BSD.var.dist)
# Have the copied system generate its own keys
# (In particular, if this SD card is used to copy
# a system onto a bunch of BBBlacks, we do not want
# them to all have the same SSH keys.)
rm -f /mnt/etc/ssh/*key*

echo
echo 'Replacing fstab on eMMC'
cat <<EOF >/mnt/etc/fstab
/dev/msdosfs/EMMCBOOT /boot/msdos msdosfs rw,noatime       0 0
/dev/ufs/eMMCroot     /           ufs     rw               1 1
tmpfs                 /tmp        tmpfs   rw,mode=1777     0 0
EOF
echo
cat /mnt/etc/fstab
echo

sync; sync; sync

echo
echo 'System copied.'
echo
echo 'eMMC root filesystem is still mounted on /mnt'

26.7.2023

Wildcard Zertifikate von CAcert für interne private Netze
oder der Fluch der guten Tat

Das Management der Systemüberwachung findet heute per Web-Browser statt, die in irgendwelchen internen Netzen sitzen und dann bestimmte Überwachungsaufgaben durchführen. Da diese Systeme ausschliesslich intern mit privaten Netzen kommunizieren, sind alle Web-Seiten via Port 80 http zu erreichen.

Seit langer Zeit mag der Firefox das nicht mehr und versucht, die Seiten nach mehr oder minder langer Zeit per https Port 443 zu erreichen. Das schlägt fehl. Aus diesem Zustand komme ich nur per Cache löschen raus. Nervig. Ich scheine nicht der einzige zu sein. Nach langem Experimentieren mit letsencrypt etc. etc. hab ichs heute mal mit einem Wildcard Zertifikat von CAcert probiert, und siehe da, kein Problem. Zertifikat erzeugen mit Namen z.B. "*.example.com", rein ins Apache Konfig File, sehr sehr schön, ab sofort keine Hänger mehr.

4.5.2023

An unserem privaten Internet Anschluß von Wilhelm Tel gibt's nachts neue IP Adressen. Für den IPv4 Teil gibts da schon immer NAT, bei IPv6 wusste ich zuerst nicht . . . Ausserdem hatte ich sixxs Adressen, und als sixxs die Einstellung des Betriebs ankündigte, musste etwas geschehen. Mein netter Firewall Hersteller hat aus offensichtlichen Gründen kein IPv6 NAT implementiert, deshalb habe ich eine kleine IPv6 NAT Appliance drumherum gebaut, seitdem ist Ruhe.

Letztens habe ich dieses Projekt bei einem Treffen der GUUG SAGE Hamburg vorgestellt, das PDF der Slides ist hier zu finden.

29.11.2022

Eine Anzeige musste her. Da finde ich doch beim Aufräumen einen alten Raspberry Pi und möchte nun eine LED Matrix Anzeige per SPI anschliessen, gesagt -  getan ? Nee, nicht ganz. Wie ging das denn noch gleich mit Gottes eigenem Betriebssystem? Lange her, das ich mit Hardware gespielt habe.

1. gehe zu https://download.freebsd.org/ftp/releases/arm/armv6/ISO-IMAGES/13.1/ und hole dort FreeBSD-13.1-RELEASE-arm-armv6-RPI-B.img.xz
2. dekomprimiere die Datei, auf dem Mac benutze ich keka dafür, was auch immer das heisst, es funktioniert, benutze es schon lange
3. kopiere das Image auf eine SD Karte, nach langem gefummel mit diskinfo und dd habe ich den balneaEtcher gefunden, einwandfrei
4. sieh' zu, das du die resultierenden Filesysteme der SD Karte WIRKLICH SAUBER unmountest (!!) bevor die SD Karte gezogen wird
5. stecke die SD Karte in den Raspi, verbinde das LAN Kabel und gib dem Raspi Strom. Die rote LED leuchtet dauerhaft, die grüne flackert zu Anfang ein bisschen und wenn das Ding da ist, flackern die beiden grünen und die gelbe LED vom Netzwerk Phy
6. suche die vergebene IP-Adresse im Logfile deines DHCP Servers
7. final gibts ein "ssh freebsd@IP-Adresse" mit Passwort freebsd.
8. sieh' zu, das die Zeit gesetzt wird, aktiviere ntp in der /etc/rc.conf
9. im Verzeichnis /boot/msdos/dtb/overlays gibt es die Datei spigen-rpi-b.dtbo, diese bitte nach /boot/msdos/overlays kopieren
10. in der Datei /boot/msdos/config.txt die Zeile "dtoverlay=spigen-rpi-b" anhängen
11. in der Datei /boot/loader.conf die Zeile "spigen_load="YES" hinten anfügen
12. den Raspi mit "shutdown -r now" neu starten

In der Ausgabe von "dmesg" sollte nun

spi0: <BCM2708/2835 SPI controller> mem 0x7e204000-0x7e2041ff irq 10 on simplebus0
spibus0: <OFW SPI bus> on spi0
spigen0: <SPI Generic IO> at cs 1 mode 0 on spibus0
spigen1: <SPI Generic IO> at cs 0 mode 0 on spibus0
spibus0: <unknown card> at cs 0 mode 0
spibus0: <unknown card> at cs 1 mode 0

erscheinen, in der Ausgabe von "kldstat -v | grep spi" dieses

134 simplebus/bcm2835_spi
         55 spi/spibus
         54 spi/ofw_spibus
 2    1 0xc0a95000    23130 spigen.ko (/boot/kernel/spigen.ko)
          1 spibus/spigen

erscheinen und "ll /dev/spi*" sollte jetzt zwei Devicefiles anzeigen:

crw-rw----  1 root  operator  0x2e Nov 29 14:55 /dev/spigen0.0
crw-rw----  1 root  operator  0x2d Nov 29 14:55 /dev/spigen0.1

 Und jetzt fängt's erst richtig an :-)  -  wie gut, das draussen so richtig pissiges, kaltes, nasses Novemberwetter ist.

1.12.2021

Auf meinem Weg zu einem kleinen Computer mit zwei Ethernet GBit Interfaces bin ich über dieses Ding hier (oder auch hier ohne Verkleidung) gestolpert, das ist ein "Dual Gigabit Ethernet NICs Carrier Board for Raspberry Pi CM4".

Macht einen guten Eindruck. FreeBSD 13 läuft ohne Änderungen und mit nur sehr kleinen Problemen dabei. Ich war wirklich überrascht. Da haben 'ne Menge Leute gute Arbeit gemacht. Danke!

Das Ding wird heiss. Nur mit dem Aludeckel als Kühlung zeigt sysctl dev.cpu.0.temperature ohne alles so 45 bis 49 Grad Celsius an, wenn er was tut (make kernel) geht das auch schon nach 65 bis 70 Grad hoch.

Da hatte ich noch einen Kühlkörper von 400 MHz HP PA-RISC CPU's gefunden und mit Gel-Pads dazwischen gibt es jetzt 36 Grad im Leerlauf und 10 Grad mehr, wenn er was zu tun hat.

Nachtrag 10/2023: Dokumenatation zu dem Teil gibt es hier bei seedstudio.

14.10.2018

rudimentärer Clavister Support für LibreNMS

Eines der von mir benutzen Netzwerk Monitoring Systeme ist LibreNMS, für das ich vor Jahren mal ein wenig Code zum Support von Clavister Firewalls geschrieben habe. Nach einer Neuinstallation habe ich die dafür relevanten Dateien zusammengetart und hier verfügbar gemacht.

 Einige Anmerkungen dazu:

• Das von mir hier verwendete LibreNMS ist in der Version 1.43 aus den FreeBSD Ports und läuft bei mir unter FreeBSD 11-Stable.

• Der geneigte Leser muß sich die MIB's noch von von Clavister herunterladen (man suche nach "mib" im Download Bereich, dann findet man sie auch) und a) im Verzeichnis "mibs" auspacken und b) ein Verzeichnis "clavister" unter "mibs" erstellen und dort auch nochmal auspacken.

• In der Datei includes/definitions/discovery/clavister-cos.yaml ist die MIB als absoluter Filename spezifiziert. Ohne diesen findet snmpbulkwalk die Clavister-MIB nicht. Auch nach viel Doku lesen und rumprobieren ist mir nicht ersichtlich, warum das so sein muß. Dieser absolute Filename muß auf anderen Systemen sicherlich angepasst werden!

1.10.2018

bind/named DNS Firewall  =  DNS Response Policy Zone (RPZ)

Es gibt immer wieder einige Domains, die möchte man nicht besuchen und man möchte auch nicht "besucht werden", meist durch komische Webseiten oder Scripte oder sonstwas. Bisher habe ich soetwas durch URL Blacklists in einem ALG in der Firewall meines Vertrauens erledigen lassen. Aber seit die Masse der Webseiten per https:// erreichbar ist, funktioniert das aus offensichtlichen Gründen nicht mehr.

Vor einiger Zeit bin ich nun auf "DNS Firewalls" oder Response Policy Zones im bind gestossen. Grob gesagt, werden dabei Domains so umgeschrieben, das sie nicht mehr auflösbar sind und dann ins Leere laufen. "Ins Leere" kann dabei auch eine eigene Webseite sein, auf der der Benutzer dann darüber informiert wird, was mit seinem Aufruf gerade geschieht. Voraussetzung dafür ist natürlich, das der so konfigurierte bind/named vom eigenen Resolver genutzt wird.

Im einfachsten Fall geht das so: in die "options" Section von named.conf wird der Name der Response Policy Zone konfiguriert, hier heisst sie "rpz.hallstr.de":

response-policy {
        zone "rpz.hallstr.de";
};

Etwas weiter wird dann das Zonenfile benannt, in meinem Fall das File "db.rpz" im Verzeichnis "master":

zone "rpz.hallstr.de"{
        type master;
        file "master/db.rpz";
};

Die Datei db.rpz sieht dann schliesslich in etwa so aus:

$TTL    2h
$ORIGIN rpz.hallstr.de.

@        SOA                    nixda.nowhere.noplace. nobody.nowhere.noplace. (
                                2018100106      ; Serial
                                12h             ; Refresh
                                15m             ; Retry every
                                3w              ; Expire after
                                2h )            ; Minimum ttl

                                NS              nixda.nowhere.noplace.

waddehaddedudennda.com          CNAME           rpz.hallstr.de.
*.waddehaddedudennda.com        CNAME           rpz.hallstr.de.

.. und das bewirkt, das die Domain waddehaddedudennda.com und alle ihre Subdomains nicht mehr erreichbar sind. Wer mag, kann das auch auf IP Adressen anwenden, ist in unserem Fall unnötig.

Etwas ausführlicher ist das bei zytrax.com und bei der IETF und beim ISC beschrieben.

FreeBSD 11: TCP hostcache formatiert anzeigen und ggf. löschen    (Februar 2017) 

Lange Zeit wurde ich von einem Fehler geplagt (siehe weiter unten "pf + ipv6 path mtu discovery" ), von dem ich nun herausgefunden habe, das das kein Fehler im FreeBSD ist. Im Zuge der Fehlersuche entstand ein perl script, mit dem man sich den TCP Hostcache im FreeBSD formatiert anschauen kann, nach verschiedenen Kriterien die angezeigten Daten auswählen kann und bei Bedarf (geht erst ab FreeBSD 11) den Hostcache löschen kann (welcher sich dann nach und nach wieder aufbaut). Nötig wurde das Ganze, weil in diesem Hostcache Änderungen der MTU eingetragen werden, die durch IPv6 ICMP "packet too big" Pakete angestossen worden sind. Diese Änderungen der MTU für bestimmte Hosts sind damit sichtbar und rückgängig zu machen.

Erklärungen zu den angezeigten Feldern findet der geneigte Leser unter /usr/src/sys/netinet/tcp_hostcache.h, Parameter werden wie üblich durch -h erklärt, manpage gibt's nicht.

Das perl Script ist, wie bei solchen Dingen üblich, nicht das Allerschönste, aber es tut was es soll: dies ist der Link zum Download.

FreeBSD auf Beaglebone Black von interner eMMC booten    (Februar 2017)

Mit crochet kann man ganz hervorragend FreeBSD Images erstellen, die dann auf eine SD geschrieben werden, von der dann ein Beaglebone bootet. Der Beaglebone Black hat aber auch eine eingebaute SD (oder besser eMMC), von der der Beaglebone potentiell auch booten kann. Auf einem laufenden Beaglebone findet man unter /root das script copy-to-emmc.sh, das aber - zumindest bei mir - noch nie funktioniert hat, führt man es aus und versucht man danach von der eMMC zu booten, schlägt das fehl. Es scheint, das der gpart Befehl, wenn er auf einem Beaglebone selbst ausgeführt wird, zu merkwürdigen Ergebnissen führt.

Um das aber jetzt zum laufen zu bekommen, habe ich das Script abgeändert, so das jetzt fdisk statt gpart zur Erstellung der DOS Partiotion benutzt wird und dann funktioniert das Ganze. Wenn man jetzt von der eMMC bootet, wirft der Beaglebone Loader Massen von „Card did not respond to voltage select!“ Meldungen aus, das hört aber auf, sobald der kernel gestartet ist.

Den diff gibt's hier: https://people.freebsd.org/~hm/misc/copy-to-emmc.sh.diff

ssh brute force Attacken auf FreeBSD 10.x minimieren    (Mai 2016)

Seit langer Zeit nerven mich die völlig sinnlosen Attacken auf meine ssh Ports auf den diversen Servern. Ich benutze schon lange z.B. sshguard und pf brute force Regeln, aber so richtig befriedigend ist das nicht. Nun schaue ich mir von Zeit zu Zeit an, woher die Attacken denn so kommen und sehe meist immer die gleichen IP Bereiche aus den immer gleichen Teilen der Welt.

Neulich nun hat Clavister eine neue Version seiner Firewallsoftware herausgebracht, mit der es auf Basis von Geo-Lokationsdaten möglich ist, IP Datenströme zu filtern: schöne Sache, nach entsprechender Konfiguration hört der Spuk einfach auf und es ist ziemlich Ruhe !

Da ich auch einige Rechner nur mit pf Firewall betreibe, habe ich mir etwas ähnliches mit FreeBSD Bordmitteln gebaut: Basis sind die frei verfügbaren Datenbanken der Firma MaxMind ( Danke sehr !!! ), die man hier bekommen kann und die einmal pro Monat upgedatet werden, das reicht für meine Zwecke völlig aus. Die Datenbank wird geholt, die IP Adressen/Ranges der gewünschten Länder extrahiert (das Länder File pf_blck_countries.txt ist ein Text File, in dem einfach Zeile für Zeile die nicht gewünschten Länder - Englisch - eingetragen sind) und in ein pf-lesbares Tabellenformat gewandelt. Den Rest erledigt eine pf-Regel in /etc/pf.conf. Das shell script, das das tut, hängt unten dran, das Programm tableutil gibts in den Ports (net/tableutil) und dann braucht man noch zwei Zeilen in /etc/pf.conf: eine Zeile deklariert die Tabelle (aus Datei /var/db/pf/blocked.ip4) und eine Zeile blockt darauf basierend - fertig. Nicht ganz, ein crontab-entry der das einmal pro Monat ausführt wird benötigt (und pf nicht vergessen zu reloaden !).

#!/bin/sh
#---------------------------------------------------------------------------
#
#       update_geoip_dbs 
#       ----------------
#
#       Hellmuth Michaelis, hm@m-bit.net
#
#       last edit-date: [Sun May  1 17:03:16 2016]
#
#       - fetch free IP geolocation database
#       - extract needed county ip adresses
#       - convert to pf table format
#
#---------------------------------------------------------------------------
LDIR=/usr/local/share/GeoIP
GIPCL=GeoIPCountryCSV.zip
GIP4=http://geolite.maxmind.com/download/geoip/database/$GIPCL
GIPCSV=GeoIPCountryWhois.csv
PFLIST=/var/db/pf/blocked.ip4
CLIST=/usr/local/etc/pf_blck_countries.txt

# cd to dest dir, create if necessary
cd $LDIR
if [ $? != 0 ]
then
        mkdir -p $LDIR
        cd $LDIR
        if [ $? != 0 ]
        then
                echo "ERROR, cannot create $LDIR, exit"
                exit 1
        fi
fi

# check if country list file exists
if [ ! -s $CLIST ]
then
        echo "ERROR, $CLIST nonexistent or empty, exit"
        exit 1
fi

# get free IP geolocation database
fetch $GIP4
if [ $? != 0 ]
then
        echo "ERROR, cannot fetch $GIP4, exit"
        exit 1
fi

# move old csv out of our way
if [ -f $GIPCSV ]
then
        mv $GIPCSV $GIPCSV.bak
fi

# unzip database
unzip $GIPCL
if [ $? != 0 ]
then
        echo "ERROR, cannot unzip $GIPCL, exit"
        exit 1
fi

# remove zip-file
rm $GIPCL

# move old filter table to backup
if [ -f $PFLIST ]
then
        mv $PFLIST $PFLIST.bak
fi

# grep: filter only the needed ip's based on country in country file
# awk: filter only the ip address ranges
# sed: remove the remaining "'s
# tableutil: convert ip address ranges into cidr representation
grep -i -f $CLIST $GIPCSV | awk '{ FS=","; print $1 "-" $2 }' | sed 's/"//g' | tableutil -q text > $PFLIST

exit 0

# EOF

IPv6 DHCP client unter FreeBSD 10.2   (August 2015)

Um einen Rechner automatisch unter FreeBSD 10.2 mit einer IPv6 Adresse zu versorgen, gibt es mehrere Möglichkeiten. Um das per IPv6 DHCP zu tun, braucht man einen dhcp v6 client - der muß aus den ports installiert werden weil soetwas bis jetzt nicht im Basissystem enthalten ist; der mitgelieferte dhclient kann kein IPv6 DHCP. Ich habe den dhcp6 KAME DHCP6 client ausprobiert (/usr/ports/net/dhcp6) - der tat auf Anhieb das, was ich brauchte.

Zur Konfiguration vom dhcp6 client bedarf es eines Konfigurationsfiles /usr/local/etc/dhcp6c.conf, das sieht bei mir so aus:

interface re0 {
     send ia-na 0;
};

id-assoc na {
};

Das Interface, um das es geht, ist "re0". In der Datei /etc/rc.conf sieht es diesbezüglich so aus:

ifconfig_re0_ipv6="inet6 accept_rtadv"

dhcp6c_enable="YES"
dhcp6c_interfaces="re0"

Nachdem diese Einträge gemacht worden sind, funktioniert das schon ganz gut, aber ich möchte wieder fest zugeordnete IP Adressen haben, damit das mit meinem DNS harmoniert.

Der besagte KAME dhcp6 client legt im Verzeichnis /var/db eine Datei "dhcp6c_duid" an, in der die DUID des clients zu finden ist. Das ist eine Binärdatei, die man sich als hexdump mit "hd" angucken kann, also lautet das Kommando: "hd /var/db/dhcp6c_duid", hier sieht das so aus:

00000000  0e 00 00 01 00 01 1d 67  0c 76 00 0d ww xx yy zz |.......g.v......|

Hiermit kann man nun den Eintrag in ein ISC dhcp v6 Server Konfigurationsfile vornehmen (die beiden ersten Blöcke "0e 00" löschen und nur den Rest verwenden):

host mein_rechner {        
        host-identifier option dhcp6.client-id 00:01:00:01:1d:67:0c:76:00:0d:ww:xx:yy:zz;
        fixed-address6 2001:nnnn:mmmm:pppp::49;
}

und schwupp - geht's schon.

pf + ipv6 path mtu discovery   (Mai 2014)

Es gibt offenbar ein Problem mit IPv6 Path MTU Discovery unter aktuellen FreeBSD Versionen (10.x) im Zusammenhang mit der Benutzung des pf-Paketfilters. Die Auswirkungen sind derart, das wenn dieses Phaenomen auftritt, "hängende" IPv6 Verbindungen zu beobachten sind. Genaueres hierzu ist in einer Mail an freebsd-net zu finden. Einen patch mit einem Workaround (es ist wirklich ein Hack und nicht im geringsten ein Fix) findet der geneigte Leser hier - die Datei /usr/src/sys/netpfil/pf/pf.c wird derart gepatcht, das bei einem IPv6 ICMP Packet Too Big Fehler (von dem der pf denkt, es sei fehlerhaft) das Paket vom pf an den Stack durchgelassen wird. Damit funktioniert es dann wieder . . .

Update 02/2017: der Fehler liegt nicht im FreeBSD oder im pf-Paketfilter. Die zwischen den FreeBSD Instanzen liegende Firewall verändert die TCP Sequence Nummern, allerdings werden in dem durch die Firewall gehende ICMP "packet too big" Paket in der damaligen Konfiguration die darin enthaltenen Fragmente der verursachenden TCP Pakete nicht die Sequence Nummern geändert, so das die Validierung der Sequence Nummer durch den pf fehl schlägt und das Paket verworfen wird und daher keine Änderung der MTU vorgenommen wird.

openssl / Heartbleed   (April 2014)

Auch dieser Webserver ist vom openssl Heartbleed bug betroffen gewesen. Genaueres dazu findet der geneigte Leser im CAcert Blog. Am 12.4.2014 ist sowohl openssl auf eine nicht betroffene Version upgegradet worden als auch ein neues CAcert Zertifikat für diese Webseite generiert und installiert worden.

Ob ein Webserver von diesem Bug betroffen ist, kann u.a. mit dem SSL Server Test getestet werden.

Genauere technische Informationen gibt es bei CVE und eine (nicht vollständige) Liste der betroffenen Produkte gibt es u.a. auf OSVDB.

SSL fingerprint T-Online   (März 2014)

T-Online hat ja - wie andere Provider auch - auf verschlüsselte Verbindungen zum Mailtransport umgestellt. Fetchmail benötigt u.a. SSL fingerprints der serverseitig verwendeten Zertifikate. Blöd ist nur, das T-Online diese Zertifikate offenbar von Zeit zu Zeit ändert, die Frequenz ist ziemlich hoch (dreimal innerhalb 2014 bis jetzt).

Der fingerprint wird so generiert: erstmal Zertifikat holen

openssl s_client -connect securepop.t-online.de:995 -showcerts > t-online.out

und dann das Zertifikat im Editor herausschnipseln und nach t-online.zertifikat speichen. Anschliessend mit

openssl x509 -in t-online.zertifikat -noout -fingerprint -md5

den fingerprint generieren und in die fetchmailrc eintragen.

Beaglebone Black   (Februar 2014)

Da der Raspberry Pi netzwerktechnisch nicht so performant ist, bin ich auf den Beaglebone Black gestossen. Der ist sowohl vom Ethernetinterface als auch on der CPU her merklich schneller als der Raspberry Pi, allerdings ist die Unterstützung seitens des FreeBSD Kernels noch nicht ganz so gut, er läuft stabil, aber man merkt, das da noch debuggt werden muß (ein Kernel ohne WITNESS und INVARIANTS bootet nicht, FreeBSD 11-current). "crochet" unterstützt den BBB und es ist ziemlich einfach zu bedienen und zu konfigurieren.

Raspberry Pi - "sixxsbox"     (Januar 2014)

Nachdem ich mit dem Raspberry Pi eine Zeit lang gespielt hatte, entschloß ich mich, meinen sixxs IPv6 Zugang auf den Pi zu verlegen. Hierzu habe ich eine möglichst kleine FreeBSD Installation gebaut, die zwar noch Verbesserungsmöglichkeiten bietet, aber im Grossen und Ganzen das tut, was ich erwarte.

Als Anlaufstellen zu FreeBSD auf dem Raspberry Pi gibt es eine Seite im FreeBSD Wiki, sowie die Seite kernelnomicon.org.

Das Netzwerkinterface des Raspberry Pi ist über (das interne) USB angeflanscht, die Netzwerkperformance ist nicht so berauschend, dieser Thread beschreibt das Problem. Um dieses Problem hat sich jemand gekümmert, es gibt einen Patch, der USB von polled auf DMA umstellt, es gibt aber offenbar noch "Nebenwirkungen". Ich habe nichts am USB angeschlossen und für mich funktioniert der Patch gut, er dreht die maximale Transferrate um 50%...100% hoch.

Dann hab ich noch "crochet" gefunden, um bootfähige FreeBSD Images zu bauen, das schaut ganz vielversprechend aus ...

Mein build script gibt es hier (ist eine Abwandlung des Scripts von kernelnomicon.org - meins ist wie alle diese Spiel-Dinge leicht grausam, der geneigte Anwender mag das vorher noch mal durchsehen ...), dazu gehört auch eine src.conf. Die Ports mounte ich mir per NFS und baue dann auf dem Pi das, was ich brauche. Da in src.conf auf die Text Tools und man-Pages verzichtet wird, fehlen beim Port bauen irgendwann "makeinfo" und "install-info". Einfach in /usr/local/bin "touch"-en und dann kann's weiter gehen.

Update 02/2014:
das sixxs-aiccu script startete nicht durch nach einem reboot, es stellte sich heraus, das die lokale Zeit nicht stimmte. Hintergrund ist, das der RPi keine RTC hat und den ntpd benötigt, um die Zeit zu setzen. Der ntpd wiederum benötigt aber eine Weile, bis er sich mit dem Server synchronisiert hat. Also muß - rcorder(8) ist dein Freund - das sixxs-aiccu script ganz zum Schluß laufen und das start command benötigt noch ein paar Sekunden sleep(1).

Upgrade auf bind 9.9.x - Probleme mit "views"     (Dezember 2013)

Nach einem Upgrade auf bind 9.9.3-P2 gab es Probleme mit views: in dem view, in dem Adressen rekursiv aufgelöst werden konnten, funktionierte genau das nicht mehr. Die Fehlermeldung im syslog war:

client 172.16.17.18#58510 (www.example.com): view recursion: query (cache) 'www.example.com/A/IN' denied

Es stellte sich heraus, das sich einige default Werte im neuen bind geändert hatten, ein allow-query-cache statement im entsprechenden view stellte das gewohnte Verhalten wieder her. Genauer beschreiben ist dies in einem Artikel der ISC Knowledge Base: What has changed in the behavior of "allow-recursion" and "allow-query-cache"

FreeBSD 10 (current/head) - "alten" C-Code kompilieren     (Juli 2013)

FreeBSD 10 benutzt einen neuen C-Compiler (CLANG) statt des bisher benutzten GNU C-Compilers im Basissystem. Der verhält sich nun in einigen Details anders ( = moderner ) so das es u.U. Probleme gibt, K&R und/oder c89 C-Sourcen zu übersetzen.

Die häufigste Fehlermeldung, über die ich gestolpert bin, ist:

file.c:nnn:nn: error: non-void function 'c_function' should return a > value [-Wreturn-type]

Dies ist jetzt ein Fehler und im Grunde muss man durch den ganzen alten Code durch (früher wurde void und int im Kontext function return nahezu gleich behandelt) - das ist nervig.

Ändern kann man dies Verhalten, indem man -Wno-return-type zu den CFLAGS hinzufügt, dann bekommt man das klassische Verhalten. Bisher kompilierte mein alter Code damit problemlos und ich habe auch keine Merkwürdigkeiten zur Laufzeit festgestellt.