• The packages from Upstream channels are no longer split into separate repositories but merged into one big. You can now access all packages during install time.

• The distribution is now delivered on DVD iso images, only. But there will be a minimal install CD and a LightWeightServer CD available, soon.

• LiveCDs and LiveDVDs for i386 and x86_64 will be released within the next few days. These will bring in the ability to directly install from the livemedia.

Please read the full CentOS 6.0 Announcement for further information and enjoy the distro artwork.

Im Lightning Talk Track konnte ich einen kurzen Vortrag über sssd halten, in dem ich das neue Authentifizierungsframework vorgestellt habe.

Der Abend klang beim gemütlichen Chässpätzli-Essen aus, wo uns Venti vom Hackerfunk einige Perlen der Schweizerdeutschen Sprachkunst nähergebracht hat.

Alles in allem ein sehr schönes und empfehlenswertes Event unter Freunden. Vielen Dank an die Veranstalter und die netten Kollegen die uns geholfen haben.

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.

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.

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.

Leo vom Debian Projekt hat dieses Photo auf dem LinuxTag 2009 aufgenommen.

/sbin/ifup-local

mit dem Inhalt:

#!/bin/bash
if [ -x /etc/sysconfig/network-scripts/up-${1} ]; then
exec /etc/sysconfig/network-scripts/up-${1}
fi


und ein ifdown-local Script:

/sbin/ifdown-local

mit folgendem Inahlt:

#!/bin/bash
if [ -x /etc/sysconfig/network-scripts/down-${1} ]; then
exec /etc/sysconfig/network-scripts/down-${1}
fi

an.

Mit:

chmod +x /sbin/ifup-local
chmod +x /sbin/ifdown-local

machst du diese Scripte ausführbar.

Der Device Name wird beim Aufruf der Scripte ge-parsed so dass du nun individuelle up und down Scripte wie z.B:

/etc/sysconfig/network-scripts/up-eth0
/etc/sysconfig/network-scripts/down-eth0

erstellen kannst.

system-config-network ermöglicht zwar die grafische Erstellung von xDSL Verbindungen, ich empfehle aber die manuelle Einrichtung über die Kommandozeile. Sonst würden aufgrund eines kleinen Fehlers alle PPPOE Verbindungen auf das gleiche PID File verweisen, da die GUI hier nicht differenziert.

Lege also dazu zunächst eine Konfigurationsdatei: /etc/sysconfig/network-scripts/ifcfg-Provider1 mit folgendem Inhalt an:

TYPE=xDSL
DEVICE=ppp101
UNIT=101
BOOTPROTO=dialup
USERCTL=no
IPV6INIT=no
PEERDNS=no
PIDFILE=/var/run/pppoe-Provider1.pid
FIREWALL=NONE
PPPOE_TIMEOUT=80
LCP_FAILURE=3
LCP_INTERVAL=20
CLAMPMSS=1412
CONNECT_POLL=6
CONNECT_TIMEOUT=60
PERSIST=yes
SYNCHRONOUS=no
DEFROUTE=no
USER=Benutzername1
ETH=eth1
PROVIDER=Provider1
DEMAND=no

Das jedes PPP Device immer den gleichen Device Namen zugeordnet bekommt wird zum einen durch den Parameter DEVICE=ppp101, zum anderen durch das Hinzufügen von UNIT=101 erreicht. Beachte bitte das DEVICE dem tatsächlichen Namen des Interfaces und UNIT der Devicenummer entspricht.

Hinweis: Aufgrund eines Kernel Bugs wird das ppp0 device nach einer Verbindungstrennung nicht wieder freigegeben, was dazu führt das die statische Device Zuordnung nicht richtig funktioniert. Deshalb empfehle ich hohe Device Nummern (z.B. 101, 102 …) zu wählen.

Leider bieten die rp-pppoe Tools keine Unterstützung für units, so dass wir das Script /sbin/adsl-connect etwas aufbohren müssen.

Suche dort nach einer Zeile die mit:

PPP_STD_OPTIONS=

und füge vor

$PPD_EXTRA

bitte

unit $UNIT

ein. Nun müssen nur noch die Login Credentials für die erste PPPOE Verbindung in /etc/ppp/chap-secrets bzw. /etc/ppp/pap-secrets eingetragen werden:

"Benutername1" "Provider1" "Passwort1"
"Benutzername1" * "Passwort1"

Weitere PPPOE Accounts werden nach dem gleichen Prinzip erstellt. Bedenke dabei bitte folgende Parameter anzupassen:

z.B.:

DEVICE=ppp102
UNIT=102
PIDFILE=/var/run/pppoe-Provider2.pid
USER=Benutzername2
ETH=eth2
PROVIDER=Provider2

und die Zugangsdaten in /etc/ppp/chap-secrets bzw. /etc/ppp/pap-secrets einzutragen. Mit:

service network restart

sollten nun alle neue eingereichtenten PPPOE Verbindungen aufgebaut werden und auch nach einer Trennung wieder die gleichen Device Namen zugeordnet bekommen.

yum install uudeview

wird der Decoder für uuencode, xxencode, Base64 und BinHex auf deinem System installiert. Nun kannst du mit uuenview beliebige Dateien als Anlagen verschicken:

uuenview -b -s "Betreff" -m mail@domain.de /pfad/zur/Datei

Erklärung der Parameter:

-b
definiert Base64 als Codierung.

-s “Betreff”
ermöglicht die Angabe eines Betreffs.

-m name@domain.de
legt den Emailempfänger fest