![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 9 - Zu OpenBSD migrieren] [Zum Kapitel 11 - Das X Window System]
Vorhandene Benutzer müssen per Hand zur Gruppe wheel hinzugefügt werden. Dies wird aus Sicherheitsgründen so gemacht und du solltest darauf achten, wem du diesen Zugriff erlaubst. Unter OpenBSD ist es Benutzern, die sich in der Gruppe wheel befinden, erlaubt, das Userland-Programm su(1) zu benutzen, um root zu werden. Benutzer, die nicht in wheel sind, können nicht su(1) nutzen. Hier ist ein Beispiel für einen /etc/group-Eintrag, in dem der Benutzer ericj in die Gruppe wheel platziert wird.
Wenn du einen neuen Benutzer mit adduser(8), hinzufügst, kannst du ihn in die Gruppe wheel platzieren, indem du bei der Frage "Invite user into other groups:" mit wheel antwortest. Damit wird er in /etc/group eingefügt, die in etwa so aussehen wird:
wheel:*:0:root,ericj
Wenn du nach einer Möglichkeit suchst, Benutzern eingeschränkten Zugriff auf die Superuser-Privilegien zu geben, ohne sie in die Gruppe wheel zu platzieren, verwende sudo(8).
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 - )
OpenBSD verwendet eine rc(8)-orientierte Startphase. Diese verwendet einige Schlüsseldateien.
Die Hauptdateien, auf die ein Systemadministrator zu achten hat, sind /etc/rc.conf (oder /etc/rc.conf.local), /etc/rc.local und /etc/rc.shutdown. Um einen Überblick darüber zu kriegen, was ausgeführt wird, wenn die rc(8)-Prozedur läuft, folgt nun eine Aufgabenliste:
Nachdem der Kernel geladen wurde, wird /etc/rc gestartet:
Die meisten Daemonen und Dienste, die mit OpenBSD standardmäßig ausgeliefert werden, können beim Hochfahren ganz einfach durch das Editieren der /etc/rc.conf-Konfigurationsdatei gestartet werden. Um zu beginnen, solltest du einen Blick auf die standardmäßige /etc/rc.conf-Datei werfen. Du wirst Zeilen wie diese sehen:
ftpd_flags=NO # for non-inetd use: ftpd_flags="-D"
Eine Zeile wie diese zeigt, dass ftpd nicht beim Systemstart aktiviert werden soll (zumindest nicht über rc(8), lies die Anonymous-FTP-FAQ, um mehr darüber zu erfahren). Unter allen Umständen hat jede Zeile einen Kommentar, der dir die Optionen zeigt, die nur für NORMALE Verwendung von diesem Daemon oder Dienst benötigt werden. Das bedeutet nicht, dass du diesen Daemon oder Dienst mit diesen Optionen aufrufen musst. Lies die entsprechende Manualseite, um zu sehen, wie du diesen Daemon oder Dienst so starten kannst, wie du möchtest. Hier ist zum Beispiel die Standardzeile, die zu httpd(8) gehört.
httpd_flags=NO # for normal use: "" (or "-DSSL" after reading ssl(8))
Hier kannst du offensichtlich erkennen, dass für den normalen Start von httpd keine Optionen notwendig sind. Daraus folgt, dass eine Zeile wie » httpd_flags=""« benutzt werden kann. Um aber httpd mit ssl zu aktiveren (Siehe auch SSL-FAQ oder ssl(8)), solltest du mit einer derartigen Zeile starten: httpd_flags="-DSSL".
Eine gute Vorgehensweise ist, niemals /etc/rc.conf selbst zu bearbeiten. Erstelle stattdessen die Datei /etc/rc.conf.local, kopiere einfach die Zeilen, die du ändern möchtest, von /etc/rc.conf und passe sie so an, wie du möchtest. Das macht zukünftige Upgrades einfacher - alle Änderungen befinden sich in dieser einen Datei.
Für andere Daemonen, die du vielleicht auf deinem System über Ports oder auf andere Wege installieren willst, solltest du die /etc/rc.local-Datei verwenden. Ich habe zum Beispiel einen Daemonen installiert, der unter /usr/local/sbin/daemonx liegt. Ich möchte, dass dieser beim Hochfahren startet. Ich würde einen Eintrag wie den folgenden in /etc/rc.local schreiben:
if [ -x /usr/local/sbin/daemonx ]; then
echo -n ' 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 local daemons: daemonx.
/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.
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 meistenen Daemonen veranlasst, ihre Konfigurationsdatei erneut einzulesen):
# kill -HUP `head -1 /var/run/sendmail.pid`
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 Ports-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:
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.
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)-Manualseite. 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)-Manualseite 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 1024
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 1024
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 -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.
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.
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
Reading /etc/login.conf
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 []: testuser
Enter full name []: Test FAQ User
Enter shell csh ksh nologin sh [sh]: ksh
Uid [1002]: Enter
Login group testuser [testuser]: guest
Login group is ``guest''. Invite testuser into other groups: guest no
[no]: no
Login class auth-defaults auth-ftp-defaults 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.
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:
Da user(8) nicht interaktiv ist, ist der einfachste Weg, um auf effiziente Art und Weise Benutzer hinzuzufügen, das adduser(8)-Kommando. Das tatsächliche Kommando /usr/sbin/user ist nur eine Oberfläche für die restlichen /usr/sbin/user*-Kommandos. Daher können die folgenden Kommandos unter Verwendung von user add oder useradd hinzugefügt werden; es ist deine Wahl, was du nutzen willst und ändert nichts an der Tatsache, wie die Kommandos genutzt werden.
In diesem Beispiel werden wir den gleichen Benutzer mit den gleichen Eigenschaften anlegen, wie wir es zuvor gemacht haben. useradd(8) ist viel einfacher zu nutzen, wenn du die standardmäßigen Einstellungen vor dem Hinzufügen eines Benutzers weißt. Diese Einstellungen befinden sich in /etc/usermgmt.conf 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
Die oben stehenden Einstellungen sind die, die genommen werden, wenn du keine anderen über die Kommandozeilenoptionen übergibst. In unserem Fall zum Beispiel möchten wir, dass der Benutzer zur Gruppe guest statt zur Gruppe users gehört. Ein weiteres Problem beim Hinzufügen der Benutzer ist, dass Passwörter in der Kommandozeile angegeben werden müssen. Dabei handelt es sich um das verschlüsselte Passwort, sodass du zuerst das encrypt(1)-Werkzeug nutzen musst, um das Passwort zu erstellen. 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.
# 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
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.
Es gibt ein paar Wege, das zu bewerkstelligen, aber ein sehr häufig genutzer 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.
Quotas werden genutzt, um den Speicher auf den Platten zu begrenzen, der den Benutzern zur Verfügung steht. Das kann insbesondere dann sinvoll 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:
/: blocks 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:
/: blocks 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
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
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.
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)-Manualseiten. 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
# adduser
Use option ``-silent'' if you don't want to see all warnings and questions.
Reading /etc/shells
Reading /etc/login.conf
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 tcsh zsh [sh]: false
Uid [1002]: Enter
Login group ftp [ftp]: Enter
Login group is ``ftp''. Invite ftp into other groups: guest no
[no]: no
Login class auth-defaults auth-ftp-defaults 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!
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)-Manualseite 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 ..
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: Leute, die FTP-Server mit HOHER Netzauslastung verwenden, sollten ftpd nicht von inetd.conf aus aufrufen. Die beste Möglichkeit ist, die Zeile für ftpd aus inetd.conf zu kommentieren und ftpd von rc.conf.local mit der Option -D aus zu starten. Somit wird ftpd als Daemon gestartet, was weniger zusätzliche Auslastung bewirkt 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="-D"
Dies funktioniert selbstverständlich nur, wenn du ftpd aus /etc/inetd.conf rausgenommen und inetd veranlasst hast, die Konfigurationsdatei neu einzulesen.
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.
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 Weise ,benutzen' können). Wenn ein kritischer Fehler gefunden wurde, wird die Korrektur in den -current-Source-Tree hinzugefügt und Patches für die unterstützten Releases von OpenBSD bereitgestellt. Diese Patches werden auf der Errata-Webseite aufgelistet, wo sie unter ,common'-Errata, die für alle Plattformen gilt, und in Errata unterteilt, die nur für eine oder mehr, aber nicht für alle, Plattformen gelten.
Bedenke jedoch, dass für Neuerungen für OpenBSD keine Patches erstellt werden, und somit nur für wichtige Stabilitäts- oder Sicherheitskorrekturen gemacht 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 gepatchtem Code aktualisieren kannst:
Alle Patches, die auf der Errata-Webseite landen, sind Patches, die direkt auf den Source-Tree vom angegebenen Release abgestimmt sind. Patches, die für den aktuellen CVS-Tree sind, beinhalten auch andere Ändungern, die auf einem Release-System nicht gewollt sind. Dies ist wichtig: Wenn du einen Snapshot installiert hast, einen Checkout für den Source-Tree zu der Zeit gemacht hast, als du den Snapshot heruntergeladen hast, und dann versuchst, einen freigegebenen Patch zu verwenden, wirst du eventuell feststellen, dass der Patch nicht anwendbar ist, da der Code sich vermutlich geändert hat.
Patches für das OpenBSD-Betriebssystem werden als Unified Diffs zur Verfügung gestellt, welche Textdateien sind, die die Unterschiede zum ursprünglichen Quelltext beinhalten. Sie werden NICHT in Binärform ausgeliefert. Dies bedeutet, dass du, um dein System patchen zu können, den Quelltext von der RELEASE-Version vorliegen haben musst. Generell gilt, dass du den gesamten Source-Tree haben solltest. Wenn du ein Release von der offiziellen CD-ROM benutzt, befinden sich die Source-Trees auf Disc 3, sie können aber auch als Dateien von den FTP-Servern heruntergeladen werden. Wir nehmen an, dass du ein Checkout für den gesamten Tree gemacht hast.
Für unser Beispiel hier betrachten wir den Patch 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 diesem Patch ist das Wiedereinlesen der Daten von Backups recht schwierig. Leute, die ein Bandlaufwerk nutzen, benötigen diesen Patch, wobei diejenigen, die kein Bandlaufwerk nutzen, keine besondere Notwendigkeit haben, diesen zu installieren. Lass uns einen Blick auf den Patch 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 */
# 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
An diesem Punkt angekommen kannst du nun wie gewohnt den Kernel erzeugen, installieren und das System neustarten.
Nicht alle Patches sind für den Kernel. In einigen Fällen musst du invididuelle Werkzeuge neuerzeugen. In anderen Fällen musst du alle statisch gelinkten Werkzeuge neukompilieren, da sich eine Bibliothek änderte. Folge den Anweisungen am Anfang vom Patch, und wenn du dir unsicher bist, erstelle das gesamte System neu.
Patches, 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 vom oben angegeben Patch nicht profitieren. Man nimmt jedoch an, dass die Patches ,in der richtigen Reihenfolge' eingefügt werden - es ist möglich, dass ein späterer Patch von einem vorherigen abhängig ist. Sei dir dessen bewusst, wenn du dich dafür entscheidest, bei der Installation von Patches ,wählerisch' zu sein, so dass du, wenn du dir unsicher bist, alle installieren solltest.
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.
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.
# apachectl stop
rename your log files
# apachectl start ; sleep 10 ; apachectl start
Zuerst werden wir das wwwcount-Package 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
# 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 Ref Name
00000000 00000000 exe 1 Count.cgi
03791000 237ca000 rlib 1 /usr/lib/libc.so.30.3
03db4000 03db4000 rtld 1 /usr/libexec/ld.so
# mkdir -p /var/www/usr/lib /var/www/usr/libexec
# cp /usr/lib/libc.so.30.3 /var/www/usr/lib
# cp /usr/libexec/ld.so /var/www/usr/libexec
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 Package 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
# tar cf - /usr/local/lib/wwwcount | (cd /var/www; tar xpf - )
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.
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.
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.
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 Packages oder Ports 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 $ '
/home/nick $
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.(lies die Manualseite ü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!)
\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.
Man könnte folgendes Kommando nutzen:
export PS1="\n\u@\H\n\w \\$ "
[FAQ-Index] [Zum Kapitel 9 - Zu OpenBSD migrieren] [Zum Kapitel 11 - Das X Window System]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org