[linux-l] LPI-Zertifikat

[Michael Gisbers]

On Tuesday 04 January 2011 13:26:59 Olaf Radicke wrote:
> Hallo Michael,
> 
> war unterwegs von Essen nach München. Deshalb erst jetzt eine Antwort.

Hallo Olaf, Hallo Liste,

kein Problem ;-)

Hat auch ein wenig länger gebraucht auf die Liste zu kommen.

> Am Sonntag, den 02.01.2011, 23:07 +0100 schrieb Michael Gisbers:
> > On Sunday 02 January 2011 20:44:45 Olaf Radicke wrote:
> [...]
> 
> > > ich lerne gerade für die LPIC-101&102 (v 3.0). Mir fiel beim lesen und
> > > lernen auf, das völlig veraltetes Wissen abgefragt werden. Nur mal ein
> > > paar Beispiele:
> > > 
> > > 1.) Der LILO-Bootloader wird rauf und runter gebetet. Von den
> > > Major-Distris ist die letzte ca. 2001 zu GRUB gewechselt.
> > 
> > Es ist richtig, dass LILO noch immer geprüft wird. Dies ist aber auch
> > richtig, da LILO noch immer im Einsatz ist und Administratoren damit
> > noch immer in Kontakt kommen und damit arbeiten können müssen. In meinem
> > Alltag habe ich noch mit genug LILO - Systemen zu tun, die ich nicht
> > updaten kann und daher damit weiterarbeiten muss.
>
> Die müssen über 10 Jahre alt sein, oder Exoten-Distries. Ich arbeite in
> einer 100% Linux-Firma. Hier laufen auch die Desktops unter Linux. LILO
> spielt in meinen Umfeld keine Geige. Im Gegenteil. Hier wird absehbar
> irgendwann Grub2 aufschlagen und dann ist wieder alles völlig anders...

Jein, es sind alte Systeme dabei, aber auch teilweise neuere, die Probleme mit 
dem Grub haben, wie in einem anderen Post zu diesem Thread zu lesen war ist 
das bei GDT - Controllern, aber auch CCISS teilweise der Fall.

Auch ist LILO weiterhin in Ubuntu eine option für den Bootloader, auch im 
aktuellen Maverick. Es ist also nicht aus den Distributionen verschwunden.

> > > 2.) Die Konfiguration des Init-Prozess ist ebenfalls veraltet. Wer viel
> > > mir Ubuntu arbeitet wird mir dem abgefragten Wissen nichts anfangen
> > > können.
> > 
> > Daher wird auch seit dem Wechsel von der Version 2 auf 3 der Objectives
> > weniger an tiefem SystemV - Init - Wissen abgefragt. Auch hier kommt es
> > wieder auf das Verhältnis der eingesetzten Systeme an. Ubuntu ist im
> > Serverumfeld bei weitem nicht der Marktführer.
> 
> Wie schon gesagt: Hier wird ausschlißlich mit Linux gearbeitet und auf
> den Desktops der Non-Techis ist Ubuntu defakto Standard. Nur die
> Techniker bei uns arbeiten z.T. mit Fedora auf den Desktops.

Ja, das mag bei Dir zutreffen. Allerdings ist es bei anderen Unternehmen wieder 
komplett anders und das ist gut so. Nur so entwickelt sich alles weiter.

Aber auch hier muss ich leider mitteilen, dass Ubuntu auch ordinär mit SystemV 
- Initscripten installiert werden kann wie es bei meinen OpenVZ - Ubuntu 
10.10. Images der Fall ist.

Im Linux-Umfeld ist halt vieles eine Option. Die Distributionen entscheiden 
sich welche der Optionen sie als 'Standard' setzen, trotzdem unterstützen sie 
zumeist auch die anderen Möglichkeiten.

> > Das von mir eingesetzte Gentoo leider auch nicht
> > ;-(
> 
> Wir haben genau _EINEN_ Kunden mit Gentoo. Und das ist "self supported".
> Der Kunde bekommt weder von SAP noch von Oracle Support. Wenn die
> Maschine steht, ist das sein Problem. Wir gucken dann (gegen Honorar)
> gerne mal drüber, aber garantieren tun wir auch für nichts.

Ja, das ist eines der normalen Probleme bei 3rd Party Software.

> > > 3.) Die Konfiguration des X-Server auf die sich LPIC bezieht gibt es
> > > weder unter Debian, RedHat noch SuSE. Die genannten Dateien gibt es
> > > schlicht weg nicht mehr.
> > 
> > Wenn ich mir die Dateien aus den Objectives ansehe, dann kommt mir das
> > von meinem Notebook, an dem ich gerade arbeite, sehr bekannt vor. Es
> > gibt eine /etc/X11/xorg.conf. (Man kann ohne arbeiten, aber muss es
> > nicht, vor allem beim Einsatz von NVIDIA-Grafikkarten.) Auch die Befehle
> > xhost, xwininfo, xdpyinfo und X gibt es weiterhin, genau wie die
> > Umgebungsvariable DISPLAY.
> 
> Gut, ich habe das Buch hier verwendet für das Lernen:
> http://www.galileocomputing.de/katalog/buecher/inhaltsverzeichnis/gp/titelI
> D-2181?GalileoSession=80758889A411lRlPWHQ
> 
> Vielleicht taucht das Buch nicht. Ich hatte mir die Konfiguration von
> Umbuntu, Fedora, CentOS und RedHat angesehen und konnte das beschriebene
> nicht nachvollziehen.

Ja, das Problem ist, dass die Bücher sich meist auf eine Distribution und eine 
Version festlegen müssen oder alternativ die rudimentäre Vorgehensweise ohne 
Distributionsbezug darstellen müssen.

In diesem Fall wurde die Variante ohne Distributionsbezug genutzt wodurch bei 
der Konfiguration Dinge wie /etc/X11/xorg.conf.d oder Konfiguration über HAL 
nicht angesprochen werden und dann nicht in der benutzten Distribution 
auffindbar sind.

> Praktisch ist es so, das auf den Server X keine Geige spielt. Auf den
> Desktops wird die Hardware nach dem OS ausgesucht. Was X nicht
> automatisch richtig erkennt und konfiguriert bekommen wir in aller Regel
> auch nicht gebogen. Aktuelles Beispiel: Ein Dell Notebook, ein Externer
> Monitor, drei gestandene Linux-Admin und eine Woche Arbeit. Ergebnis: no
> way! Und ab in die Tonne....

Ja, auch diese Fälle gibt es, leider.

> > > 4.) LPIC geht davon aus, das man noch auf Hardware mit BIOS stößt, die
> > > nur begrenzte Größen von Partitionen zu lassen. Das betrifft Hartware
> > > vor 1998! Das waren Zeiten, wo man stolz war 64mb RAM zu haben. Weder
> > > privat, noch beruflich kann ich mich erinnern, in den letzten Jahren
> > > solch alte Hardware vor mir gehabt zu haben.
> > 
> > Mhhh... Da musst Du mir mal die genauen Objectives zeigen.
> 
> Entnahm ich aus dem oben genannten Buch...

Habs nachgelesen und dort steht, dass es Nutzung von LILO mit mehr als 1024 
Zylindern auf alter Hardware Probleme geben kann.

Und das ist noch immer korrekt. 

Zusätzlich könnte man ergänzen, dass eine /boot immer dann sinnvoll ist, wenn 
man RAID-Controller einsetzt, die einen Zugriff auf die Daten per BIOS nur bis 
zu einem bestimmten Datenbereich zulassen. Denn falls die Boot-Dateien des 
Bootloaders, egal ob Grub1/2 oder LILO nicht mehr über das BIOS ansprechbar 
sind, kann man nicht booten.

> > > 5.) In der LPIC wird man abgefragt nach den Eigenarten des 2.2 Kernel
> > > (Etwa bezüglich der USB-Unterstützung.) Der Kernel wurde 2004
> > > abgekündigt!! Ich vermute mal, das man 2.2er Kernel in Betrieb nur noch
> > > als Steuerungseinheit in irgend welchen Satelliten um die Erde kreisen
> > > sehen wird. Wenn ich nicht irre, war der 2.2er in der RedHat 7.0 noch
> > > drinnen. Die Version hatte ihre Release im Jahre 2000!
> > 
> > Der Kernel 2.2 ist nicht mehr Bestandteil der LPI Prüfungen Version 3.0.
> > Bitte auch hier die entsprechenden Objectives heraussuchen in denen Du
> > das Problem vermutest.
> 
> Entnahm ich aus dem oben genannten Buch...

Mhhh... Stimmt, dort gibt es noch immer Fragen zum 2.2er Kernel bei den 
Testfragen.

In der LPIC-1 (LPI-101 und LPI-102) gibt es nur ein Objective bei dem es um 
den Kernel geht. Dabei handelt es sich nur um den Bootprozess bei dem die 
Kernel - Version unerheblich ist.

Hier muss der Verfasser des Buches für die nächste Version nachbessern.

Ohne das Buch schlecht machen zu wollen muss ich allerdings auch anmerken, 
dass das LPI dieses Buch nicht geprüft hat und damit nicht sichergestellt ist, 
dass die Inhalte den Objectives entsprechen. 

Die Verlage haben die Möglichkeit Ihre Bücher vom LPI zertifizieren zu lassen. 
Im Zuge dieser Zertifizierung wird das Buch geprüft ob es die Objectives 
abdeckt und sicherstellt, dass für den Leser alle Themen in ausreichender Form 
abgedeckt werden.

Auf den Seiten des LPI Central Europe findet man auch eine Liste der 
zertifizierten Lernmaterialien (http://www.lpice.eu/LPI-Literatur-und-
Lern.65.0.html?&L=4).

Natürlich kann das Studium eines Buches nicht die Erfahrung, die man bei der 
Arbeit mit Linux sammelt, ersetzen. Aber es kann beim zielgerichteten Lernen 
helfen.

> > > In Anbetracht dessen, stell ich mir die Frage, ob RedHat-Zertifikate
> > > nicht sinnvoller sind. Mag sein das sie nicht so universell ist, aber
> > > dafür bezieht sich die Prüfung auf eine Distribution bzw. dessen
> > > Technologie, die auf tatsächlich in der Praxis Anwendung findet.
> > 
> > Eine gute und oft gestellte Frage...
> > 
> > Die LPI - Prüfung hat natürlich Ihre Schwächen, da sie nicht an einer
> > bestimmten Distribution nachzuvollziehen ist und auch nicht an einer
> > bestimmten Versionsnummer fest zu machen ist.
> > 
> > Dafür hat sie kein 'Ablaufdatum' und wendet sich genau an die
> > Administratoren, die sich nicht von einer Distribution abhängig machen
> > wollen. Da liegen die Schwächen der anderen Prüfungen.
> 
> Das kann ich schon nachvollziehen. Bei uns im Betrieb gilt der
> Grundsatz: "Keine Standardisierung ohne Referenz-Implementierung". Ich
> denke es wehre besser mindestens eine, oder meinetwegen auch drei
> Major-Distris als Referenz zu benutzen um ein Orientierungspunkt zu
> haben.

Dies würde leider dem Grundsatz einer 'distributionsunabhängigen 
Zertifizierung', die das LPI Programm darstellt, komplett entgegen stehen.

Es wird versucht einen Zwischenweg zwischen den Vorgehensweisen der Entwickler 
und der Distributoren zu finden um distributionsunabhängige Fragen für die 
Zertifizierung entwickeln zu können. 

Das bedeutet teilweise auch, dass einige Bereiche, wenn sie zu unterschiedlich 
gelöst sind, nicht in den Objectives vorkommen. Aber man kann ja nicht alles 
ausblenden.

Ich habe schon so oft das Wort Objectives genutzt und noch nicht einmal die 
URL dazu geschrieben: http://www.lpice.eu/LPIC-Programm.52.0.html?&L=4

Du solltest Dir die Objectives (deutsch: Lernziele) mal genauer ansehen und 
wirst dann noch einige Unterschiede zu den Materialien im Buch feststellen.

Der Autor wird sich bestimmt über entsprechende Anmerkungen für seine nächste 
Auflage freuen.

Parallel möchte ich aber noch gerne auf die englischsprachige Mailingliste 
lpi-discuss at lpi.org aufmerksam machen, auf der auch gerade über das Thema 
'Warum gibt es in der Prüfung nichts zu upstart' diskutiert wird. 
(http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-discuss)

Gruß
-- 
Linux-Schmie.de

Michael Gisbers

Neukölner Str. 94
46147 Oberhausen
Telefon: +49 208 628 950
Telefax: +49 208 628 951
Mobil: +49 173 510 68 22
http://linux-schmie.de
St.-Nr. 123/5039/131