[OpenBSD]

[FAQ-Index] [Zum Kapitel 9 - Zu OpenBSD migrieren] [Zum Kapitel 11 - Das X Fenstersystem]

10 - Systemverwaltung


Inhaltsverzeichnis


10.1 - Wenn ich mich per su zu root machen will, wird mir gesagt, dass ich in der falschen Gruppe sei.

Unter OpenBSD ist es Benutzern der Gruppe wheel erlaubt, mit Hilfe von su(1) zum Benutzer root zu werden. Anderenfalls wird der Benutzer einen Fehler erhalten.

Erzeugst du einen neuen Benutzer mit adduser(8), so kannst du ihn zu der Gruppe wheel hinzufügen, indem du am Prompt der Frage "Invite user into other groups:" mit »wheel« antwortest. Bestehende Benutzer müssen per Hand zu der Gruppe wheel hinzugefügt werden. Hier ist das Beispiel eines Eintrags in /etc/group, das den Benutzer ericj zu der Gruppe wheel hinzugefügt zeigt:

wheel:*:0:root,ericj

Möchtest du »Superuser«-Privilegien ermöglichen, ohne Benutzer zu der Gruppe wheel hinzuzufügen, verwende sudo(8).

10.2 - Wie kann ich ein Dateisystem duplizieren?

Um ein Dateisystem zu duplizieren, verwende dump(8) und restore(8). Um zum Beispiel alles unter dem Verzeichnis SRC in das Verzeichnis DST zu duplizieren, führe Folgendes aus:

# cd /SRC; dump 0f - . | (cd /DST; restore -rf - )

Das Programm dump wurde so entworfen, dass es dir reichliche Backupmöglichkeiten gibt und es könnte viel zu viel sein, wenn du einfach nur einen Teil (oder das gesamte) Dateisystem duplizieren möchtest. Das Kommando tar(1) kann für diese Aufgabe schneller sein. Das Format sieht sehr ähnlich aus:

# cd /SRC; tar cf -  . | (cd /DST; tar xpf - )

10.3 - Wie starte ich Daemons mit dem System? (Überblick über rc(8))

OpenBSD selbst verwendet eine rc(8)-orientierte Startphase. Diese verwendet einige Schlüsseldateien.

Wie funktioniert rc(8)?

Die Hauptdateien, auf die ein Systemadministrator zu achten hat, sind /etc/rc.conf (als Anleitung), /etc/rc.conf.local (für Änderungen), /etc/rc.local und /etc/rc.shutdown. Um einen Überblick über die rc(8)-Prozedur zu erhalten, folgt der Ablaufplan:

Nachdem der Kernel geladen wurde, wird /etc/rc gestartet:

In OpenBSD enthaltene Daemons und Dienste starten

Die meisten der in OpenBSD enthaltenen Daemons und Dienste werden während des Systemstarts durch Variablen kontrolliert, die in den Konfigurationsdateien des Verzeichnisses /etc/rc.conf definiert sind. Wirf einen Blick in die Datei /etc/rc.conf. Dort wirst du Zeilen ähnlich der Folgenden sehen:

ftpd_flags=NO           # for non-inetd use: ftpd_flags=""

Eine Zeile wie diese zeigt das ftpd(8) nicht mit dem System gestartet wird (zumindest nicht als Dämon durch rc(8); ftpd wird oft durch inetd(8) gestartet, siehe die Anonymes FTP FAQ, um mehr darüber zu lesen). Jede Zeile besitzt ein Kommentar, das die benötigten Optionen für die geläufige Form der Benutzung des Dämonen oder Service aufzeigt. Dies bedeutet nicht, dass du diesen Dämon oder Service mit exakt diesen Optionen starten musst. Lies die relevanten Handbuchseiten, um in Erfahrung zu bringen, wie dieser eine Dämon oder Service auf die gewünschte Art und Weise gestartet werden kann.

Wir empfehlen dringend /etc/rc.conf nicht zu ändern. Stattdessen sollte die Datei /etc/rc.conf.local erzeugt oder editiert werden; kopiere einfache jene Zeilen, die geändert werden sollen, aus /etc/rc.conf und passe sie ganz nach Gusto an. Diese Vorgehensweise macht zukünftige »Upgrades« einfacher - alle Änderungen befinden sich in einer Datei, die während des »Upgrade« nicht berührt wird. Tatsächlich nimmt der standardmäßige »Upgrade«-Prozess an, dass /etc/rc.conf nicht verändert wurde, und überschreibt diese Datei mit einer neuen Version.

Hier zum Beispiel ist die standardmäßige Zeile bezüglich httpd(8).

httpd_flags=NO          # for normal use: "" (or "-DSSL" after reading ssl(8))

Wie zu sehen ist benötigt httpd für den Programmstart normalerweise keinerlei Optionen, sodass das Hinzufügen einer Zeile wie httpd_flags="" zu /etc/rc.conf.local für die vollständige Einrichtung dieses Services ausreicht. Um aber httpd mit aktiviertem SSL zu starten (siehe auch SSL-FAQ oder ssl(8)), würde man mit einer Zeile wie httpd_flags="-DSSL" beginnen, obwohl man eventuell andere Optionen aus anderen Gründen wird hinzufügen müssen.

Lokale Daemons starten und konfigurieren

Für andere Daemons, die vielleicht auf dem System via Paket, oder auf andere Art installiert werden, könnte die Datei /etc/rc.local verwendet werden. Zum Beispiel hat der Autor einen Dämon in /usr/local/sbin/daemonx installiert, und möchte ihn zur Systemstartzeit gestartet haben. Im dies zu erreichen, könnte er einen Eintrag wie den folgenden in /etc/rc.local schreiben:

if [ -x /usr/local/sbin/daemonx ]; then
    echo 'Starting daemonx'; /usr/local/sbin/daemonx
fi

(Wenn der Daemon sich beim Starten nicht automatisch von der Konsole löst, denke daran, dass du ein »&« an das Ende der Kommandozeile hängen musst.)

Von nun an wird dieser Daemon beim Booten gestartet. Du wirst in der Lage sein, jegliche Fehler beim Hochfahren zu sehen, ein normaler Boot ohne Fehler würde eine Zeile wie die folgende anzeigen:

Starting daemonx

Das Verzeichnis /etc/rc.d/

Beginnend mit OpenBSD 5.1 werden Systemdämonen (»Services«) von /etc/rc.d gestartet, gestopped und kontrolliert. Alle Systemdämonen werden durch diese Skripte gehandhabt, und ebenso die meisten Pakete.

Diese Skripte, einer pro Dämon, werden von rc aufgerufen. Die Reihenfolge der Systemdämonen ist fest in rc codiert, und die Reihenfolge für hinzugefügte Pakete wird von der pkg_scripts Umgebungsvariable gesteuert, welche in /etc/rc.conf.local gesetzt würde. Beachte, dass das einfache Platzieren eines Skripts in diesem Verzeichnis nicht dazu führt, dass es automatisch während des Systemstarts aufgerufen wird; dafür muss der Name des Skripts in pkg_scripts vorkommen.

Das Starten von Systemskripten wird von Einträgen in der Datei /etc/rc.conf.local bestimmt. Zum Beispiel wird /etc/rc.d/httpd nicht httpd(8) starten bevor /etc/rc.conf oder /etc/rc.conf.local eine Zeile beinhalten, die die Variable »httpd_flags« definiert. Um dabei zu helfen, dass das System sich genau wie erwartet beim nächsten Systemstart verhält, starten die rc.d-Skripte ihren Dämon nicht, es sei denn eine entsprechende Variable wurde definiert. Man kann natürlich /usr/sbin/httpd direkt, mit was auch immer für Optionen man will direkt aufrufen, will man das Programm denn manuell aufrufen.

Es ist anzumerken, dass Skripte in rc.d keineswegs die komplette »startup«-, »shutdown«-, »reload«-, »restart«- und »check«-Funktionalität voll implementieren müssen; die meisten rc.d-Skripte können auf die Spezifikation einiger weniger Variablen und den Aufruf des rc.subr-Skripts reduziert werden, da der genannte Skript die meisten normalen Wege zur Bewältigung dieser Aufgaben handhaben kann.

Zum Beispiel könnte die oben angeführte Anwendung daemonx mit einer /etc/rc.d-Datei wie der Folgenden gestartet werden:

#!/bin/sh

daemon="/usr/local/sbin/daemonx"

. /etc/rc.d/rc.subr

rc_cmd $1
sowie dem Hinzufügen des Namen des Dämonen zu der Variable pkg_scripts in /etc/rc.conf.local.

rc.shutdown

/etc/rc.shutdown ist ein Skript, das beim Herunterfahren ausgeführt wird. Alles, was du zuvor erledigt haben möchtest, bevor das System herunterfährt, sollte in diese Datei geschrieben werden. Falls du apm hast, kannst du ebenfalls powerdown=YES setzen. Das wird dir das Äquivalent zu »shutdown -p« geben.

10.4 - Wieso erhalten Benutzer ein »relaying denied« wenn sie versuchen, von woanders her Mails über mein OpenBSD-System zu verschicken?

Versuch das hier:

# grep relay-domains /etc/mail/sendmail.cf

Die Ausgabe könnte wie folgt sein:

FR-o /etc/mail/relay-domains

Wenn diese Datei nicht vorhanden ist, erstelle sie. Du musst die Hosts mit der folgenden Syntax eintragen, die Mails über dein System senden.

.domain.com    #Allow relaying for/to any host in domain.com
sub.domain.com #Allow relaying for/to sub.domain.com and any host in that domain
10.2           #Allow relaying from all hosts in the IP net 10.2.*.*

Vergiss nicht, ein HangUP-Signal an sendmail zu senden (ein Signal, das die meisten Daemons veranlasst, ihre Konfigurationsdatei erneut einzulesen):

# kill -HUP `head -1 /var/run/sendmail.pid`

Weitere Informationen

10.5 - Ich habe POP installiert, erhalte aber Fehler, wenn ich versuche, meine Mails per POP abzuholen. Was kann ich tun?

Die meisten Konflikte mit POP sind Probleme mit temporären und Lockdateien. Wenn dein POP-Server eine Fehlernachricht wie diese sendet:

-ERR Couldn't open temporary file, do you own it?

Versuche, deine Berechtigungen wie folgt einzurichten:

permission in  /var
drwxrwxr-x   2 bin     mail     512 May 26 20:08 mail


permissions in  /var/mail
-rw-------   1 username   username        0 May 26 20:08 username

Eine andere Sache, die überprüft werden sollte, ist, dass der Benutzer tatsächlich seine eigene /var/mail-Datei besitzt. Selbstverständlich sollte das der Fall sein (also, dass /var/mail/joe joe gehört) aber wenn das nicht richtig eingestellt ist, könnte es das Problem sein!

Selbstverständlich wird eine Schreibberechtigung der Gruppe mail ein unwahrscheinliches und obskures Sicherheitsproblem hervorrufen. Es ist sehr wahrscheinlich, dass du niemals Probleme damit haben wirst. Aber es könnte sein (insbesondere, wenn du eine sehr beschäftigte Site hast, ISP, ...)! Es gibt einige POP-Server, die du direkt von der Portierungs-Kollektion aus installieren kannst. Wenn möglich, verwende popa3d, das in der OpenBSD-Basisinstallation vorhanden ist. Oder aber, du könntest einfach die falschen Optionen für deinen POP-Daemon ausgewählt haben (wie Dotlocking). Vielleicht musst du das Verzeichnis wechseln, in dem er ein Lockin durchführt (obwohl das Locking dann nur für den POP-Daemon von Bedeutung sein wird).

Hinweis: Denke daran, dass OpenBSD keine Gruppe namens mail hat. Du musst diese in deiner /etc/group-Datei erstellen, wenn du sie brauchst. Ein Eintrag wie:

mail:*:6:

wäre ausreichend.

10.6 - Warum ignoriert Sendmail die /etc/hosts-Datei?

Standardmäßig verwendet Sendmail DNS für die Namensauflösung, nicht die /etc/hosts-Datei. Die Vorgehensweise kann durch das Nutzen der /etc/mail/service.switch-Datei geändert werden.

Wenn du die hosts-Datei vor den DNS-Servern überprüfen willst, erstelle eine /etc/mail/service.switch-Datei, welche folgende Zeile beinhaltet:

hosts       files dns

Wenn du NUR die hosts-Datei überprüfen willst, verwende die folgende:

hosts       files

Sende Sendmail ein HUP-Signal:

# kill -HUP `head -1 /var/run/sendmail.pid`

und die Änderungen werden wirksam.

10.7 - Einen sicheren HTTP-Server mit Hilfe von SSL(8) aufsetzen

OpenBSD wird mit einem SSL-fähigen httpd und RSA-Bibliotheken ausgeliefert. Für die Verwendung mit httpd(8) musst du zuerst ein Zertifikat erstellen. Dieses wird unter /etc/ssl/ mit dem dazugehörigen Schlüssel unter /etc/ssl/private/ abgelegt. Die Schritte, die hier gezeigt werden, sind Teil der ssl(8)-Handbuchseite. Greife für weitere Informationen auf diese zurück. Dieser FAQ-Eintrag zeigt nur, wie man ein RSA-Zertifikat für Webserver erstellt, nicht ein Zertifikat für einen DSA-Server. Um zu erfahren, wie man das macht, greife auf die ssl(8)-Handbuchseite zurück.

Um zu beginnen, musst du deinen Serverschlüssel und dein -zertifikat unter Verwendung von OpenSSL erstellen:

# openssl genrsa -out /etc/ssl/private/server.key 2048

Oder, wenn du möchtest, dass dein Schlüssel mit einem Passwort verschlüsselt wird, das du beim Starten des Servers angeben wirst:

# openssl genrsa -des3 -out /etc/ssl/private/server.key 2048

Der nächste Schritt ist das Generieren eines »Certificate Signing Request«, welches genutzt wird, um eine »Certifying Authority« (CA) dazu zu bringen, dein Zertifikat zu signieren. Verwende hierfür dieses Kommando:

# openssl req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr

Diese server.csr-Datei kann danach zu einer »Certifying Authority« übergeben werden, die den Schlüssel signieren wird. Eine solche CA ist Thawte Certification, welche unter http://www.thawte.com/ erreicht werden kann.

Wenn du dir das nicht leisten kannst oder du das Zertifikat einfach nur selbst signieren möchtest, kannst du das Folgende nutzen.

# openssl x509 -sha256 -req -days 365 -in /etc/ssl/private/server.csr \
       -signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt

Mit /etc/ssl/server.crt und /etc/ssl/private/server.key an der richtigen Stelle solltest du in der Lage sein, httpd(8) mit der Option -DSSL zu starten (siehe die Sektion über rc(8) in dieser FAQ), was HTTPS-Transaktionen mit deiner Maschine über den Port 443 ermöglicht.

10.8 - Ich habe zwar mit vi(1) Änderungen an /etc/passwd gemacht, die Änderungen haben aber keinen Effekt. Warum?

Wenn du /etc/passwd direkt editierst, werden deine Änderungen verloren gehen. OpenBSD generiert /etc/passwd dynamisch mit pwd_mkdb(8). Die Hauptpasswortdatei unter OpenBSD ist /etc/master.passwd. Laut pwd_mkdb(8),

FILES
     /etc/master.passwd  current password file
     /etc/passwd         a 6th Edition-style password file
     /etc/pwd.db         insecure password database file
     /etc/pwd.db.tmp     temporary file
     /etc/spwd.db        secure password database file
     /etc/spwd.db.tmp    temporary file

In einer traditionellen Unix-Passwortdatei, wie /etc/passwd, ist alles für jeden auf dem System verfügbar, dazu zählt auch das verschlüsselte Passwort des Benutzers (und ist somit das Hauptziel für Programme wie zum Beispiel Crack). 4.4BSD führte die Datei master.passwd ein, welche ein erweitertes Format hat (mit zusätzlichen Optionen, die über die hinausgehen, die in /etc/passwd aufgelistet sind) und ist nur von root lesbar. Für schnelleren Zugriff auf die Daten lesen die Bibliotheksaufrufe, die auf jene Daten zugreifen, normalerweise /etc/pwd.db und /etc/spwd.db.

OpenBSD wird mit einem Tool ausgeliefert, mit welchen du deine Passwortdatei editieren solltest. Es wird vipw(8) genannt. Vipw verwendet vi (oder deinen bevorzugten Editor, der mit $EDITOR definiert wird), um /etc/master.passwd zu bearbeiten. Wenn du mit dem Editieren fertig bist, wird es /etc/passwd, /etc/pwd.db und /etc/spwd.db anhand deiner Änderungen aktualisieren. Vipw kümmert sich ebenfalls um das Locking dieser Dateien, sodass, falls jemand zur gleichen Zeit versucht, sie zu editieren, ihm der Zugriff verwehrt wird.

10.9 - Was ist der beste Weg, Benutzer hinzuzufügen oder zu löschen?

OpenBSD bietet zwei Kommandos, um Benutzer auf einfache Weise dem System hinzuzufügen:

Du kannst Benutzer ebenfalls manuell unter Verwendung von vipw(8) hinzufügen, aber das ist für die meisten Operationen umständlicher.

Der einfachste Weg, um einen Benutzer unter OpenBSD hinzuzufügen, ist die Verwendung des adduser(8)-Skripts. Du kannst adduser(8) durch das Editieren der /etc/adduser.conf konfigurieren. adduser(8) erlaubt Konsistenzüberprüfungen für /etc/passwd, /etc/group und Shelldatenbanken. Es wird die Einträge und $HOME-Verzeichnisse für dich erstellen. Es kann sogar eine Nachricht an die Benutzer zur Begrüßung senden. Hier ist ein Beispielbenutzer, testuser, der zu einem System hinzugefügt wird. Er/Sie bekommt das $HOME-Verzeichnis /home/testuser, wird ein Mitglied der Gruppe guest und bekommt die Shell /bin/ksh.

# adduser
Use option ``-silent'' if you don't want to see all warnings and questions.

Reading /etc/shells
Check /etc/master.passwd
Check /etc/group

Ok, let's go.
Don't worry about mistakes. There will be a chance later to correct any input.
Enter username []: testuser
Enter full name []: Test FAQ User
Enter shell csh ksh nologin sh [ksh]: ksh
Uid [1002]: Enter
Login group testuser [testuser]: guest
Login group is ``guest''. Invite testuser into other groups: guest no
[no]: no
Login class authpf daemon default staff [default]: Enter
Enter password []: Type password, then Enter
Enter password again []: Type password, then Enter

Name:        testuser
Password:    ****
Fullname:    Test FAQ User
Uid:         1002
Gid:         31 (guest)
Groups:      guest
Login Class: default
HOME:        /home/testuser
Shell:       /bin/ksh
OK? (y/n) [y]: y
Added user ``testuser''
Copy files from /etc/skel to /home/testuser
Add another user? (y/n) [y]: n
Goodbye!

Um Benutzer zu entfernen, solltest du das rmuser(8)-Werkzeug nutzen. Dieses wird jegliche Existenz eines Benutzers löschen. Es wird jegliche crontab(1)-Einträge entfernen, sein $HOME-Verzeichnis (wenn es dem Benutzer gehört) und seine Mails. Selbstverständlich wird es ebenfalls seine /etc/passwd- und /etc/group-Einträge löschen. Als nächstes folgt ein Beispiel, in dem der Benutzer, der gerade hinzugefügt wurde, wieder gelöscht wird. Achte darauf, dass du nach dem Namen gefragt wirst und ob du das Heimatverzeichnis des Benutzers löschen möchtest oder nicht.

# rmuser
Enter login name for user to remove: testuser
Matching password entry:

testuser:$2a$07$ZWnBOsbqMJ.ducQBfsTKUe3PL97Ve1AHWJ0A4uLamniLNXLeYrEie:1002
:31::0:0:Test FAQ User:/home/testuser:/bin/ksh

Is this the entry you wish to remove? y
Remove user's home directory (/home/testuser)? y
Updating password file, updating databases, done.
Updating group file: done.
Removing user's home directory (/home/testuser): done.

Benutzer mit user(8) hinzufügen

Diese Tools sind nicht so interaktiv wie das adduser(8)-Kommando, wodurch sie einfacher in Skripten genutzt werden können.

Die gesamte Palette dieser Tools ist:

Benutzer tatsächlich hinzufügen

Das Kommando /usr/sbin/user ist nur ein Frontend für den Rest der /usr/sbin/user*-Kommandos. Deshalb können die folgenden Kommandos sowohl per user add als auch per useradd hinzugefügt werden, wobei die Form hier am Ergebnis nichts ändert. Erinnere: Da user(8) nicht interaktiv ist, ist adduser(8) der einfachste Weg, Benutzer hinzuzufügen.

useradd(8) ist weniger entmutigend zu nutzen, wenn die Standardeinstellungen im voraus bekannt sind. Diese Einstellungen befinden sich in usermgmt.conf(5) und können wie folgt angezeigt werden:

$ user add -D
group           users
base_dir        /home
skel_dir        /etc/skel
shell           /bin/csh
inactive        0
expire          Null (unset)
range           1000..60000

Diese Standards werden benutzt solange über Kommandozeilenoptionen keine Alternativen spezifiziert werden. Wenn zum Beispiel der Benutzer zur Gruppe guest, anstatt zur Gruppe users hinzugefügt werden soll. Eine weitere kleine Hürde beim Hinzufügen von Benutzern ist es, dass Passwörter auf der Kommandozeile angegeben werden müssen. Wichtiger, die Passwörter müssen verschlüsselt sein, sodass man das Dienstprogramm encrypt(1) benutzen muss. Zum Beispiel: OpenBSDs Passwörter werden standardmäßig unter Verwendung des Blowfish-Algorithmus mit 6 Runden verschlüsselt. Hier ist eine Beispielzeile, die zeigt, wie man ein verschlüsseltes Passwort erstellt, das man dann useradd(8) übergibt.

$ encrypt -p -b 6
Enter string:
$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq

Nun, da wir unser verschlüsseltes Passwort haben, sind wir bereit, den Benutzer hinzuzufügen. Wir fügen denselben Benutzer mit denselben Spezifikationen hinzu, den wir weiter oben via adduser(8) hinzugefügt haben.

# user add -p '$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq' -u 1002 \
-s /bin/ksh -c "Test FAQ User" -m -g guest testuser

Hinweis: Stelle sicher, dass du ' ' (einfache Anführungszeichen) um die Passwortzeichenkette legst, nicht etwa " " (doppelte Anführungszeichen), da die Shell diese vor dem Übergeben an user(8) auswerten würde. Stelle zusätzlich dazu sicher, dass du Option -m übergibst, wenn du möchtest, dass das Heimatverzeichnis vom Benutzer angelegt und die Dateien aus /etc/skel herüberkopiert werden.

Um zu sehen, ob der Benutzer korrekt angelegt wurde, können wir viele verschiedene Werkzeuge nutzen. Unterhalb stehen ein paar Kommandos, du du benutzen kannst, um schnell zu überprüfen, ob alles richtig gemacht wurde.

$ ls -la /home
total 14
drwxr-xr-x   5 root      wheel   512 May 12 14:29 .
drwxr-xr-x  15 root      wheel   512 Apr 25 20:52 ..
drwxr-xr-x  24 ericj     wheel  2560 May 12 13:38 ericj
drwxr-xr-x   2 testuser  guest   512 May 12 14:28 testuser
$ id testuser
uid=1002(testuser) gid=31(guest) groups=31(guest)
$ finger testuser
Login: testuser                         Name: Test FAQ User
Directory: /home/testuser               Shell: /bin/ksh
Last login Sat Apr 22 16:05 (EDT) on ttyC2
No Mail.
No Plan.

Zusätzlich zu diesen Kommandos bietet user(8) sein eigenes Werkzeug, um Benutzercharakteristiken anzuzeigen, welches userinfo(8) genannt wird.

$ userinfo testuser
login   testuser
passwd  *
uid     1002
groups  guest
change  Wed Dec 31 19:00:00 1969
class
gecos   Test FAQ User
dir     /home/testuser
shell   /bin/ksh
expire  Wed Dec 31 19:00:00 1969

Benutzer löschen

Um Benutzer mit Kommandos der user(8)-Hierarchie zu entfernen, wirst du userdel(8) nutzen müssen. Dies ist ein sehr einfaches, aber dennoch sehr nützliches, Kommando. Um den Benutzer zu löschen, der im letzten Beispiel angelegt wurde, verwende einfach:

# userdel -r testuser

Beachte die Option -r, die angegeben werden muss, wenn du möchtest, dass das Heimatverzeichnis des Benutzers ebenfalls gelöscht werden soll. Als Alternative dazu kannst du statt -r auch -p angeben, wodurch der Account des Benutzers gesperrt wird, aber keine Informationen gelöscht werden.

10.10 - Wie erzeugt man ein Benutzerkonto, das nur für FTP genutzt werden kann?

Es gibt ein paar Wege, das zu bewerkstelligen, aber ein sehr häufig genutzter Weg ist, /usr/bin/false in /etc/shells einzufügen. Wenn du dann die Shell eines Benutzers auf /usr/bin/false setzt, wird dieser Benutzer nicht in der Lage sein, sich interaktiv anzumelden, kann aber noch die FTP-Möglichkeiten nutzen. Du möchtest vielleicht ebenfalls den Zugriff beschränken, indem du Benutzer unter ftpd in ihre Heimatverzeichnisse einsperrst.

10.11 - Quotas einrichten

Quotas werden genutzt, um den Speicher auf den Platten zu begrenzen, der den Benutzern zur Verfügung steht. Das kann insbesondere dann sinnvoll sein, wenn du Ressourcen begrenzen musst. Quotas können für Benutzer und/oder für Gruppen gesetzt werden.

Der erste Schritt, um Quotas einzurichten, ist sicherzustellen, dass »option QUOTA« sich in deiner Kernelkonfiguration befindet. Diese Option ist im GENERIC-Kernel. Hiernach musst du die Dateisysteme in /etc/fstab markieren, für die Quotas aktiviert sein sollen. Die Schlüsselwörter userquota und groupquota sollten verwendet werden, um jedes einzelne Dateisystem zu markieren, für die Quotas aktiviert sein sollen. Standardmäßig werden die Dateien quota.user und quota.group im Root der Dateisysteme erstellt, um die Quota-Informationen zu erfassen. Dieser Standard kann geändert werden, indem der Dateiname mit der Quota-Option in /etc/fstab angegeben wird, wie zum Beispiel userquota=/var/quotas/quota.user. Hier ist ein Beispiel für eine /etc/fstab, die ein Dateisystem mit aktivierten userquotas hat und die Quotadatei sich an einer nicht standardmäßigen Stelle befindet:

/dev/wd0a / ffs rw,userquota=/var/quotas/quota.user 1 1

Jetzt ist es Zeit, um die Quotas für die Benutzer einzurichten. Verwende hierfür das Werkzeug edquota(8). Ein einfacher Aufruf wäre »edquota <user>«. edquota(8) wird vi(1) nutzen, um die Quotas zu ändern, es sei denn, die Umgebungsvariable EDITOR wurde auf einen anderen Editor gesetzt. Zum Beispiel:

# edquota ericj

Dies wird dir eine Ausgabe geben, die ähnlich dieser ist:

Quotas for user ericj:
/: KBytes in use: 62, limits (soft = 0, hard = 0)
        inodes in use: 25, limits (soft = 0, hard = 0)

Um Begrenzungen hinzuzufügen, editiere sie, um Resultate wie diese hier zu erhalten:

Quotas for user ericj:
/: KBytes in use: 62, limits (soft = 1000, hard = 1050)
        inodes in use: 25, limits (soft = 0, hard = 0)

Beachte, dass die Quota-Allokierung auf 1-k-Blöcke gesetzt ist. In diesem Fall wurde das Softlimit auf 1000 k gesetzt und das Hardlimit auf 1050 k. Ein Softlimit ist eine Begrenzung, bei der der Benutzer lediglich gewarnt wird, dass er sie überschritten hat und weiterhin über ihr liegt, bis ihre Schonzeit vorbei ist und ihre Plattennutzung wieder unter diese Grenze reduziert wird. Schonzeiten können mit edquota(8) und der Option -t gesetzt werden. Wenn die Schonzeit vorbei ist, dann wird das Softlimit als Hardlimit angesehen. Dies führt normalerweise zu Allokierungsfehlern.

Nun, da die Quotas gesetzt sind, musst du die Quotas aktivieren. Um dies zu tun, verwende quotaon(8). Zum Beispiel:

# quotaon -a

Dies wird durch /etc/fstab gehen und alle Dateisysteme mit Quota-Optionen aktivieren. Nun, da Quotas eingerichtet sind und laufen, kannst du sie mit quota(1). betrachten. Die Nutzung von einem Kommando wie »quota <user>« gibt dir die Informationen über einen Benutzer. Wenn es mit keinen Argumenten aufgerufen wird, wird das quota(1)-Kommando deine Quota-Statistiken ausgeben. Zum Beispiel:

# quota ericj

Wird zu einer Ausgabe führen, die dieser ähnlich ist:

Disk quotas for user ericj (uid 1001):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
              /      62    1000    1050              27       0       0

Standardmäßig werden Quotas, die in /etc/fstab gesetzt sind, automatisch beim Hochfahren aktiviert. Um sie auszuschalten, verwende:

# quotaoff -a

10.12 - KerberosV-Clients und -Server einrichten

OpenBSD beinhaltet KerberosV als vorinstallierte Komponente des Standardsystems.

Für weitere Informationen über KerberosV rufe folgendes Kommando von deinem OpenBSD-System aus auf:

# info heimdal

10.13 - Anonymous-FTP-Dienste einrichten

Anonymous FTP erlaubt Benutzern ohne Accounts, auf Dateien auf deinem Computer über das »File Transfer Protocol« zuzugreifen. Dies hier gibt einen Überblick über das Einrichten eines Anonymous-FTP-Servers, dem Aufzeichnen (logging) dieses Servers etc.

Das FTP-Benutzerkonto hinzufügen

Um beginnen zu können, musst du einen ftp-Account auf deinem System haben. Dieser Account sollte kein nutzbares Passwort haben. Hier werden wir das Login-Verzeichnis auf /home/ftp setzen, aber du kannst es wohin du willst legen. Wenn Anonymous FTP genutzt wird, wird der FTP-Daemon sich selbst in das Heimatverzeichnis des ftp-Users chrooten. Um mehr hierüber zu erfahren, lies die ftpd(8)- und chroot(2)-Handbuchseiten. Hier ist ein Beispiel, wie man den Benutzer ftp hinzufügt. Ich werde das unter Verwendung von adduser(8) machen. Wir müssen ebenfalls /usr/bin/false in unsere /etc/shells hinzufügen, dies ist die Shell, die wir dem ftp-User zuteilen. Dies erlaubt ihnen nicht, sich einzuloggen, selbst wenn wir ihm ein leeres Passwort geben. Um das zu tun, kannst du einfach Folgendes ausführen:

echo /usr/bin/false >> /etc/shells
Hiernach ist alles vorbereitet, sodass der ftp-Benutzer hinzugefügt werden kann:
# adduser
Use option ``-silent'' if you don't want to see all warnings and questions.

Reading /etc/shells
Check /etc/master.passwd
Check /etc/group

Ok, let's go.
Don't worry about mistakes. I will give you the chance later to correct any input.
Enter username []: ftp
Enter full name []: anonymous ftp
Enter shell csh false ksh nologin sh [ksh]: false
Uid [1002]: Enter
Login group ftp [ftp]: Enter
Login group is ``ftp''. Invite ftp into other groups: guest no
[no]: no
Login class authpf daemon default staff [default]: Enter
Enter password []: Enter
Set the password so that user cannot logon? (y/n) [n]: y

Name:        ftp
Password:    ****
Fullname:    anonymous ftp
Uid:         1002
Gid:         1002 (ftp)
Groups:      ftp
Login Class: default
HOME:        /home/ftp
Shell:       /usr/bin/false
OK? (y/n) [y]: y
Added user ``ftp''
Copy files from /etc/skel to /home/ftp
Add another user? (y/n) [y]: n
Goodbye!

Verzeichniseinrichtung

Neben dem Benutzer wurde hiermit das Verzeichnis /home/ftp angelegt. Das ist genau das, was wir wollen, aber es müssen einige Änderungen vorgenommen werden, die wir machen müssen, um es für Anonymous FTP bereit zu machen. Es sei wieder erwähnt, dass diese Änderungen in der ftpd(8)-Handbuchseite beschrieben werden.

Du musst nicht ein Verzeichnis namens /home/ftp/usr oder /home/ftp/bin erstellen.

Beachte, dass alle Verzeichnisse Root gehören sollten. Hier ist eine Liste, wie die Verzeichnisse nach der Erstellung aussehen sollten.

# pwd
/home
# ls -laR ftp
total 5
dr-xr-xr-x  5 root  ftp    512 Jul  6 11:33 .
drwxr-xr-x  7 root  wheel  512 Jul  6 10:58 ..
dr-x--x--x  2 root  ftp    512 Jul  6 11:34 etc
dr-xr-xr-x  2 root  ftp    512 Jul  6 11:33 pub

ftp/etc:
total 43
dr-x--x--x  2 root  ftp    512 Jul  6 11:34 .
dr-xr-xr-x  5 root  ftp    512 Jul  6 11:33 ..
-r--r--r--  1 root  ftp    316 Jul  6 11:34 group
-r--r--r--  1 root  ftp  40960 Jul  6 11:34 pwd.db

ftp/pub:
total 2
dr-xr-xr-x  2 root  ftp  512 Jul  6 11:33 .
dr-xr-xr-x  5 root  ftp  512 Jul  6 11:33 ..

Den Server und das Aufzeichnen starten

Du kannst ftpd entweder über inetd(8) oder von den rc-Skripten aus starten. Diese Beispiele zeigen, wie unser Daemon von inetd.conf aus aufgerufen wird. Zuerst müssen wir uns mit den Optionen für ftpd vertraut machen. Der Standardeintrag in /etc/inetd.conf sieht wie folgt aus:

ftp             stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -US

Hier wird ftpd mit -US augerufen. Hiermit werden alle anonymen Verbindungen unter /var/log/ftpd aufgezeichnet und zusammenwirkende Verbindungen unter /var/run/utmp. Somit können diese Sitzungen per who(1) angesehen werden. Für einige gilt, dass sie nur einen Anonymous-Server starten wollen und somit ftp für Benutzer deaktivieren sollten. Rufe hierzu ftpd mit der Option -R auf. Hier ist eine Zeile, die ftpd so startet, dass nur anonyme Verbindungen zugelassen werden. Es verwendet ebenfalls -ll, wodurch jede Verbindung mit syslog aufgezeichnet wird, zusätzlich zu den FTP-Kommandos get, retrieve etc.

ftp             stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -llUSA

Hinweis: Wessen FTP-Server mit HOHER Netzauslastung zu rechnen haben, sollte ftpd nicht von inetd.conf aus starten. Die beste Option in einem solchen Fall ist, die Zeile des ftpd in der inetd.conf auszukommentieren und ftpd aus rc.conf.local heraus zu starten. Dies wird den ftpd als Dämon starten, was viel weniger Mehraufwand mit sich bringt, als wenn der Start von inetd aus erfolgt. Hier ist eine Beispielzeile, wenn der Start von rc.conf.local aus erfolgt.

ftpd_flags="-DllUSA"           # for non-inetd use: ftpd_flags=""

Dies funktioniert selbstverständlich nur, wenn du ftpd aus /etc/inetd.conf rausgenommen und inetd veranlasst hast, die Konfigurationsdatei neu einzulesen.

Um anonyme Verbindungen zu erlauben, ist es ist nicht nötig, weitere, zusätzliche Startoptionen zu übergeben. Die vorangehenden Schritte des Erzeugens des Benutzers »ftp«, und der Konfiguration der relevanten Verzeichnisse mit den korrekten Rechten ist genug. Auf der anderen Seite ist es nicht nötig, alles rückgängig zu machen, wenn man anonyme Verbindungen nicht länger gestatten will. Starte ftpd einfach neu, einschließlich der Option -n. Anonyme Verbindungen sind in diesem Fall nicht länger möglich.

Andere relevante Dateien

10.14 - In ftpd(8) Benutzer in ihre Heimatverzeichnisse einsperren.

Standardmäßig können Benutzer, wenn sie sich über ftp angemeldet haben, in jedes Verzeichnis auf deinem Dateisystem wechseln, wenn sie die benötigten Rechte dafür haben. In einigen Fällen kann es sein, dass das nicht erwünscht ist. Es ist möglich, einzuschränken, was Benutzer über die FTP-Sitzung sehen können, indem man sie in ihr Heimatverzeichnis einsperrt.

Wenn du nur in Chroot eingeschlossene FTP-Anmeldungen erlauben willst, verwende die Option -A mit ftpd(8).

Wenn du diese Begrenzung gezielter einsetzen willst, macht OpenBSDs »login capability infrastructure« zusammen mit ftpd(8) das recht einfach.

Benutzer, die sich in einer Login-Klasse mit der gesetzten Variable ftp-chroot befinden, werden automatisch in Chroot eingeschlossen. Zusätzlich kannst du einen Benutzernamen zur Datei /etc/ftpchroot hinzufügen, damit Chroot auch für diese Benutzer genutzt wird. Ein Benutzer muss nur in einer dieser Orte aufgelistet werden.

10.15 - Korrekturroutinen in OpenBSD einfügen.

Selbst unter OpenBSD treten Fehler auf. Einige Fehler können zu Stabilitätsproblemen führen (z. B. dass etwas dazu führen kann, dass etwas nicht mehr wie gewünscht funktioniert). Andere Fehler könnten zu Sicherheitsproblemen führen (wodurch Andere deinen Computer auf nicht beabsichtigte und nicht authorisierte Weise »benutzen« können). Wenn ein kritischer Fehler gefunden wurde, wird die Korrektur in den -current-Quelltextbaum hinzugefügt und Korrekturroutinen für die unterstützten Releases von OpenBSD bereitgestellt. Diese Korrekturroutinen werden auf der Errata-Webseite aufgelistet, wo sie in »gemeinsame« Errata, die für alle Plattformen gelten, und in solche, die nur für eine oder mehrere, nicht jedoch für alle Plattformen gelten, unterteilt werden.

Bedenke jedoch, dass für neue Eigenschaften von, oder zusätzlichen Hardwaresupport für OpenBSD keine Korrekturroutinen veröffentlicht werden, und somit nur für wichtige Stabilitäts- oder Sicherheitskorrekturen veröffentlicht werden, die sofort auf den betroffenen Systemen eingespielt werden sollten (was meist NICHT für alle Systeme gilt, je nach ihrem Anwendungsgebiet).

Es existieren drei Wege, wie du dein System mit korrigiertem Code aktualisieren kannst:

Noch einmal: Das korrigieren von individuellen Dateien ist nicht immer einfach, denke also gründlich darüber nach, ob du nicht dem -stable Zweig (oder »patch-branch«) von OpenBSD folgen willst. Das Kombinieren und Anpassen von Korrekturlösungen kann durchgeführt werden, wenn man weiß, wie alles funktioniert, aber neue Benutzer sollten eine Methode auswählen und bei dieser bleiben.

Wie unterscheiden sich die Errata-Korrekturen von dem, was sich im CVS-Baum befindet?

Alle Korrekturroutinen, die auf der Errata-Webseite landen, sind solche, die direkt auf den Quelltextbaum vom angegebenen Release abgestimmt sind. Korrekturen, die für den aktuellen CVS-Baum sind, beinhalten auch andere Änderungen, die auf einem Release-System nicht gewollt sind. Dies ist wichtig: Wenn du einen Schnappschuss installierst hast, eine Arbeitskopie des Quelltextbaums zu jener Zeit gemacht hast, als du den Schnappschuss heruntergeladen hast, und dann versuchst, eine freigegebene Korrekturroutine zu verwenden, wirst du eventuell feststellen, dass diese Korrektur nicht anwendbar ist, da der Quelltext sich vermutlich geändert hat.

Korrekturroutinen anwenden.

Korrekturroutinen (»patches«) für das OpenBSD-Betriebssystem werden als »Unified diffs« verteilt; dies sind Textdateien, die Unterschiede zum ursprünglichen Quelltext beschreiben. Sie werden NICHT in Binärform verteilt. Das heisst das zur Einspielung der Korrekturroutine der Quelltext der RELEASE-Version auf dem System vorhanden sein muss. Im Allgemeinen gilt, dass es ratsam ist, sich den kompletten Baum des Quelltexts zu besorgen, bevor man eine Korrekturroutine anwendet. Wird eine Veröffentlichung von einem offiziellen CD-ROM-Set benutzt, so ist der Quelltext in Dateiform auf Scheibe 3 verfügbar, aber die Dateien können auch von den FTP-Servern heruntergeladen werden. Wir nehmen an im Folgenden an, dass ein kompletter Baum vorliegt.

Für unser Beispiel hier betrachten wir die Korrektur 001 für OpenBSD 3.6, der sich mit dem st(4)-Treiber befasst, der für die Verarbeitung von Bandlaufwerken zuständig ist. Ohne diese Korrektur war die Wiederherstellung von Sicherungsdaten recht schwierig. Leute, die ein Bandlaufwerk nutzten, brauchten diesen »Patch«, solche ohne ein Bandlaufwerk jedoch hatten keinen besonderen Bedard, ihn zu installieren. Lass uns einen Blick auf die Korrekturroutine werfen:

# more 001_st.patch
Apply by doing:
        cd /usr/src
        patch -p0 < 001_st.patch

Rebuild your kernel.

Index: sys/scsi/st.c
===================================================================
RCS file: /cvs/src/sys/scsi/st.c,v
retrieving revision 1.41
retrieving revision 1.41.2.1
diff -u -p -r1.41 -r1.41.2.1
--- sys/scsi/st.c       1 Aug 2004 23:01:06 -0000       1.41
+++ sys/scsi/st.c       2 Nov 2004 01:05:50 -0000       1.41.2.1
@@ -1815,7 +1815,7 @@ st_interpret_sense(xs)
        u_int8_t skey = sense->flags & SSD_KEY;
        int32_t info;

-       if (((sense->flags & SDEV_OPEN) == 0) ||
+       if (((sc_link->flags & SDEV_OPEN) == 0) ||
            (serr != 0x70 && serr != 0x71))
                return (EJUSTRETURN); /* let the generic code handle it */
Wie du sehen kannst, befindet sich am Anfang der Korrektur eine kurze Einweisung, wie er eingefügt werden kann. Wir nehmen an, dass du ihn in das Verzeichnis /usr/src gelegt hast, wodurch in diesem Fall folgende Schritte gemacht werden müssen:
# cd /usr/src
# patch -p0 < 001_st.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Apply by doing:
|        cd /usr/src
|        patch -p0 < 001_st.patch
|
|Rebuild your kernel.
|
|Index: sys/scsi/st.c
|===================================================================
|RCS file: /cvs/src/sys/scsi/st.c,v
|retrieving revision 1.41
|retrieving revision 1.41.2.1
|diff -u -p -r1.41 -r1.41.2.1
|--- sys/scsi/st.c      1 Aug 2004 23:01:06 -0000       1.41
|+++ sys/scsi/st.c      2 Nov 2004 01:05:50 -0000       1.41.2.1
--------------------------
Patching file sys/scsi/st.c using Plan A...
Hunk #1 succeeded at 1815.              <-- Look for this message!
done
Achte auf die obrige Nachricht "Hunk #1 succeeded". Diese weist darauf hin, dass die Korrektur erfolgreich eingefügt wurde. Viele Korrekturen sind viel komplexer als diese hier und werden viele Hunks und mehrere Dateien miteinbeziehen, daher solltest du in einem solchen Fall sicherstellen, dass alle Hunks für alle Dateien erfolgreich waren. Wenn sie es nicht waren, heißt das normalerweise, dass dein Quelltextbaum sich in irgendeiner Weise von dem Quelltextbaum der Veröffentlichung unterscheidet, von welchem aus die Korrekturroutine erzeugt wurde, oder dass du den Anweisungen nicht gründlich gefolgt bist, oder aber die Korrekturroutine verunstaltet wurde. Korrekturen sind sehr sensibel gegenüber Leerstellen - Copy&Paste von deinem Browser wird oft Tabulatoren in Leerstellen umwandeln oder auf andere Art und Weise die Leerstellen der Datei modifizieren, wodurch er nicht eingefügt werden kann.

An diesem Punkt kannst du wie gewohnt den neuen Kernel erzeugen und installieren, und danach das System neu starten.

Nicht alle Korrekturroutinen sind für den Kernel. In einigen Fällen musst du individuelle Werkzeuge neuerzeugen. In anderen Fällen musst du alle statisch gelinkten Werkzeuge neukompilieren, da sich eine Bibliothek änderte. Folge den Anweisungen am Anfang der Korrektur, und wenn du dir unsicher bist, erstelle das gesamte System neu.

Korrekturen, die für bestimmte Systeme unbedeutend sind, müssen nicht mit eingefügt werden - normalerweise. Wenn du zum Beispiel kein Bandlaufwerk auf deinem System hattest, würdest du von oben gezeigter Korrektur nicht profitieren. Man nimmt jedoch an, dass die Korrekturroutinen »in der richtigen Reihenfolge« eingefügt werden - es ist möglich, dass eine spätere Routine von einer vorherigen abhängig ist. Sei dir dessen bewusst, wenn du dich dafür entscheidest, bei der Installation von Korrekturen ,wählerisch' zu sein, so dass du, wenn du dir unsicher bist, alle installieren solltest.

10.16 - Wie geht das mit dem chroot()-Apache?

Unter OpenBSD wird der Apache-Server httpd(8) standardmäßig in einer chroot(2) eingeschlossen. Obwohl dies ein ungeheurer Sicherheitsvorteil ist, kann das zu Problemen führen, wenn man nicht darauf vorbereitet ist.

Was ist ein chroot?

Eine in chroot(2) eingeschlossene Anwendung wird in ein bestimmtes Verzeichnis eingesperrt und ist nicht in der Lage, im Rest der Verzeichnisstruktur herumzuwandern, da es das Verzeichnis als / (Root-)Verzeichnis sieht. Im Fall von httpd(8) startet das Programm, öffnet seine Logdateien, greift auf seine TCP-Ports zu (obwohl es zu diesem Zeitpunkt noch keine Daten akzeptiert) und liest seine Konfiguration. Als nächstes sperrt es sich in /var/www ein und lässt seine Privilegien fallen; erst dann akzeptiert es Anfragen. Dies bedeutet, dass alle Dateien, die von Apache zur Verfügung gestellt und benutzt werden, sich im Verzeichnis /var/www befinden müssen. In der Standardkonfiguration von OpenBSD kann der Apache-User www die Dateien im /var/www-Verzeichnis nur lesen. Dies hilft der Sicherheit ungemein - sollte es ein Sicherheitsproblem mit Apache geben, wird der Schaden auf ein einziges Verzeichnis begrenzt sein, dessen Rechte nur das Lesen erlauben und auch keine Ressourcen hat, die jemand ausnutzen könnte.

Was bedeutet das für den Administrator?

Grob gesagt ist chroot(2)ing Apache etwas, das nicht standardmäßig unter anderen Betriebssystemen eingesetzt wird. Viele Applikationen und Systemkonfigurationsdateien werden in einem chroot(2) ohne Anpassungen nicht funktionieren. Zusätzlich muss erwähnt werden, dass sich Sicherheit und Komfort als Ziel gegenseitig ausschließen. OpenBSDs Implementation von Apache gefährdet die Sicherheit nicht, um Funktionen oder »Bequemlichkeiten« zu ermöglichen.

In einigen Fällen können die Applikation oder die Konfiguration geändert werden, damit sie im chroot(2) läuft. In anderen Fällen wirst du diese Funktionalität einfach unter Verwendung der Option -u mit httpd(8) in der /etc/rc.conf.local abstellen.

Beispiel einer Einschließung einer Applikation in chroot(2): wwwcount

Als ein Beispiel für die Vorgehensweise, die genutzt werden kann, um eine Applikation in einer Chroot einzuschließen, werden wir einen Blick auf wwwcount werfen, einem einfachen Webseitenzähler, der über die Portierungen verfügbar ist. Obwohl dieses ein sehr effektives Programm ist, weiß es nichts über den in chroot(2) eingeschlossenen Apache und wird in seiner standardmäßigen Konfiguration nicht in chroot(2) funktionieren.

Zuerst werden wir das wwwcount-Paket installieren. Wir konfigurieren und testen es und stellen fest, dass es nicht funktionieren will und dass wir eine Apache-Nachricht erhalten, die »Internal Server Error« sagt. Der erste Schritt ist das Beenden und Neustarten von Apache mit der Option -u, um sicherzustellen, dass das Problem im chroot(2) liegt und nicht in der Systemkonfiguration.

# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd -u
Hiernach sehen wir, dass der Zähler einwandfrei läuft, zumindest nachdem wir die Dateirechte umgestellt haben, sodass Apache (und die CGIs, die er ausführt) in die Dateien schreiben können, die gehalten werden. Somit haben wir ganz sicher ein Problem mit chroot, sodass wir Apache wieder beenden und neustarten können, dieses Mal wieder mit standardmäßigem Chroot:
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd

Ein guter Anfangspunkt wäre anzunehmen, dass wwwcount einige Bibliotheken und andere Dateien benötigt, die im chroot nicht vorliegen. Wir können das Kommando ldd(1) benutzen, um alle dynamischen Objektabhängigkeiten festzustellen, die das CGI hat:

# cd /var/www/cgi-bin/
# ldd Count.cgi
Count.cgi:
        Start    End      Type Open Ref GrpRef Name
        1c000000 3c007000 exe  1    0   0      /var/www/cgi-bin/Count.cgi
        0c085000 2c0be000 rlib 0    1   0      /usr/lib/libc.so.57.0
        08713000 08713000 rtld 0    1   0      /usr/libexec/ld.so
Ok, hier ist ein Problem, zwei Dateien sind in der chroot(2)-Umgebung nicht verfügbar. Wir kopieren sie also hinein:
# mkdir -p /var/www/usr/lib /var/www/usr/libexec
# cp /usr/lib/libc.so.57.0 /var/www/usr/lib
# cp /usr/libexec/ld.so /var/www/usr/libexec
und testen den Zähler wieder.

Nun ja, jetzt läuft das Programm zumindest und gibt uns Fehlermeldungen direkt: "Unable to open config file for reading". Fortschritt, aber wir sind noch nicht fertig. Die Konfigurationsdatei ist normalerweise in /var/www/wwwcount/conf, aber innerhalb der chroot-Umgebung, wäre das /wwwcount/conf. Unsere Möglichkeiten sind nun entweder das Neukompilieren vom Programm, sodass es mit den Dateien arbeitet, wo sie jetzt sind, oder aber das Verschieben der Dateien. Da wir vom Paket aus installiert haben, werden wir die Dateien verschieben. Um die gleiche Konfig mit sowie ohne chroot(2) verwenden zu können, benutzen wir einen symbolischen Link:

# mkdir -p /var/www/var/www
# cd /var/www/var/www
# ln -s ../../wwwcount wwwcount
Beachte, dass dieser symbolische Link so erstellt wurde, dass er innerhalb vom chroot läuft. Und wir werden wieder einmal testen ... und stellen fest, dass es noch ein Problem gibt. Nun beschwert sich wwwcount darüber, dass es die Stripimage-Dateien, die zum Anzeigen von Nachrichten genutzt werden, nicht finden kann. Nach einer kurzen Suche finden wir heraus, dass sich diese unter /usr/local/lib/wwwcount befinden, sodass wir diese ebenfalls ins chroot kopieren müssen.
# tar cf - /usr/local/lib/wwwcount | (cd /var/www; tar xpf - )
wir testen wieder ... und es läuft!

Beachte, dass wir wirklich nur die Dateien kopiert haben, die absolut notwendig sind, um das Programm ausführen zu können. Generell gilt, dass die Mindestanzahl an Dateien in die Chroot-Umgebung kopiert werden sollte, um das Programm ausführen zu können.

Sollte ich auf die Chroot-Funktion zurückgreifen?

Im obigen Beispiel war das Programm zwar recht einfach, doch hatten wir unterschiedlichste Probleme, bis es lief.

Nicht jede Anwendung kann oder sollte in einer Chroot(2)-Umgebung laufen.

Das Ziel ist ein sicherer Webserver. Chroot(2)ing ist nur ein Teil des Weges, um dieses Ziel zu erreichen - und nicht das Ziel selbst. Denke daran, dass die Standardkonfiguration von OpenBSDs Apache in chroot(2) vorsieht, dass der Benutzer des httpd(8)-Programms keine anderen Programme ausführen, keine Dateien verändern und auch nicht die Identität des Benutzers ändern kann. Wenn du diese Einschränkungen lockerst, so verringerst du die Gesamtsicherheit - mit oder ohne chroot.

Einige Applikationen sind recht einfach und chroot(2) macht für sie Sinn. Andere sind recht komplex und sind die Anstrengungen, sie in ein chroot zu zwingen, nicht wert, oder aber du wirst den kompletten Nutzen der chroot(2)-Umgebung verloren haben, wenn du genügend Dateien vom System kopiert hast. Zum Beispiel muss das Programm OpenWebMail auf das Mailverzeichnis und auf das Heimatverzeichnis des Benutzers zugreifen können sowie die Möglichkeit haben, Programme mit den Rechten aller Anwender auszuführen. Ein Versuch, diese Anwendungen in eine Chroot-Umgebung zu sperren wäre völlig sinnlos, da hiermit alle Vorzüge einer solchen Umgebung umgangen werden. Selbst Applikationen, die so einfach wie der zuvor beschrieben Counter sind, müssen auf die Platte schreiben (um den Zähler zu speichern), sodass einige Vorteile vom chroot(2) verloren gegangen sind.

Des Weiteren ist es nutzlos, chroot(2) für Programme umzusetzen, die Rootrechte benötigen. Root kann generell aus einer Chroot(2)-Umgebung ausbrechen.

Vergiss eine Sache nicht: Wenn die Einrichtung einer Chroot-Umgebung sehr schwer war, so wirst du vielleicht der Versuchung erliegen, das System seltener zu aktualisieren/upgraden als du solltest. Dies wiederum würde dazu führen, dass dein System UNSICHERER ist als ein System, das zwar auf Chroot verzichtet, dafür aber leichter zu verwalten ist.

10.17 - Kann ich die Rootshell ändern?

Es wird manchmal gesagt, dass man niemals die Rootshell ändern dürfte, doch gibt es unter OpenBSD nichts, was dagegen spricht.

Die Standardshell für root ist unter OpenBSD ksh.

Eine geschichtliche Unix-Richtlinie ist, nur statisch kompilierte Shells für root zu benutzen, da im Fall des Singleuser-Modus andere als die root-Partitionen nicht gemountet werden und dynamisch gelinkte Shells nicht auf die Bibliotheken auf der /usr-Partition zugreifen können. Dies ist kein wirklich schlimmes Problem für OpenBSD, da das System dich nach einer Shell fragt, wenn es im Singleuser-Modus angekommen ist und der Standard sh ist. Die drei standardmäßigen Shells unter OpenBSD (csh, sh und ksh) sind alle statisch gelinkt und daher im Singleuser-Modus einsatzfähig.

10.18 - Was kann ich noch mit ksh machen?

Unter OpenBSD ist ksh pdksh, die »Public Domain Korn Shell«, und die gleiche Binary wie sh.

Anwender, die gerne bash benutzen, die oft unter Linux-Systemen genutzt wird, werden ksh als recht ähnlich einschätzen. Ksh(1) bietet die meisten häufig genutzten Funktionalitäten von bash, einschließlich der Tab-Erweiterung, Kommandozeileneditierung und History über die Pfeiltasten und STRG+A/STRG+E, um zum Anfang/Ende der Kommandozeile zu springen. Wenn andere Funktionalitäten der bash benötigt sind, kann bash selbst entweder über Pakete oder Portierungen installiert werden.

Der Kommandoprompt von ksh kann auf einfache Weise auf etwas informativeres geändert werden, weg vom standardmäßigen »$ «, indem die Variable PS1 gesetzt wird. Das Einfügen folgender Zeile:

export PS1='$PWD $ '
in deine /etc/profile führt beispielsweise zu folgendem Kommandoprompt:
/home/nick $
Siehe dir die Datei /etc/ksh.kshrc an, in der viele nützliche Funktionalitäten und Beispiele stehen, die in die .profile deines Benutzers geschrieben werden können.

OpenBSDs ksh(1) wurde mit einigen ,speziellen Zeichen' für den primären Promptstring (PS1) verbessert, sodass sie ähnlich zu denen in bash sind. Zum Beispiel:

\e - Füge eine ASCII-Escapesequenz ein.
\h - Der Hostname ohne Domänenname.
\H - Der gesamte Hostname, einschließlich Domänennamen.
\n - Füge einen Zeilenumbruch ein.
\t - Die aktuelle Zeit im 24-Stunden-Format HH:MM:SS.
\u - Der Benutzername vom aktuellen Anwender.
\w - Das momente Arbeitsverzeichnis. $HOME wird als ~ dargestellt.
\W - Der Basisname vom aktuellen Arbeitsverzeichnis.
\$ - Gibt # für root-User und $ für alle anderen aus.
(lies die Handbuchseite über ksh(1) für weitere Details, und noch vielen, vielen weiteren Spezialzeichen! Beachte bitte, dass das Zeichen $ innerhalb doppelter Anführungszeichen eine besondere Bedeutung hat. Pass also auf!)

Man könnte folgendes Kommando nutzen:

export PS1="\n\u@\H\n\w \\$ "
um einen recht ausgiebigen aber nützlichen Prompt zu bekommen.

10.19 - Verzeichnisdienste

OpenBSD kann sowohl für Server, als auch für Klienten von Datenbanken, die Benutzerausweisdaten, Gruppeninformationen und andere, mit dem Netzwerk in Zusammenhang stehende Daten enthalten, benutzt werden.

10.19.1 - Welche Verzeichnisdienste sind verfügbar?

Selbstverständlich könnte man vielerlei Verzeichnisdienste unter OpenBSD benutzen. Aber YP ist der Einzige, auf den direkt durch die Standard-C-Bibliotheksfunktionen wie getpwent(3), getgrent(3), gethostbyname(3) und so weiter zugegriffen werden kann. Werden also die Daten in einer YP-Datenbank vorgehalten, so müssen sie nicht in lokale Konfigurationsdateien wie master.passwd(5) übertragen werden, bevor man sie nutzen kann, zum Beispiel zur Authentifizierung eines Nutzers.

YP ist ein Verzeichnisdienst der mit Sun Microsystems' NIS (»Network Information System«, Netzwerkinformationssystem) kompatibel ist. Siehe yp(8) für einen Überblick über die verfügbaren Handbuchseiten. Vorsicht ist geboten, da einige Betriebssysteme Verzeichnisdienste enthalten, die zwar ähnliche Namen tragen, jedoch vollständig unverträglich sind, wie zum Beispiel NIS+.

Um andere Verzeichnisdienste als YP benutzen zu können, müssen entweder lokale Konfigurationsdateien aus dem Verzeichnis heraus erzeugt werden, oder aber es wird ein YP-Frontend benötigt. Zum Beispiel kann man die Portierung sysutils/login_ldap nutzen, wenn man den ersten Weg wählt, während der ypldap(8)-Dämon letzteren anbietet.

Für einige Anwendungen stellt die Synchronisation einer kleinen Anzahl Konfigurationsdateien unter einer Gruppe von Maschinen mit Hilfe von Werkzeugen wie cron(8), scp(1) oder rsync (in den Portierungen verfügbar) eine einfache und robuste Alternative zu einem vollwertigen Verzeichnisdienst dar.

10.19.2 - YP Sicherheitsüberlegungen

Aus Kompatibilitätsgründen sind alle sicherheitsrelevanten Merkmale, die in OpenBSDs Implementierung von YP eingebaut sind, standardmäßig ausgeschaltet. Selbst wenn sie alle eingeschaltet sind, gilt, dass das NIS-Protokoll immer noch inhärent unsicher ist, und zwar aus zwei Gründen: Alle Daten, einschließlich sensitiver Daten wie Passwort-Hashs, werden unverschlüsselt über das Netzwerk übertragen, und weder der Klient, noch der Server können zuverlässig die Identität des jeweils Anderen feststellen.

Deshalb sollte man prüfen, ob diese inhärenten Sicherheitslücken im gewünschten Kontext akzeptabel sind, bevor man einen YP-Server einrichtet. Insbesondere ist YP unzureichend, wenn potentielle Angreifer physischen Zugriff auf das Netzwerk besitzen. Jeder, der root-Zugriff auf irgendeinem Computer erlangen kann, der an YP-Verkehr transportierende Netzwerksegmente angeschlossen ist, kann sich an die YP-Domäne anbinden und Daten empfangen. In einigen Fällen besteht die Option, YP-Verkehr durch SSL- oder IPSec-Tunnel zu leiten, oder man kann erwägen, YP mit kerberos(8)-Authentifizierung zu verknüpfen.

10.19.3 - Einrichten eines YP-Servers

  1. Ein YP-Server bedient eine Gruppe von Klienten, die »domain« (Domäne) genannt wird. Man sollte zuerst einen Domänennamen aussuchen; es kann eine beliebige Zeichenfolge sein, und muss in keiner Weise etwas mit dem DNS-Domänennamen zu tun haben. Einen zufälligen Namen wie »Eepoo5vi« auszuwählen mag die Sicherheit marginal verbessern, obwohl dieser Effekt größtenteils auf Sicherheit aus Unklarheit zurückzuführen ist. Für den Fall, das mehrere unterschiedliche YP-Domänen zu verwalten sind, ist es wahrscheinlich besser, aussagekräftige Namen, wie »Verkauf«, »Marketing« oder »Entwicklung« zu wählen, um Systemadministrierungsfehlern durch Unklarheit vorzubeugen. Anzumerken ist außerdem, dass einige Versionen von SunOS verlangen, das der DNS-Domänenname des Hosts benutzt wird, sodass die Auswahl in einem Netzwerk mit solchen Hosts beschränkt sein könnte.

    Benutze das Dienstprogramm domainname(1), um den Domänennamen zu setzen, und schreibe ihn in die Datei defaultdomain(5), um ihn beim Systemstart automatisch setzen zu lassen.

    echo "puffynet" > /etc/defaultdomain
    domainname `cat /etc/defaultdomain`
    
  2. Initialisiere den YP-Server mit Hile des interaktiven Kommandos

    ypinit -m
    
    An diesem Punkt ist es nicht notwendig, »Slave-Server« zu spezifizieren. Um »Slave-Server« hinzuzufügen, kann man später erneut ypinit(8) mit Hilfe der Option -u aufrufen. Das Einrichten von zumindest einem »Slave-Server« für jede Domäne ist zweckmäßig, um Serviceunterbrechungen zu vermeiden, sollte der Master-Server jemals untergehen oder seine Netzwerkverbindung verlieren, insbesondere da Klienten, die versuchen, auf YP-Zuordnungen zuzugreifen, unbegrenzt blockieren, bis sie die angeforderte Antwort erhalten. Aus diesem Grunde führen YP Serviceunterbrechungen normalerweise dazu, dass Klienten komplett unbenutzbar sind, bis YP wieder einsatzbereit ist.
  3. Entscheide wo die Quelldateien gespeichert werden sollen, aus denen die YP-Zuordnungen generiert werden sollen. Die Serverkonfiguration unabhängig von der angedienten Konfiguration aufzubewahren, hilft zu kontrollieren, welche Informationen angedient werden und welche nicht, sodass das standardmäßige /etc oft nicht die beste Wahl ist.

    Die einzige Unbequemlichkeit, die sich aus der Änderung des Quellverzeichnisses ergibt, ist, das man nicht in der Lage ist, Benutzer und Gruppen mit Hilfe der Dienstprogramme user(8) und group(8) zu der YP-Domäne hinzuzufügen, zu entfernen oder zu modifizieren. Stattdessen muss man die Konfigurationsdateien mit einem Texteditor bearbeiten.

    Um das Quellverzeichnis zu definieren, editiere die Datei /var/yp/`domainname`/Makefile und ändere die Variable DIR, z. B.

    DIR=/etc/yp/src/puffynet
    
  4. Erwäge die Anpassung weiterer Variablen in /var/yp/`domainname`/Makefile. Siehe Makefile.yp(8) für Details.

    Zum Beispiel, selbst wenn das Standardquellverzeichnis /etc benutzt wird, so wird man normalerweise nicht alle Benutzerkonten und Gruppen, die auf dem Server existieren, auf allen Klienten benötigen. Insbesondere ist es oft vorteilhaft für die Sicherheit, wenn man das root-Konto nicht andient, und damit den Passwort-Hash von root geheim hält. Überprüfe die Werte von MINUID, MAXUID, MINGID und MAXGID, und passe sie deinen Bedürfnissen an.

    Wenn alle deine YP-Klienten unter OpenBSD oder FreeBSD laufen, so schließe die verschlüsselten Passwörter aus den passwd-Zuordnungen aus, indem du UNSECURE="" in /var/yp/`domainname`/Makefile setzt.

    Die bisherige Praxis des Editieren der Schablonendatei /var/yp/Makefile.yp wird nicht länger empfohlen. Änderungen an dieser Datei beeinflussen alle Domänen, die nach den Änderungen initialisiert werden, nicht aber solche, die vor den Änderungen initialisiert wurden, sodass dies ein auf jede Weise fehleranfälliger Weg ist: Man riskiert sowohl, das die angestrebten Änderungen nicht wirksam werden, als auch, sie zu vergessen, in welchem Fall sie später andere Domänen beeinflussen, für die sie nie gedacht waren.

  5. Erzeuge das Quellverzeichnis und fülle es mit den Konfigurationsdateien, die gebraucht werden. Siehe Makefile.yp(8) um zu lernen, welche YP-Zuordnungen welche Quelldateien benötigen. Für das Format der jeweiligen Quelldatei siehe passwd(5), group(5), hosts(5) und so weiter, und prüfe die Beispiele in /etc.

  6. Erzeuge die erste Version deiner YP-Zuordnungen mit Hilfe der Kommandos

    cd /var/yp
    make
    
    Im Moment sind Sorgen über Fehlermeldungen von yppush(8) unnötig. Der YP-Server wurde noch nicht gestartet.
  7. YP benutzt rpc(3) (»remote procedure calls«) um mit Klienten zu kommunizieren, sodass es nötig ist, portmap(8) zu ermöglichen. Um dies zu tun, editiere rc.conf.local(8) und setze portmap=YES. Dies wird beim nächsten Systemstart den »portmapper« starten. Man kann den Neustart durch manuelles Starten vermeiden:

    echo 'portmap_flags=""' >> /etc/rc.conf.local
    portmap
    
  8. Erwäge die Benutzung von entweder securenet(5) oder den ypserv.acl(5) Sicherheitsfeatures des YP-Serverdämonen. Aber beachte, dass diese beiden einzig IP-basierte Zugriffskontrolle bieten. Aus diesem Grund helfen sie nur solange, wie potentielle Angreifer weder physischen Zugriff auf die Hardware des Netzwerksegments haben, der den YP-Verkehr transportiert, noch root-Zugriff auf einem an diese Netzwerksegmente angeschlossenen Host besitzen.

  9. Abschließend starte den YP-Serverdämon:

    ypserv
    
    Solange das Verzeichnis /var/yp/`domainname` existiert, wird der Dämon bei einem Systemneustart automatisch gestartet werden.
  10. Um den neuen Server zu testen, erwäge, ihn zu seinem eigenen Klienten zu machen, indem du den Instruktionen des nächsten Abschnitts folgst. Sollte es nicht erwünscht sein, den Server mit seinen eigenen Zuordnungen zu benutzen, kann man den Klienten nach dem Test mit den folgenden Kommandos deaktivieren:

    pkill ypbind
    rm -rf /var/yp/binding
    
  11. Ist es erwünscht, Benutzern von Klienten die Änderung ihres Passworts zu erlauben, so muss yppasswdd(8) aktiviert werden:

    echo 'yppasswdd_flags="-d /etc/yp/src/puffynet"' >> /etc/rc.conf.local
    rpc.yppasswdd
    
    Für den Fall, dass das Quellverzeichnis beim standardmäßigen /etc belassen wurde, kann dafür einfach yppasswdd_flags="" benutzt werden.
  12. Präge dir ein, das jede Änderung an einer YP-Zuordnungs-Quelldatei eine Erneuerung der YP-Zuordnungen erfordert.

    cd /var/yp
    make
    
    Dies aktualisiert alle Datenbankdateien in /var/yp/`domainname`, mit einer Ausnahme: Die Datei ypservers.db, die alle mit einer Domäne assoziierten YP-Master und -»Slave-Server« auflistet, wird direkt von ypinit -m erzeugt und ausschließlich mit ypinit -u modifiziert. Sollte sie zufällig gelöscht worden sein, führe ypinit -u aus, um sie von Grund auf neu erzeugen zu lassen.

10.19.4 - Einrichten eines YP-Klienten

Einen YP-Klienten einzurichten, besteht aus zwei getrennten Teilen. Zuerst muss der YP-Klient-Dämon gestartet werden, der den Klienten an einen YP-Server bindet. Die folgenden Schritte zu vollenden wird es erlauben, Daten von einem YP-Server zu beziehen, allerdings werden diese Daten noch nicht vom System benutzt werden:
  1. Wie auf dem Server müssen zuerst der Domänenname gesetzt, und der »portmapper« aktiviert werden:

    echo "puffynet" > /etc/defaultdomain
    domainname `cat /etc/defaultdomain`
    echo 'portmap_flags=""' >> /etc/rc.conf.local
    portmap
    
  2. Es wird empfohlen, eine Liste aller YP-Server in der Konfigurationsdatei /etc/yp/`domainname` anzugeben. Anderenfalls wird der YP-Klient-Dämon Netzwerk-»Broadcasts« benutzen, um YP-Server für seine Domäne zu finden. Die Server explizit anzugeben ist sowohl robuster, als auch ein bißchen weniger offen für Attacken. Wurden keine »Slave-Server« eingerichtet, so schreibe einfach den Hostnamen des Master-Servers in /etc/yp/`domainname`.

  3. Der YP-Klient-Dämon ist ypbind(8). In manuell zu starten erzeugt das Verzeichnis /var/yp/binding, sodass er in Zukunft bei Systemneustarts automatisch gestartet wird.

    ypbind
    
  4. Wenn alles gut gegangen ist, sollte es möglich sein, den YP-Server mit Hilfe von ypcat(1) zu befragen und die »passwd«-Zuordnung zurückzubekommen.

    ypcat passwd
    bob:*:5001:5000:Bob Nuggets:/home/bob:/usr/local/bin/zsh
    ...
    
    Andere nützliche Werkzeuge zum »Debuggen« der YP-Konfiguration schliessen ypmatch(1) und yptest(8) ein.
Der zweite Teil der Konfiguration eines YP-Klienten beinhaltet das Editieren lokaler Konfigurationsdateien, sodass gewiss YP-Zuordnungen von den verschiedenen Systemkomponenten benutzt werden. Nicht alle Server dienen alle Standardzuordnungen an, die von den verschiedenen Betriebssystemen unterstützt werden, einige Server bieten zusätzliche nicht-standardisierte Zuordnungen, und man wird keineswegs gezwungen, all diese Zuordnungen auch zu benutzen. Welche der verfügbaren Zuordnungen benutzt oder nicht benutzt werden sollen, und für welche Zwecke sie benutzt werden sollen, all dies liegt vollständig im Ermessen des Systemadministrators des Klienten.

Für eine Liste aller Standard YP-Zuordnungen und ihrer standardmäßigen Nutzung, siehe Makefile.yp(8). Die üblichsten Fälle umfassen:

10.20 - Zeichensätze und Lokalisierung

OpenBSD benutzt standardmäßig den ASCII Zeichensatz. Es unterstützt ebenfalls die Zeichensätze Latin (ISO-8859-*), KOI-8, und Unicode (UTF-8).

10.20.1 - Konfiguration des aktiven Zeichensatzes

Um einen der erweiterten Zeichensätze zu benutzen, muss die Umgebungsvariable LC_CTYPE auf den Namen eines unterstützten »Locale« gesetzt werden. LC_CTYPE beeinflusst nur den Zeichensatz, der für Anwendungen verfügbar ist. Sie ändert nicht die Sprache, in der Anwendungen ihre Meldungen präsentieren.

Die Liste der unterstützten Locales gibt das folgende Kommando aus:

locale -a
Die Umgebungsvariable LC_CTYPE kann auf einem der folgenden Wege gesetzt werden:

Einige Dienstprogramme des Basissystems unterstützen UTF-8 zu diesem Zeitpunkt. Die meisten werden im UTF-8 »Locale« ASCII benutzen. Allerdings unterstützen viele Programme aus der Portierungs-Kollektion UTF-8.

UTF-8 kann auch mit bestimmten Anwendungen einzig dadurch benutzt werden, dass man sie innerhalb von uxterm(1) startet. Dies funktioniert selbst dann, wenn die Anmelde-Session keinen UTF-8-»Locale« benutzt.

Wenn in ein entferntes System mit Hilfe von ssh(1) eingeloggt wird, so wird die Umgebungsvariable LC_CTYPE nicht propagiert, und muss daher manuell auf denselben Wert wie im lokalen Terminal gesetzt werden.

10.20.2 - Ändern der in Anwendungen benutzten Sprache

Die Sprache, die für Anwendungsmeldungen benutzt wird, kann durch das Setzen der Umgebungsvariable LC_MESSAGES auf den Namen eines unterstützten »Locale« geändert werden. Dies kann auf dieselbe Weise geschehen, wie es für LC_CTYPE weiter oben beschrieben wurde. Sowohl LC_MESSAGES als auch LC_CTYPE sollten auf denselben Wert gesetzt werden.

Nur wenige Dienstprogramme des Basissystems unterstützen im Moment eine andere Sprache als Englisch. Jedoch unterstützen viele Programme der Portierungs-Kollektion lokalisierte Meldungen in vielerlei Sprachen. Sie greifen auf Englisch zurück, sollte die gewünschte Sprache nicht verfügbar sein.

[FAQ-Index] [Zum Kapitel 9 - Zu OpenBSD migrieren] [Zum Kapitel 11 - Das X Fenstersystem]


[back] www@openbsd.org
$OpenBSD: faq10.html,v 1.49 2013/11/01 18:04:04 ajacoutot Exp $