Im develop branch laufen alle aktuellen Entwicklungen zusammen, z. B. wenn ein Entwickler meint, er habe sein feature fertig: es wird zurück in den develop branch gebracht. Vorher hat der Entwickler (weil wir ja gern TDD machen) sichergestellt, dass das feature eine ausreichende Unit Test Abdeckung hat. Für ihn persönlich sollte es also ausreichend sein auf diese zu achten. Eine persönliche CI für sein feature wäre sicherlich ein adminitrativer overkill: ist das feature klein wird es sicher schnell fertig, dafür extra einen neuen CI job aufsetzen und nach Beendigung der feature Entwicklung wieder löschen?! Ne!

Der release branch benötigt aus anderen Gründen keine CI: er unterliegt nur einer kurzen Zeit wirklicher Entwicklungsarbeit: während der Erstellung eines Release.

Wichtiger ist dann schon der master branch. Er enthält den Source Code der aktuell in der Produktion verwendet wird. Aber: gegen ihn werden auch hotfixes durchgeführt! Also Änderungen am Produktions Kode. Diese sollten frühzeitig mit CI abgedeckt werden, jeder hotfix branch sollte also einen eigenen CI job haben. Ist der hotfix gut und es werden keine Integrationsfehler (mit dem Produktions Kode) mehr festgestellt, dann ist der hotfix fertig in den master branch überzugehen (und in develop).

Diese Anleitung beschreibt kurz die Installation und Konfiguration eines Kerberos Servers und eines OpenAFS Server unter Debian GNU/Linux. In der ganzen Anleitung werden als Beispiele die Domain example.com und das IP-Netz 10.0.0.0/24 verwendet.

Voraussetzungen

Es werden neue Pakete auf dem Debian GNU/Linux System installiert, diese müssen bereitgestellt werden. Desweiteren muss das Netzwerk zu einem Client funktionsfähig sein.

Der Kerberos und OpenAFS Server wird im Beispiel auf dem gleichen System installiert: 10.0.0.11.

DNS

Damit Kerberos und OpenAFS optimal funktionieren sind einige DNS Einträge in der Zone example.com zu machen:

kerberos                IN      A       10.0.0.11
afs                     IN      A       10.0.0.11
_kerberos               IN      TXT     "EXAMPLE.COM"
_kerberos-master._udp   IN      SRV     0 0 88 kerberos
_kerberos-adm._tcp      IN      SRV     0 0 749 kerberos
_kpasswd._udp           IN      SRV     0 0 464 Kerberos
_kerberos._udp          IN      SRV     0 0 88 kerberos
EXAMPLE.COM.            IN      AFSDB   1 afs.example.com.

In allen Dokumentationen wird immer wieder darauf hingewiesen, dass es wichtig ist auf die Gross-/Kleinschreibung zu achten: das Kerberos realm wird immer komplett gross geschrieben und die AFS cell immer komplett klein. Zur vereinfachung geht diese Anleitung davon aus, dass die realm und die cell den gleichen Namen tragen.

Kerberos Installation

Die Installation der Kerberos Software geht recht schnell, apt-get install krb5-kdc krb5-admin-server krb5-clients ; krb5_newrealm. Die Fragen die apt-get muss man beantworten. Die Konfiguration von Kerberos findet vor allem in /etc/krb5.conf statt. Hier ist wichtig, dass default_realm und EXAMPLE.COM in der Sektion <realms> richtig konfiguriert ist.
Als nächstes wird ein principal (also ein Account) für einen Benutzer angelegt, dieser wird administrative Rechte erhalten und später den OpenAFS server verwalten.

kadmin.local -q "addprinc user@EXAMPLE.COM"
kadmin.local -q "addprinc user/admin@EXAMPLE.COM"

user/admin@EXAMPLE.COM muss jetzt in /etc/krb5kdc/kadm5.acl der Eintrag user/admin@EXAMPLE.COM * sorgt dafür das dieser principal vollen Zugriff auf die Kerberos Datenbank erhält.

Mittels kinit user/admin und dem richtigen Passwort sollte man die entsprechenden Ticket vom Kerberos Server bekommen (verifizierbar mittels klist).

OpenAFS Installation

apt-get install openafs-dbserver openafs-krb5 openafs-client installiert die OpenAFS Basis, hierbei ist darauf zu achten, dass openafs-client nicht nacht der Installation des Paketes oder nach dem booten gestartet wird. Die Antworten auf die Fragen von apt-get sollten klar sein. Zur Verifikation der Installation sollte in /etc/openafs/CellServDB der Zellenname mit der IP-Adress 10.0.0.11 enthalten sein. /etc/openafs/ThisCall sollte den Zellennamen enthalten.

OpenAFS Kernel Modules

Die Kernel Module für OpenAFS müssen wahrscheinlich auf dem Server kompiliert werden, am schnellsten geht es mit:

apt-get install module-assistant
module-assistant prepare openafs-modules
module-assistant auto-build openafs-modules

Kerberos: AFS principal anlegen

Für die Administration von OpenAFS wird ein separater principal angelegt. Hierzu wird kadmin.local genutzt und folgende Befehle

addprinc -randkey -e des-cbc-crc:v4 afs
ktadd -k /tmp/afs.keytab -e des-cbc-crc:v4 afs

Dieser principal wird mit asetkey add <kvno> /tmp/afs.keytab afs in die OpenAFS Konfiguration übernommen und im Keyfile abgelegt. kvno ist die kvno die von kadmin.local ausgegeben wurde.

Anlegen der root.cell

Als nächstes muss eine root.cell angelegt werden, hierzu nutzt OpenAFS initial die Partition /vicepa, dies muss eine Partition sein. Der Schnellstart wäre eine mittels loop gemountete Datei:

dd if=/dev/zero of=/var/lib/openafs/vicepa bs=1024k count=64
mke2fs /var/lib/openafs/vicepa
mkdir /vicepa
mount -oloop /var/lib/openafs/vicepa /vicepa

Den Eintrag in /etc/fstab zum automatischen mounten während des booten sollte man nicht vergessen!

Das Skript afs-newcell führt die entsprechende Konfiguration zum anlegen einer neuen Zell durch. kinit user/admin; aklog holt vom Kerberos mit adminitrativen Rechten ausgestattete Tickets und überträgt sie in ein entsprechendes OpenAFS Token. Dies muss mittels tokens sichtbar sein. afs-rootcell legt die root.cell auf dem Server an. Idealerweise bootet man den server jetzt neu – Muss aber nicht.

Einen Benutzer anlegen

Nachdem der Server läuft wird in diesem Abschnitt beschrieben wie ein neuer Benutzer und ein Datenbereich für diesen angelegt.

Benutzer anlegen

Mit kadmin.local fügt man einen neuen principal in die Kerberos Datenbank an: add benutzer, danach wird dieser Benutzer auch im OpenAFS angelegt:
pts createuser benutzer -id 501

Datenbereich

Auf dem OpenAFS Server wird jetzt ein volume für den Benutzer angelegt, ihm werden alle Rechte auf diesen Datenbereich zugesichert und die quota auf 0 (unbegrenzt) gesetzt:

vos create afs /vicepa user.benutzer -maxquota 0
cd /afs/.example.com/user 
fs mkm benutzer user.benutzer 
chown benutzer benutzer 
fs sa benutzer benutzer all  
fs sa benutzer system:authuser l 
vos release user 
fs checkvolumes 

MacOSX Client

Nach der Installation des OpenAFS for MacOS 10 Client ist für diesen die CellServDB und ThisCell in /var/db/openafs/etc anzupassen. In der CellServDB muss mindestens

example.com  # example
10.0.0.11      # afs.example.com

enthalten sein. Nach den # folgt kein Kommentar, sondern genutzte Daten!

zusätzliche Authentisierung

Zusätzlich zur Authentisierung unter MacOS muss man auf dem Client mittels des Terminals auch ein Kerberos Ticket und ein OpenAFS Token vom Server erfragen:

kinit benutzer
aklog
tokens

tokens listet dabei nur die AFS tokens auf.

Jetzt sollte man vollen schreib/lese-Zugriff auf /afs/example.com/daten/benutzer auf dem MacOS client haben.

Quellen

• DFN Cert OpenAFS
• Bayour LDAPv3 Howto
• OpenAFS for MacOS 10
• Mac OS X Kerberos Extras

Ich mein… Hallo?? Ihr nehmt keine EC Karte der Deutschen Bank?

Also raus auss’m Rossmann, 4m weiter rein in’n DM und alles wird gut.

As I go along with julian’s paradigm of “implement something and if it works publish it” I’ve done my pubsub experiments. The hardest part for me as a non-programmer was to get the application talk to the pub/sub service. I use python, so there is no library that contains JEP-0060 support at all.

Publication/subscription service
In addition to the server PubSub Components we need some projects focusing on implementing the client side library, for Python or C# or both. I’ve done parts of this, but I think they are to crappy to make it into public. ralphm told me that maybe he is going to make a Python library for JEP-0060. We must support him!

Encryption
On another frontier I have tried to get client to client GPG encryption working; macosx to macosx and macosx to linux. I used Fire.app and Psi on macosx and Gabber and Psi on Linux. All of the clients are not very interoperable, only Psi/macosx to Psi/Linux works which encryption and signing. Why is that? I understand that there is JEP-0027 and JEP-0116, both are kind of outdated, because there is RFC3923, which is not implemented by and client.

Move things forward
I guess there is some kind of “moving things forward masterplan”… but where is it? May I read it?