Aktuelles in der Kategorie RHEL/CentOS

tux.jpgUm Postfix als SMTP-Server für viele Nutzer anzubieten, muss er auf eine Nutzerdatenbank zurück greifen. Dieser Artikel zeigt am Beispiel der Groupware Zarafa, wie Postfix via libsasl mit einer MySQL-Nutzerdatenbank verknüpft wird.

Mit Hilfe von SASL können Nutzer sich gegen Postfix authentifizieren und E-Mails einliefern, damit dieser die weiter zustellt. Dies ist zum Beispiel interessant, wenn der Postfix als zentraler MTA für eine Firma oder größere Institution genutzt werden soll.

Die Schwierigkeit besteht darin, eine vorhandene Nutzerdatenbank einzubinden, hier die MySQL-DB der Groupware Zarafa. Häufig wird dabei auf PAM zurückgegriffen: Postfix authentifiziert gegen PAM, via PAM kann eine Vielzahl verschiedenster Plugins angebunden werden, um z.B. auch auf Datenbanken zurück zu greifen. Ein anderer Weg ist, die Bibliothek libsasl des Cyrus-Projekts zu nutzen, da dies ebenfalls auf verschiedene Plugins zurückgreifen kann.

Dafür muss im ersten Schritt Postfix in der main.cf für die Authentifizierung gegen SASL fit gemacht werden:

smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_path = smtpd
smtpd_sender_restrictions = permit_sasl_authenticated, ...

saslauthd wird nicht direkt aufgerufen, es wird nur die libsasl-Bibliothek genutzt. Daher kann /etc/sysconfig/saslauthd auf den Standardwerten bleiben. Der Dienst selbst braucht nicht gestartet werden!

Es fehlt aber noch die eigentliche Konfiguration, in der unter Anderem auch die Syntax der MySQL-Abfrage definiert wird. Diese Konfiguration wird in der smtpd.conf definiert, die standardmäßig unter /usr/lib/sasl2/ erwartet wird. Erst wenn sie dort *nicht* vorliegt, wird sie unter /etc/sasl2/smtpd.conf erwartet. Warum dort nicht zuerst gesucht wird, entzieht sich meinem Verständnis. Es bietet sich also an, einen symbolischen Link auf die Datei unter /etc/ zu erstellen...
So oder so muss der Inhalt wie folgt aussehen:

pwcheck_method: auxprop
auxprop_plugin: sql
mech_list: PLAIN LOGIN
allow_plaintext: true
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: zarafa
sql_passwd: ******
sql_database: zarafa
sql_select: select value from objectproperty where objectid=(select objectid from objectproperty where value='%s' limit 1) and propname='loginname'

Dabei müssen die natürlich die Sternchen für das Passwort gegen das tatsächliche Passwort ersetzt werden. Sind alle Komponenten neu gestartet worden, können E-Mails von Nutzern eingeliefert werden, die sich via libsasl gegen die MySQL-Datenbank von Zarafa authentifizieren.

Alle Artikel zum Thema CentOS stehen auch als eigene Kategorie mit eigenem Feed zur Verfügung. Falls Ihr tiefergehende Fragen zu Support und Services für Zarafa habt, oder euch Supportangebote für CentOS interessieren, seid ihr bei uns ebenfalls richtig.

Update:
Ursprünglich hatte ich in diesem Artikel auf saslauthd direkt aufgesetzt, dann aber fälschlicherweise nicht gegen die DB, sondern gegen den IMAP-Server von Zarafa (via rimap) authentifiziert. Danke an Uli in den Kommentaren für den Hinweis. Mehr Infos zu saslauthd, libsasl und den unterschiedlichen Einsatzszenarien finden sich im SASL-Readme von Postfix.

tux.jpgIn 6 Monaten wird RHEL 3 sowie alle davon abgeleiteten Distributionen das Ende ereilen: sie werden ab da nicht mehr mit Sicherheitsupdates versorgt werden.

Für Red Hats kommerzielle Linux-Distribution werden regulär 7 Jahre lang Updates angeboten. Für den Zweig 3.x der Distribution nähert sich damit das Ende: am 31. Oktober 2010 sind die 7 Jahre um, es wird keinen weiteren Support mehr geben. Dies betrifft auch die Community-Distributionen, die auf den Quellen von RHEL aufbauen, wie CentOS und Scientific Linux.

Nutzern der Distribution legen wir ein Upgrade auf eine neuere Version wärmstens ans Herz, da sonst nicht garantiert werden kann, dass die Maschinen zuverlässig und vor allen Dingen sicher weiter laufen. Zur Zeit liegen für alle genannten Distributionen die aktuell noch gepflegten Zweige 4.x und 5.x vor, ein Release des Zweigs 6.x könnte eventuell noch rechtzeitig zum EOL des Zweigs 3.x veröffentlicht werden.
Da solche Upgrades sehr umfangreich und arbeitsaufwendig sein können, bietet sich alternativ auch eine Migration auf eine andere Distribution wie Debian an.

Ein entsprechender Upgrade-Plan sollte aber in jedem Fall bereits jetzt evaluiert werden - tendenziell sind es gerade die Maschinen des sensiblen produktiven Betriebs, die selten angefasst und noch seltener aktualisiert werden. Eine tiefgehende Analyse des Ist-Zustands so wie der Ansprüche, Notwendigkeiten und Bedingungen an das System vor dem Upgrade sind genau so unerlässlich wie Tests auf Staging-Systemen und eine frühzeitige Migration lange vor dem EoL. Wer bis zum letzten Tag wartet, tut sich keinen Gefallen.

Alle Blog-Artikel zum Thema CentOS werden auch als Kategorie RHEL/CentOS samt eigenem Feed angeboten. Wir bieten natürlich auch Support und Services für CentOS - insbesondere bei Upgrades und Migrationen auf neuere Versionen oder alternative Distributionen.

Die Resonanz auf die Vorstellung der Open Source Support Card war immens. Im Folgenden listen wir die wichtigsten Reaktionen der Presse und das Feedback der Community auf.

Die gestern erfolgte Vorstellung der Open Source Support Card wurde von einem großen Presse-Echo begleitet - alle großen Nachrichtenportale haben darüber berichtet, und die Berichte waren sehr positiv. Das ist ein deutliches Zeichen dafür, dass Linux-Support für viele Business-Kunden ein interessantes und wichtiges Thema ist - und dass unser Angebot etwas wirklich neues ist - wir lassen "einen frischen Frühlingswind" durch den Markt fegen, wie die Pressemitteilung so schön sagte.

Hier die bisher gefundenen Artikel im deutschsprachigen Raum - bitte hinterlasst Kommentare, wenn wir was übersehen haben:

Aber auch die Reaktionen in diversen Foren waren interessant zu lesen: die Preise, aber auch unser Open Source Support Center (OOSC), unsere Open Source Support Referenzen und unsere Firma an sich wurden ausführlichst besprochen. Diese sehr umfangreichen Diskussionen zeigen ebenfalls, dass wir mit dem Angebot den Puls der Zeit und den Nerv vieler Linux-Admins im professionellen Umfeld getroffen haben.

Für uns alle war es ein dementsprechend bestärkender Tag, und wir sind zufrieden in den Feierabend gegangen. Wir danken für das umfangreiche Feedback, und stehen für Fragen immer gerne zur Verfügung - auch hier im Blog. Allerdings werden wir nicht verraten, welches Thema die nächste Open Source Support Card abdeckt. Ihr könnt ja mal raten. ;-)

Alle Blog-Artikel zu unserer Firma werden auch als Kategorie credativ samt eigenem Feed angeboten.

Ab sofort bietet credativ die Open Source Support Card an. Mit ihr kann Open Source Support für klar umrissene Themen ohne Vertragsbindung eingekauft werden - zu einem festen Preis.

Nach langer Vorbereitungszeit ist es jetzt so weit: ab heute bieten wir mit der Open Source Support Card unseren gewohnten Service auf eine neue, einfachere Art an: Themen-bezogen, im Vorfeld bezahlt und mit festem Kontingent.

frontside_3_shade_bg_white.png

Mit der Open Source Support Card haben die Kunden den Vorteil einer absoluten Kostenkontrolle, und es entfällt die für einige Kunden hinderliche Bindung an einen Vertrag - die Karte wird als normales Produkt erworben! Das kann insbesondere in der Rechnungsführung größerer Unternehmen praktisch sein, nicht zu Unrecht wird sich der ein oder andere Leser an die "Prepaid"-Modelle im Mobilfunkbereich erinnert fühlen. Die Presse-Mitteilung gibt eine ganz gute Übersicht der Vorteile und Bedingungen der Karte:

  • Open Source Support für ein klar umrissenes Thema
  • Themenbezogener Support für alle Desktops und Server des Unternehmens
  • Knackiger Preis: 890 Euro
  • Volle Kostenkontrolle
  • Support per Telefon, E-Mail und Remote
  • Hilfe in englischer oder deutscher Sprache
  • KEINE Abhängigkeit von Zahl der Nutzer, CPUs oder ähnlichem
  • KEINE Vertragsbindung, sondern einfache Bestell-Abwicklung
  • KEIN Call-Center - direkter Support durch uns
  • Die Supporteinheiten können für folgende Dienstleistungen genutzt werden:
    • Administration
    • Installation (Remote)
    • Beratung

Dabei wird der Support auf die credativ-typische Art und Weise geliefert: unabhängig von der Zahl der CPUs, Nutzer oder DB-Einträge, wie auch bei unseren klassischen Verträgen. Support-Einheiten, die mit der Open Source Support Card erworben werden, können für alle vorhandenen Rechner genutzt werden, unternehmensweit. Geleistet wird der Support - selbstverständlich - von unserem Open Source Support Center: dort gibt es keine FAQ-Schleifen oder lästige Diskussionen mit nicht-technischem Personal. Wir sind Linux-Spezialisten und Open-Source-Experten, die allesamt selbst in diversen Projekten aktiv sind - regelmäßigen Lesern dieses Blogs dürfte das aber eh klar sein. ;-)

Für die Community ist das Angebot in so fern interessant, dass der Einsatz freier Distributionen jetzt attraktiver wird. Denn das Preisangebot von unter 1000 Euro dürfte den Anbietern kommerzieller Distributionen einiges an Kopfzerbrechen bereiten, und nicht wenige Firmen können sich jetzt einen Umstieg hin zu Debian oder CentOS ernsthaft überlegen. Die Karte ist sogar so angelegt, dass auch Reseller sie verkaufen können - mit etwas Glück könnt ihr demnächst neben dem Debian-Server auch gleich den Support in den Warenkorb klicken.

Aktuell steht die Support Card in Deutschland für die Distributionen Debian und CentOS zur Verfügung. Weitere Projekte und andere Open-Source-Software werden folgen, genauso wie die Verfügbarkeit in den USA, Großbritannien und Kanada. Wenn ihr weitere Fragen oder vielleicht auch Wünsche habt, hinterlasst bitte Kommentare - wir haben viel Arbeit in dieses Projekt gesteckt, und sind sehr auf die Reaktion unserer Kunden, aber auch der Community selbst, gespannt.

tux.jpgNach der Einführung in RHCS geht es jetzt ins Eingemachte: die Installation von RHCS unter Debian, um einzelne KVM-Gäste als Dienst anzubieten.

Die Hintergründe von RHCS haben wir bereits erklärt. Die konkrete Umsetzung wird am Beispiel zweier Hosts mit einem Shared Storage erklärt, die als Service verschiedene KVM-Gäste anbieten.

Installation der Nodes

In diesem Setup sind die Nodes die Maschinen, auf denen KVM läuft. Jeder darauf laufende KVM-Gast ist wiederum ein über RHCS verwalteter Dienst. Bei der Installation der KVM-Hosts ist auf mehrere Punkte zu achten:
  • /tmp/ und /var/ sollten auf verschiedenen Partitionen liegen, das verbessert die Performance.
  • Es sollten Debian-Backports genutzt werden, insbesondere für die Kernel.
  • Alle IP-Adressen sollten via DNS in beide Richtungen auflösbar oder in /etc/hosts eingetragen sein.
  • Der Hostname darf nicht auf 127.0.0.1 zeigen, das führt zu Problemen mit dem Cluster Management System CMAN.
  • /etc/hosts/ und /etc/resolv.conf sollte auf allen Nodes gleich sein.
  • ssh-Keys sollten auf allen Nodes passwortlos für root bestehen und auf alle anderen Nodes verteilt werden.
  • Aus Performance-Gründen ist es besser, den aktuellesten stabilen Kernel zu installieren. Allerdings lässt linux-image-2.6.32-bpo.2-amd64 die Gast-Kernel >= 2.6.30 crashen, ein Patch ist aber verfügbar, siehe #573071.
  • Die Netzwerk-Geräte sollten für einen guten Überblick klar benannt sein - zum Beispiel rhcs-backbone und external anstatt eth0 und eth1.

Einrichtung des Shared Storage

Ein zentrales Element des RHCS ist das Shared Sotrage, auf das die Nodes gemeinsame zugreifen. In diesem Beispiel nehmen wir einen "normalen" Rechner, und installieren auf diesem ein iSCSI-Target:
apt-get install iscsitarget iscsitarget-source 
echo 'ISCSITARGET_ENABLE=true' > /etc/default/iscsitarget
m-a a-i iscsitarget


Hier ist zu beachten, dass das iscsi-Target korrekt bauen muss, siehe auch #566740. Eingerichtet wird die Maschine, welche das Shared Storage bereit stellt, via /etc/ietd.conf:

IncomingUser discovery_in YourSecurePwd1
OutgoingUser discovery_out YourSecurePwd2
Target YOURMACHINE:clvm1
       IncomingUser node_in YourSecurePwd1
       OutgoingUser node_out YourSecurePwd2
       Lun 0 Path=/dev/sdx1,Type=blockio


Auf den Nodes muss das Target korrekt angesprochen werden. Dies wird in der /etc/iscsi/iscsid.conf definiert:

discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = discovery_in
discovery.sendtargets.auth.password = YourSecurePwd1
discovery.sendtargets.auth.username_in = discovery_out
discovery.sendtargets.auth.password_in = YourSecurePwd2
node.startup = automatic
node.session.auth.authmethod = CHAP
node.session.auth.username = node_in
node.session.auth.password = YourSecurePwd1
node.session.auth.username_in = node_out
node.session.auth.password_in = YourSecurePwd2


Gestartet wird der Dienst mit /etc/init.d/open-iscsi start. Vorhandene Targets werden mit den folgenden Befehlen gesucht, gelöscht oder hinzugefügt:

# discovering the targets
iscsiadm -m discovery -t st -p YOURMACHINE -P 1
# deleting target on wrong interface
iscsiadm -m node -p 192.168.0.100:3260,1 -o delete
# opening the portal
iscsiadm -m node --targetname "iqn.2010-03.YOURMACHINE:clvm1" --portal "YOURMACHINE:3260" --

VM setup

Die virtuellen Maschinen werden via KVM bereit gestellt. Dafür muss zuerst die passende Software installiert werden:
apt-get install linux-image-2.6.32-bpo.2-amd64 kvm libvirt-bin virtinst -t lenny-backports


Bei der Einrichtung der Bridge für die Gäste muss darauf geachtet werden, dass der Bridge-Name für alle Nodes gleich sein muss. Auch die libvirt-Konfiguration muss gleich sein, es ist daher hilfreich, auf git und vergleichbare Techniken zurück zu greifen. Danach können die Gäste mit

virt-install -n <NAME> -r 256 --vcpus=1 --disk path=/dev/vg_cluster#/<LV> \
  -c /root/debian-<VERSION>-amd64-netinst.iso --vnc --noautoconsole --os-type linux \
  --os-variant debianLenny --accelerate --network=bridge:bridge0 --hvm -k de


installiert und mit virt-viewer -c qemu+ssh://:/system angesehen werden.

RHCS setup

Der nächste Schritt ist das Aufsetzen von RHCS selbst - dafür müssen in erster Instanz die Programme installiert und aufgerufen werden: apt-get install redhat-cluster-suite. Die dadurch bereit gestellten NFS-Dienste werden aber nicht gebraucht:
invoke-rc.d nfs-kernel-server stop
invoke-rc.d nfs-common stop
invoke-rc.d portmap stop
update-rc.d -f nfs-kernel-server remove
update-rc.d -f nfs-common remove
update-rc.d -f portmap remove


Ein anderes Problem ist, dass das Programm system-config-cluster nicht unter Lenny zur Verfügung steht. Es wurde von credativ-Mitarbeiter Philipp Hübner paketiert und ist in Debian erst ab Squeeze enthalten.
Durch einen Backport kann system-config-cluster aber auch auf Lenny genutzt werden:

wget --no-check-certificate https://www.credativ.com/~phu/lenny-backports/system-config-cluster/system-config-cluster_1.0.53-1_all.deb
dpkg -i system-config-cluster_1.0.53-1_all.deb
apt-get -f install
apt-get install xauth


Damit LVM Locking Cluster-weit funktioniert, muss in der /etc/lvm/lvm.conf im Abschnitt global eine Anpassung vorgenommen werden:

 locking_type = 3


Falls wie empfohlen ein neuerer Kernel eingesetzt wird, liegt das Modul lock_dlm nicht mehr vor. Daher muss das Init-Script von CMAN angepasst werden, die Zeile modprobe lock_dlm 2>&1 || return 1 muss auskommentiert werden. Außerdem unterstützt RHCS 2 nur XEN, für libvirt-Unterstützung muss der Ressource Handler vm.sh geladen werden - er liegt für Debian Squeeze bereit:

wget --no-check-certificate https:///www.credativ.com/~phu/vm.sh -O /usr/share/cluster/vm.sh
chmod +x /usr/share/cluster/vm.sh

RHCS selbst wird gestartet mittels

/etc/init.d/cman start
/etc/init.d/clvm start
/etc/init.d/rgmanager start

Fencing

Fencing beschreibt das automatisierte Neutralisieren von Nodes, die nicht mehr reagieren. Wir setzen in unserem Beispiel dafür eine per Netz steuerbare Steckdose ein, NETIO-230A. Es liegt bisher kein fence agent für dieses Gerät vor, aber mit Hilfe der verfügbaren Python-Bibliothek kann ohne Weiteres ein solcher geschrieben werden.

Abschließende Worte

Dieses Howto zeigt, dass das Einrichten von RHCS unter Debian mit einfachen Schritten möglich ist - wenn auch je nach Einsatz weitere Anpassungen vorgenommen werden müssen. Dabei helfen wir übrigens gerne - Open Source Hochverfügbarkeits-Lösungen gehören zu unseren Spezialitäten, und Services und Support bei KVM-Virtualisierung ist unser Alltagsgeschäft.

tux.jpgDie Red Hat Cluster Suite bietet ein Framework, in dessen Rahmen zwei oder mehr Rechner eine Aufgabe erledigen. Der folgende Artikel stellt die Grundlagen der Suite unter der Perspektive des Dienste-Failovers vor.

Der Einsatz von Linux in unternehmenskritischen Umgebungen gehört zu unserem Tagesgeschäft. Dementsprechend ist der Anspruch an die Verfügbarkeit von Linux-Servern und darauf aufsetzenden Diensten sehr hoch. Um eine Ausfallsicherheit bzw. ein Fallback zu gewährleisten, bietet sich unter Anderem der Einsatz der Red Hat Cluster Suite (RHCS) an: diese ermöglicht es, ein Cluster von Rechnern aufzusetzen, die alle die gleiche Arbeit erledigen, bzw. den gleichen Dienst vorhalten. Fällt der Rechner aus, auf dem der Dienst gerade aktiv ist, wird der Dienst auf einem anderen Rechner gestartet.

Zentrale Elemente des RHCS

RHCS besteht aus mehreren Schlüssel-Komponenten:

  • Cluster-Infrastruktur
  • Hochverfügbarkeits-Dienste-Management
  • Werkzeuge für die Cluster-Administration
  • Linux Virtual Server-Routing

Die Cluster-Infrastruktur beinhaltet all die Kernkomponenten, die für den Aufbau und den Betrieb eines Clusters bestehend aus mehreren Nodes notwendig sind. Diese Komponenten verwalten die Integration von Nodes, das Abschalten ausgefallener Nodes (Fencing), replizieren die Konfiguration und so weiter.

Wenn der Cluster konfiguriert wurde, ist der nächste Schritt das Einrichten des Hochverfügbarkeits-Dienste-Managements: wenn ein Cluster einen Dienst hoch-verfügbar anbieten soll, so läuft dieser aktiv auf einer Node. Fällt diese aus, gibt es einen Failover auf eine andere Node. Die Konfiguration dieses Failovers, also des entsprechenden Dienstes so wie dazugehöriger Skripte zum Starten, die Priorität der Failover-Nodes und die notwendigen Ressourcen werden im Hochverfügbarkeits-Dienste-Management definiert.

Die Cluster-Administrations-Werkzeuge sind weniger eine notwendige Kernkomponente, als vielmehr benutzerfreundliche Schnittstellen zu den oben genannten Arbeiten: GUIs, Web-Oberflächen und Programme zur Status-Verfolgung der Nodes.

Auch das Linux Virtual Server-Routing ist nicht zwingend für den Cluster-Betrieb, auch wenn die RHCS-Dokumentation es als Kernkomponente auflistet: es dient als Load-Balancer auf IP-Ebene, und leitet den Verkehr um, falls eine Node ausfällt.

Neben diesen RHCS-Komponenten kann das System auf weitere Dienste zurückgreifen, sofern sie vorhanden sind: ein globales Dateisystem wie GFS und ein Cluster Logical Volume Manager helfen beim Einbinden von Block-Devices via Netzwerk und vereinfachen so den Umgang mit Shared Storage.

Hardware eines RHCS-Clusters

Um einen RHCS-Cluster inital aufzubauen werden mehrere Maschinen benötigt:

  1. Shared Storage wie z.B. iSCSI oder Fibre Channel.
  2. Für jeden Node eine Methode, um diese vom Netz vollständig zu trennen (Fencing), z.B. eine via Netzwerk an/abschaltbare Steckdose
  3. Mindestens zwei Nodes mit Netzwerkkarte.
  4. Ein Switch.

Wichtig ist, dass das Shared Storage dabei nicht auf einer der Nodes läuft. Außerdem beschreibt die hier aufgelistete Konfiguration nur das absolut notwendige Minimum an Hardware-Konfiguration - bei einem größeren Cluster wären deutlich mehr Nodes denkbar.

Fazit

Die RHCS bietet ein gut durchdachtes Framework zum Management von Clustern, insbesondere in zur Bereitstellung von Dienste-Failovern. Mit einfachen Mitteln und Standard-Hardware kann so ein kritischer Teil der IT-Infrastruktur gesichert und hoch verfügbar gemacht werden.Zwar impliziert das R in RHCS, dass diese Methode vor allen Dingen auf Red-Hat-Maschinen läuft, dem ist aber nicht so - mehr dazu die nächsten Tage.

tux.jpgWie jedes Jahr laufen auch dieses Jahr einige Versionen von wichtigen Open-Source-Programmen aus: für sie werden keine weiteren Updates mehr veröffentlicht. Wir führen die Wichtigsten auf.

Das Ende einer Software-Version (EOL) bedeutet meist, dass ab dem Zeitpunkt keine Updates mehr geboten werden. In besonderen Ausnahmesituationen wird vielleicht noch mal ein Sicherheitsupdate nachgeschoben, dies ist aber selten, und verlassen sollte man sich darauf erst recht nicht. Daher ist es wichtig, immer einen Blick auf die wichtigsten Projekte zu halten, und deren EOL zu verfolgen. Wir bieten hier eine kleine Übersicht, gegliedert in Projekte und Distributionen.

Projekte

Bei PostgreSQL werden dieses Jahr gleich drei Versionen auf das Altenteil geschoben: PostgreSQL 7.4 und 8.0 werden im Juli, Version 8.1 im November auslaufen.

Auch Apache hat für den Web Server der Serie 1.3 das Ende eingeleitet. Es wird für die 1.3er-Serie allenfalls noch kritische Sicherheitsupdates geben.

Nicht ganz so tragisch, und doch eine Erwähnung wert ist Python: die 2.x-Reihe wird ebenfalls ihr letztes Release noch dieses Jahr sehen. Danach gibt es zwar noch Bugfixes, die Sprache selbst wird aber nur noch im 3.x-Zweig weiter entwickelt.

Distributionen

Auch bei den Distributionen geht der Reigen weiter, und wichtige Versionen werden nicht mehr weiter gepflegt. Den größten Augenmerk verdient hier sicherlich Debian Etch: der Support läuft in wenigen Tagen, am 15. Februar aus. Da Debian Etch gerne als stabiles Server-Betriebssystem verwendet wurde, ist hier besondere Vorsicht geboten, Upgrades auf neuere Versionen sind dringend angeraten!Das Gleiche gilt für CentOS 3: diese häufig im Server-Umfeld eingesetzte Version erreicht das Ende der Lebenszeit im Oktober 2010.Für andere, teilweise mehr auf Endnutzer ausgerichtete Distributionen kommt ebenfalls bald das Ende: openSUSE 11.0 und 11.1 werden noch dieses Jahr eingestellt (im Juni bzw. Dezember), gleiches gilt für Ubuntu 8.10 (Intrepid Ibex) und 9.04 (Jaunty Jackalope), die es im April und Oktober erwischt.Die vermutlich schnelllebigste Distribution Fedora verliert dieses Jahr die Version 11, die im Juni, einen MOnat nach der Veröffentlichung von Version 13, auslaufen dürfte.

Was tun?

In allen genannten Fällen, von Python vielleicht mal abgesehen, sollte die jeweils eingesetzte Software dringend auf eine unterstützte Version aktualisiert werden. Da eine solche Migration eventuell nicht ganz ohne ist, stellen die Projekte meist umfangreiche Informationen zu den Upgrade-Pfaden und -Methoden bereit. Wichtig ist, dass nichts überstürzt wird: ein Upgrade sollte ausgiebig geplant und auf einem Staging-System im Vorfeld getestet werden.

Bei allen genannten Software-Projekten und Distributionen hilft auch gerne unser Open Source Support Center. Wir verfügen über langjährige Erfahrung mit allen Software-Komponenten, Projekten und Distributionen, und können bei Migration jeden Maßstabs bei Planung und/oder Umsetzung helfen