LUGAdventskalenderLPI

Adventskalender mit Test-Fragen zur LPI-Prüfung#

Wer sich auf eine Zertifizierung durch das Linux Professional Institute vorbereiten möchte,
freut sich eventuell auf die im LPI-Simulator (Spoiler-Warnung) angebotene Trainingsmöglichkeit.
Anmeldungen zu einer der LPI-Prüfungen LPIC-1, LPIC-2 oder LPIC-3 sind z.B. über LPI möglich.
LPI-Fragen werden auch im Forum von Karl Schock erörtert,
wo es auch eine LPI Live-CD namens elpicx zum Üben gibt.

Hier wird nun für jeden Tag des Advents 2007 je eine Frage präsentiert.

Einen Contentframework-Adventskalender habe ich für Perl-Catalyst entdeckt: http://catalystframework.org/calendar/2007
... und der Perl-Adventskalender liegt wie in den Vorjahren unter http://perladvent.org/.

WICHTIG: DIES IST KEIN BRAINDUMP!
Die Fragen in dieser Datei sind frei erfunden und haben nichts
mit der echten Prüfung zu tun. Bitte lernen Sie diese Fragen
nicht auswendig, um damit die Prüfung zu bestehen. Sie werden
durchfallen und sind dann selber daran schuld.

Fragen für Prüfung 101 von Anselm Lingnau, Thomas Erker#

Simulierte Prüfungsfragen Copyright © 2004-5 Linup Front GmbH (http://lpi-buch.linupfront.de/lpisim/)

Adventskalendertürchen #

(Lösungen gibt es am Folgetag)
Lösung:

Das Kommando »ldconfig« liest »/etc/ld.so.conf« und schreibt »/etc/ld.so.cache«. Man muss es immer aufrufen, wenn neue Shared Libraries dazukommen -- ein Neustart des Systems ist aber zum Glück nicht erforderlich (Antwort <<4>> ist falsch).

Wenn ein neues Verzeichnis mit Bibliotheken dazukommt, dann muss der Name dieses Verzeichnisses in »/etc/ld.so.conf« eingetragen werden, damit »ldconfig« das Verzeichnis mit betrachtet. Die korrekte Antwort ist also <<1>> (nicht <<2>> -- Vorsicht mit den Dateinamen!). Nur »ldconfig« aufrufen wie in Antwort <<3>> reicht in diesem Fall leider nicht aus.

Ich wünsche frohe Festtage. Danke für Eure Anregungen und Aufmerksamkeit. --MarkusMonderkamp

Zu Weihnachten hier nun eine Anleitung zur Herstellung von Schoko-Weihnachtsmännern und Frauen (L-GPL):

http://blog.chip.de/xbox-watch-blog/wp-content/uploads/2006/12/kameo-xmas.jpg

Oh, Verzeihung:

http://www.kraftfoods.de/kraft/images/dede1/pictures/3_2_2infografik_weihnachtsmann72.jpg


Lösung:
Es spricht nichts dagegen, ein Dateisystem auf einem Verzeichnis zu mounten, in dem bereits Dateien stehen. Diese Dateien werden unsichtbar, solange das Dateisystem gemountet ist, und kommen später wieder zum Vorschein. Antwort <<1>> ist also richtig.

Eine relativ neue Entwicklung in Linux ist das »unionfs«, das es erlaubt, ein Dateisystem auf einem Verzeichnis zu mounten, so dass die Dateien, die in diesem Verzeichnis stehen, trotzdem sichtbar bleiben. Sie erscheinen zusätzlich zu denen im gemounteten Dateisystem (gleichnamige Dateien im gemounteten Dateisystem haben Vorrang), und Schreibvorgänge werden im gemounteten Dateisystem ausgeführt. Diese Funktion wird zum Beispiel von Live-CDs wie Knoppix verwendet, die eine (schreibbare) RAM-Disk über eine (nur lesbare) CD oder DVD mounten, damit Benutzer Dateien auf der CD »ändern« können. Dies entspräche Antwort <<3>>, ist aber nicht das Standardverhalten.

Lösung:

Die Datei /proc/usb/type gibt es leider nicht, genausowenig wie ein usbinfo-Programm -- die Antworten <<2&4>> sind also falsch. Das Programm usbview gibt es, aber es setzt voraus, dass USB schon funktioniert -- es zeigt eine baumartige Ansicht der Geräte am USB. Auch Antwort <<3>> kann also nicht richtig sein.

Korrekt ist Antwort <<1>>; mit lspci bekommen Sie den Hardwaretyp Ihrer USB-Controller angezeigt, und das läßt Schlüsse auf den zu verwendenden Treiber zu. Sie können natürlich auch beide Treiber auf Verdacht laden; nur einer von ihnen wird funktionieren, und der andere richtet zumindest keinen Schaden an.

Lösung:

USB 1.x standardisiert zwei Geschwindigkeitsstufen, namentlich die »niedrige« Geschwindigkeit von 1,5 MBit/s (allemal genug für Mäuse, Joysticks, Modems, Grafiktabletts und ähnliche Geräte) und die »volle« Geschwindigkeit von 12 MBit/s (die für altertümliches Ethernet, Scanner, Soundkarten und sowas reichen sollte).

Da das aber nicht genug ist für Speichermedien wie USB-Platten und optische Laufwerke (CD- und DVD-Laufwerke und -brenner) oder auch Digitalkameras, gibt es seit USB 2.0 eine »hohe« Geschwindigkeit von 480 MBit/s (theoretisch). Antwort <<3>> ist also richtig.

Lösung:
Traditionell waren in Unix keine Übertragungsraten von mehr als 38400 Bit/s vorgesehen (es gab sowieso kaum schnellere Modems), so dass, als Linux neu war, in vielen Unix-Programmen 38400 Bit/s als höchste Übertragungsrate eingestellt werden konnte. Der Linux-Trick bestand zunächst darin, diese Übertragungsrate über »setserial«-Optionen mit höheren tatsächlichen Übertragungsraten gleichzusetzen. Die offiziell richtige Antwort ist darum <<2>>.

Antwort <<1>> könnte auch funktionieren, allerdings hindert Sie niemand daran, hier beliebige Phantasiewerte anzugeben; Antwort <<2>> ist darum sicherer. Antwort <<3>> alleine reicht nicht, und Antwort <<4>> ist sicher konzeptuell interessant, aber nicht so implementiert (mithin falsch).

Lösung:
Der vielversprechendeste Ansatz ist hier Antwort <<1>> -- http://www.linmodems.org ist wohl die aufschlussreichste Informationsquelle zum Thema »Win-Modems unter Linux«.

Treiber für Win-Modems finden sich nicht notwendigerweise direkt im Kernel (deswegen ist Antwort <<2>> nicht unbedingt zielführend), und die Datei »Documentation/winmodems.txt« (Antwort <<3>>) muss ebenfalls noch geschrieben werden. Antwort <<4>> ist der übliche Defätismus und auch falsch.

Lösung:
Die Datei »/proc/pci« ist seit Linux 2.6 verpönt, Antwort <<1>> ist also richtig. Die anderen drei Antworten sind Nebelwerferei. Lösung:
Wie der Name andeutet, beschäftigt »lspci« sich mit dem PCI-Bus. Antwort <<3>> ist also falsch. »/proc/pci« ist eine Datei, die früher (etwa zu den Zeiten von Linux 2.4) Informationen enthalten hat, die der Ausgabe von »lspci« durchaus ähnlich waren; in neueren Kernelversionen ist die Datei jedoch nicht mehr vorhanden, und in jedem Fall kann »lspci« ein paar Sachen mehr; Antwort <<2>> ist also auch nicht richtig.

»lspci« kann viele Geräte identifizieren, und die unter anderem von »lspci« gelieferten Gerätecodes sind die mögliche Grundlage einer Zuordnung von Treibern zu PCI-Geräten, aber »lspci« selbst stellt diese Zuordnung nicht her; das ist Werkzeugen vorbehalten, die typischerweise distributionsspezifisch sind (etwa »kudzu« von Red Hat oder die entsprechenden Komponenten des YaST-Werkzeugs bei den SUSE-Distributionen). Also scheidet auch Antwort <<4>> aus.

Die einzige übrigbleibende (und damit richtige) Antwort ist <<1>>.

Lösung:
PCI ist ein 32-Bit-Bus (also ist <<2>> falsch), auf dem mehrere Geräte sich einen Interrupt teilen können (schauen Sie auf Ihrem Rechner mal nach IRQ 11 -- also ist <<4>> auch falsch). Die anderen beiden Antworten sind richtig. Lösung:
CompactFlash-Karten (Antwort <<1>>), die zum Beispiel mit Digitalkameras verwendet werden, benehmen sich wie ATA-Platten (also vulgo »IDE«-Platten). Um sie kümmert sich das IDE-Subsystem. Die anderen Medientypen werden alle wie SCSI-Geräte angesprochen; ein USB-Stick in einem ansonsten IDE-basierten System bekommt also zum Beispiel den Gerätenamen »/dev/sda« zugesprochen. Lösung:
Richtig ist Antwort <<1>> (sndconfig). »alsaconf« (Antwort <<3>>) ist, wie der Namen schon sagt, für das ALSA-Soundsystem gedacht, und die Programme »soundconfig« (Antwort <<2>>) und »soundconf« (Antwort <<4>>) gibt es gar nicht. Lösung:
Dies ist eine ziemlich gemeine Frage; um sie korrekt zu lösen, müssen Sie wissen, dass das »stty«-Kommando auf seine Standardeingabe (!) wirkt. Sie könnten prinzipiell direkt »stty speed 115200 </dev/ttyS0« sagen, aber der Umweg über »spd_vhi« und die Geschwindigkeit 38400 Bit/s ist ebenfalls gangbar. Richtig ist also Antwort <<1>>.

Ein Kommando »setmodem« (Antwort <<3>>) gibt es leider genauso wenig wie eine Datei »/proc/modem/speed« (Antwort <<4>>). Hierbei handelt es sich um pure Nebelwerferei.

Lösung:
In ISA-basierten Systemen kommt es leicht vor, dass Peripheriegeräte um Systemressourcen wie Interrupts oder DMA-Kanäle konkurrieren. ISA-basierte Soundkarten werden von Linux natürlich unterstützt, jedenfalls die meisten (Antwort <<4>> ist darum falsch). Von ISA-PnP war nicht die Rede, und aktuelle Linux-Kernels sollten auch ohne BIOS in etwa das Richtige tun, darum zählt Antwort <<3>> nicht zu den wahrscheinlichen Gründen. ISA-Soundkarten verwenden gerne einen DMA-Kanal, parallele Schnittstellen aber in der Regel nicht (Antwort <<2>>), so dass Antwort <<1>> als plausibelste Lösung des Problems übrig bleibt. Lösung:
Antwort <<1>> ist der vielversprechendste Ansatz; ein Kommando »modeminfo« (Antwort <<2>>) gibt es leider ebensowenig wie eine Datei »/proc/modem/interrupt« (Antwort <<3>>) oder eine »-i«-Option für »setserial« (Antwort <<4>>).

Voraussetzung ist natürlich, dass Ihr Modem wirklich unterstützt wird, denn »/proc/interrupts« liefert nur Informationen über Geräte mit einem initialisierten Treiber. »setserial /dev/modem« (ohne »-i«) wäre übrigens auch eine Möglichkeit.

Lösung:
Win-Modems nennt man billige Modems, die keinen eigenen Signalprozessor haben (Antwort <<1>>). Bei Win-Modems steckt die ganze »Intelligenz« im Treiber, sie sind darum hochgradig vom verwendeten Betriebssystem abhängig.

Für viele Win-Modems gibt es heute auch Linux-Unterstützung, siehe [http://www.linmodems.org]]. Leider wird diese in der Regel in Gestalt proprietärer, binärer Treiber vom Hersteller zur Verfügung gestellt, so dass es schwierig sein kann, z. B. Kernel-Updates zeitnah durchzuführen.

Sie sollten den Einsatz von Win-Modems vermeiden, wenn Sie es sich aussuchen können. Win-Modems werden gerne in Notebooks verbaut, wo es dann keine Wahlmöglichkeit gibt; im schlimmsten Fall können Sie aber meist ein Modem auf PC-Kartenbasis (oder USB) verwenden.

Lösung:
Die Zuordnung von Interrupts zu Geräten finden Sie in der Datei »/proc/interrupts«. Beachten Sie, dass nur diejenigen Interrupts in der Datei auftauchen, die wirklich vom Kernel benutzt werden - Interrupts von Geräten, für die kein Treiber aktiv ist, tauchen in der Liste nicht auf.

Lösung:
Die Zuordnung von I/O-Ports zu Geräten finden Sie in der Datei »/proc/ioports«. Beachten Sie, dass nur diejenigen I/O-Ports in der Datei auftauchen, die wirklich vom Kernel benutzt werden - Ports von Geräten, für die kein Treiber aktiv ist, tauchen in der Liste nicht auf.

Lösung:
Wurzel des Übels ist die antiquierte Adressierung von Blöcken auf der Platte über Zylinder-, Kopf- und Sektornummer (CHS). Alte BIOS-Implementierungen können nur solche CHS-Angaben verwenden, die die ersten 1024 Zylinder der Platte adressieren (typischerweise etwa 8 GB). Alles, was dahinter liegt, ist für das BIOS unsichtbar.

Für Linux ist das eigentlich egal, da es (wie alle heutigen Betriebssysteme) das BIOS links liegen läßt. Ein Problem gibt es aber möglicherweise beim Booten, wenn Sie eine (einzige?) große Linux-Partition haben und der Systemkern (oder Teile davon) jenseits der 1024-Zylinder-Grenze liegt. In diesem Fall kann der Bootlader, der sich ja des BIOS bedient, nicht den kompletten Kernel laden - der Rechner bootet nicht.

Die probate Abhilfe besteht darin, am Anfang der Platte eine kleine Partition für das Verzeichnis »/boot« anzulegen (20 MB sind typischerweise dicke genug). Darin wird der Kernel untergebracht, so dass der Bootlader ihn garantiert komplett finden kann. Später, wenn der Kernel läuft, ist die 1024-Zylinder-Grenze egal.

Richtig ist also <<1>>, die anderen drei Antworten sind Nebelwerferei.

Lösung:
Die CMOS-Uhr wird von Linux nur beim Systemstart angeschaut, um die Kernel-Uhr zu stellen.

Sie sollten die CMOS-Uhr in Zonenzeit laufen lassen, wenn Sie auf Ihrem Rechner außer Linux noch ein Windows-Betriebssystem haben; diese verwenden die CMOS-Uhr direkt. Wenn Sie nur Linux auf dem Rechner haben, sind Sie besser damit beraten, UTC zu verwenden - so vermeiden Sie Verwirrung mit der Sommerzeit. In jedem Fall ist es aber egal (Antwort <<1>>), solange Sie Ihrem Linux sagen, wie es beim Stellen der Kernel-Uhr die Zeit interpretieren soll, die es in der CMOS-Uhr findet.

Am Domänennamen (Antwort <<4>>) kann Linux sich leider nicht orientieren, dafür ist der nicht eindeutig genug: Mit ».de« könnte es gerade noch angehen, aber was ist mit ».us«, ».ru«, ».com« oder ».org«?

Lösung:
Die Paketbandidee aus Antwort <<2>> ist nett, dürfte aber einen entschlossenen Cracker kaum abhalten. Antwort <<3>> fällt aus, weil CD-Laufwerke im BIOS in der Regel nicht einmal angemeldet werden. Was die Bootreihenfolge angeht: »A:« ist das Floppylaufwerk und »C:« steht für die IDE-Platte. Die richtige Antwort ist also <<1>>. Lösung:
»ECP« ist die Abkürzung für »Extended Capabilities Parallel Port« (mithin ist Antwort <<1>> richtig). Im Gegensatz zu anderen Implementierungen der parallelen Schnittstelle erlaubt ECP Datentransfers per DMA und benutzt einen FIFO-Puffer zur Beschleunigung von Sende- und Empfangsvorgängen. Außerdem gibt es Lauflängenkomprimierung (run length encoding, RLE) und eine Kanaladressierung, mit der in Multifunktionsgeräten (Fax/Drucker/Scanner/...) die einzelnen Funktionen separat angesprochen werden können. Nähere Informationen finden Sie zum Beispiel [http://www.beyondlogic.org/ecp/ecp.htm|hier]]. Lösung:
Können Sie Ihr Handy auf »Linux-Datenübertragung« einstellen? Wir unsere auch nicht ... Und Infrarotschnittstellen nach IrDA unterstützt Linux schon lange, lange Zeit. Was die Datenformate angeht: Da ist Kompatibilität sicher nützlich, aber erst, wenn die Verbindung funktioniert - und Sie sollten auf jeden Fall dafür sorgen, dass im BIOS eine serielle Schnittstelle für den Infrarot-Port ausgewählt ist! Ansonsten tut sich nämlich gar nichts ... Antwort <<1>> ist richtig. Lösung:
Gewisse BIOS-Versionen können Platten mit einer Kapazität von mehr als 32 GB nicht erkennen. Die naheliegendste Abhilfe ist natürlich ein BIOS-Upgrade; wenn das aus Altersgründen nicht mehr möglich ist, dann können Sie bei den meisten Platten über einen Jumper dafür sorgen, dass die Platte dem BIOS vorlügt, sie hätte gerade 32 GB (oder so) Kapazität; Linux ist das dann später egal, da es das BIOS nicht verwendet. Eine andere Maßnahme ist unsere Antwort <<1>>; melden Sie einfach die große Platte nicht im BIOS an (Sie brauchen dann natürlich eine »kleine« Platte zum Booten). Mit den Antworten <<3&4>> ist es leider nicht getan - aber zum Glück müssen Sie auch nicht gleich zu Antwort <<2>> greifen! Lösung:
»LBA« ist die Abkürzung für »Linear Block Access«, ein Verfahren, bei dem das BIOS Blöcke auf einer Festplatte nicht (wie traditionell) über ein Tripel »Zylindernummer, Kopfnummer, Sektornummer« -- vulgo »CHS« --, sondern über eine einfache fortlaufende Blocknummer adressiert. Da die CHS-Adressierung bei heutigen Festplatten sowieso eine Scharade ist (moderne Platten haben auf den Zylindern am äußeren Rand viel mehr Sektoren als auf denen am inneren, warum Platz verschenken?), spricht nichts dagegen, LBA zu benutzen, wenn Festplatte und BIOS das beherrschen. Denken Sie daran, gegebenenfalls auch Ihren Bootlader entsprechend zu konfigurieren!

Die anderen drei Antworten sind frei erfunden.