![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 1 - Einführung in OpenBSD] [Zum Kapitel 3 - Wo man OpenBSD herbekommt]
Die offizielle Website des OpenBSD-Projekts findest du unter: http://www.OpenBSD.org.
Hier kannst du viele wertvolle Informationen über alle Aspekte des OpenBSD-Projekts erhalten.
Das OpenBSD Journal ist ein Neuigkeiten- und Meinungsportal, das auf OpenBSD fokusiert ist.
OpenBSDsupport.org ist eine Seite, die ,benutzerverwaltete' Dokumentation von unterschiedlicher Qualität sammelt, aber häufig Themen abdeckt, die nicht in dieser FAQ oder anderen offiziellen Dokumentation behandelt werden.
Viele Benutzer haben Webseiten und Homepages mit OpenBSD-spezifischen Informationen erstellt. Wie mit allem im Internet, wird eine gute Suchmaschine dein Leben einfacher machen, wie es auch mit einer gesunden Dosis an Skepsis der Fall ist. Wie immer, gebe keine Befehle blindlings in deinen Computer ein, die du nicht verstehst.
Das OpenBSD-Projekt betreibt mehrere populäre Mailinglisten, die die Benutzer abonnieren und lesen sollten. Um eine Mailingliste zu abonnieren, schicke eine E-Mail an majordomo@openbsd.org. Diese Adresse ist ein automatischer Abonnementservice. Im Textkörper der Nachricht sollte in einer einzigen Zeile der Befehl stehen, um sich in die gewünschte Liste einzutragen. Zum Beispiel:
subscribe announce
Der Mailinglistendienst wird dir antworten und dich um Bestätigung bitten, so dass andere nicht in der Lage sind, dich mit einer Flut an ungewünschten E-Mails zu überschwemmen. Die Nachricht beinhaltet mehrere verschiedene Optionen zum Bestätigen, dazu gehören ein ,list server'-Webseitenlink und die Möglichkeit, der Bestätigungs-E-Mail oder majordomo@openbsd.org zu antworten. Verwende die Option, die für dich am einfachsten ist. Du wirst feststellen, dass alle drei Varianten eine einzigarte und zeitbegrenzte Identitätsnummer beinhalten, wie zum Beispiel A56D-70D4-52C3, ebenfalls, um zu gewährleisten, dass du tatsächlich die Person bist, die den Mailinglisten-Eintrag angefordert hat (das ist wirklich ,opt-in').
Nach deiner Bestätigung wirst du sofort in die Liste eingetragen und der Mailinglistendienst schickt dir eine Erfolgsbestätigung.
Um dich wieder von einer Liste abzumelden, schickst du eine Nachricht an majordomo@openbsd.org. Sie könnte etwa so aussehen:
unsubscribe announce
Solltest du Schwierigkeiten mit dem Mailinglistensystem haben, dann lies zunächst die Anweisungen und Hinweise, die du durch Schicken einer E-Mail an majordomo@openbsd.org mit dem Textkörper ,help' erhalten kannst.
Dein Abonnement der OpenBSD-Mailinglisten kann ebenfalls durch das Webinterface auf http://lists.openbsd.org verwaltet werden.
Einige der beliebtesten OpenBSD-Mailinglisten sind:
Bevor du eine Frage auf misc oder einer anderen Mailingliste stellst, überprüfe bitte zunächst, ob deine Frage nicht schon in den Archiven auftaucht, da die meisten Fragen schon einmal gestellt wurden. Auch wenn du das Problem zum ersten Mal siehst, ist es anderen doch oftmals schon begegnet, wurden die Mailinglisten vielleicht schon letzte Woche damit überschwemmt und freuen sich die Leser sicher nicht auf eine Wiederholung. Falls du eine Frage stellst, die möglicherweise mit Hardware zu tun hat, füge immer eine dmesg(8) mit ein!
Du kannst einige Archive, andere Mailinglistenrichtlinien und weitere Informationen auf der Mailinglisten-Seite finden.
Eine unoffizielle Mailingliste, die insbesondere für neue Anwender von OpenBSD interessant sein könnte, ist die ,OpenBSD Newbies'-Liste
OpenBSD wird von einer ausführlichen Dokumentation in Form von Manualseiten und weiteren, längeren Artikeln, die sich auf spezielle Anwendungen beziehen, begleitet. Besonders viel Wert wird darauf gelegt, sicherzustellen, dass die Manualseiten aktuell und genau sind. In allen Fällen werden die Manualseiten als maßgebliche Informationsquelle für OpenBSD angesehen.
Um die Manualseiten lesen zu können, müssen die man38.tgz- und misc38.tgz-Dateisets installiert sein.
Hier eine Liste der nützlichsten Manualseiten für Anfänger:
Einführung
Die OpenBSD-Manualseiten sind im Web über http://www.openbsd.org/cgi-bin/man.cgi zu finden oder auch auf deinem eigenen Computer, wenn du das man38.tgz-Dateiset installierst.
Im Allgemeinen kannst du die Manualseite eines dir namentlich bekannten Befehls erreichen, indem du ,man befehl' eingibst. Zum Beispiel: ,man vi' bringt dir die Manualseite des Vi-Editors. Solltest du den genauen Namen des Befehls nicht wissen oder ,man Befehl' nicht die gewünschte Manualseite bringt, kannst du mittels ,apropos irgendwas' oder ,man -k irgendwas' nach dem Namen des Befehls suchen, wobei ,irgendwas' möglicherweise in der von dir gesuchten Manualseite enthalten sein sollte. Zum Beispiel:
# apropos "time zone" tzfile (5) - time zone information zdump (8) - time zone dumper zic (8) - time zone compiler
Die Zahlen in Klammern deuten auf das Kapitel, in dem sich die Manualseite befindet. In einigen Fällen enthalten die Manualseiten den gleichen Befehl in verschieden Kapiteln. Zum Beispiel: Du möchtest das Format der Konfigurationsdatei des Cron-Daemons wissen. Wenn du einmal weißt, in welchem Kapitel sich die gewünschte Manualseite befindet, kannst du mittels ,man n befehl', wobei n die Kapitelnummer ist, die gewünschte Seite direkt aufrufen.
# man -k cron cron (8) - clock daemon crontab (1) - maintain crontab files for individual users crontab (5) - tables for driving cron # man 5 crontab
Zusätzlich zu den UNIX-Manualseiten gibt es noch einen weiteren Dokumentensatz (enthalten im misc38.tgz-Dateiset). Dieser befindet sich im Verzeichnis /usr/share/doc. Wenn du auch die Text-Distribution installiert hast, dann kannst du jedes Dokument mittels ,make' im entsprechenden Verzeichnis formatieren. Das Unterverzeichnis psd beinhaltet die ,Programmer's Supplementary Documents'-Distribution. Im Unterverzeichnis smm liegt das ,System Manager's Manual'. Im Unterverzeichnis usd findest du die ,UNIX User's Supplementary Documents'-Distribution. Du kannst ,make' in den drei Distributionsunterverzeichnissen starten oder ein spezielles Kapitel einer Distribution auswählen und dort ein ,make' in dessen Unterverzeichnis ausführen.
Einige der Unterverzeichnisse sind leer. Standardmäßig werden die Dokumente im Postscriptformat ausgegeben, das sich zum Ausdrucken eignet. Die Postscriptausgabe kann sehr groß werden -- etwa 250-300% Zuwachs an Größe. Ohne Postscriptdrucker oder -anzeige kannst du die Dokumente auch für das Lesen auf einer Terminalanzeige formatieren. Jedes Dokumentenunterverzeichnis hat ein Ziel zum Erzeugen von ASCII-Kopien dieser Dokumente (genannt ,paper.txt'), welches mit make(1) generiert werden kann. Zum Beispiel:
# cd /usr/share/doc/usd/04.csh # make paper.txt # more paper.txt
Bedenke, dass Superuser-Privilegien benötigt sein können, um die Dokumente in diesen Verzeichnissen zu erstellen, und der Aufruf von make clean alle Dokumente löscht, die von vorherigen Make-Aufrufen erstellt worden sind. Siehe /usr/share/doc/README für weiter Details über die Dokumente in /usr/share/doc/.
Die UNIX-Manualseiten sind im Allgemeinen aktueller und vertrauenswürdiger als die formatierten Dokumente, die aber manchmal kompliziertere Anwendungen in größerem Detailumfang als die Manualseiten erklären.
Für viele ist eine ausgedruckte Manualseite nützlich. Hier folgen die Richtlinien, um eine Manualseite auszudrucken.
Dies gilt für den gesamten Source-Tree. Die Manualseiten befinden sich unformatiert im Verzeichnisbaum und werden automatisch durch CVS aktualisiert. Um sich diese Seiten anzusehen:
# nroff -Tascii -mandoc <Datei> | more
Dies ist nützlich, um die Manualseite ohne nicht druckbare Zeichen zu
erhalten.
Beispiel:
# man <Befehl> | col -b
Beachte, dass <Datei> die Manualseiten-Quelltextdatei ist (wahrscheinlich eine Datei, die in einer Zahl endet; z.B. tcpdump.8). Die Postscriptversionen der Manualseiten sehen sehr gut aus. Sie können ausgedruckt oder am Bildschirm mit einem Programm wie gv (GhostView) betrachtet werden. GhostView kannst du in unserer Packagekollektion finden. Benutze die folgenden nroff(1)-Befehlsoptionen, um eine PostScriptversion von einer OpenBSD-Systemmanualseite zu bekommen:
# nroff -Tps -mandoc <Datei> > Ausgabedatei.ps
Für Leute, die ihr System vom Sourcecode aus erzeugen, gibt es einige Optionen, um Manualseiten zu entwickeln. Diese Optionen können in /etc/mk.conf (vielleicht muss diese Datei erst angelegt werden) geschrieben und somit in die Systemerzeugung mit integriert werden. Eine besonders gebräuchliche Option ist, komprimierte Manualseiten zu erzeugen, um Plattenplatz sparen zu können. Diese Dateien können auf den üblichen Weg angezeigt werden, unter der Verwendung des Befehls man. Um diese Option zu setzen, füge das folgende in /etc/mk.conf ein:
Eine andere nützliche Option ist, während der Systemkompilierung die Manualseiten im Postscriptformat sowie als ASCII-Text entwickeln zu lassen. Dies wird durch das Setzen der Option MANPS=yes in /etc/mk.conf gemacht. Siehe mk.conf(5) für weitere Einzelheiten.MANZ=yes
Einige Teile der Dokumentation für OpenBSD kommt in Info-Dateien, typischerweise befinden sie sich im /usr/share/info-Verzeichnis. Dies ist eine alternative Form der Dokumentation, die von GNU angeboten wird. Viele dieser Dateien sind aktueller als die Manualseiten von GNU und können mit dem info(1)-Befehl betrachtet werden. Um zum Beispiel die Informationen über den GNU-Compiler gcc(1) anzusehen, gib ein:
Nach der Verwendung von info wirst du unsere Manualseiten zu schätzen wissen!# info gcc
Die standardmäßige Konfigurationsdatei für xterm(1) zeigt keine farbigen Manualseiten an. Um farbige Ausgabe zu erhalten, kopiere die Datei /etc/X11/app-defaults/XTerm-color in dein Heimatverzeichnis und benenne sie in ".Xdefaults" um. Sei vorsichtig, damit du nicht irgendwelche aktuellen Einstellungen in ".Xdefaults" überschreibst. Diese Datei beinhaltet alle Einstellungen, um Farbe im XTerm zu aktivieren. Allerdings müssen diese drei Zeilen auskommentiert werden, bevor sie funktionieren können:
Der Rest der Datei erlaubt dir, Farben für verschiedene Einstellungen zu wählen. Relevant für die Manualseiten sind:!*VT100*colorULMode: on !*VT100*underLine: off !*VT100*colorBDMode: on
Dies produziert recht helle Manualseiten, daher ändere es nach deinen Bedürfnissen: Dürfen wir rot für ,colorUL' und magenta für ,colorBD' empfehlen? Es ist ebenfalls ein Manualseiten-Betrachter für X11 verfügbar, xman, welcher eine alternative (grafische) Oberfläche für die Manualseiten bietet.*VT100*colorUL: yellow *VT100*colorBD: white
Falls du eine eigene Manualseite für dein selbstentwickeltes Programm schreiben möchtest, kannst du die Anleitung, die in mdoc.samples(7) zur Verfügung gestellt wird, verwenden. Ein weiterer handlicher Referenzguide wird in mdoc(7) bereitgestellt.
Schließlich, bevor du einen Fehler berichtest, solltest du http://www.openbsd.org/report.html lesen.
Richtige Fehlerberichte sind eine der wichtigsten Aufgaben von Endbenutzern. Sehr detaillierte Informationen werden benötigt, um die schwersten Fehler zu diagnostizieren. Entwickler erhalten häufig Fehlerberichte per E-Mail wie diesen:
From: joeuser@example.com To: bugs@openbsd.org Subject: HELP!!! I have a PC and it won't boot!!!!! It's a 486!!!!! |
Hoffentlich verstehen die meisten Menschen, warum solche Fehlerberichte gelöscht werden. Jeder Fehlerbericht sollte detaillierte Informationen enthalten. Wenn ein normaler Benutzer wirklich die Untersuchung seines Fehlers wünscht, dann sollte sein Fehlerbericht in etwa so aussehen:
From: smartuser@example.com
To: bugs@openbsd.org
Subject: 3.3-beta panics on a SPARCStation2
OpenBSD 3.2 installed from an official CD-ROM installed and ran fine
on this machine.
After doing a clean install of 3.3-beta from an FTP mirror, I find the
system randomly panics after a period of use, and predictably and
quickly when starting X.
This is the dmesg output:
OpenBSD 3.3-beta (GENERIC) #9: Mon Mar 17 12:37:18 MST 2003
deraadt@sparc.openbsd.org:/usr/src/sys/arch/sparc/compile/GENERIC
real mem = 67002368
avail mem = 59125760
using 200 buffers containing 3346432 bytes of memory
bootpath: /sbus@1,f8000000/esp@0,800000/sd@1,0
mainbus0 (root): SUNW,Sun 4/75
cpu0 at mainbus0: CY7C601 @ 40 MHz, TMS390C602A FPU; cache chip bug
- trap page uncached
cpu0: 64K byte write-through, 32 bytes/line, hw flush cache enabled
memreg0 at mainbus0 ioaddr 0xf4000000
clock0 at mainbus0 ioaddr 0xf2000000: mk48t02 (eeprom)
timer0 at mainbus0 ioaddr 0xf3000000 delay constant 17
auxreg0 at mainbus0 ioaddr 0xf7400003
zs0 at mainbus0 ioaddr 0xf1000000 pri 12, softpri 6
zstty0 at zs0 channel 0 (console i/o)
zstty1 at zs0 channel 1
zs1 at mainbus0 ioaddr 0xf0000000 pri 12, softpri 6
zskbd0 at zs1 channel 0: reset timeout
zskbd0: no keyboard
zstty2 at zs1 channel 1: mouse
audioamd0 at mainbus0 ioaddr 0xf7201000 pri 13, softpri 4
audio0 at audioamd0
sbus0 at mainbus0 ioaddr 0xf8000000: clock = 20 MHz
dma0 at sbus0 slot 0 offset 0x400000: rev 1+
esp0 at sbus0 slot 0 offset 0x800000 pri 3: ESP100A, 25MHz, SCSI ID 7
scsibus0 at esp0: 8 targets
sd0 at scsibus0 targ 1 lun 0: <SEAGATE, ST1480 SUN0424, 8628> SCSI2 0/direct fixed
sd0: 411MB, 1476 cyl, 9 head, 63 sec, 512 bytes/sec, 843284 sec total
sd1 at scsibus0 targ 3 lun 0: <COMPAQPC, DCAS-32160, S65A> SCSI2 0/direct fixed
sd1: 2006MB, 8188 cyl, 3 head, 167 sec, 512 bytes/sec, 4110000 sec total
le0 at sbus0 slot 0 offset 0xc00000 pri 5: address 08:00:20:13:10:b9
le0: 16 receive buffers, 4 transmit buffers
cgsix0 at sbus0 slot 1 offset 0x0: SUNW,501-2325, 1152x900, rev 11
wsdisplay0 at cgsix0
wsdisplay0: screen 0 added (std, sun emulation)
fdc0 at mainbus0 ioaddr 0xf7200000 pri 11, softpri 4: chip 82072
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
root on sd0a
rootdev=0x700 rrootdev=0x1100 rawdev=0x1102
This is the panic I got when attempting to start X:
panic: pool_get(mclpl): free list modified: magic=78746572; page 0xfaa93000;
item addr 0xfaa93000
Stopped at Debugger+0x4: jmpl [%o7 + 0x8], %g0
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb> trace
pool_get(0xfaa93000, 0x22, 0x0, 0x1000, 0x102, 0x0) at pool_get+0x2c0
sosend(0x16, 0xf828d800, 0x0, 0xf83b0900, 0x0, 0x0) at sosend+0x608
soo_write(0xfac0bf50, 0xfac0bf70, 0xfac9be28, 0xfab93190, 0xf8078f24, 0x0)
at soo_write+0x18
dofilewritev(0x0, 0xc, 0xfac0bf50, 0xf7fff198, 0x1, 0xfac0bf70) at
dofilewritev+0x12c
sys_writev(0xfac87508, 0xfac9bf28, 0xfac9bf20, 0xf80765c8, 0x1000, 0xfac0bf70)
at sys_writev+0x50
syscall(0x79, 0xfac9bfb0, 0x0, 0x154, 0xfcffffff, 0xf829dea0) at syscall+0x220
slowtrap(0xc, 0xf7fff198, 0x1, 0x154, 0x1, 0xfac87508) at slowtrap+0x1d8
ddb> ps
PID PPID PGRP UID S FLAGS WAIT COMMAND
27765 8819 29550 0 3 0x86 netio xconsole
1668 29550 29550 0 3 0x4086 poll fvwm
15447 29550 29550 0 3 0x44186 poll xterm
8819 29550 29550 35 3 0x4186 poll xconsole
1238 29550 29550 0 3 0x4086 poll xclock
29550 25616 29550 0 3 0x4086 pause sh
1024 25523 25523 0 3 0x40184 netio XFree86
*25523 25616 25523 35 2 0x44104 XFree86
25616 30876 30876 0 3 0x4086 wait xinit
30876 16977 30876 0 3 0x4086 pause sh
16977 1 16977 0 3 0x4086 ttyin csh
5360 1 5360 0 3 0x84 select cron
14701 1 14701 0 3 0x40184 select sendmail
12617 1 12617 0 3 0x84 select sshd
27515 1 27515 0 3 0x184 select inetd
1904 1 1904 0 2 0x84 syslogd
9125 1 9125 0 3 0x84 poll dhclient
7 0 0 0 3 0x100204 crypto_wa crypto
6 0 0 0 3 0x100204 aiodoned aiodoned
5 0 0 0 3 0x100204 syncer update
4 0 0 0 3 0x100204 cleaner cleaner
3 0 0 0 3 0x100204 reaper reaper
2 0 0 0 3 0x100204 pgdaemon pagedaemon
1 0 1 0 3 0x4084 wait init
0 -1 0 0 3 0x80204 scheduler swapper
Thank you!
|
In report.html finden sich weitere Informationen über das Erzeugen und Einsenden von Fehlerberichten. Detaillierte Informationen über deine Hardware sind absolut notwendig, wenn du glaubst, der Fehler könnte irgendwie mit deiner Hardware oder deiner Hardwarekonfiguration zusammenhängen. Normalerweise ist die Ausgabe von dmesg(8) in dieser Hinsicht ausreichend. Eine detaillierte Beschreibung deines Problems ist notwendig. Dmesg beschreibt deine Hardware, der Text erklärt warum Smart User denkt, das System sei defekt (3.2 lief noch bestens), wie dieser Absturz erzeugt wurde (indem er X gestartet hat) und die Ausgabe der Debugger-Befehle ,ps' und ,trace'. In diesem Fall hat Smart User die Informationen bereitgestellt, die er über serielle Konsole bekommen hat, wenn du das nicht tun kannst, bist du gezwungen, mittels Stift und Papier die Informationen vom Absturz aufzuzeichnen. (Das Beispiel oben war im Übrigen ein echtes Problem und die oben bereitgestellte Information führte dazu, dass dieses Problem, das Sun4c-Systeme betraf, behoben werden konnte).
Wenn Smart User ein funktionierendes OpenBSD-System gehabt hätte, von dem aus er einen Fehlerbericht abschicken wolle, dann hätte er sendbug(1) verwendet, um den Fehlerbericht zu verfassen und zum GNATS-Problemerfassungssystem zu senden. Wenn dein System nicht startet, dann kannst du sendbug(1) selbstverständlich nicht verwenden, aber du solltest es nutzen, wann immer du kannst. Du wirst noch zusätzliche Informationen, wie z.B. was geschah und deine genaue Konfiguration einfügen müssen und wie man das Problem reproduzieren kann. Der sendbug(1)-Befehl benötigt eine Verbindung zum Internet und einen funktionsfähigen MTA, um den Fehlerbericht per E-Mail versenden zu können. Beachte, dass der Mailserver spamd(8) basierendes ,greylisting' verwendet, so dass es eine halbe Stunde oder so dauern kann, bevor der Mailserver deinen Fehlerbericht akzeptiert, habe also bitte Geduld.
Nach dem Einsenden eines Fehlerberichts per sendbug(1) wirst du per E-Mail über den Status informiert. Du kannst auch von Entwicklern kontaktiert werden, die dich nach weiteren Informationen fragen oder dich bitten, Patches zu testen. Des Weiteren kannst du dir auch die Archive der bugs@openbsd.org-Mailingliste ansehen, Details dazu gibt es auf der Mailinglisten-Seite oder du kannst den Status des Fehlerberichts auch online abfragen, und zwar im Bug Tracking System.
Die ,Panic message' verloren?
Unter bestimmten Umständen kannst du die ersten Zeilen vom ,panic',
die den Grund für den ,panic' angeben, verlieren.
Dies ist eine sehr wichtige Nachricht, daher möchtest du sie ebenfalls
berichten. Du kannst diese wiederbekommen, indem du den ,show
panic'-Befehl in ddb> wie folgt verwendest:
ddb> show panic 0: kernel: page fault trap, code=0 ddb> |
In diesem Fall war die ,panic'-Zeichenkette ,Kernel: page fault trap, code=0'
Besonderer Hinweis für SMP-Systeme:
Du solltest einen ,trace' von jedem Prozessor als Teil deines Berichts
holen:
ddb{0}> trace
pool_get(d05e7c20,0,dab19ef8,d0169414,80) at pool_get+0x226
fxp_add_rfabuf(d0a62000,d3c12b00,dab19f10,dab19f10) at fxp_add_rfabuf+0xa5
fxp_intr(d0a62000) at fxp_intr+0x1e7
Xintr_ioapic0() at Xintr_ioapic0+0x6d
--- interrupt ---
idle_loop+0x21:
ddb{0}> machine ddb 1
Stopped at Debugger+0x4: leave
ddb{1}> trace
Debugger(d0319e28,d05ff5a0,dab1bee8,d031cc6e,d0a61800) at Debugger+0x4
i386_ipi_db(d0a61800,d05ff5a0,dab1bef8,d01eb997) at i386_ipi_db+0xb
i386_ipi_handler(b0,d05f0058,dab10010,d01d0010,dab10010) at i386_ipi_handler+0x
4a
Xintripi() at Xintripi+0x47
--- interrupt ---
i386_softintlock(0,58,dab10010,dab10010,d01e0010) at i386_softintlock+0x37
Xintrltimer() at Xintrltimer+0x47
--- interrupt ---
idle_loop+0x21:
ddb{1}>
|
Wiederhole ,machine ddb x' gefolgt von ,trace' für jeden einzelnen Prozessor in deiner Maschine.
[FAQ-Index] [Zum Kapitel 1 - Einführung in OpenBSD] [Zum Kapitel 3 - Wo man OpenBSD herbekommt]
![[zurück]](../../images/back.gif){kind=small}
www@openbsd.org