/etc/bashrc
/etc/csh.login
/etc/cron.allow;
/etc/cron.allow;
| Suchstrategien | Übersichtstabelle | Dateien im /etc/ -Verzeichnis | Dateien im HOME-Verzeichnis | Anmerkungen |
Es gibt im Wesentlichen zwei Orte, an denen Linux (und andere Unixe) ihre Konfigurationsdateien verwalten.
Im folgenden möchte ich die wichtigste Konfigurationsdateien kurzbeschreiben. Da ich jedoch nicht auf alle Dateien eigengehen kann und auch nicht immer alles in aller Ausführlichkeit darstellen kann, zunächst eine kleine Einführung, wie man aus dem System selbst die benötigten Informationen ziehen kann.
Für die meisten der Konfigurationsdateien existiert eine Online-Hilfe. Das Hilfesystem, was dabei verwendet wird, stammt noch aus der vor-GUI-Zeit und ist daher Text/Shell-basiert. Es besteht aus sogenannten man-pages (Maunal-pages), die mit dem Shell-Befehl
> man dateinameabgerufen werden. Beispielsweise liefert
> man passwddie Beschreibung zur der Datei /etc/passwd (Beim Abfragen der man-pages wird der Pfad der Datei weggelassen.). Wenn man sich in den Stil dieser - in der Regel englischsprachigen - man-pages eingelesen hat, liefern sie eine Menge nützlicher Informationen. Da alle man-pages ähnlich aufgebaut sind, findet man mit etwas Übung bereits beim überfliegen der man-page, die gewünschte Information.
Wenn man aber nun ein bestimmtes Problem (z.B. man kann sich von außen mit telnet nicht einloggen) lösen muss und nicht weiss welche Datei dafür zuständigt ist, gibt es zwei Strategien diese herauszufinden.
Mit dem Shellkommando man -k kann man Im Kopf der man-pages nach Stichwörtern suchen, z.B. also:
> man -k telnetDieser Befehl liefert z.B. folgendes Ergebnis:
issue.net (5) - identification file for telnet sessions telnet (1) - user interface to the TELNET protocol telnetd (8) - DARPA telnet protocol server
Es wurden also drei man-pages mit dem Stichwort telnet gefunden. Die Ziffern in den runden Klammern geben an zu welche Sektion der man-pages die angegebene Seite gehört. Nur in Sektion 5 befinden sich Beschreibungen von Konfigurationsdateien. Es käme also nur die Datei issue.net in Frage. Leider löst diese nicht unser Telnet-Problem.
Nun ist telnet ein Internetdienst. Man könnte also auch mal mit
> man -k internetsuchen. Und siehe da, man findet die vermutlichen Übeltäter inet.conf und services.
Man wechselt in einer Shell in das Verzeichnis /etc/ (mit cd /etc). Dort durchsucht man mit grep alle Konfigurationsdateien nach einem Stichwort, von dem man annimmt, das es in der gesuchten Konfigurationsdatei auftaucht. In dem Telnet-beispiel ginge das so:
> grep -l telnet * 2> /dev/nullDieser Befehl durchsucht alle Dateien (*) des aktuellen Verzeichnisses nach der Zeichenkette telnet und gibt nur die Namen dieser Dateien an (dazu die -l-Option). Damit alle Fehlermeldungen (z.B. die dass ein Verzeichnis nicht durchsucht werden kann, wie eine Datei) verworfen werden leiten wir mit 2> /dev/null die Fehlermeldungen ins Nirwana um[1].
Nun also eine kleine (unvollständige) Liste der Konfigurationsdateien. Falls ihr eine wichtige vermisst, mailt mir, damit ich sie hier aufnehmen kann.
Ich werde auch nicht in aller Ausführlichkeit auf alle Dateien eingehen können, sondern nur das wichtigste anreißen können. Ausführliche Informationen entnehmt doch bitte den man-pages (wie oben beschrieben).
Zunächst eine kleine Übersicht der hier erklärten Dateien (Vorläufig sind noch nicht alle beschrieben.Dies wird im Laufe der Zeit nachgeholt.):
inittab
Diese Datei regelt welcher runlevel[2]
vom init-Prozess beim Booten gestartet wird und welche
interaktiven Prozesse dabei gestartet werden.
Die wichtigste Zeile ist wohl die Zeile:
id:5:initdefault:
Die angibt den runlevel angibt, der beim booten gestartet wird. In diesem Fall runlevel 5.
rc.d
ist ein Unterverzeichnis von /etc/.
/etc/rc.d hat seinerseits mehrere Unterverzeichnisse, und zwar:
init.d in dem (fast) alle Skripte liegen, mit denen der init-Prozess beim booten, die verschiedenen Dienste startet. Für jeden Dienst existiert hier prinzipiell ein Skript. Jedes Skript erwartet als Parameter start oder stop je nach dem ob der Dienst gestartet oder gestoppt werden soll.
und für jeden runlevel[2] ein Verzeichnis namens rcn.d, wobei n die Nummer des jeweiligen runlevels darstellt. In diesen Verzeichnissen liegen Links auf die Skripte in init.d und zwar nur auf die Skripte der Dienste, die in dem jeweiligen runlevel gestartet werden. So findet sich in rc2.d kein Link auf /etc/rc.d/init.d/netfs, wohl aber findet sich eine solcher Link in rc3.d und rc5.d.
Die Links auf die Skripte in den rcn.d-Verzeichnissen können entweder beim Betreten oder Verlassen des runlevels gestartet werden. Entsprechend sind beginnen die Namen der Links mit 'S' für Start oder 'K' für Kill (=Ende/Verlassen). Die Ziffern dahinter geben die Reihenfolge an, in der die Skripte aufgerufen werden. S-Skripte werde daher mit dem Parameter start aufgerufen, K-Skripte mit stop.
Außerdem liegen in /etc/rc.d> noch zwei Skripte die nur beim Booten, nicht aber beim wechseln des runlevels ausgeführt werden. Zum einen ist das rc.sysinit, das vor allen anderen ausgeführt wird und rc.local, das nach allen anderen ausgeführt wird. Hier kann man eigene Initialisierungen in den Boot-Prozess einbauen.
| zum Anfang | Zur Übersicht |
passwd
In der passwd werden die Benutzerdaten abgespeichert. Für jeden Benutzer existiert eine Zeile
die 7 Felder enthäalt die durch ':' getrennt sind. Die Felder beinhalten folgendes:
Jede Benutzernummer sollte nur einmal vorkommen.
Da das System für bestimmte Aufgaben eigene User eingerichtet hat,
sollten die Benutzernummer unter 1000 dafür reserviert bleiben. Diese System eigenen Benutzer sind auch
in der passwd eingetragen.
Statt eines Passwortes kann auch ein 'x' eingetragen sein. Dann steht das Passwort in der Datei
/etc/shadow. Durch Eintragen von '*' in das Passwortfeld lässt sich ein Benutzer sperren,
das es kein Passwort gibt das so verschlüsselt wird.
shadow
Die Datei /etc/passwd ist für jederman lesbar. Auch wenn die Passwörter verschlüsselt sind,
ist es leichter ein Passwort zu knacken, wenn man eben die verschlüsselte Form kennt. Daher besteht die
Möglichkeit Passwörter in einer nur für root lesbaren Datei abzulegen,
eben der /etc/shadow.
Auch hier existiert für jeden Nutzer eine Zeile, mit durch ':' getrennten Feldern. Das erste Feld gibt wieder den Benutzernamen an , das zweite enthält das Passwort. Die weiteren Felder enthalten Informationen über die Gültigkeit des Passwortes. Siehe dazu die entsprechende man-page.
group
Diese Datei entspricht der /etc/passwd, nur das hier die Benutzergruppen verwaltet werden.
Sie enthält für jede Gruppe ein Zeile. Auch hier sind die Felder durch ':' getrennt und auch
hier gibt es vom Systemeingerichtet Gruppen. Die Gruppennummern (GID) der "normalen" Gruppen
sollten daher oberhalb von 500 oder 1000 liegen. Die einzelnen Felder einer Zeile haben folgende Bedeutung:
Zum letzten Feld noch eine Erklärung. Jeder Nutzer wird in der /etc/passwd einer Gruppe über die GID zugeordnet. Soll er darüberhinaus noch weiteren Gruppen angehören, so muss sein Benuztername im 4. Felder der entsprechenden Gruppen in dieser Datei hier eingetragen sein.
| zum Anfang | Zur Übersicht |
fstab
In dieser Datei wird angegeben welche Partition beim Booten an welcher Stelle in den Dateibaum eingebunden werden sollen.
Für jede Partition existiert eine Zeile, die sechs Felder enthält, die durch sogenannte
whitespaces[7], getrennt sind:
Neben den normalen Partitionen, werden auch noch zwei Spezialpartitionen eingebunden, nämlich auf die Pfade /proc und /dev/pts. Die Zeilen dazu sollten nicht verändert werden, können aber sonst ignoriert werden.
Durch ein vorangestelltes '#' lassen sich einzelne Zeilen auskommentiert und damit einzelne Partitionen deaktivierenm (erst ab dem nächsten boot. Vorher muss dies von Hand erledigt werden).
mtab
ist keine Konfigurationsdatei, sondern gibt Auskunft über die aktuell gemounteten Partitionen.
exports
bestimmt Verzeichnisse (samt Unterverzeichnissen) an andere Rechner freigegeben werden sollen. Anders als
bei MacOS oder Windows geschieht die Freigabe nicht an bestimmte Benutzer sondern an bestimmte Rechner.
Die Zugriffsrechte auf die Dateien wird über die normalen Dateiattribute geregelt.
Für jedes freigegebene (exportiert) Verzeichnis existiert eine Zeile.
Am Anfang dieser Zeile steht das freigegebene (exportierte) Verzeichnis, gefolgt von einer Liste
der Rechner an die exportiert wird. Die Liste ist wiederum durch
whitespaces[7] unterteilt.
Hinter jedem Rechnernamen kann in Klammern eine Liste von Optionen angegeben werden. Die
Optionen in dieser Liste wird durch Kommata getrennt. Mit diesen Optionen kann bestimmt werden,
ob ein Verzeichnis nur zum Lesen (z.B. deinRechner(ro)) oder zum lesen und schreiben
(z.B. deinRechner(rw)) freigegeben wird.
| zum Anfang | Zur Übersicht |
sysconfig/network
Die sysconfig/network enthält einige wenige grundlegende Einstellungen zum Netzwerk,
so ob überhaupt eines existiert, wie der Rechner im Netzwerk heißt.
sysconfig/network-scripts
Ist ein Verzeichnis mit Skripten, die beim Starten oder Stoppen des Netzwerkes aufgerufen werden.
Für jedes Netzwerkinterface, also Ethernet, PPP, usw. steht ein Satz Skripte zur Verfügung.
Diese Skripte heißen ifup-* und ifdown-*, wobei der * für den Namen des jeweiligen
Interfaces steht.
Die meisten Interfaces sind temporäre Interfaces, wie z.B. PPP. Für die festen Interfaces, loopback (lo) und Ethernet (eth0) gibt es noch je eine weitere Konfigurationsdatei, namens ifcfg-*. Diese enthält pro Parameter eine Zeile, der Form "parametername=Wert". Die wichtigsten Parameter sind:
inetd.conf
Diese Datei regelt welcher Dienste vom inet-Deamon[3]
beim seinem Start gestartet werden sollen.
Für jeden Dienst existiert eine Zeile.
Aus Sicherheitsgründen sind viele der Dienste die
gestartet werden könnten standardmäßig abgeschaltet. Dies geschieht durch ein
vorangestelltes '#'. Um einen Dienst beim nächsten Booten
(bzw. Start des inet-Deamons[4])
zu aktivieren muss man das '#' am Beginn der Zeile entfernen.
services
Um im Netz Datenpakete für verschiedene Dienste unterscheiden zu können, werden diese an unterschiedliche
"virtuelle" Eingänge geschickt, den sogenannten Ports. Welcher Port zu welchem Dienst gehört wird
von der IANA (Internet Assigned Numbers Authority) geregelt. Damit es kein Kudelmudel gibt wenn zwei Programme
denselben Port wollen.
Nun muss das System aber auch wissen welcher Port welchem Dienst unter welchem Protokoll zu geordnet ist, gibt es die Datei /etc/services. Jede Zeile in dieser Datei stellt eine Verbindung zwischen dem Dienst (z.B. telnet) und dem Port und dem Protokoll, mit dem dieser Port angesprochen werden soll, her. Für telnet sieht das dann so aus:
telnet 23/tcpPort 23 wird also von telnet mit dem TCP/IP-Protokoll angesprochen. Neben dem TCP/IP Protokoll gibt es noch das UDP (User Data Protocol, hieß das nicht mal Unix Data Protocol?). Wenn AppleTalk in Form von netatalk installiert ist kommt noch das DDP (Datagram Delivery Protocol).
Durch Ein- und Auskommentieren (d.h. durch löschen, bzw. hinzufügen den Kommentarzeichens '#' am Anfang einer Zeile) können auch hier einzelne Port ein- und ausgeschaltet werden. Die Änderungen werden aber erst beim nächsten Start[4] des Internet-Deamon inetd aktiv, in der Regel also beim nächsten Boot.
hosts
Auch wenn man immer Internet-Namen der Form host.domain.topLevelDomain liest, eigentlich funktioniert
ist jedem Rechner im Netz eine 32-bit-Zahl (d.h. eine zwischen 0 und 4294967295). Zur Vereinfachung werden diese
aber normalerweise in vier 8-bit-Häppchen geschrieben (z.B. 212.227.69.48).
Das gibt dann die IP-Nummer eines Rechners.
Das man sich dies aber immer noch sehr schwer merken kann, kann man sich diese Zahlenfolgen auch in Namen
der Form host.domain.topLevelDomain übersetzen lassen, bzw. die Namen in die IP-Nummer.
In der Regel geschieht dies ohne das man davon etwas mitbekommt.
Nun muss der Rechner aber wissen, wie eine solche Übersetzung aussieht. Dazu kann er entweder einen anderen Rechner fragen (das nennt sich dann DNS, mehr bei /etc/resolv.conf) oder er kann in einer eigenen "Datenbank" nachsehen, die in der Datei /etc/hosts steht.
Diese Datei ist wieder zeilenweise aufgebaut. Jede Zeile enthält eine Übersetzung. Diese beginnt mit der IP-Nummer und einem oder mehr Namen, z.B.
212.227.69.48 www.r-goetz.de meinWebServer
Man sieht in der /etc/hosts müssen die Namen nicht der
host.domain.topLevelDomain-Konvention folgen (beim DNS schon).
Pro IP-Nummer dürfen auch mehrere Zeilen existieren (Das ist vor allem bei virtuellen Webservern
interessant.).
Das Kommentarzeichen ist wieder '#', so dass Zeilen in der üblichen Art und Weise ein- und auskommentiert
werden können.
resolv.conf
Die andere Möglichkeit Internetnamen in IP-Nummer zu übersetzen
(mehr dazu bei /etc/hosts), ist einen Domain Name Service (DNS) zu bemühen.
Dazu muss der Rechner aber wissen wo er einen solchen findet. Diese Information findet er in der
/etc/resolv.conf.
Die wichtigsten Einträge sind die Zeilen die mit domain und nameserver beginnen.
Diese domain-Zeilen teilen dem Rechner mit, welche Domain er annehmen soll, wenn keine Domain
angegeben wurde und er den Rechnernamen auch nicht vorher in der /etc/hosts gefunden hat.
Die nameserver-Zeilen sagen im nun, unter welcher IP-Nummer er nun einen Nameserver (DNS-Server) findet.
Hier müssen IP-Nummer stehen!
Der Rechner kann ja noch keine Rechnernamen in IP-Nummer übersetzen, da er ja noch keinen DNS ansprechen kann,
um die IP-Nummer des DNS herauszufinden.
conf.routes
Innerhalb des eignen LAN können alle Rechner direkt erreicht werden.
Wenn aber ein Rechner ausserhalb angesprochen werden soll, muss der lokale Rechner
wissen über welchen Rechner (Router oder Gateway gennant) er seine TCP/IP-Packte
verschiecken soll.
Genau dies (die sog. default-route) wird hier eingetragen.
Ein Eintrage könnte z.B. so aussehen:
Damit werden alle Packte die zum Netz default (das sind alle Netze für die keine eigne Route angegeben wurde, d.h. in der Regel alles ausser dem LAN) über den Rechner (Router Gateway 0> gw) mit der IP 192.168.20.250 geschickt werden sollen. Dieser Router sollte dabei im eigenen LAN sein, d.h. die IP sollte eine aus dem eignen LAN sein.
Wenn man sich mit PPP einwählt, braucht man sich darum in der Regel nicht zu kümmern. Normalerweise wird die Gegenstelle einem die Routeraddresse zuweisen. Wenn nicht trägt man diese in der Konfiguartion von PPP (z.B. bei kpp ein).
nsswitch.conf
Das Linux-System muss immer wieder Informationen, wie Passwörter Gruppen-IDs, IP-Nummern usw.
von verschiedenen Stellen im Rechner und im Netz abfragen. Damit der System weiss wo es au fragen anfangen soll
und wie es weiterfragen soll gibt es die Datei /etc/nsswitch.conf. Für jede "Frage" gibt es hier
eine Zeile, die mit dem "Namen" der "Frage" beginnt. Das sieht zum Beispiel so aus:
In der Regel entsprechen die Namen der "Fragen", den Namen der dazugehörigen
Dateien im /etc/-Verzeichnis. Hinter der "Frage" folgt dann eine Liste von Instanzen,
die gefragt werden können.
Mögliche Instanzen sind:
files, d.h. es werden die entsprechenden lokalen Konfigurationsdatein durchsucht.
nis: NIS (Network Information System) ist eine intranetweites Informationssystem,
das solche Informationen bereit stellen kann.
nisplus: NIS+ ist der verbesserte Nachfolger von NIS. Leider sehr aufwendig in der Handhabung und hat
sich daher bisher nicht so richtig durchgesetzt.
ldap: Ein anderes System mit ähnlichen Eigenschaften wie NIS aber flexibler und leistungsfähiger.
dns: DNS (Domain Names Service). Mehr dazu bei /etc/resolv.conf und /etc/hosts
.
/etc/httpd/
Diese Verzeichnis enthält die Konfiguration des apache-Webserver-Deamons. Wer hier etwas ändern will
sollte sich die entsprechende apache-Dokumentation zur Gemüse führen.
/etc/ssh/
Diese Verzeichnis enthält die Konfiguration der secure-Shell. Die secure-Shell ist eine Ersatz für
telnet und rlogin, dessen Datenfluss im Gegensatz zu den genannten älteren Protokollen verschlüsselt
abergewickelt wird. Das gilt auch für die Übertragung von Passwörtern, die bei telnet und
rlogin im Klartext übers Netz gehen. Genaueres zu den einzelnen Optionen findet sich in den
entsprechenden man-pages zu ssh (Client) und sshd(Server).
| zum Anfang | Zur Übersicht |
atalk/atalkd.conf
Diese Datei legt fest über welches Interface das AppleTalk-Netz laufen soll.
Ich muss zugeben, viel verstehe ich auch nicht von netatalk. Aus einem HowTo-im Netz habe ich aber
folgende Konfiguration entnommen:
Diese Zeile funktioniert bei mir sehr gut. Alle anderen Zeilen sind Kommentar (Das Kommentarzeichen ist wie meistens das '#'). Falls jemand Probleme mit dieser Zeile hat, kann er mich gerne korrigieren.
atalk/AppleVolumes.default
Legt fest welche Partitionen, an alle AppleTalk-Nutzer freigegeben werden sollen. Eine simple '~' reicht
auch, um allen Nutzer ihr Heimatverzeichnis anzubieten. Natürlich können auch weitere
Verzeichnisse offeriert werden. In der Datei "appleVolumes" in seinem Heimatverzeichnis unter Linux kann
jeder Nutzer weitere Partitionen für das AppleTalk-Filesharing freigegeben.
Mehr dazu in der man-page zu afpd, dem Apple Filing Protocol Deamon.
atalk/AppleVolumes.system
Ist die Ü
Standardmäßig ist diese Datei bereits gut gefüllt. Mehr dazu in der man-page zu afpd.
atalk/afpd.conf
Offenbar dient diese Datei zur weiteren Konfiguration des Apple Filing Protocol Deamon (afpd),
wenn netatalk wie mehrere AppleTalk-Server auftreten soll.
Ich bin aber schon mit einem AppleTalk-Server zufrieden und kommen daher gut mit bis auf Kommentar leeren
Datei /etc/atalk/afpd.conf zurecht. Wer mehr wissen will sehe sich den Kommentar und dieman-page
vom afpd an.
atalk/papd.conf
Ist die Konfiguration des "appleTalk print server daemon". Da ich nie meine Drucker via AppleTalk
genutzt habe, kann ich nur auf die Man-page von papd. verweisen.
| zum Anfang | Zur Übersicht |
fb.modes
Enthält verschieden Modi des Framebufferdevices, über den bei LinuxPPC die Textconsolen und ggfs.
auch die X-Oberflächen realisiert wird. Der aktuelle Mode lässt sich mit dem Kommando
fbset und den geeigneten Optionen (siehe man-page) bearbeiten.
Hat man einen eigenen Mode erstellt kann man mit fbset (ohne Optionen)
die Parameter des aktuellen Modes erfragen. Diese können dann in die /etc/fb.modes
übertragen werden. Man sollte dabei den Namen des Modes aber durch einen sinnvollen ersetzten.
X11/
Diese Verzeichnis enthält (fast) alle Konfigurationen der X-Oberfläche.
Angefangen von der Konfiguration des X-Servers bis hin zu Tastureinstellungen, etc.
X11/XF86config
Unter Linux gibt oft für ein und denselben "Dienst" mehrere Implementationen.
Ein prominentes Beispiel dazu ist der X-Server.
Bei x86-Linux gibt es z.B. neben dem freien XFree86 noch einige kommerzielle X-Server, die z.B.
durch bessere Unterstützung bestimmer Grafikkarte oder durch besser Ausnutzung der Beschleunigungsfunktionen
der Grafikkarten auszeichnen.
Bei Linux auf dem Mac gibt es neben XF68_FBDev (einer Variante des Xfree86) noch den Xpmac,
der als eigene Implementation speziell für die Grafikhardware des Macs entstanden ist.
Während der Xpmac einfach die Einstellungen vom MacOS übernimmt, nutzt der XF68_FBDev
- wie alle Xfree86-Server - die Datei /etc/X11/XF86config zur Konfiguration.
In dieser Datei werden alle möglichen Aspekte der grafischen Oberfläche eingestellt, angefangen
mit der Auflösung und dem Monitortiming bis hin zum Tastaturlayout Mauseinstellungen und Zeichensätzen.
Für jeden dieser Bereiche steht in der /etc/X11/XF86config eine eigenen
Section zur Verfügung.
Ich möchte hier nur das Monitortiming und die Auflösung eingehen. Den Rest kann man man-page
XF86Config entnehmen oder man guckt einfach in die gut dokumentierte Datei selbst rein.
In der Section "Monitor" der /etc/X11/XF86config stellt man die Auflösung ein und wieviel Zeit (gemessen in Pixeln bzw. Zeilen) für die Ränder und den Zeilenrücklauf benötigt werden. Kurz es geht hier um das Timing der Grafikkarte und des Monitors.
Wenn man den XF68_FBDev-Server nutzt, kann man mit einem kleinen Umweg sich diese Einstellungen leichter erstellen (Klingt paradox ist aber wahr). Das produziert man zunächst einen Mode für den Framebufferdevice[5] in einer Textkonsole. Das Format der dazugehörigen Konfigurationsdatei /etc/fb.modes ist dabei intuitiver als das der /etc/X11/XF86config. Die kann einfach mit dem Kommando fbset geschehen (Details auf der man-page). Hat man sich so einen Mode für den Framebufferdevice erstellt, kann man ihn mit fbset -x in das Format der /etc/X11/XF86config übersetzen. Diese Zeilen trägt man nun in der /etc/X11/XF86config in der Section "Monitor" neben den dort bereits vorhanden anderen Monitormodi ein. Dabei sollte man dem Monitormode einen eindeutigen und sinnvollen Namen geben (fbset nennt alle Modi "name"), z.B. "1280" für einen Mode mit 1280x960 Pixeln.
Um diesen Mode nun auch nutzen zu können muss man die Auflösungen noch in der Section "screen" anmelden. In dieser sollte für den XF68_FBDev-Server als Driver "fbdev" eingetragen sein. Bei DefaultColorDepth sollte man die gewünschte Farbtiefe (vorzugsweise 24 oder 32 (bit), je nach dem was die Grafikkarte unterstützt.). Danach folgen mehrere Subsection "Display", die jeweils verschiedenen Auflösungen definieren. Der X-Server versucht nun diese der Reihe nach zu starten, bis er eine gefunden hat, die mit dem die Grafikkarte funktioniert. Bei x86-Linux kann man übrigen mit einem Tastaturkürzel zwischen den Display-modi wechseln. Leider scheint dies bei LinuxPPC (noch?) nicht zu funktionieren.
Jede Subsection "Display" enthält nun folgende Angaben:
Depth legt die Farbtiefe in diesem Mode fest.
Modes legt fest mit welchen Modi
(für die Auflösung und das Timing der Grafikkarte und des Monitors)
aus der Section "Monitor" dieser Display-Mode gestartet werden soll. Sind mehrere angegeben
werden sie wiederum der Reihe nach durchprobiert.
Virtual ist ein Schmankerl. man kann beim XFree86 virtuell größere Auflösungen nutzen,
als die Grafikkarte und/oder der Monitor zulassen. Bewegt man die Maus an den Rand des Bildschirm rutscht
das "sichtfenster" des Monitors entsprechend über den virtuell größeren Desktop.
Virtual legt fest, wie groß dieser virtuelle Desktop sein soll.
Wenn man hier die echte Auflösung einträgt, verhält sich X, wie vom MacOS gewohnt.
ViewPort legt fest wo die linke obere Ecke des kleinere "sichtfenster"
auf dem größeren virtuellen Desktop liege soll. Macht nur Sinn, wenn bei Virtual
eine größere Auflösung eingestellt ist, als tatsächlich dargestellt wird.
EndSubsection beendet die Subsection "Display". Es können weitere folgen.
Tools wie Xautoconfig oder SaX bei der SuSE nehmen einem die Arbeit die /etc/X11/XF86config zu editieren. Xautoconfig erstellt dabei aber nur einen Snapshot der aktuellen Einstellungen. SaX erlaubt schon recht flexible Einstellungen. Wenn man aber exotische Auflösungen nutzen will , kommt man ums editieren nicht herum (Ich schreibe dies bei 1400x1050 Pixeln auf einem 19'' Monitor).
X11/X
Eigentlich keine Konfigurationsdatei sondern ein Link. Dieser Link zeigt jedoch auf den X-Server
der verwendet werden soll. Da es (min.) zwei verschiedene für LinuxPPC gibt, kann man
durch setzten dieses Links konfigurieren, welchen X-Server man einsetzen will.
Die Binaries der X-Server (auf die dieser Link zeigen soll) liegen im Verzeichnis
/usr/X11R6/bin/ und heißen XF68_FBDev oder Xpmac.
X11/xdm/
In diesem Verzeichnis wird der (alte) grafische Loginprozess xdm konfiguriert.
Einige der Konfigurationsdateien werden auch von den moderneren kdm und gdm
genutzt. In der Regel kommt man aber mit den Defaulteinstellungen gut aus.
| zum Anfang | Zur Übersicht |
shells
Enthält die Pfade der zugelassen Shells beim login. In der Regel sind dies:
/bin/bash,
/bin/sh,
/bin/csh und
/bin/tcsh.
Anmerkung: Linux unterscheidet zwischen login-shells, bei denen man sich neu einloggt und "normalen" Shells, die von anderen Shells aufgerufene werden. Ein Shell die in einem Terminalfenster geöffnet wird, ist jedoch in der Regel eine login-Shell, da man sich hier mit einer neuen Shell anmeldet, auch wenn man nicht mehr Username und Passwort angeben muss. Das ist leider etwas verwirrend.
profile und bashrc
In diesen Dateien werden Environmentvariablen, Aliase usw. der bash
(Bourne-again-Shell ; gesprochen wie 'born again shell') systemweit für alle bash-Instanzen vorbelegt.
Die ist quasi die Konfiguration der bash. Dabei ist zu beachten, das /etc/profile nur von login-shells
abgearbeitet wird. Nach diesen Dateien werden noch die Nutzer-eigenen Konfigurationsdateien
abgearbeitet. Erst dann erscheint der Prompt (d.h. die Eingabeaufforderung).
Anmerkung: Die Datei /etc/bashrc gehört nicht zu den üblichen Konfigurationsskripten der bash. LinuxPPC installiert aber standardmäßig bei jedem Nutzer eine nutzerspezifisches Konfigurationsskript (.bashrc), das seinerseits /etc/bashrc aufruft.
Letztlich sind diese Dateien einfache Shellskripte. Shellskript sind nun nicht anderes als eine Folge von Kommandos, wie man sie auch interaktiv eingeben könnte. Versüßt wird das ganze durch Kontrollelemente, wie if, for oder while, die sich aber interaktiv nur schwer einsetzten lassen. Wer mehr über Shellskript lernen will, sollte zum einen in die man-page der bash gucken, vor allem aber sich schon existierende Skripte ansehen und nachvollziehen.
csh.cshrc und csh.login
In diesen Dateien werden Environmentvariablen, Aliase usw. der csh (C-Shell) und die tcsh (Turbo-C-Shell)
systemweit für alle bash-Instanzen vorbelegt.
Die ist quasi die Konfiguration der (t)csh. Dabei ist zu beachten, das /etc/csh.login nur von login-shells
abgearbeitet wird. Nach diesen Dateien werden noch die Nutzer-eigenen Konfigurationsdateien
abgearbeitet. Erst dann erscheint der Prompt (d.h. die Eingabeaufforderung). Ansonsten gilt das bei den
Konfigurationsdateien der bash genannte in analoger Weise.
crontab
Es gibt Aufgaben, die soll der Rechner zu bestimmten Zeiten regelmäßig ausführen.
Damit dies möglich ist, gibt es den cron-Deamon. Dieser überprüft minütlich
seine Aufgabenlisten, die er in der Datei /etc/crontab und im Verzeichnis /var/spool/cron/.
In letzterem stehen die Aufgabenlisten (im UNIX-Jargon crontabs genannt) der einzelnen Anwender.
Diese sollten nicht direkt editiert werden, sondern man sollte dazu das Kommando
crontab -e[6] verwenden.
Die Datei /etc/crontab verwaltet die systemrelevante Aufgabenliste.
Sowohl die Anwender-Listen als auch die /etc/crontab sind nahezu identisch aufgebaut. Sie beginnen mit einer Liste von Environmentvariablen, die für die cron-jobs (d.h. die Aufgaben in Liste) gelten sollen. Wichtig ist hier, dass die cron-jobs sonst ihre eigenen knapp bemessenen Einträge in den Environmentvariablen haben. Dannach kommt dann die Liste der einzelnen Aufgaben. Für jede Aufgabe wird eine Zeile benutzt, die aus 6 oder 7 Feldern besteht, die durch whitespaces[7] getrennt sind. Die ersten 5 Felder bezeichen dabei den Zeitpunkt, an dem der cron-job laufen soll. Nur wenn alle 5 Einträge erfüllt sind, wird der job gestartet. Im einzelnen bezeichnen die Felder:
Statt einer Zahl kann man bei jedem Feld auch einen Stern angeben. Dieser besagt dann, dass dieser Wert egal ist. Außerdem kann man auf folgende Konstruktion benutzen:3/5. Findet man diese im Minutenfeld, so besagt sie, das der job alle 5-Minuten beginnend um 3 nach ausgeführt werden soll.
Das 6. Feld findet sich nur in der /etc/crontab. Wozu es gut ist,weiß ich auch nicht. Es enthält typischerweise den Username 'root'. Belassen wir es also dabei.
Das letzte (6. oder 7.) Feld enthält nun das Kommando, das zu dem spezifizierten Zeitpunkt ausgeführt werden soll. Diese Feld umfasst alles hinter den vorherigen Feldern bis zum Zeitenende und darf daher whitespaces[7] enthalten.
cron.allow und cron.deny
Nicht jeder Anwender soll eigene Cron-jobs (siehe /etc/crontab) anlegen dürfen.
Um dies einschränken zu können gibt es die Dateien /etc/cron.allow und /etc/cron.deny.
Zugriff aus den cron-Deamon haben nur Anwender die in /etc/cron.allow ausgelistet sind.
Sollte diese Datei nicht existieren, haben alle Anwender die in /etc/cron.allow ausgelistet sind,
keinen Zugriff auf den cron-Deamon.
at.allow und at.deny
Neben dem cron-Deamon, der Aufgaben regelmäßig zu bestimmten Zeiten durchführt, gibt es
noch den at-Deamon, der Aufgaben einmalig zu einem bestimmten Zeitpunkt durchführt.
Analog zum cron-Deamon, kann auch hier der Zugriff auf den at-Deamon durch die die
Dateien /etc/at.allow und /etc/at.allow gesteuert werden.
printcap
In der Regel wird unter Linux das BSD-Printer-Spooling-System genutzt. In der Datei /etc/printcap
werden die Queue dieses Spooling-Systems festgelegt.
Da eine genauere Erklärung hier zu weit führen würde, sei nur auf die
entsprechende man-page ( man printacp) verwiesen. In der Regel wird man die Einrichtung und
Wartung dieser Datei jedoch Tools wie linuxconf oder demcontroll-panel
überlassen.
| zum Anfang | Zur Übersicht |
KDE verfügt über einen ganzen Satz von Konfigurationsdateien, sowohl Anwenderspezifische als auch globale. Häufig werden globale Einstellungen übernommen, wenn keine Anwenderspezifischen vorhanden sind. Leider ist der Ort, an diese Dateien liegen nicht festgelegt. Ausgehend von einem Wurzelverzeichnis folgt jedoch ein einheitlicher Dateibaum. Bei LinuxPPC R4 war dieses Wurzelverzeichnis /opt/kde/share, bei LinuxPPC 1999 ist es nun /usr/share. Bei anderen Distribution mag es noch andere Pfade dazu geben. Darunter ordnen sich dann sieben Verzeichnis an. (Im Falle von LinuxPPC 199 und /usr/share findet man noch weitere Verzeichnisse die jedoch nichts oder nur wenig mit KDE zu tun haben):
Hier finden sich Konfigurationsdateien, die zum einen zu Applikationen gehören, die nur auf Systemniveau laufen (z.B. zum kdm) oder Standardkonfigurationen, die ggfs. von Anwendereinstellungen überschrieben werden können.
Weitere Dateien einzelner Applikationen, wie z.B. applikationsinterne Icons, Sounds, etc. Für jede Applikation existiert ein Unterverzeichnis.
Die Dateien in diesem Unterverzeichnis bilden zum einen das globale KDE-Menü. Für jeden Menüeintrag existiert eine Datei, für jedes Untermenü ein Unterverzeichnis. Darüberhinaus werden hier Verknüpfungen zwischen den einzelnen Programmen und den Datei-, bzw. MIME-Typen(s.u.) hergestellt.
| zum Anfang | Zur Übersicht |
.kderc und .kde/
In der Datei .kderc speichert KDE seine globalen Einstallungen und im Verzeichnis .kde/
speichern die einzelnen Komponenten und Programme von KDE ihre Parameter. Die Parameterdateien sind
dabei in der Regel nach dem Schema "Parametername=Wert" aufgebaut.
Manche Dateien sind durch [XYT]-Zeilen in Abschnitte gegliedert. Kommentarzeilen beginnen
mit '#'.
Das Verzeichnis .kde/ gliedert sich wie folgt:
.kde/ -----> apps/
|
|---> share/ ------> config/
|----> apps/
|----> applnk/
|----> mimelnk/
|----> icons/
|----> sound/
|----> wallpapers
Im Verzeichnis .kde/share/config liegen die Konfigurationsdateien der einzelnen KDE-Programme.
Im Verzeichnis .kde/share/apps liegen alle weiteren Dateien, die eine KDE-Applikation benötigt, z.B. Bilder oder Sounds. Manche Programme legen dies Daten auch unter .kde/apps ab.
Im Verzeichnis .kde/share/applnk liegen Dateien die einerseits Verknüpfungen zwischen Dateitypen (genauer Mimetypen, s.u.) und Programmen herstellen und gleichzeitig eine Menüstruktur für das KDE-Menü darstellen. Jedes eigne KDE-Menü hat hier ein Unterverzeichnis; Jeder Eintrag im Menü eine .kdelnk-Datei. Die Gesamtheit dieser Dateien (zusammen mit den globalen KDE-Dateien und dem mimelnk-Verzeichnis) bilden etwas, das grob der Schreibtischdatei unter MacOS entspricht. Diese Dateien sollte man nicht direkt editieren sondern dazu den Menü-Editor von KDE verwenden.
Im Verzeichnis .kde/share/mimelnk liegen wiederum Dateien, die Verknüpfungen zwischen Dateierweiterungen und MIME-Typen herstellen. Ein MIME-Typ entsprecht in etwa demTYPE unter MacOS. Im Gegensatz zu den MacOS-Typen werden die MIME-Typen auch im Web-verwendet. Da MIME-Typen in der Regel festvorgegeben sind, finden sich diese Dateien sich vor allem bei den globalen KDE-Dateien. Im .kde/share/mimlnk/-Verzeichnis kann jedoch jeder MIME-Typen für den eigenen Bedarf und Bereich hinzufügen.
In den Verzeichnissen .kde/share/icons, .kde/share/sound und .kde/share/wallpapers kann jeder zu den global vorhandenen Icons, Sounds und Wallpapers (=Bildschirmhintergründe) eigene hinzufügen.
Im Allgemeinen sollte man alle diese Dateien nur mit den Dialogen der entsprechenden KDE-Anwendungen oder des KDE-Controll-Centers verändern und nicht direkt editieren. Ausnahmen bilden nur die Verzeichnisse Icons, Sounds und Wallpapers, zu denen man jederzeit gefahrlos eignen Kreationen hinzufügen kann.
.rhosts
rlogin und ssh bieten, neben dem Password basiertem Einloggen noch einen zweiten unsichereren Mechanismus an
(Bei ssh muss dieser erst in der Datei /etc/ssh/sshd_config des Remotehost
erlaubt werden). Dabei wird statt dem Passwort überprüft, ob der Login in von einem
Account auf einem vertrauenswürdigem Rechner und von einem vertrauenswürdigem Account
aus erfolgt. Welche Account auf welchen Rechnern vertrauenswürdig sind steht in der Datei
.rhosts (bzw. bei ssh alternativ in /shosts).
Jeder Zeile in dieser Datei besteht aus einem Rechnername (oder auch IP-Nummer) und einem
Accountnamen. Nur wenn man sich von einer dieser Kombinationen auch Rechner und Account aus einloggen will,
kommt man um das Passwort herum.
Notwendig ist dieser Mechanismus, dann wenn man von einem Rechner aus Programme auf einem
anderen Starten will ohne aufwendig eigne Deamons dazu zu schreiben.
.bashrc und .profile
Nachdem die systemweiten Konfigurationskripte abgearbeitet sind, wird die nutzerspezifische bash-Konfiguration
angegangen. Abweichend von den man-pages wird bei LinuxPPC 1999 nur die Datei .bashrc abgearbeitet, nicht jedoch
die Dateien .profile, .bash_profile, oder .bash_login,.
Statt dessen enthält dieses Skript in der standardmäßig installierten Form einen Aufruf des
systemweiten Skriptes /etc/bashrc. Dieser Aufruf sollte nicht gelöscht werden.
Systemadministratoren fügen oft hier noch den Aufruf eines netzweit einheitlichen Konfigurationsskriptes
hinzu, um allen Nutzer eine einheitliche Shellumgebung zu ermöglichen.
Selbstverständlich ist jeder Nutzer aber in der Lage die dort getroffenen voreinstellungen zu verändern.
Zur Form die dieser Konfigurationsskripte siehe /etc/profile.
.(t)cshrc und .login
Nachdem die systemweiten Konfigurationskripte abgearbeitet sind, wird die nutzerspezifische (t)csh-Konfiguration
angegangen. Die csh arbeitet dabei zunächst die Datei .cshrc ab und dann .login. Letztere
wird aber nur genutzt wenn es sich um eine login-Shell handelt.
Die tcsh versucht zunächst die Datei .tcshrc abzuarbeiten. Wird diese nicht gefunden, greift die tcsh auch auf .cshrc zurück. Ansonsten gilt in analoger Weise das bei den anderen Shellkonfigurationen gesagte (siehe dazu .bashrc, /etc/profile und /etc/profile/csh.cshrc).
.Xdefaults und .Xresources
Neben den Konfigurationsformaten, die jede Applikation neu definiert gibt es für GUI-Einstellungen einen
einheitlichen Mechanismus (der leider nicht mehr von allen modernen Programmen, z.B. KDE unterstützt wird.):
die X-Resourcen. Die X-Resourcen werden in globalen und anwenderspezifischen Dateien gespeichert.
Auch hier gilt ein Parameter eine Zeile. Jeder Zeile ist wie folgt aufgebaut:
Applikationsname.Parameter: Wert oder Applikationsname*Parameter: Wert.
Neben einige Parametern, die für alle Applikation gleich sind (z.B. geometry, foreground etc.)
gibt es auch Applikationspezifischen Parameter, die man am besten den man-pages oder anderen
Dokumentationen entnimmt.
Eigne Einstellungen kann man entweder in /Xdefaults oder in .Xresources ablegen. Leider ist es von Linux zu Linux zu UNIX unterschiedlich welcher der beiden Dateien genutzt wird. Um auf der sicheren Seite zu sein lege ich eine immer die fehlende immer als Link auf die existierende an.
.xmodmap
In dieser Datei kann man sich ein eigenes Tataturlayout anlegen. Mehr dazu siehe in
meinem Artikel Wie bekomme ich unter X ein deutsches Tastaturlayout.
AppleVolumes oder .AppleVolumes
In dieser Datei kann man für den eigene Account Partitionen zum Export via AppleTalk-Filesharing freigeben.
Mehr dazu in der Beschreibung zur Systemweiten AppleTalk- bzw. netatalk-Konfiguaration.
.netscape
Hier legt Netscape seine Daten ab. Entspricht unter MacOS dem Verzeichnis Macintosh HD:Systemordner:Preferences:Netscape.
.emacs,.pinerc,.gimp, ...
Nicht nur Netscape legt seine anwenderspezifischen Konfiguration ins Heimatverzeichnis. Andere Programme
tun dies auch. In welchem Format und in welcher Datei da geschieht, ist von Programm zu Programm verschieden.
Typischerweise heißen diese Dateien aber .programmnamerc ("rc" für Resource)
oder einfach ..programmname
Ein Ausnahme bilden KDE-Applikation, die ihrer Parameter im .kde/share/config-Verzeichnis ablegen
(s.o.).
| zum Anfang | Zur Übersicht |
| 0 | Shutdown, Anhalten des Systems |
| 1 | Singleusermode, wird mitunter zur Systemadministration bei ernsten Problemen benötigt. |
| 2 | Multiusermode, mit Netzwerk aber ohne NFS (Networking file system, entspricht dem Filesharing von MacOS) |
| 3 | Multiusermode, mit Netzwerk und NFS |
| 5 | Multiusermode, mit Netzwerk und NFS und X-Oberfläche |
| 6 | Reboot, Neustart des Rechners. |