Als ich gestern über das Ende von Debian Sarge nachdachte fiel mir auf, das diese Version nicht einmal 3 Jahre gehalten hat, eigentlich sehr schade, wie ich finde. Gerade die Langlebigkeit von Debian-Distributionen empfand ich immer sehr angenehm, denn für viele Server ist ein zu kurzer Lebenszyklus weder sinnvoll noch rentabel.

Schaut man über die Lebenszeit eines Systems, sind 3 Jahre eine verdammt kurze Zeit. Projektierung, Anschaffung, Test, Betrieb und das Ausphasen verschlingen doch etliche Zeit. Ist zu diesen Zeitpunkt die Distribution schon ein Jahr veröffentlicht verschlimmert sich die Sache sogar noch. Debian mit seinen bisherigen Lebenszyklen war daher für mich das erste Enterprise-Linux, auch wenn die Länge nicht immer geplant war, sondern sich durch Unzulänglichkeiten oder dem Erwachsenwerden der Organisation begründeten.

Man braucht also einen guten Kompromiss für den Lebenszyklus einer Distribution. Wenn 3 Jahre zu kurz sind, denke ich, kann man mit 5 Jahren gut leben. So hat man die Gewissheit auch noch mitten im Lebenszyklus einer Distribution nicht auf ein totes Pferd zu setzen. Diese lange Zeit stellt aber auch die Distribution vor Probleme, denn die Hardware ändert sich in dieser Zeitspanne dramatisch. Das war schon immer ein wunder Punkt von Debian, welches sich aber durch den Einsatz der Backports stark gebessert hat.

Wie es mit dem LTS von Ubuntu ausschaut wird sich auf Dauer zeigen. Im Moment sieht es so aus, das sie einen Haufen Software für Stabil erklärt haben und das für die nächsten 5 Jahre nicht ändern wollen. In Konsequenz bedeutet dieser Umstand schon heute, das Ubuntu Dapper LTS für langfristige Projekte Tod ist. Man stelle sich ein Projekt vor, das in ein, zwei Jahren erweitert werden muss. Die heutige Hardware ist nicht mehr lieferbar und installieren lässt sich Dapper LTS auch nicht mehr. Klar kann man nun zu Frickeln anfangen, aber das pflegen eigener Pakete kann ganz schön aufwändig sein.

Einen wirklich guten Kompromiss zwischen Lebenszyklus und Aktualität was Hardware-Treiber angeht liefert im Moment Redhat resp. CentOS. Selbst CentOS 4 kann man heute noch in Projekten ohne Bedenken einsetzen, da Redhat mit Version 4 bis ins Jahr 2012 plant. Neue Hardware trotz 2.6.9er-Kernel? Kein Problem!

Schaut man über den Tellerrand zu Solaris sieht die Situation noch besser aus. Nächstes Jahr fängt, nach über 10 Jahren, Solaris 8 an auszulaufen. Die Schmerzen die es hinterläßt sind aber erträglicher als die Schmerzen die ein Wechsel der Version unter Linux verursachen kann, besonders wenn man viel selbstgeschriebene oder gekaufte Software einsetzt. Bedeutet eine neue Version der Linux Distribution vielfach neue Software, kann man die alte unter Solaris dank der garantierten Binärkompatibilität weiter einsetzen. Das Solaris dafür an anderen Ecken stinkt macht die Wahl einer Umgebung nicht einfacher.

Posted: März 1st, 2008 under Debian, Linux, Redhat/CentOS, Solaris.
Comments: 15

Die Entscheidung vermehrt auf CentOS resp. Redhat zu setzen ist mir beileibe nicht leicht gefallen, aber der extrem niedrige Frickelfaktor bei der Installation und die sehr gute Treiber-Unterstützung sind nicht von der Hand zu weisende Argumente. Redhat schenkt einem aber nichts, denn man bezahlt an anderer Stelle dafür. Besonders hart trifft es einen, wenn man von Debian kommt. Von deren Aufgeräumtheit und Verlässlichkeit im Konfigurationsbereich sind die Rothüte Kilometer weit entfernt.

Beispiel Bind unter Redhat/CentOS: Man installiert bind mit yum install bind, man startet es mit service named start, die Konfiguration liegt in /var/named. Unter Debian liegt die Konfiguration, egal ob Bind8 oder Bind9 unter /etc/bind, man installiert mit apt-get install bind(9) und startet mit /etc/init.d/bind(9). Dieses /var/named erinnert mich immer an bind4-Zeiten *schauder*

Oder Apache: Das Debian Konstrukt mit sites-available und sites-enabled ist simpel und effektiv, bei Redhat gibt es soetwas nicht. Dort heisst der Apache-Prozess auch httpd und nicht apache(2) wie bei Debian. Genau das gleiche Spiel bei der Installation: yum install httpd gegen apt-get install apache(2). Alles voll krass logisch und durchdacht.

Ich könnte jetzt wieder über die Netzwerk-Konfiguration lästern, aber das möchte ich nicht nochmal wiederholen.

Posted: Januar 22nd, 2008 under Debian, Linux, Redhat/CentOS, Software.
Comments: 4

Cluster sind für viele etwas schwer greifbares. Ich habe es schon oft erlebt, das Firmen einen HA-Cluster hingestellt und es von den Mitarbeitern mit Ehrfurcht betrachtet wurde. Nur nicht anfassen, es könnte ja etwas kaputt gehen.

Dabei gibt es hierfür keinen Grund, denn in der IT wird auch nur mit Wasser gekocht und das beste Mittel gegen Ehrfurcht und Berührungsängste ist es immer noch sich damit auseinander zu setzen.

Wer also einen Einstieg haben möchte kann recht problemlos mit dem Redhat Cluster beginnen, welches es auch von CentOS gibt. Besondere Hardware ist nicht nötig, das folgende Beispiel, auf Basis von CentOS 4.6, läuft zum Beispiel in einem VMWare Server.

Read more »

Posted: Dezember 23rd, 2007 under Linux, Redhat/CentOS, Software.
Comments: 2

Und es funktioniert sogar! Wohooo!

Posted: Dezember 6th, 2007 under Linux, Redhat/CentOS.
Comments: 8

Gegeben Redhat Enterprise Linux AS 4 Update 6 mit neuesten Updates:

[root@zapbrannigan ~]# system-config-cluster
Traceback (most recent call last):
  File “/usr/sbin/system-config-cluster”, line 52, in ?
    from ConfigTab import ConfigTab
  File “/usr/share/system-config-cluster/ConfigTab.py”, line 27, in ?
    from ConfigTabController import ConfigTabController
  File “/usr/share/system-config-cluster/ConfigTabController.py”, line 35, in ?
    from FaildomController import FaildomController
  File “/usr/share/system-config-cluster/FaildomController.py”, line 213
    if val == “Yes” or val == “yes” or val=”1″:
                                          ^
SyntaxError: invalid syntax

Dafür gibt es natürlich auch einen Bug-Report. Am besten finde ich die letzte Zeile:

Looking for qa ack…please.

Die spannende Frage ist doch: wo war die Qualitäts-Sicherung vor Auslieferung des kaputten Programmes?

Posted: November 30th, 2007 under Linux, Redhat/CentOS.
Comments: 6

Die Redhat-Seiten sind mehr als mißverständlich was die Lizensierung (Ja, ich weiss Redhat hat keine Lizenzen nur Subscriptions) angeht. Hier eine kleine Hilfe.

1. Man benötigt grundsätzlich eine Subscription, um irgendetwas von Redhat zu bekommen, seien es Sicherheitsupdates oder Hilfe bei Problemen. Wenn man eine hat, ist es gleichgültig ob man RHEL4 oder RHEL5 betreibt.
• Basic - Zugriff auf Patche, Upgrades und Websupport. Reaktionszeit: 2 Werktage
• Standard - Zugriff auf Patche, Upgrades, Telefon- und Websupport (12×5). Reaktionszeit: Je nach Schwere von 1 bis 4 Stunden
• Premium - Zugriff auf Patche, Upgrades, Telefon- und Websupport (24×7). Reaktionszeit: Je nach Schwere von 1 bis 4 Stunden

Die Supportform Basic ist nicht für die RHEL5 Advanced-Platform erhältlich.

2. Mit Socket oder Sockeln sind wirklich Prozessor-Sockel gemeint (ob bestückt oder nicht ist egal). Cores (Dual- oder Quadcores werden nicht mitgezählt
3. Bei der RHEL5 Advanced Platform sind Cluster-Manager und GFS ClusterFS enthalten

Die Preise findet man im Redhat-Shop.

Posted: November 12th, 2007 under Linux, Redhat/CentOS.
Comments: 1

Eigentlich wollte ich mit Archlinux beginnen bei der Suche nach einer neuen Distribution, aber ich habe schnell gemerkt, das es etwas mehr Vorarbeit benötigt. Also hab ich schnell zur Fedora 8 RC3 DVD (am Donnerstag wurde es veröffentlicht) gegriffen, da sie gerade hier rumlag. Die Installation wird jedem der schon einmal Redhat installiert hat, und wenn es schon ein paar Jahre her ist, bekannt vorkommen.

Der erste Versuch ging bei mir schief, da ich Extra Repositories angeklickt hatte und mich daraufhin in einen Dialog befand, den man nicht abbrechen konnte. Eine direkte Konsequenz aus der leider immer mehr um sich greifenden Unsitte Dialog Fenster nur noch mit einen Schließen Button zu versehen. Der zweite Versuch ging dann ohne Probleme. Der Installer, wie auch der Boot-Vorgang, Login-Screen und das Gnome-Theme sind sehr schick gestaltet, das muss man den Fedora-Leuten lassen.

Da ich kein Gnome-Fan bin habe ich mir sofort KDE installiert und dann ging das Drama ein wenig los. Fedora, wie auch Suse, liefern keine MP3-Codecs mit. Das ist natürlich schlecht, wenn man bei der Konfiguration etwas Musik hören will. Dafür soll es in Fedora 8 einen sogenannten Codec Buddy geben, der aber leider nirgends im KDE-Menü zu finden war, noch gab es ein Programm mit solchen Namen. Man findet zwar überall schicke Screenshots, mehr aber auch nicht. Nach einer geschlagenen Viertelstunde stiess ich dann auf codeina, dem Codec Buddy.

Der Codec Buddy ist so ziemlich das am schlimmsten hingerotzte Programm das ich je gesehen hab. Fällt jemand an dem Screenshot was auf?

Genau, am Codec ist vorne ein Häkchen, hinten steht not installed, man kann es aber nicht installieren, weil Get selected ausgegraut ist. Ein veritabler Intelligenztest würde ich sagen der sich auflöst, wenn man einen anderen Codec zustätzlich aus- und wieder abwählt. Der wirkliche Hammer aber ist, das Amarok mit dem Codec nichts anfangen kann. Das ganze also vollkommen Sinnlos ist.

Fedora liefert auch keine proprietären Treiber für Nvidia oder ATI aus, so das man spätestens hier sich nach externen Software-Repositories umschaut. Erste Wahl dürfte hier Livna sein. Dort gibt es MP3-Codecs für Amarok und Treiber für Nvidia.

Von diesen Punkt an, das muss ich als alter Redhat-Hasser zugeben, hat es angefangen Spass zu machen. Die Nvidia-Treiber und Compiz waren mit ein paar Befehlen und Klicks eingerichtet. Meine DVB-T Karte ging Out-of-the-Box und sogar meinen Lexmark z517 Drucker habe ich mit den Treibern eines z617 von der Lexmark-Seite und dem compat-libstdc++-33 Paket zum laufen bekommen.

Natürlich gibt es ein paar kleinere Unschönheiten. Die Desktop-Fonts sehen noch scheisse aus und ich DVB-T nicht mit Klear gucken. Das ist zwar dabei, aber es liefert kein Bild und Ton. Dagegen funktioniert Kaffeine ohne Probleme inkl. Senderscan.

Fazit: Wenn ich einen Vergleich zu Ubuntu ziehen muss, dann hat Ubuntu in Punkto Anfängerfreundlichkeit kilometerweit die Nase vorn. Man installiert es und man hat ersteinmal ein komplettes System vor sich. Bei Fedora hingegen muss noch recht viel getan werden, um einen Stand zu erreichen wo man von einen normalen Betriebssystem reden kann. Für fortgeschrittene Nutzer die halbswegs wissen was sie wollen und wo sie es finden ist Fedora ein gute Wahl. Ich werde jedenfalls ein Image der Installation machen, bevor ich mir die anderen Distributionen anschaue, denn eigentlich bin ich im Moment sehr zufrieden mit Fedora.

Posted: November 10th, 2007 under Linux, Redhat/CentOS.
Comments: 13

Ich hab heute die Preise für einen Redhat Enterprise Server mit Cluster-Lizenz gesehen und bin nur knapp dem Herzkasper entkommen *hust*

Posted: September 24th, 2007 under Linux, Redhat/CentOS, Software.
Comments: 6

Freunde werden wir wohl nicht mehr, also ich und CentOS resp. Redhat. Mir hätte heute auch kein Redhat-Mitarbeiter über den Weg laufen sollen, es hätte Böse für ihn geendet. Warum ich mich so Aufrege? Es gibt anscheinend mehrere Wege unter Redhat Netzwerkkarten zu konfigurieren und die eine Möglichkeit weiss nichts von der anderen. Da lobe ich mir doch die einfache /etc/network/interfaces von Debian und selbst der krude Solaris-Krams macht eine um längen bessere Figur!

Posted: September 11th, 2007 under Debian, Linux, Netzwerk, Redhat/CentOS, Solaris.
Comments: 4

• Wolfsquest - Pinkelspiele für Jugendliche (WTF?!)
• Top 5 Reasons to Move from RHEL to SLE - Ein dicker Grund der dagegen spricht: es gibt kein CentOS-Äquivalent von SLES
• Solaris 10-AD Integration - Hmm *kinnschab*

Posted: August 23rd, 2007 under Fundsachen, Linux, Redhat/CentOS, Solaris, Suse.
Comments: 2