Hier greift wieder die »Sandkastenproblematik«. Wird LiLo in den MBR geschrieben kann man durchaus auch andere Betriebssysteme damit starten lassen – wenn man den LiLo dementsprechend konfiguriert. Sollte ein »nettes« Betriebssystem dann auf die grandiose Idee kommen, den MBR »zu reparieren«, ist der LiLo gelöscht bzw. überschrieben und man kommt nicht mehr an sein Linux heran. Außer man bootet von einer evtl. vorhandenen Diskette oder von einer bootfähigen CD und repariert den LiLo im MBR wieder »zurück«.
Ich lasse LiLo immer in die Partition des Wurzelverzeichnis installieren – bzw. lasse Linux dies tun. Die zu bootende Partition wähle ich dann mit dem XFdisk-Bootmanager aus, das beschreibe ich im nächsten Schritt.
Als Basis für diese Erklärung gehe ich von einem installierten Windows 2000 auf der ersten Festplatte aus, auf der zweiten Platte ist ein Linux installiert.
Beide Betriebssysteme befinden sich jeweils in einer primären Partition, die Partitionen sind also von sich aus bootfähig.
Wie der installierte Bootmanager sich beim Starten vom System meldet, ist bei meiner kleinen Beschreibung von XFdisk nachzulesen xfdisk.html. Die Installation des Bootmanagers geht ansich sehr einfach von der Hand, die intuitive Benutzerführung sollte bei XFdisk eigentlich auch kein Problem darstellen. Im .ZIP-Archiv von XFdisk ist eine sehr ausführliche Anleitung zur Installation und Konfiguration des Bootmanagers vorhanden, bei dem als deutsche Version des .ZIP-Archivs gekennzeichtenden Download ist diese Anleitung auf Deutsch geschrieben.
Einfach formuliert wird folgendermaßen vorgegangen: Der Bootmanager wird installiert (in den MBR) und konfiguriert. Die beiden zu startenden Partitionen werden als »Neuer Bootmenue Eintrag« eingefügt und bei dem Beenden von XFdisk muß die Änderung an den Bootmanager-Einstellungen auf die Platte übertragen werden.
Jetzt wird es klar, warum man den LiLo nicht in den MBR installieren sollte: Er würde knallhart vom Bootmanager von XFdisk überschrieben werden, ein Booten von dem bereits installierten Linux wäre somit nicht mehr möglich.
Man könnte auch LiLo als Bootmanager einrichten und von ihm aus das Windows oder sonstige installierte Betriebssysteme installieren. Darauf will ich allerdings nicht weiter eingehen. Zum sind Anfänger – meiner bescheidenen Meinung nach – sowieso erstmal mit XFdisk besser bedient, und die Profis wissen sowieso selbst, wie sie LiLo einrichten müssen.
Außerdem könnte man mit dem LinuxLoader alleine schon wieder ein mittelgroßes Tutorial füllen – so wie es auch andere gemacht haben. Mit google.de – oder ein anderen Suchmaschine – sollten sich binnen weniger Minuten solche Tutorials finden lassen, inklusive einer deutschsprachigen Varianten davon.
Als Abschluß des HowTos noch die in vier Teile aufgesplittete Anleitung, wie man vorhandene Windowspartitionen in ein Linux einbindet. Die Aufteilung wurde nach der Art des »Einhängens« der Partitionen gemacht. Eigentlich sollten alle Varianten des Mountens von sogenannten »vfat-Datenträgern« abgedeckt sein.
mount -t vfat /dev/hda1 /mnt/win_c
Mit diesem Aufruf wird die erste primäre Partition der ersten IDE-Festplatte im System am Mountpoint /mnt/win_c »eingehängt«. Der Mountpoint muß natürlich zuvor als Verzeichnis angelegt worden sein.
In der Datei /etc/fstab werden all jene Eintragungen gemacht, die das mounten von Laufwerken beim Systemstart bzw. die Konfiguration der zu mountenden Laufwerke beinhaltet. Um beim Beispiel der ersten primären Partition zu bleiben:
/dev/hda1 /mnt/win_c vfat
So würde der Eintrag in der /etc/fstab lauten, diese würde nun automatisch beim Systemstart bei /mnt/win_c eingehängt werden.
DOS-Dateisysteme, wozu auch FAT16 bzw. FAT32 gehören, kennen keine Eigentümer, Gruppen und (auf diese bezogene) Rechte. Daher werden solche Partitionen/Datenträger so eingebunden, dass alle User zwar die Dateien lesen dürfen, die Rechte zum Ändern hat allerdings ausschließlich der Root-User, also der Administrator.
Meistens ist das auch ausreichend, mit den vfat-Partitionen wird – bei einem MultiOS-PC – in erster Linie mit dem Windows-Betriebssystem gearbeitet werden. Wenn es nur um die Verfügbarkeit von Datein geht, beispielsweise das die MP3-Sammlung auch unter Linux abgespielt werden soll, geht das Problemlos. Man kann aber durch weitere Parameter auch Usern Schreibrechte auf gemounteten vfat-Datenträgern geben.
mount -t vfat <device> <dir> -o rw,uid=<your user id>,gid=<your group id>
Mit uid wird der Besitzer festgelegt, welcher Schreibrechte auf den zu mountenden Datenträger hat. Wie schon geschrieben unterstützt ein DOS Dateisystem keine User- und Gruppenrechte, daher erhalten alle Dateien auf dem Datenträger die gleichen Zugriffsrechte. Mit gid wird die Gruppenzugehörigkeit aller Dateien festgelegt.
Dies gilt bei den Dateisystemen msdos, vfat und iso9660 (CD-ROM). Bei letzterem sind die Schreibrechte relativ uninteressant – außer beim Brennen von CDs. Das ist aber ein anderes Thema.
Laut mehreren Tutorials im Web muß die Gruppen- bzw. User-ID muß als numerischer Wert übergeben werden. Ein Beispiel für einen Aufruf:
mount -t vfat /dev/hda1 /mnt/win_c -o rw,uid=1000,gid=1000
Es würde die erste primäre Partition der ersten IDE-Festplatte im Rechner gemountet werden, alle Dateien werden dem User mit der ID 1000 und der Gruppe mit der ID 1000 zugeordnet. User-ID und Gruppen-ID müssen nicht identische Werte sein.
In der Datei /etc/fstab würde der Eintrag folgendermaßen aussehen:
/dev/hda1 /mnt/win_c vfat rw,user,uid=1000,gid=1000
Die Option rw läßt das Laufwerk auch mit Schreibrechten mounten, user bewirkt, das auch ein »normaler« User (also nicht nur der Administrator bzw. root das Laufwerk mounten darf.
Bei mir konnte ich auch mit dem User- bzw. Gruppennamen anstatt der entsprechenden ID das Laufwerk mounten. Ob das evtl. nur bei einer neueren Version von mount geht oder ob die Tutorials im Web derart veraltet waren kann ich nicht sagen. Mit der User- bzw. Gruppen-ID ist man jedenfalls auf der sicheren Seite, man kann aber auch versuchen, die Partition mit folgendem Befehl zu mounten:
mount -t vfat /dev/hda1 /mnt/win_c -o rw,uid=turanga,gid=turanga
Die beiden turanga werden natürlich durch die auf dem System vorhandenen User- und Gruppennamen ersetzt. Eine Ausgabe von ls -la sieht dann folgendermaßen aus:
turanga:/mnt/win_d/timerc# ls -la insgesamt 680 drwxr-xr-x 2 turanga turanga 8192 14. Mär 2001 . drwxr-xr-x 15 turanga turanga 16384 1. Jan 1970 .. -rwxr-xr-x 1 turanga turanga 57688 2. Feb 1999 about.bmp -rwxr-xr-x 1 turanga turanga 147 29. Aug 12:40 _deisreg.isr -rwxr-xr-x 1 turanga turanga 40960 23. Apr 1997 _isreg32.dll -rwxr-xr-x 1 turanga turanga 9203 9. Feb 1999 readme.doc -rwxr-xr-x 1 turanga turanga 141 13. Feb 1999 revisions.txt -rwxr-xr-x 1 turanga turanga 651 2. Feb 1999 servers.txt -rwxr-xr-x 1 turanga turanga 510976 13. Feb 1999 TimeRC3.exe -rwxr-xr-x 1 turanga turanga 67 14. Mär 2001 ws_ftp.log turanga:/mnt/win_d/timerc#
Wie man sehen kann »gehören« alle Dateien dem User und der Gruppe mit dem Namen turanga. Außer Turanga kann nur noch der Administrator bzw. root die Dateien verändern. Getreu dem Motto: »Ich bin root – root darf das!« 
Die IDs für User und Group werden in zwei unterschiedlichen Dateien abgelegt.
Am einfachsten kann man die ID eines bekannten Usernamens mit dem Befehl id <username> herausfinden. Gibt man nur id ein bekommt man als Ausgabe die Informationen jenes Users, unter dem man den Befehl aufruft. Zwei Beispiele für eine Ausgabe:
turanga:/mnt/win_d/timerc# id turanga uid=1000(turanga) gid=1000(turanga) Gruppen=1000(turanga),29(audio),44(video) turanga:/mnt/win_d/timerc# id uid=0(root) gid=0(root) Gruppen=0(root)
Um die ID einer bestimmten Gruppe herauszufinden gibt es (AFAIK) keinen besonderen Befehl. Daher kann man folgendes machen:
grep <gruppenname> /etc/group
Die Abfrage nach der Gruppe video hat bei mir folgende Zeile ausgegeben:
video:x:44:turanga
Somit wäre die Gruppen-ID der Gruppe video laut der Angabe im dritten Feld 44.
Die Informationen über die Benutzer liegen in der Datei /etc/passwd, die Informationen über die Gruppen in der Datei /etc/group. Der im Beispiel von »vfat als bestimmter User mounten« verwendete User 1000 ist (bei mir) mit folgender Zeile in der /etc/passwd eingetragen:
turanga:x:1000:1000:Standarduser,,,:/home/turanga:/bin/bash
Ich gehe nicht auf den Aufbau der kompletten Zeile ein, lediglich die Bedeutung der ersten vier »Felder« werde ich (von links nach rechts) »aufschlüsseln«:
Das erste und dritte Feld ist also für das Auffinden der User-ID für einen bestimmten User relevant.
In der Datei /etc/group gibt es weniger Felder. Die Gruppe 1000 ist (bei mir) folgendermaßen eingetragen:
turanga:x:1000:
Auch hier eine kleine Aufschlüsselung:
Somit kann man – wie auch beim User – mit dem ersten und dritten Feld die ID einem Namen zuordnen.
Für den Fall das ein User mit Schreibrechten auf die vfat-Datenträger nicht ausreicht kann man die Datenträger auch so mounten, das alle (!) User Schreibrechte haben:
mount /dev/hda1 /mnt/win_c -o umask=000
Der Anhang -o umask=000 sorgt dafür, dass restlos alle User Schreibrechte auf alle Dateien des gemounteten Datenträgers haben. Die Dateien werden mit User und Group root gemountet. Das Verändern, Löschen und Neuanlegen von Dateien ist aber allen Usern gestattet. Der entsprechende Eintrag in der /etc/fstab lautet:
/dev/hda1 /mnt/win_c vfat rw,user,umask=000
Die Option user bewirkt, das auch ein »normaler« User das Laufwerk mounten darf. Das dadurch entstehende Sicherheitsloch darf natürlich nicht außer Acht gelassen werden. Sind die Dateien erstmal gelöscht hat man sie natürlich auch unter Windows nicht mehr – und schon gar nicht im »Papierkorb« vom Windows-OS.
Sollte es jetzt noch Fragen, Ergänzungen oder Korrekturen geben: Bitte schickt mir eine E-Mail und ich werde darauf eingehen.
