de.credativ-Blog: Kategorie Support

credativ veröffentlicht den Open Source Schutzbrief

2010-08-17T10:15:00Z

Ab sofort bietet credativ den Open Source Schutzbrief an, einen Notfallsupport für IT-Infrastrukturen.

Mit dem Open Source Schutzbrief bietet credativ eine Lösung für alle Diejenigen, die ihre IT grundsätzlich selbst verwalten, aber im Notfall doch Zugriff auf Expertenwissen benötigen.

Dr. Michael Meskes, credativs Geschäftsführer, bringt das grundlegende Problem in der Pressemitteilung auf den Punkt:

Leider ist es oft so, dass Störungen und Notfälle in den absolut ungünstigsten Situationen eintreten. Viele Unternehmen werden die folgenden Situationen kennen: Die Administratoren, die sich mit dem betroffenen Open Source Systemen am besten auskennen sind gerade in Urlaub oder krank. Die Störung erfolgt genau in der Hauptgeschäftszeit. Der Fehler lässt sich nicht genau lokalisieren.

In einem solchen Fall müssen externe Dienstleister her, um die Systeme wieder lauffähig zu machen. Die Zeit ist dann aber zu kurz, um fähige Dienstleister zu suchen, Verträge auszuhandeln und und und.

Der Open Source Schutzbrief aber wirkt hier als eine Art Versicherung, mit der garantiert wird, dass auch im schlimmsten Fall umgehend fähige Techniker das Problem angehen.

credativ US und Forest Informatics vereinbaren Partnerschaft

2010-06-17T10:37:58Z

Die US-Abteilung von credativ ist mit dem auf Forst-Ressourcen-Management spazialisierten Unternehmen Forest Informatics eine Partnerschaft eingegangen. Zusammen bieten die beiden Unternehmen Training und Support für die Verarbeitung von Geodaten mit Hilfe von Open-Source-Software an.

Forest Informatics bietet Lösungen rund um die Verwaltung von forstwirtschaftlichen Gebieten mit Hilfe von Geodaten an. Ein Schwerpunkt liegt dabei auf der Offenheit der eingesetzten Lösungen: bewusst wird den Kunden von proprietären Lösungen abgeraten, die Vorteile von Open Source werden klar wahr genommen und vermittelt. Dieser Ansatz versteht sich exzellent mit der Perspektive credativs: als Open-Source-Unternehmen kennen wir nicht nur die Vorteile von Open Source, wir vermitteln sie aktiv an unsere Kunden weiter und stehen für die Vorteile und Ideale dahinter ein.

Auf Grund dieser Gemeinsamkeiten haben sich beide Unternehmen dazu entschlossen, eine Partnerschaft einzugehen, und Kunden gemeinsam Open-Source-Lösungen und -Schulungen für GIS und Forst-Ressourcen-Management anzubieten. Die Themenschwerpunkte sind dabei PostgreSQL, PostGIS, R, und PL/R.

Zur Einführung wird es im September einen dreitägigen Kurs Intro to PostgreSQL with Spatial Analysis Extensions in San Diego geben. Den Kursteilnehmern werden dabei sowohl Datenbank-Grundlagen anhand von PostgreSQL näher gebracht, also auch Geodaten-Management mit Hilfe von PostGIS und die Prinzipien der Datenverarbeitung mit Hilfe von PL/R und R erlernen können.

Wir von credativ freuen uns über diesen neuen Partner, und wünschen von Deutschland aus alles Gute auf die andere Seite des Atlantiks!

Mehr über credativs Open-Source-Angebote erfahrt Ihr auf unserer Webseite. Wir freuen uns aber auch gerne über Kommentare und Fragen hier auf dem Blog oder über unser Kontakt-Formular.

End of Life für RHEL/CentOS 3 angekündigt

2010-05-11T12:18:00Z

In 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.

Pressespiegel Open Source Support Card

2010-03-24T11:22:28Z

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:

Heise - Linux-Support à la carte

Golem - Linux Support Card: Prepaid-Karte für Linux-Hilfe

Linux-Magazin - Linux-Support auf Guthabenkarte (Dort waren wir auch Top-Thema im Newsletter.)

Pro-Linux - Credativ startet die Linux Support Card

Winfuture - Linux-Support gibt es nun auch per Prepaid-Karte

OSZine - credativ veröffentlicht die Open Source Support Card (Achtung: bei OSZine arbeiten wir selbst ehrenamtlich viel als Autor mit!)

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.

[Howto] Einstieg in Puppet

2010-02-25T08:33:32Z

Bei der Administration einer großen Zahl von Servern ist ein zentrales Konfigurations-Management irgendwann unabdingbar. Dieser Artikel beschreibt in einer ersten Einführung das in Ruby geschriebene Framework Puppet.

Einführung

Teil unseres Tagesgeschäfts ist es, beliebig große Server-Installationen zu verwalten und zu warten. Gerade bei großen Clustern heißt dies, eine Vielzahl von Maschinen mit fast identischer Konfiguration nebeneinander zu betreiben. Ohne eine zentralisierte, automatisierte Konfigurations-Verteilung ist dies kaum machbar - an dieser Stelle tritt Puppet auf den Plan.
Wie auch andere Konfigurations-Management-Werkzeuge greift Puppet auf einen zentralen Server zurück, der die Konfiguration verwaltet. Dort fragen die "Clients" verschlüsselt die Konfiguration ab, und spielen Sie gemäß der Vorgaben des Servers ein, verändern Rechte, führen Befehle aus, etc. Die Vorteile liegen auf der Hand:

Arbeitsschritte müssen unabhängig von der Rechner-Zahl nur einmal umgesetzt werden, unnötige Wiederholungen werden vermieden.
Für alle Rechner vereinheitlicht sich die Konfiguration zwangsweise - und wird damit einfach wartbar.
Die zentrale Infrastruktur ermöglicht einen schnellen Überblick an einer Stelle - ein "Rumlaufen", entfällt.
Der zentrale Konfigurationsbaum ermöglicht damit eine Versionierung: das Zurückspielen der Konfiguration für alle Rechner eines Netzwerkes z.B. auf den Stand "PRE-UPDATE" geht mit wenigen Befehlen, für das ganze Netzwerk!

Technische Arbeitsweise

Puppet besteht aus einem zentralen Server, Puppet-Master genannt, und den Clients, genannt Nodes. Diese melden sich beim Master an, und fragen dort nach der aktuellen Konfiguration. Der Master gibt diese an die Nodes weiter - die Möglichkeiten der Anweisungen des Masters sind schier unbegrenzt:

Der Server kann Dateien übergeben, die an bestimmte Orte kopiert werden.
Die Node kann angewiesen werden, Dateirechte zu prüfen und notfalls zu korrigieren.
Je nach Betriebssystem kann erzwungen werden, dass die Node prüft, ob bestimmte Dienste aktiv sind, oder ob bestimmte Pakete auch in der neuesten Version installiert sind.
Der Server kann die Node anweisen, bestimmte Befehle auszuführen.
usw.

Im Prinzip kann alles mit der Übergabe von Dateien vom Server an die Node erledigt werden, doch ist dies in komplexen Setups weder übersichtlich noch vereinfachend. Gerade die Abstraktion von System-Aufgaben (Dienste neu starten, Paket-Versionen sicherstellen, Nutzer einrichten, etc.) ohne das direkte Überschreiben von Dateien hilft ungemein beim Konfigurieren komplexer Systeme.

Installation

Für die Installation benötigt man einen zentralen Puppet-Master, der die Konfiguration verwaltet: apt-get install puppetmaster Puppet geht davon aus, dass alle beteiligten Rechner FQDNs haben, dies sollte in einem korrekt gewarteten Netzwerk aber eh der Fall sein!
Auf jedem zu verwaltenden Rechner wird ein Puppet-Client mit apt-get install puppet installiert.

Konfiguration von Puppet

Die Puppet-Nodes suchen automatisch nach dem Rechner, der auf den Namen puppet auflöst, so lange der Name korrekt auf den Hauptserver zeigt, brauchen sie nicht weiter konfiguriert werden.
Beim Puppet-Master muss der Dateiserver noch korrekt konfiguriert werden, der wie oben beschrieben Dateien an die Nodes übergeben kann. Je nach Anspruch können die Dateien dabei nah bei der weiteren Konfiguration gehalten werden, oder aber zentral in einem externen Archiv untergebracht werden. Für unser Beispiel werden wir die zu verteilenden Dateien nah bei der eigentlichen Konfiguration halten, ganz so, wie es auch im Best Practice Guide und in der Anleitung Module Configuration der Puppet-Dokumentation beschrieben wird.
Daher reicht es, in der Datei /etc/puppet/fileserver.conf folgende Konfiguration vorzunehmen:

[modules]
allow 192.168.0.1/24
allow *.credativ.de

Konfiguration der Konfiguration - Module

Um eine Server-Konfiguration durch Puppet erledigen zu lassen, ist es am Besten, diese in Aufgabenbereiche oder Themen zu unterteilen, wie zum Beispiel "ssh", "logs", "apache", etc. Diese Bereiche werden in Puppet als "Module" bezeichnet, und sind der Kern von Puppets Konfigurationsverwaltung. Den Aufbau eines Modules beschreiben wir hier anhand einer fiktiven SSH-Konfiguration und halten uns dabei eng an den Best Practice Guide.
Es sei angemerkt, dass die tatsächliche Konfiguration von SSH durch Puppet an einigen Stellen dynamischer wäre, hier wird nur ein vereinfachter Weg gezeigt.

Das SSH-Modul

Der Anspruch des SSH-Moduls ist:

Das openssh-server-Paket soll in neuester Version installiert sein.
Die Datei sshd_config soll der entsprechen, die im Puppet-Master hinterlegt ist.
Falls die Datei sshd_config installiert wird, soll der sshd neu gestartet werden.
Der Nutzer credativ soll bestimmte Dateien in seinem Verzeichnis $HOME/.ssh haben.

Um diesen Ansprüchen gerecht zu werden, erstellen wir die notwendigen Verzeichnisse des Moduls:

mkdir -p /etc/puppet/modules/ssh/manifests
mkdir -p /etc/puppet/modules/ssh/files

Der Ordner Mainfests enthält die eigentlichen Konfigurations-Anweisungen des Moduls, der Ordner files hält Dateien vor, die an die Nodes ausgeliefert werden sollen.
Die Konfigurations-Anweisungen des Modules finden sich in der Datei init.pp im Ordner manifests. Die Gruppe von Anweisungen, um die obigen Ziele 1.-4. zu erfüllen, wird dort als "Klasse" zusammen gefasst. Die Klasse enthält selbst wiederum Untersektionen, sogenannte Types. In unserem Fall findet sich für jedes vorher definierte Ziel ein Type:

class ssh{
        package { "openssh-server":
                 ensure => latest,
        }
        file { "/etc/ssh/sshd_config":
                owner   => root,
                group   => root,
                mode    => 644,
                source  => "puppet:///ssh/sshd_config",
        }
        service { ssh:
                ensure          => running,
                hasrestart      => true,
                subscribe       => File["/etc/ssh/sshd_config"],
        }
        file { "/home/credativ/.ssh":
                path    => "/home/credativ/.ssh",
                owner   => "credativ",
                group   => "credativ",
                mode    => 600,
                recurse => true,
                source  => "puppet:///ssh/ssh",
                ensure  => [directory, present],
        }
}

jeder Type setzt eine gänzlich andere Aktion auf dem Node um:

package
Hier wird sicher gestellt, dass das Paket openssh-server in der neuesten Version installiert ist.: file
Eine Datei auf der Node wird durch die Version vom Server überschrieben und mit entsprechenden Rechten versehen.: service
Der Dienst sshd muss laufen, und wird notfalls gestartet. Falls außerdem die Datei /etc/ssh/sshd_config aktualisiert wird, wird auch der Dienst neu gestartet.: file
Hier taucht noch einmal der Type "file" auf - es wird aber nicht eine einzelne Datei übertragen, sondern gleich ein ganzes Verzeichnis.

Damit das Modul auch korrekt arbeitet, müssen die beim Type "file" definierten Dateien und Verzeichnisse auch unter /etc/puppet/modules/ssh/files/ zu finden sein.

Nodes und Module

Wir haben nun drei Elemente: den Puppet-Master, die Nodes, und die Module. Nun muss die Zuweisung erfolgen, welche Nodes welche Module aufrufen sollen. Dafür muss zuerst das Modul in der Datei /etc/puppet/manifests/modules.pp aktiviert werden:

import "ssh"

Die Zuweisung zu den einzelnen Nodes erfolgt in der Datei /etc/puppet/manifests/nodes.pp. Diese legt für jede Node fest, welches Modul geladen wird. Außerdem gibt es für alle nicht weiter spezifizierten Nodes einen Default-Eintrag, und zu guter Letzt können auch Einträge von anderen abgeleitet werden. Um also für alle Nodes das Modul "rsyslog" zu laden, aber nur für die Node "external" das Modul "ssh", sieht der Eintrag wie folgt aus:

node default {
   include rsyslog
}

node 'external' inherits default {
  include ssh
}

Damit ist Puppet fertig konfiguriert, und nimmt sofort seine Arbeit auf.

Zertifikate - Sichere Kommunikation zwischen Node und Master

Die Kommunikation zwischen Master und Node verläuft verschlüsselt. Um dies zu gewährleisten, müssen Nodes auf dem Master zertifiziert werden. Dies ist möglich, nachdem ein Node das erste Mal eine Anfrage an den Master gestellt hat - der Master setzt diesen Node dann auf wait, und stellt ihm so lange keine Daten zur Verfügung. Erst, wenn die Node durch einen Admin verifiziert wurde, wird die Node frei geschaltet. Mit # puppetca --list wird die Liste der noch zu verifizierenden Nodes angezeigt, verifiziert wird mit: # puppetca --sign external.example.com Bei Bedarf kann dieser Prozess weiter verfeinert werden.

Abschließende Worte

Die hier vorgestellten Beispiele sind natürlich stark vereinfacht. Im Real-Betrieb würde die SSH-Konfiguration komplexer sein, und Schlüssel würden nicht gerade mit dem Type "file" statisch verteilt werden. Aus diesen Beispielen lassen sich aber leicht weitere Module ableiten, und die an vielen Stellen verlinkte Konfiguration tut ihr Übriges, damit der geneigte Leser sich tiefer in die Materie einarbeiten kann.
Wir hier bei credativ haben mit Puppet mittlerweile sehr umfangreiche und sehr gute Erfahrungen gemacht, leisten an vielen Ecken Support und Beratung für Puppet und merken, wie die Nachfrage steigt. Puppet ist derzeit auf der Überholspur, und es wird spannend sein zu beobachten, wie sich der Platzhirsch cfengine angesichts dieser Konkurrenz verhält.

Mobiles Linux vereint: Moblin + Maemo = MeeGo

2010-02-15T12:59:08Z

Soeben wurde bekannt gegeben, dass Nokia und Intel ihre mobilen Linux-Plattformen verschmelzen, um eine gemeinsame Basis zu schaffen: MeeGo.

Mit Intel und Nokia hatten zwei Technik-Schwergewichte seit geraumer Zeit Ihre jeweils eigene Linux-Plattform für mobile Geräte: Nokia setzte auf Maemo, während Intel Moblin voran trieb. Diese standen sich in einem hart umkämpften Markt gegenüber, in dem auch Android und LiMo mit mischen - ganz zu schweigen von den proprietären Anbietern.

Nun haben Intel und Nokia bekannt gegeben, dass die beiden Projekte zukünftig ihre Kräfte in der gemeinsamen Plattform MeeGo bündeln werden:

Moblin und Maemo werden vereint! Wir nehmen die besten Teile dieser beiden Open-Source-Projekte, und erschaffen damit die MeeGo software platform.

Wirtschaftlich ist dieser Schritt einleuchtend: in einem so hart umkämpften Markt sind Intel und Nokia zwei schwergewichtige Partner, die sich gemeinsam auch gegen Größen wie Google, Apple oder Microsoft stemmen können. Bisher hatten sie jeweils alleine nur wenig Erfolg, Geräte mit Maemo oder Moblin gibt es nur vereinzelt. Darüber hinaus sind beide Plattformen technisch ähnlich gewesen, eine Zusammenarbeit spart hier Ressourcen. Da MeeGo aber auf allen möglichen Geräten, vom Mobiltelefon bis zum Fernseher laufen soll, stellt sich die Frage, ob Nokia und Intel beim Geräteangebot nicht auch in Konkurrenz treten werden.

Technisch ist interessant, dass MeeGo zukünftig auf Qt setzen wird. Dieses mittlerweile von Nokia voran getriebene Framework zum Programmieren grafischer Oberflächen ist unter Anderem die Basis für KDE. Auch wir bei credativ arbeiten häufig mit Qt, leisten bei Kunden dafür Support und kennen daher die Stärken der Oberfläche sehr gut: MeeGo baut mit Qt auf einer modernen und erprobten Oberfläche auf! Darüber hinaus wurde mitgeteilt, dass MeeGo auf RPM aufsetzen wird. Das, zusammen mit dem Hinweis auf "kickstart"-Dateien im Entwickler-Bereich, legt nahe, dass die zukünftige Basis von MeeGo sich in der Nähe von Distributionen wie OpenSuse, Fedora oder RHEL befindet.

Neben dem technischen und wirtschaftlichen Aspekten ist aber vor allen Dingen wichtig, wie die Community integriert wird: während LiMo nachgesagt wird, dass es faktisch die Community außen vor lässt, hat sich Android jede Menge Kritik gefallen lassen müssen, da sie ihre Änderungen an z.B. dem Kernel nicht in diesen einbringen. MeeGo hingegen soll unter der Schirmherrschaft der Linux-Foundation entwickelt werden, die der Community nicht fremd ist und bei der auch namenhafte Entwickler angestellt sind.

Es wird sich zeigen, wie sehr MeeGo sich im Markt behaupten wird - noch gibt es keine Geräte in der Masse. Spannender wird der Wettbewerb dadurch aber allemal.

Skolelinux 5.0 veröffentlicht

2010-02-09T13:23:11Z

Das Skolelinux-Team hat die Version 5.0 seines beliebten Schulservers veröffentlicht, der jetzt auf Debian Lenny aufsetzt.

Die Distribution Skolelinux, auch Debian-Edu genannt, ist eine angepasste Debian-Version für den Betrieb eines Schulnetzes unter Linux: mit nur wenigen Schritten können so auch technisch unbedarfte Nutzer mit wenigen Handgriffen einen zentralen Schulserver mit Terminal-Server und Thin-Clients, Workstations und Laptops als Arbeitsplatzrechner installieren. Auch die Integration von bestehenden Windows-Installationen wird unterstützt.

Mit der Veröffentlichung der Version 5.0 wurde auch Skolelinux auf die Software-Basis aktueller Debian-Installationen gehievt. Neben der deutlich besseren Unterstützung neuerer Hardware ist auch die mitgelieferte Software so deutlich aktueller und somit ansprechender für Schüler und Schulen. Zu den hervorstechenden technischen Neuerungen dieser Version gehören außerdem:

Der GNOME Desktop wird nun zusätzlich zu KDE unterstützt.
Verbesserter Schüler-Desktop mit Lernsoftware-Verknüpfungen zu GCompris, Kalzium, KGeography, KMplot, KStars, Stopmotion und der OpenOffice Suite.
Verbesserte LTSP-Server Konfiguration:
- Neben den traditionellen Thin Clients sind plattenlose Arbeitsstationen jetzt auch 'out of the box' unterstützt.
- Das neue PXE-Start-Menü erlaubt plattenlosen Arbeitsstationen das Booten über das Netzwerk oder über lokale Medien.
- Plattenlose Arbeitsstationen (Diskless Workstations) erhalten ihre Software vom Server und führen sie dann lokal aus, sie kann also zentral auf dem Server gewartet werden.
Die Dokumentation wurde weiter verbessert und von Englisch nach Deutsch, Italienisch und Norwegisch übersetzt.
Verbessertes und vereinfachtes Benutzer- und Maschinen-Administrations Werkzeug LWAT (LDAP Web-based Administration Tool).
Verbesserte Browser-Unterstützung mit freien Softwareprodukten wie Gnash, Java und anderen Plug-ins.
PulseAudio sorgt zusätzlich neben ALSA und dem OSS Sound System für eine verbesserte Audio- und Multimedia-Leistung.
Verbessertes Maschinen- und Netzwerkmonitoring, das jetzt den Status aller zum Netzwerk hinzugefügten Maschinen automatisch meldet.

Philipp Hübner, ehrenamtlicher Helfer des Skolelinux-Projekts und Mitarbeiter bei credativ unterstreicht insbesondere die Modernität der neuen Version:

Skolelinux hat mit der Lenny-Version einen großen Schritt nach vorn gemacht: durch die nahtlose Integration von Diskless Workstations out-of-the-box wird Skolelinux modernen Anforderungen und der stetig zunehmenden Leistung von Computern gerecht. Auf diesem Weg wird die Performance von Workstations mit dem geringen Wartungsaufwand von Thin-Clients vereint.

Skolelinux wird derzeit in mehreren Bundesländern in Deutschland produktiv eingesetzt oder für den Einsatz getestet. So wurde in Rheinland-Pfalz ein von der credativ GmbH betreutes Skolelinux-Evaluationsprojekt 2009 erfolgreich abgeschlossen. Die Lösung wird dort in immer mehr Schulen im täglichen Schulbetrieb genutzt, zertifizierte Dienstleister wie die credativ GmbH bieten den Schulen und Schulträgern bei Bedarf professionellen Support.

Außerhalb Deutschlands ist die größte bekannte Installation in Extremadura: dort nutzen 250.000 Schüler Skolelinux in ihren Schulen.Wir von credativ gratulieren Skolelinux für dieses Release und wünschen das Beste für die Zukunft!

EOL: Auslaufende Versionen bekannter Open-Source-Projekte in 2010

2010-02-05T09:24:13Z

Wie 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

gebündelte Kräfte: OpenLogic und credativ vereinbaren Partnerschaft

2010-01-29T11:18:29Z

Was schon durch die englischsprachige Nachrichtenlandschaft geisterte, sickert heute auch in die deutschsprachige Welt ein: OpenLogic und credativ bündeln ihre Open-Source-Kräfte in einer engen Partnerschaft.

Nachdem vor zwei Tagen die Neuigkeit zuerst auf englisch veröffentlicht wurde, ist heute auch eine deutsche Pressemitteilung online gegangen: OpenLogic und credativ bündeln ihre Kräfte in einer Partnerschaf rund um Open-Source. Ziel der Partnerschaft ist es, OpenLogics Enterprise-zertifizierte Open-Source-Lösungen mit der umfangreichen Erfahrung und Expertise von credativs Open-Source-Support zusammen zu bringen.

Im Kern bedeutet dies, dass OpenLogics 3rd-Level Support zukünftig von credativ übernommen wird. Außerdem unterstützt credativ den Enterprise-CentOS-Support, den OpenLogic seit Ende letzten Jahres anbietet, genau so wie den Support für alle anderen, mehr als 500 zertifizierten Open-Source-Software-Pakete von OpenLogic. credativ greift dabei auf ihre Open Source Support Center zurück, die in den USA, Kanada, Großbritannien und Deutschland betrieben werden.

Dazu noch ein paar kurze Worte des Geschäftsführers von credativ, Dr. Michael Meskes:

Ich bin über die Zusammenarbeit mit OpenLogic sehr erfreut. Hier zeigt sich ganz klar, dass wir mit dem erfolgreichen Konzept unserer Open Source Support Center in Europa auch in den USA genau die Bedürfnisse unserer Kunden treffen und mit dem internationalen Ausbau unserer Aktivitäten die richtige Strategie verfolgen.

Auf eine produktive und vielseitige Partnerschaft!