Im heutigen HowTo geht es um das auf dem Spacewalk eingesetzte SSL Zertifikat.

Zertifikat erstellen

Während der Installation eines Satellite/Spacewalk Servers wird in der Regel ein selbst signiertes Zertifikat erstellt (falls die Option --skip-ssl-cert-generation nicht aktiviert wurde). In den meisten Fällen kann es aber sinnvoll sein dieses Zertifikat von einer ‘offiziellen’ Zertifizierungsstelle signieren zu lassen.

Dieser Vorgang kann auch nachträglich mit Hilfe von rhn-ssl-tool wiederholt werden.

Soll zum Beispiel ein neues Server Zertifikat für den Host spacewalk.mydomain.ch erstellt werden, geschieht dies mit folgendem Programmaufruf:

rhn-ssl-tool --gen-server --dir="/root/ssl-build" --set-state="Zurich" --set-city="Zuerich" --set-org="MyOrg" --set-org-unit="MyOrg Unit" --set-email="admin@mydomain.ch" --set-hostname="spacewalk@mydomain.ch"

Die Parameter müssen natürlich an die örtlichen Gegebenheiten angepasst werden. Es wird eine bestehende lokale CA vorausgesetzt das entsprechend Passwort als Eingabe erwartet.

Hinweis: Bei der Verwendung eines ‘Common Name/Aliases’ ist es wichtig dies mit der Variable --set-hostname anzugeben, da sonst der tatsächliche Hostname des Systems genutzt wird.

Weitere Informationen zur Verwendung von rhn-ssl-tool finden sich in der Red Hat Knowledge Base.

Zertifikat signieren

Hinweis: In den folgenden Beispielen gehen wir aber von der Verwendung des tatsächlichen Hostnames aus. Wird ein Alias genutzt muss $(hostname -s) durch dieses ersetzt werden.

Um das Zertifikat bei einer offiziellen CA signieren zu lassen muss der Certificate signing request /root/ssl-build/$(hostname -s)/server.csr bei der Zertifizierungsstelle eingereicht werden.

Diese stellt dann in der Regel ein signiertes .pem oder .crt File zur Verfügung. Falls das Zertifikat nicht im richtigen Format vorliegt kann es mit Hilfe von:

openssl x509 -in $MYCERT.crt -text > /root/ssl-build/$(hostname -s)/server.crt

umgewandelt werden und direkt an die richtige stelle kopiert werden, wobei $MYCERT durch das erhaltene Zertifikat ersetzt werden muss.

Server Zertifikat RPM erstellen und einspielen

Das signierte Zertifikat muss nun auf dem System eingespielt und verfügbar gemacht werden.

cd /root/ssl-build/$(hostname -s); cat server.crt server.key >server.pem

Das benötigte RPM Paket kann mit rhn-ssl-tool erstellt und mit rpm installiert werden. Der genaue Pfad zum noarch RPM wird während des Scriptaufrufes ausgegeben:

cd /root; rhn-ssl-tool --gen-server --rpm-only
rpm -Fvh /root/ssl-build/$HOSTNAME/rhn-org-httpd-ssl-key-pair-spacewalk-1.0-2.noarch.rpm

Auch hier ist bei Bedarf wieder die Angabe von --set-hostname= möglich um z.B. einen Alias anzugeben.

Jabber erwartet das Zertifikat in /etc/jabberd:

cp /root/ssl-build/$HOSTNAME/server.pem /etc/jabberd/server.pem

Abschliessend kann der Satellite/Spacewalk mit rhn-satellite restart neu gestartet werden.

Root CA Zertifikat einrichten

Während der Dienst neu gestartet wird, kann das Root Zertifikat der CA auf dem System eingespielt und verfügbar gemacht werden. Im folgenden Beispiel wird davon ausgegangen das sich das Root Zertifikat der Zertifizierungsstelle unter /root/ssl-build/root.crt befindet.

openssl x509 -in /root/ssl-build/root.crt -text > /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT
cp /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT /var/www/html/pub/

Mit Hilfe von:

cd /root; rhn-ssl-tool --gen-ca --rpm-only
cp /root/ssl-build/rhn-org-trusted-ssl-cert-1.0-2.noarch.rpm /var/www/html/pub

wird ein entsprechendes RPM Paket erstellt. Auch hier wird der genaue Pfad während des Scriptaufrufes ausgegeben und muss ggfls. angepasst werden.

Um diese Lücke zu schliessen, haben Sandro und ich uns entschlossen ein neues (und besseres) Event Rund m Open Source und Free Content zu veranstalten: das FrOSCamp.

Ziel ist es die Vorzüge bereits bestehender, internationaler Events wie der FOSDEM oder dem LinuxTag zu kombinieren um es zur besten Veranstaltung in der Region Schweiz und Süddeutschland zu machen.

Das erste FrOSCamp findet am Freitag den 17 und Samstag den 18 September 2010 in Gebäuden der ETH Zürich statt. Es wird eine Messe, Vorträge für Entwickler und Administratoren, Workshops und Vorträge für Endanwender sowie einige Hackfests geben.

Projekte erhalten ausserdem die Möglichkeit ihre regelmässigen Entwickler- oder Anwendertreffen als Side-Event zu veranstalten.

Kommerzielle Aussteller wird es auf der FrOSCamp nicht geben (Keine Angst, Projekte dürfen natürlich T-Shirts und anderen Swag verkaufen). Es steht Firmen aber offen Projektstände zu betreiben, ohne allerdings Ihr Unternehmen zu bewerben.

Am Freitag Abend wird ein ‘Social Event’ mit Creative Commens lizenzierter Live Musik stattfinden. Anstatt irgend einer beliebigen Biersorte wird dort ‘Free Beer’ ausgeschenkt das nach einem unter der CC-BY-SA Lizenz stehenden Rezept gebraut wird.

Wenn du also aktiv am FrOSCamp teilnehmen möchtest, beantworte bitte die Call for Projects/Papers auf unserer Webseite. Wir würden uns auch sehr über weitere Helfer aus der Region freuen, da freiwillige Mithilfe der Schlüssel zum Erfolg solch eines nicht-kommerziellen Events ist.

Bei Fragen oder Anregungen laden wir dich herzlich ein unsere Mailinglisten zu abonnieren und/oder den IRC Channel #FrOSCamp auf Freenode (irc.freenode.net) zu besuchen.

Die meisten anderen Vögel nahmen ihn einfach nicht ernst, einige versuchten ihm zu erklären das er ein Vogel sei und so etwas nunmal dazu gehöre, andere fühlten sich einfach gestört.

Doch der kleine Vogel ging sogar einen Schritt weiter: er fing an zu versuchen andere Vögel davon zu überzeugen mit ihm am Fluss auszuharren. Schnell merkte er jedoch das sich bis auf ein oder zwei keiner darauf einliess, der Groll auf ihn bei allen anderen aber wuchs als diese davon erfuhren, weil sie sich aufgehalten fühlten.

Doch auch bei ihm wurde der Unmut grösser. Das Gezwitscherte der anderen Vögel fing an ihn zu stoeren und nervoes zu machen, was soweit ging das er es kaum noch aushielt und sich entweder zurueckzog oder mit seinen Flügeln die Ohren bedeckte. Natürlich liess sich die Gruppe das Zwitschern nicht verbieten, da es ja zu ihrer natürlichen Art gehörte und wichtig fuer das Zusammenleben war. Er war sich jedoch keines Fehlers bewusst und meinte immer noch alle anderen wuerden sich falsch verhalten.

Eines Tages jedoch, kurz vor dem anstehenden Weiterflug trafen Sie auf ein Nilpferd, das genüsslich im Fluss badete. Sofort fuehlte sich der kleine Vogel zu ihm hingezogen und plantschte mit ihm gemeinsam im Wasser.

Er bemerkte gar nicht das die Gruppe schon aufbrach um weiter zu fliegen und auch ihnen viel sein Fehlen nicht auf.

So passierte es, dass der kleine Vogel die kommende Zeit zusammen mit dem Nilpferd am Fluss verbrachte, im Winter zwar etwas frohr aber ansonsten glücklich war. Und das ganz ohne zu Zwitschern. Er pflegte dem Nilpferd den Pelz, so dass auch dieses davon profitiert.

So kehrte zu guter Letzt auch in der Vogelgruppe wieder Ruhe ein und das Zusammenleben wurde viel friedlicher.

Als Host empfehle ich eine aktuelle CentOS i386 Version ohne grafische Oberfläche (optional in einer KVM Instanz). Da Axigen einen eigenen Mailserver mitbringt muss vor der Installation sichergestellt werden das kein anderer Mailserver läuft. In der Standardinstallation wird unter CentOS sendmail installiert. Mit Hilfe von service sendmail stop | chkconfig sendmail off kann die Anwendung beendet und der automatische Start des Dienstes beim Systemstart unterbunden werden.

Nach dem Herunterladen des passenden Axigen Pakets von der Herstellerseite kannst du es mit Hilfe von sh axigen-*.i386.rpm.run und dem darauf folgenden Abnicken der Lizenzbestimmungen installieren. Die initiale Konfiguration erfolgt über das /opt/axigen/bin/axigen-cfg-wizard Script. Der textbasierte Wizard ist selbsterklärend und wird im Detail in der Online Dokumentation beschrieben. Wichtig ist die Angabe der Primary Domain. Hier sollte die TLD angegeben werden, für den sich der Server zuständig fühlen soll (also z.B. deinedomain.ch). Bei der Einrichtung wird ein gleichnamiges Verzeichnis unter /var/opt/axigen/domains angelegt, in dem alle Objekte und Mails der Domain abgespeichert werden.

Die weiteren Voreinstellungen können belassen oder je nach Vorlieben angepasst werden. Standardmässig wird POP3, IMAP und Webmail ohne SSL/TLS Verschlüsselung aktiviert. Für jeden der Dienste kann angegeben werden auf welchen Interfaces er lauschen soll. Wichtig ist noch der Punkt Relay Policies. Falls der Server aus dem Internet erreichbar ist, darf auf dem entsprechenden Interface auf keinen Fall replaying ohne Authentifizierung aktiviert werden. Möchtest du Mails direkt von der Kommandozeile des Servers aus verschicken können, so muss der Sendmail Wrapper eingerichtet werden.

Damit ist die Grundkonfiguration auch schon abgeschlossen. Um auf die Administrationskonsole und die eingerichteten Dienste zugreifen zu können, müssen noch die entsprechenden Ports in der Firewall freigeschaltet werden. Starte dazu bitte system-config-securitylevel-tui und wähle den Punkt Anpassen. Hier kannst du unter Eingang ermöglichen: die Punkte SSH, WWW, Sicheres WWW und Mail wählen und unter Andere Ports: 9000:tcp 143:tcp 110:tcp angeben.

service axigen start | chkconfig axigen on startet den Dienst und aktiviert den automatischen Start beim Systemstart. Nun solltest du über den Aufruf der URL http://IP-Adresse-des-Servers:9000 auf das Admin Frontend zugreifen und dich mit dem Benutzer ‘admin’ und dem während der Installation angegebenen Passwort anmelden können.

Die Grundeinstellungen sind weitestgehend korrekt. Wir möchten jedoch den Zugriff auf das Webmail Frontend über HTTPS ermöglichen. Öffne dazu bitte den Punkt Services / Webmail und wähle beim Listener den Punkt Edit. Hier kannst du den Port auf 443 umstellen. Das Ändern des Ports alleine reicht natürlich nicht aus. Aktiviere bitte auf dem Reiter SSL Settings den Punkt Enable SSL for this listener. Während der Installation wird unter /var/opt/axigen/axigen_cert.pem ein selbstsigniertes Zertifikat erstellt welches bei Path to certificate file: angegeben werden kann. Mit Save Configuration aktivierst du die Konfiguration. Um Anfragen auf HTTP Port 80 auf HTTPS Port 443 umzuleiten, kann der Apache Webserver genutzt werden. Dieser wird mit yum install httpd installiert. Der redirect auf HTTPS kannst du in der Apache Konfigurationsdatei /etc/httpd/conf/httpd.conf wir folgt definieren:

Redirect / https://URL-des-Axigen-Servers

Nach dem Start des Dienstes mit service httpd start sollten alle regulären HTTP Anfragen auf den neu eingerichteten Axigen HTTPS Listener weitergeleitet werden.

SpamAssassin

Axigen bringt eine Version des SpamAssassin Spamfilters mit. Um diese nutzen zu können müssen die axigenfilters gestartet werden. Da bei deren Start per Default auch der kommerzielle Spamfilter commtouch mitgestartet würde, der nicht SELinux kompatibel ist, sollte dieser Daemon in der Datei /etc/sysconfig/axigenfilters aus der Variablendefinition DAEMONS= entfernt werden.

Leider wurden während der Installation einige Rechte nicht korrekt gesetzt, was dazu führt das lock files nicht korrekt angelegt werden können. Um diese Problem zu lösen, setze bitte zunächst die Rechte korrekt:

chown -R axigen:axigen /var/opt/axigen/spamassassinauto-whitelist.lock

und erweitere die Variablendefinition DAEMON_OPTIONS_spamd=”-d” in der Datei /etc/init.d/axigenfilters um -u axigen so dass der spamd Dienst unter den axigen Benutzerkontext gestartet wird.

Nun kann die Filtererweiterung mit service axigenfilters start | chkconfig axigenfilters on und im Admin Frontend Bereich Security & Filtering / AntiVirus and AntiSpam über den Punkt SpamAssassinBundled -> Enable gestartet und aktiviert werden.

sa-update

Auch das automatische Update der SpamAssassin Regeln mit Hilfe von sa-update funktioniert nicht korrekt. Grund dafür ist ein fehlendes Perl Modul. Da Axigen eine eigene Perl Instanz mitbringt muss diese Erweiterung dort installiert werden.

Lade dazu bitte zunächst das Archive::Tar Paket herunter und entpacke es. Nach dem Wechsel in das entstandene Verzeichnis kannst du das Modul wie folgt installieren:

/opt/axigen/perl5/bin/perl Makefile.PL
make
make install

Alternativ kann auch das enthaltene CPAN genutzt werden:

/opt/axigen/perl5/bin/perl -MCPAN -e 'install Package::Constants'

Um die Signaturen täglich zu aktualisieren kannst du ein Script: /etc/cron.daily/sa-update mit folgendem Inhalt

#!/bin/bash
/opt/axigen/bin/sa-update --updatedir /etc/opt/axigen/spamassassin/rules

erstellen und mit:

chmod 755 etc/cron.daily/sa-update

ausführbar machen.

ClamAV

Nun fehlt nur noch ein Virenscanner. Axigen bringt Schnittstellen für einige kommerzielle Virenscanner wie AVG aber auch für ClamAV mit. ClamAV ist kein Bestandteil der CentOS Distribution, kann aber über das EPEL Repository installiert werden. Hinweise zur Einbindung und Nutzung von EPEL findest du im entsprechenden FAQ auf fedoraproject.org.

Mit Hilfe von yum install clamav-server clamav-update kannst du die benötigten Komponenten installieren. ClamAV erfordert leider etwas Konfigurationsarbeit. Kopiere dir am besten die beiliegende Beispielkonfiguration mit:

cp /usr/share/doc/clamav-server-*/clamd.conf /etc/clamd.d/axigen.conf

und bearbeite folgende Werte:

# Wichtig: Die Example Zeile muss auskommentiert oder gelöscht werden.
# Example
LogFile /var/log/clamd.axigen
PidFile /var/run/clamd.axigen/clamd.pid
LocalSocket /var/run/clamd.axigen/clamd.sock
User axigen

Nun kannst du noch einen Symlink auf das Programm:

ln -s /usr/sbin/clamd /usr/sbin/clamd.axigen

und ein Verzeichnis für die PID und eine leere Logdatei erstellen:

mkdir -p /var/run/clamd.axigen
chown axigen:axigen /var/run/clamd.axigen
touch /var/log/clamd.axigen
chown axigen:axigen /var/log/clamd.axigen

Jetzt fehlt nur noch ein init Script. Die Dokumentation enthält ein Beispiel, das wir nutzen können:

cp /usr/share/doc/clamav-server-*/clamd.init /etc/init.d/clamd.axigen
chmod 755 /etc/init.d/clamd.axigen

Passe in der Datei: /etc/init.d/clamd.axigen bitte noch die Variable:

# description: The clamd server running for axigen
CLAMD_SERVICE=axigen

an.

Mit service clamd.axigen start | /sbin/chkconfig clamd.axigen on startest und aktivierst du den Dienst.

ClamAV kann wahlweise mit lokalen oder TCP Sockets arbeiten. Obiges Beispiel geht von einer lokalen Socket Datei aus. Damit Axigen auch darauf zugreifen kann, muss die Konfigurationsdatei: /var/opt/axigen/run/axigen.cfg angepasst werden. Diese enthält per default zwei Beispielkonfigurationen, AV:ClamAV für TCP Sockets und ClamAV-local für Socket Files.

Der ClamAV-local Abschnitt kann also einfach auf obige Konfiguration hin angepasst werden und sieht dann wie folgt aus:

name = "ClamAV-local"
address = "local:///var/run/clamd.axigen/clamd.sock"
protocolFile = "/var/opt/axigen/filters/clam-av.afsl"
idleTimeout = 60
actionOnMatch = discard
maxConnections = 10

Wie auch beim SpamAssassin muss der Filter im Admin Frontend Bereich Security & Filtering / AntiVirus and AntiSpam über den Punkt ClamAV-local -> Enable aktiviert werden.

freshclam

ClamAV wird über freshclam aktualisiert. Die enthaltene Konfigurationsdatei: /etc/freshclam.conf muss wie folgt bearbeitet werden:

# Wichtig: Auch hier muss die Example Zeile auskommentiert oder gelöscht werden.
# Example
DatabaseOwner axigen

Erstelle daraufhin bitte ein leeres Logfile und passe die Rechte entsprechendan:

touch /var/log/freshclam.log
chown axigen:axigen /var/log/freshclam.log

Damit freshclam unter dem axigen Benutzerkontext arbeiten kann müssen auch noch die Rechte auf das Datenbankverzeichnis angepasst werden:

chown -R axigen:axigen /var/lib/clamav/

freshclam lädt via cron Signaturupdates herunter nachdem du in der Datei /etc/sysconfig/freshclam die Zeile:

FRESHCLAM_DELAY=disabled-warn # REMOVE ME

auskomment oder gelöscht hast.

Feinarbeit

clamav schickt seine Benachrichtigungen an postmaster, webmaster und clamav. Es ist also sinnvoll auf dem postmaster Account noch die Aliases webmaster und clamav zu hingerlegen.

Nun kannst du über den Punkt Manage Accounts in der Administrationsoberfläche weitere Konten hinzufügen.

Nun hat sich am Samstag, den 21. November ein tragischer Unfall ereignet, bei dem ein geistig behinderter Mann über die Umzäungung zu den Bären geklettert ist und schwer verletzt wurde. Der Bär (der auf den Namen Finn getauft wurde) konnte im letzten Moment durch den Einsatz eines Streifenpolizisten mit Hilfe eines Mannstopp-Geschosses zur Strecke gebracht werden. Der Bär Finn wurde dabei (ebenso wie der Mann der angegriffen wurde) schwer verletzt.

In der Presse wird seither um die Gesundheit des Bären gebangt. Hier eine Sammlung von Medienberichten (die ich zufällig ausgewählt habe):

http://www.blick.ch/news/schweiz/bern/so-kaempfen-wir-um-finn-134071
http://www.derbund.ch/bern/Grosse-Anteilnahme-fuer-Finn/story/19957857
http://www.20min.ch/news/bern/story/11831645

Der Gesundheitszustand des geistig behinderten Mannes wurde in der Presse wenn überhaupt nur in Nebensätzen erwähnt. Natürlich kann ich auch das Mitgefühl für einen Bären verstehnen (der in Deutschland wahrscheinlich als Problembär geächtet und getötet werden würde), doch frage ich mich wo das Mitgefühl für den verletzten Menschen bleibt.

Ursächlich tun sich aber auch noch ganz andere Abgründe auf: Wer war für die Betreeung des geistig Behinderten zuständig? Wurde diese vielleicht vernachlässigt? Laut Zeugenaussagen stand der Mann noch einige Zeit auf der Mauer, bevor er in das Bärengehege sprang. Konnte er nicht aufgehalten werden?

Für mich stellt sich eher die Frage ob durch eine bessere Betreuung von geistig Behinderten solch ein Problem in Zukunft vermieden werden kann. Und damit meine ich nicht das Wegsperren, sondern eine einfühlsahme Integration in die Gesellschaft.

Ein schlechtes Bild wird auch auf den Einsatz von Mannstopp Munition geworfen, die sehr umstritten ist und in Kriegszeiten in der Schweiz sogar verboten ist.

Im Jahre 1986 habe ich ihn dan endlich bekommen. Ein Commodore 64 mit Datasette und Grünmonitor als Geschenk meiner Eltern zu Weihnachten. (Grundgerät hat ungefähr 500 DM gekostet.) Das einzige Manko war, daß ich den C64 mit meinem Bruder teilen musste, da er als Geschenk für einen alleine deutlich zu teuer gewesen wäre. Unsere ersten Programme waren Howard the Duck, ActionBiker und Dinky Doo auf Tape. Da das Laden von Datasette mir schon nach kürzester Zeit auf die Nerven ging, hab ich solange meine Eltern angebettelt, bis sie mir für über 300DM einen 1541 Klon gekauft hatten. Das war auch schon das erste Highlight (im warsten Sinne des Wortes), als dann das Gerät nach dem Einschalten anfing zu rauchen und zu qualmen. (Besser man kauft Markenware!) Also umgetauscht und los gings. Die ersten Progs wurden geschrieben, und auf Disk! abgespeichert. Mir wurde der Spagetti Code von Basic aber doch mit der Zeit zu mühselig und ich fing an mich mit Assembler Programmierung zu beschäftigen.

Schon früh interessierte mich das Cracken von Spielen und so habe ich zusammen mit meinem Bruder und 2 Kumpels 1987 meine ersten Cracking Group “TCM – the crack masters” gegründet. Die Logos wurden damals mit dem legendären Koala Paint gezeichnet. Die nächste große Anschaffung war ein Modem mit 300 Baud. Da das Gerät nicht FTZ Zulassung war, weil es sich um einem US-Import handelte, musste mein Opa (der Ingenieur bei der Post war) ein Kabel für die deutschen TAE Dosen löten. Die einzige BBS im Nahbereich war damals “Frank’s Amiga Corner” und so wurden mit 300 Baud die ersten Programme geleecht.

Mit dem Modem kam auch das phreaken und die ersten Blue Boxing Progs wurden geschrieben. Somit konnten wir mit Hilfe von bestimmten Break Impulsen 0130 (heute 0800) Nummern dazu bringen, ein Gespräch weiterzuleiten. So kamen die ersten Kontakte zu Groups im Ausland zustande, ohne das die Telefonrechnung ins unermessliche stieg.

1989 wagte ich den Umstieg von Commodore 64 auf Amiga 500. (damals 800DM). Die erste Group auf dem Amiga in der ich member war, war “MOVEX – Sound Departement”. Wir haben uns auf mit Protracker produzierte Musik Disks spezialisiert. “MOVEX” wurde jedoch nach kurzer Zeit Aufgrund mangelnder Erfahrungen in 68000/ASS Programmierung wieder aufgelöst. Die verbliebenen Mitglieder, darunter auch ich, gründeten im selben Jahr die Gruppe “Unity”. Mit USX (ehemals E+L) bekamen wir einen neuen Coder dazu durch den ich Erfahrungen in 68000/ASS Programmierung machen konnte.

1992 kaufte ich mir dann meinen ersten 286er mit 16Mhz, den ich aber schon bald wieder verkauft habe, da ich mit DOS und Windows 3.1 überhaupt nichts anfangen konnte.

Mein Bruder hat sich kurz darauf einen Intel PC gekauft und kam damit erheblich besser damit klar als ich. So kam es auch das er Sysop unserer ersten eigenen BBS (Bulletin Board System, im deutschen auch unter dem Namen Mailbox bekannt) “the deadzone” wurde, wo ich cosysop war. Calling Cards hacking/Blue Boxing wurden zu dieser Zeit meine neue Leidenschaft. Ich habe einige neue Tools für diesen Zweck geschieben. Natürlich für Commodore Computer.

Da mein Bruder keine große Lust am Sysop sein entwickelte wurde die “Dead Zone” auch bald wieder geschlossen. Bei mir war das Interesse an BBS/Boarding aber geweckt und ich machte mein eigenes System, die “Trancentral BBS”, auf. Ich nutzte damals die BBS Software “Fastcall” für den Amiga. Das Stuff Trading fing an zu boomen. Ich gründete die Group “digital underground” die sehr schnell aus 12 membern bestand. Mein board lief nur mit 0-3 days stuff. PC, Amiga und C64. Die group “digital undergound” ist schnell weltweit bekannt geworden. Wir haben sogar ein eigenes Verschlüsselungsverfahren entwickelt, um unsere Daten sicher auszutauschen. Auch die “Trancentral BBS” wurde zu einer der beliebtesten Boards Deutschlands. Ich habe mich zu dieser Zeit wieder mehr und mehr mit BBS Systemen für den C64 beschäftigt, da der PETSCII Zeichensatz einfach coolere Boardstyles ermöglichte. Nach insgesamt 5 Jahren Laufzeit habe ich dann die “Trancentral BBS” aufgegeben, weil immer mehr Leute auf das Internet umgestiegen sind. Damit ich den Kontakt zu den member von “digital underground” nicht verliere, beschloss ich trotzdem eine Mailbox zum E-Mail Austausch zu betreiben. Ich entschied mich wieder den C64 einzusetzen. Angeschlossen waren insgesamt 4 Floppy 1541 II. Zu der Zeit gabs noch keine HDs von CMD oder das IDE64 Porjekt. Leider lief auch das Board nicht mehr sehr lange und ich trennte mich von meinen Commodore Rechnern. Beruflich nutze ich heute als Netzwerkadministrator zumeist Linux basierende PCs. Da meine Leidenschaft zum C64 nie ganz abgekühlt ist, spiele ich auch heute noch ganz gern mal ein Spielchen auf dem Volkscomputer.

Der Prozess läuft in der Regel so, dass sich ein neuer ‘Contributor’ zunächst auf der Mailingliste vorstellen und einen Wiki Account in der Form VornameNachname anlegen sollte, falls noch nicht geschehen.

Daraufhin kann Sie/Er einen Artikel oder ein Thema vorschlagen sowie Korrekturen zu vorhandenen Artikeln einbringen. Das schreckt leider viele Leute ab, da sie Angst haben das ihr Beitrag in aller Öffentlichkeit auseinandergenommen wird (was auch des öfteren vorkommt ). Des weiteren gibt es zu vielen Themen unterschiedliche Gesichtspunkte. (10 Admins, 15 Meinungen) was das ganze nicht einfacher macht.

Bei Projekten für die schon gute ‘Upstream’ Dokumentation (also auf den Ressourcen der Autoren der Software selbst) vorliegt, macht es oft sogar mehr Sinn die dortige Dokumentation um CentOS-spezifische Aspekte zu erweitern (bei Spacewalk ist das z.B. so).

Doch auch das CentOS Wiki selbst wäre deutlich vitaler wenn die Einstiegshürden verringert würden. Der Vorstellungsprozess ist sicherlich sinnvoll; auch denke ich das der erste Artikel auf der Liste veröffentlicht werden sollte. Falls die Qualität allerdings den Erwartungen entspricht, sollten Editierrechte auf das gesamte Wiki erteilt werden (Ausnahme: Startseite, Pulse – da hier Mitgliedschaft in der Newsletter Group erwartet wird und Hidden Content).

Des weiteren sollte es eine Gruppe von Wiki Admins geben (die nicht zwingend mehr Rechte benötigen, ausser ggfls ACLs neu zu setzen), die das gesamte Wiki monitoren. Das machen neben mir heute schon einige andere Team Mitglieder. So können Fehler schnell korrigiert werden (natürlich mit entsprechenden ‘Changelog’ Kommentar) oder in der Mailingliste diskuttiert werden.

Update: Laut Ralph Angenendt sind bisher ca 80 Benutzer in der Edit Group, haben also Schreibrechte auf grosse Teile des Wikis. Viele andere haben aber aufgrund der hohen Einstiegshürden aufgegeben und resigniert.

Davon ab habe ich die Contribute Seite um Informationen über das Beobachten von Veränderungen im Wiki ergänzt, in der Hoffnung das sich weitere Leute anschliessen und mithelfen die Qualität der Inhalte weiter zu verbessern.

Der Weg dorthin ist in manchen Fällen jedoch etwas holprig. Zunächst schien das Produkt dem Verkäufer des Intershops nicht geläuftig zu sein, bis er in einer Schublade einen Haufen Flyer fand die auf den mobilen Datentarif hindeuteten. Sollten diese nicht eigentlich offen ausliegen und den Kunden zum Kauf animieren?

Um den Tarif nutzen zu können muss allerdings erst einmal ein ‘normaler’ Coop Mobile Pre-Paid Vertrag abgeschlossen werden. Hierbei handelt es sich um ein ge-brandetes Orange Produkt. Gesagt getan. Nach Abschluss des Vertrages eine SMS mit START DATAPROMO an 5155 und der kostenlose 3-monatige Test kann beginnen (theoretisch zumindest).

Leider erhielt ich recht früh eine Fehlermeldung ‘Sie sind kein Teilnehmer eines mobilen Datennetzwerkes’ auf meinem iPhone 3G, was mich dazu bewegt hat bei der Hotline anzurufen.

Der erste Ansprechpartner versuchte mir zu erklären das dieser Tarif mit dem iPhone nur mit GPRS funktionieren würde und ich doch 3G abschalten sollte. Das alleine fand ich schon eine Frechheit, da GPRS für mobiles Surfen eher ungeeignet ist. Das Abschalten der Funktion brachte aber eh keinen Erfolg.

Also der nächste Anruf bei der Hotline und die Stimme der Dame die mir ins Ohr hauchte: ‘Ich schicke Ihnen gerne eine Konfigurations-SMS’ worauf ich antwortete das dies unter dem iPhone wohl nicht funktionieren wird, ich sie aber bat mir die SMS dennoch zu schicken (auf die ich übrigens heute immer noch warte).

Da sie nicht weiter wusste rief ich tags darauf erneut an. Der nette Herr sagte mir das noch die ‘Premium Internet Services’ auf meinem Tarif aktiviert werden müssten, was er gerne machen würde. Dieser Vorgang sollte ca. 1/2 Tag dauern und danach würde dem mobilen Surfvergnügen nichts mehr im Wege stehen. Auch dies brachte keine Verbesserung, also noch einmal der Griff zum Telefon.

Hier erbat ich erneut die Nennung des APNs oder das Zusenden einer entsprechenden Konfigurations SMS. Auch diese traf bei mir nicht ein. Die Dame schlug aber einen Rückruf des 2nd Level Supports innerhalb von 24 Std. vor.

Der Anruf kam leider nicht, dafür nach 2 Tagen aber eine SMS: ‘Ihr 3-monatiger Testzeitraum ist abgelaufen, möchten Sie den Dienst weiternutzen bezahlen sie bitte 9.90 CHF im Monat.’

Nochmal angerufen, Situation geschildert und 1 Tag später erneut eine SMS: Willkommen zum 3-monatigen Test…

Surfen konnte ich allerdings immer noch nicht.

Da sich immer noch kein Techniker gemeldet hatte, sah ich mich genötigt nachzufragen. Der 1st Level Supporter schaute in der Ticket History und sah keine Eskalation an den 2nd Level Support, würde es gerne aber noch einmal veranlassen. Er empfahl mir auch noch das ich das iPhone mit iTunes synchronisieren sollte, da dadurch die Providerdaten aktualisiert würden. Das habe ich getan (nachdem ich eine geeignete Windos Box gefunden hatte) und erhielt hier wirklich die Meldung: Providerdaten werden aktualisiert. Scheinbar jedoch nicht aktuell genug …

Heute habe ich es dann doch noch einmal bei der Hotline versucht und wurde diesmal sogar an die Technik durchgestellt. Der hilfsbereite Herr wusste recht bald Bescheid und empfahl mir folgende Einstellung:

Allgemein / Netzwerk / Mobiles Datennetzwerk / APN:

APN: click

Und siehe da: ich bin drin!

Solche eine Odyssee habe ich aber selbst bei der Deutschen Telekom bisher nicht erlebt.

Schnell kommst du auf die Idee, das die wenigen Köche die das Projekt ins Leben gerufen haben evtl. Unterstützung brauchen könnten. Da du selbst Hobby Koch bist, denkst du dir das du doch auch deinen Teil zu diesem tollen Projekt beitragen könntest und damit die hart arbeitenden Köche entlastest. Ausserdem kennst du dich besonders gut mit Nachspeisen aus (die es bisher in dem Restaurant nicht gibt) und die bei den Gästen bestimmt gut ankommen würden.

Gesagt getan. Du fragst einen der aktiven Köche ob du mitmachen kannst und wirst zunächst auf die Spüle verwiesen. Jeder ‘Neue’ müsse sich erst einmal beweisen. Dabei scheint es egal das du schon lange Zeit aktiv kochst und sogar schon mehrere Essen für grössere Anlässe wie Hochzeiten oder Geburtstage zubereitet hast.

Da du denkst das es sich um ein gutes Projekt handelt, machst du dennoch mit. Im ersten halben Jahr versuchst du mehr über den Aufbau der Küche und die Verantwortlichkeiten der jeweiligen Köche herauszubekommen (was sich schon als recht schwierig erweist). Nach einem Jahr an der Spüle kommst du noch mal auf die Idee nachzufragen ob du wenigstens schon mal Gemüse schnibbeln darfst. Auch das wird dir nicht gestattet. Die kurze Antwort lautet: Wir sagen dir schon wenn du mitmachen darfst.

Ein weiteres halbes Jahr später ist immer noch nichts geschehen. Zwischendurch durftest du mal den Müll rausbringen. Deine Rezeptvorschläge wurden ignoriert. Im Restaurant hingegen geht es immer noch genauso zu wie bisher. Das Essen kommt zu spät oder ist schon kalt wenn es ankommt.

Nach einiger Zeit kommst du dann auf die Idee deinen Kollegen an der Spüle zu fragen was er davon hält. Er antwortet dir das er nun schon 3 Jahre an der Spüle arbeitet ohne je weiter gekommen zu sein. Das gibt dir zu denken und du gehst eines morgens ins Restaurant und sprichst die Missstände bei den Gästen an. In diesem Moment beteiligen sich die Köche an der Diskussion und versuchen Ihre Position zu erklären. Das ‘Lager’ der Gäste spaltet sich in mehrere Seiten. Der erste sagt: “Ruhe bitte, ich möchte beim Essen nicht gestört werden”. Andere schliessen sich dir an und fordern mehr Gleichberechtigung sowie den einfacheren Zugang zur Küche für neue Köche. Davon würde ja das gesamte Restaurant provitieren. Es gibt Gäste die einfach nur die kostenlose Leistung in Anspruch nehmen, selbst aber nichts zum Erhalt und dem Wachstum des Restaurants beitragen (die sich aber bei einer Schliessung des Restaurants am lautstärksten beschweren würden) und andere die sich gerne beteiligen, sich aber durch die elitären Machtstrukturen in der Küche abgeschreckt fühlen.

Der Tenor der ‘alteingesessenen Köche’ ist das nur sie in der Lage seien die Sterne-Qualität des Essens zu gewährleisten und sich bisher kaum einer als würdig erwiesen habe. Ausserdem würden Neuerungen wie ‘Nachspeisen’ nicht gut ankommen. Einer der Köche beschimpft dich sogar als Schwätzer, der nichts leistet. Das ärgert dich aufgrund der Zeit und Energie die du bereits in das Projekt gesteckt hast umso mehr.

In der Vergangenheit haben sich allerdings auch andere Projekte mit ähnlichen Zielen entwickelt, die eine viel klarere Organisationsstruktur haben. In einem werden z.B. die besten Köche von allen gewählt und Neueinsteiger bekommen einen alteingesessenen ‘Kochpaten’ zur Hand der sie in die Strukturen einführt und Tips gibt. Auch hier muss erst gespült werden, aber schon nach 3 Monaten ist das erste Gericht zubereitet. Ein Großteil der Köche ist hilfsbereit und dein Spezialgebiet ‘Nachspeisen’ würde hier sicher Anklang finden.

Ein anders Restaurantprojekt hat sich auf die Zubereitung von Sushi spezialisiert. In letzter Zeit bist du immer mehr auf den Geschmack gekommen und kannst schon recht gut mit Stäbchen umgehen. Ein ‘alteingesessener Sushi-Roller’ hat dir zugesagt dir die Zubereitung zu erklären.

Wurden die Köche in dem Restaurant in dem du bisher freiwillig gearbeitet hast durch deinen ‘Aufschrei’ wachgerüttelt? Oder möchtest du in Zukunft lieber Sushi zubereiten?

Wie es weiter geht erfährst du in der nächsten Folge….

Die englischsprachig Version findest du hier:

http://lists.centos.org/pipermail/centos/2009-August/080227.html

Das CentOS-Wiki und das Bug-Tracking-System ist von dem Angriff nicht betroffen, obwohl die Komponenten auf dem gleichen Server installiert sind.

Auch wurde der CentOS-Server nicht zum Versenden von SPAM missbraucht. Dennoch wurden vorsichtshalber alle Benutzerpasswörter im CMS als ‘abgelaufen’ markiert und müssen neu gesetzt werden.