[OpenBSD]

[索引] [第一章 - OpenBSD介绍] [第三章 - 开始OpenBSD之旅]

2 - 进一步了解OpenBSD

目录

2.1 - Internet上的网页

http://www.OpenBSD.org OpenBSD项目官方网站, 官方网站上有一系列有价值的资料、涉及OpenBSD项目的方方面面。

OpenBSD Journal 一个发布OpenBSD重要消息和建议的网站。

OpenBSDsupport.org 一个收集各种性质的用户维护文档的网站, 经常讨论一些官方FAQ或者其它文档不包含的内容。

许多用户建立了关于OpenBSD的网站或网页, 因为所有信息全分布在Internet上, 所以一个好的搜索引擎可以使您的生活更加轻松, 最后永远记住一点:千万不要在您的计算机上输入您不知道含义的命令。

2.2 - 邮件列表

OpenBSD项目维护着几个热门的邮件列表, 用户应该订阅并关注它们, 订阅邮件列表很简单, 给majordomo@OpenBSD.org发一封邮件, 这个电子邮件地址提供自动的订阅服务。在邮件信息中您应该用单独的一行给出订阅命令, 以便让服务器明白您要订阅那些内容, 例如:

subscribe announce

邮件列表处理器会回复您一封邮件让您确认, 确认方式有几种, 并且包含了一个邮件列表服务器的list server主页信息, 这样可以确认是您可以得到您所订阅的内容, 也能避免您收到垃圾邮件, 您仅需要确认订阅或者发一封邮件给majordomo@OpenBSD.org, 无论哪种方法订阅全很方便。您会看见有时限的三组身份识别号码, 就像这样 A56D-70D4-52C3, 目的是再一次确认是的确是您订阅了我们的邮件列表。

一旦您确认了您的订阅, 您会被马上加入邮件列表, 并且邮件列表服务器会通知您:您已经被成功的加入了。

取消订阅邮件列表您也仅仅需要再次给majordomo@OpenBSD.org发一封信, 内容看起来像这样:

unsubscribe announce

如果您订阅邮件列表时还有什么困难请封一封信给majordomo@OpenBSD.org 在邮件中写明"help", 这样您会得到一封回信, 仔细阅读里面的内容会对您的邮件列表设置有帮助。

您也可以通过http://lists.openbsd.org网站进行邮件列表的订阅维护。

OpenBSD 一些受欢迎的邮件列表清单:

在misc或其它邮件列表上提出一个问题之前,请您先请查阅一下以往的文章, 有些问题对您来说可能是第一次碰到, 但是它可能在这里已经被问过很多次了, 也许上周就在版面上出现过几次, 您可以试想一下再次在同样的地方提同样的老问题可能会使回答者不愉快, 所以请先仔细浏览以往的文章, 也许您马上就找到答案了。如果包含硬件方面的问题, 一定不要忘记提供一份您的dmesg(8)!

其它邮件列表指南及更多的信息, 请参阅mailing lists page。

一个非官方的邮件列表或许更能引起Unix或者OpenBSD新手的兴趣OpenBSD Newbies。

2.3 - 用户手册

OpenBSD用户手册包含了大量的文档及对具体程序足够详尽的描述。为使用户手册更新及时并准确无误, OpenBSD团队一直付出大量的努力, OpenBSD用户手册上的文件在任何时候都具有权威性。

您需要先安装man48.tgz和misc48.Tgz才能在本地阅览用户手册和其它文档, 如何安装请详见系统组件。

这里有一份对新手来说很有用的部分用户手册清单:

初级用户

高级用户

您可以在http://www.openbsd.org/cgi-bin/man.cgi找到所有的 OpenBSD用户手册, 同样, 如果您安装了man48.tgz这个文件您在本地计算机上也可以浏览。

一般来讲, 如果知道命令的名称您可以通过运行"man command"查询到此命令的用户手册。例如"man vi"将显示关于vi编辑器的用户手册。如果您不清楚确切的命令名称, 或者您使用"man command"在用户手册上“找”不到您需要的命令, 您可以通过运行"apropos something" 或者 " man -k something", 这里的"something"就是一个接近您要找的命令的意思的词, 也许用户手册会给出您想要的命令, 例如: 

# apropos "time zone"
tzfile (5) - time zone information
zdump (8) - time zone dumper
zic (8) - time zone compiler

附加的数字指出了用户手册所在的章节数, 有时您会发现同一个命令的不同解释内容在不同的章节上, 例如:假如您想知道"cron"命令的具体用法, 如果您知道了您所需要的"cron"命 令的具体章节数, 您可以用命令 "man n cron"直接去那个章节阅读您所需要的内容。 

# man -k cron
cron (8) - clock daemon
crontab   (1) - maintain crontab files for individual users
crontab (5) - tables for   driving cron
# man 5 crontab

除了UNIX用户手册外, 还有面对不同用户的文档包(包含在misc48.tgz组件内),它位于/usr/share/doc目录. 您可以在适当的子目录内通过"make"命令生成各类文档。psd子目录是程序员辅助文档。smm子目录里面是系统管理者用户手册。usd子目录是Unix用户辅助文档。 您可以在上面的三个子目录中运行"make"命令, 或者您也可以"make"某一章节或一部分段落。

一些子目录内是空的,默认情况下的输出的是适于打印的PostScript格式, PostScript 输出格式会很大——您会发现文件体积增大了250-300%。如果您不打算打印或显示这种格式, 您完全可以将文档输出成在终端上的显示格式。每个文档目录内的文档全可以用 make(1)命令输出为ASCII码 的纯文本格式(被称为'paper.txt"), 例如:

# cd /usr/share/doc/usd/04.csh
# make paper.txt
# more paper.txt

注意在这些子目录中创建文档时系统可能要求您具有超级用户权限, 而且您在输入make clean命令后 您以前"make"生成的文档会被删除。具体请参看/usr/share/doc/README文档, 更多关于创建文档的说明在/usr/share/doc/目录中可以找到。

用户手册(manual pages )通常情况下比可打印文档的内容更新更可靠, 但是有时可打印文档对相关应用程序的解释更详尽。

对多数人来讲自己拥有一份硬拷贝的用户手册是十分有益的。在这里我们介绍一下怎样打印一份用户手册的拷贝。

怎样显示一个用户手册的原始文档(例如一个以数字结尾的文档, 像tcpdump.8等)?

这些文档可以在src tree上找到。在src tree中的用户手册是无格式的原始文档, 通过使用 CVS, 它们会被更新。如果您想看这些页面, 很简单: 

# nroff -Tascii -mandoc <file> | more

我如何才可以得到一个无格式及控制符的用户手册原始文档?

下面的命令会帮您直接获得一份简单的无格式及无打印控制符的文档:

# man <command> | col -b

我如何得到一份可打印的PostScript格式用户手册?

注意下面命令行中所指的<file>必须是用户手册原始文档(很可能是以数字结尾的文件名, 如:tcpdump.8)。PostScript版的用户手册看起来很漂亮, 它们可以被打印出来, 或者用某些程序, 如gv(GhostView)在屏幕上浏览。GhostView 可以在packages collection中找到。在OpenBSD系统中用下面的 nroff(1)命令可以得到PostScript格式的用户手册: 

# nroff -Tps -mandoc <file> > outfile.ps

我怎样得到压缩拷贝的用户手册?

对那些通过编译系统源码构建自己系统的人来讲, 有一系列选项可以创建用户手册, 这些选项可以在您构建系统时放到/etc/mk.conf这个文件中(也许你需要创建这个文件), 一个特别的选项可以帮助您生成压缩格式的用户手册文档以便节省磁盘空间, 而且这种压缩格式的文档可以通过man命令正常显示出来。在文件mk.conf里加入一个选项: 

MANZ=yes

除了可以生成纯文本ASCII码格式的用户手册文档外, 另一个有用的选项可以让系统产生 PostScript格式的用户手册文档, 您仅需在/etc/mk.conf里加入一个选项: 

MANPS=yes

请参看mk.conf(5)以获得更多的信息。

什么是info文档?

OpenBSD的一些文档是由info文档构成的, 典型的就是在/usr/share/info下的文件, 它们GNU 提供文档的替代品, 这里的多数GNU的说明文档比OpenBSD用户手册上的以前GNU提供的说明文档更新, 您可以通过 info(1)命令查看 这些GNU提供的文档, 例如, 您想了解GNU提供的编译器 gcc(1)的说明文档, 输入命令: 

# info gcc
您用过info命令后, 您将会更加喜爱我们的用户手册!

我怎样在XTerm终端上显示彩色的用户手册?

xterm(1)终端默认的 配置文件并不能显示彩色的用户手册, 如果想要得到彩色输出您必须把/etc/X11/app-defaults/XTerm-color 拷贝到您的根目录, 并把它的名字改成.Xdefaults。仔细点，您不要随便修改这个".Xdefaults"文件的当前设定, 您的XTerm终端可以彩色显示的所有设定选项全在这个文件里,但您要确保去掉下面这三个选项的注释符: 

!*VT100*colorULMode: on
!*VT100*underLine: off
!*VT100*colorBDMode: on

您可以通过设定这个文件的其它部分的选择不同的颜色, 有关用户手册的彩色显示选项是: 

*VT100*colorUL: yellow
*VT100*colorBD: white
设置成这种的颜色搭配的用户手册可能有些不美观, 所以如果您想个性化一下用户手册的显示也许可以将colorUL设置成red(红), 把colorBD设置成magenta(洋红)?两一个选择是xman(1), 它可以在X11下浏览用户手册。您可以在用户手册上找到更多的关于xterm和xman的知识。

我怎样写自己的用户手册?

如果您想为自己所编写的程序写自己的用户手册, 可以看mdoc.samples(7)和mdoc(7)。


2.4 - 报告bug

在提交bug前, 请您确认您真的发现了错误。也许您不知道在OpenBSD中这样的问题已经解决了或是您没有正确设置, 或者您在用户手册及主页上没有找到答案, 抑或您忘了在邮件列表(通常用misc@OpenBSD.org)上寻求帮助。如果您是初次使用OpenBSD, 老实说: 也许这并非是一个未知的bug。同样, 请注意有缺陷的硬件设备会导致程序出现莫名其妙的问题, 有时看起来像是程序本身的错误, 所以在您确认发现一个程序"错误"之前请先确认您的硬件系统当前工作正常。

最后递交任何错误报告前请先认真浏览http://www.openbsd.org/report.html页面。

提交真正的bug是最终用户一个最重要的责任, 诊断多数严重的程序错误需要您提供尽量详细的情况。OpenBSD开发人员经常通过email收到这样的错误报告, 就像: 

From: joeuser@example.com
To: bugs@openbsd.org
Subject: HELP!!!
I have a PC and it won't boot!!!!! It's a 486!!!!!

幸好大多数人理解为什么这类邮件会被立刻删除。所有的提交的bug必须包含详尽的信息, 上面例子中如果Joe User真的希望别人帮助来解决这个"问题", 那应该提供更多的情况......, 像这样:

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!

关于如何描述和提交bug的更多内容请参阅report.html。如果您认为这个bug可能与您的硬件或硬件配置有关(哪怕仅有一点点可能), 您就应该提供您硬件的详尽信息, dmesg(8)提供了对硬件的详细描述, 通常情况下这些描述已经足够开发者判断问题所在了。对出现问题时情况的详尽描述也是必须的。 您会注意到上面dmesg(8)提供了对硬件的详细描述, 这些文字解释了为什么聪明的用户知道他们的硬件并没有问题, (译者注:根据上面第二封电子的内容, 因为运行OpenBSD3.2一切正常, 情况仅出现在安装3.3beta后运行X时), 什么导致了程序的崩溃(启动X), 并且输入调试命令"ps"和"trace"。在这种情况下聪明的用户会将这些信息通过串口控制台输出到文件中;如果您不知道如何操作, 那您只有用纸和笔把这些信息记录下来了。(这是一个真实的案例, 上面的第二封邮件中详尽的bug描述, 帮助OpenBSD开发者修正了OpenBSD3.3beta版在Sun4c系统中的一个bug。)

如果你想用运行的OpenBSD系统提交一个bug的话, 那么就会使用sendbug(1)发送bug给GNATS问题跟踪系统。不过如果您的系统无法启动您就不能用sendbug(1)工作,但是您可以使用时您应该尽量用它, 另外发生问题时详细的情况说明, 您的OpenBSD系统的详细配置、错误在哪种情况下重复发生等等这些信息也是必不可少的。使用sendbug(1)命令要求您的系统可以在因特网上发送电子邮件。注意错误报告服务器启用了spamd(8)(反垃圾邮件技术), 所以可能邮件可能会半小时后才可能被服务器接收到, 所以请您保持耐心。

当您使用sendbug提交了bug后, 您会收到一封关于此报告目前状态的通知。开发人员也许会与您联系, 并让您提供更多的情况, 或者给您提供一个补丁程序进行测试。您也可以自己访问OpenBSD的邮件列表bugs@OpenBSD.org, 查询这个错误修补的进展情况, 如何订阅邮件列表请参阅mailing list page或在Bug Tracking System错误跟踪系统)的数据库中查询它的状况。

对程序员的有用信息

这里有一些额外的小建议:

遗失了"Panic message"?

有时您可能没有记录下系统出问题时的第一手系统信息及出问题的原因, 这个系统信息十分重要, 您又想要提交它, 这时您可以在ddb>状态下用"show panic"命令像这样:

ddb> show panic
0:      kernel: page fault trap, code=0
ddb>

在这个案列中, 崩溃信息是"Kernel: page fault trap, code=0"

多处理器系统的特别说明:

您应该"trace"您的每一个处理器并将结果全写在报告里: 

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}>

对机器的每一个处理器, 在每个"machine ddb x"后重复使用trace命令。

How to gather further information from a kernel crash.

A typical kernel crash on OpenBSD might look like this: (things to watch for are marked with bold font)

kernel: page fault trap, code=0
Stopped at    _pf_route+0x263:        mov     0x40(%edi),%edx
ddb>
The first command to run from the ddb> prompt is "trace" (see ddb(4) for details):

ddb> trace
_pf_route(e28cb7e4,e28bc978,2,1fad,d0b8b120) at _pf_route+0x263
_pf_test(2,1f4ad,e28cb7e4,b4c1) at _pf_test+0x706
_pf_route(e28cbb00,e28bc978,2,d0a65440,d0b8b120) at _pf_route+0x207
_pf_test(2,d0a65440,e28cbb00,d023c282) at _pf_test+0x706
_ip_output(d0b6a200,0,0,0,0) at _ip_output+0xb67
_icmp_send(d0b6a200,0,1,a012) at _icmp_send+0x57
_icmp_reflect(d0b6a200,0,1,0,3) at _icmp_reflect+0x26b
_icmp_input(d0b6a200,14,0,0,d0b6a200) at _icmp_input+0x42c
_ipv4_input(d0b6a200,e289f140,d0a489e0,e289f140) at _ipv4_input+0x6eb
_ipintr(10,10,e289f140,e289f140,e28cbd38) at _ipintr+0x8d
Bad frame pointer: 0xe28cbcac
ddb>
This tells us what function calls lead to the crash.

To find out the particular line of C code that caused the crash, you can do the following:
Find the source file where the crashing function is defined in. In this example, that would be pf_route() in sys/net/pf.c. Recompile that source file with debug information:

# cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC/
# rm pf.o
# DEBUG=-g make pf.o
Then use objdump(1) to get the disassembly:

# objdump --line --disassemble --reloc pf.o >pf.dis
In the output, grep for the function name (pf_route in our example):

# grep "<_pf_route>:" pf.dis
00007d88 <_pf_route>:
Take this first hex number and add the offset from the 'Stopped at' line: 0x7d88 + 0x263 == 0x7feb.
Scroll down to that line (the assembler instruction should match the one quoted in the 'Stopped at' line), then up to the nearest C line number:

# more pf.dis
/usr/src/sys/arch/i386/compile/GENERIC/../../../../net/pf.c:3872
    7fe7:       0f b7 43 02             movzwl 0x2(%ebx),%eax
    7feb:       8b 57 40                mov    0x40(%edi),%edx
    7fee:       39 d0                   cmp    %edx,%eax
    7ff0:       0f 87 92 00 00 00       ja     8088 <_pf_route+0x300>
So, it's precisely line 3872 of pf.c that crashes:

# cat -n pf.c | head -n 3872 | tail -n 1
3872          if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {
Note that the kernel that produced the crash output and the object file for objdump must be compiled from the exact same source file, otherwise the offsets won't match.

If you provide both the ddb> trace output and the relevant objdump section, that's very helpful.

[索引] [第一章 - OpenBSD介绍] [第三章 - 开始OpenBSD之旅]

[back]www@openbsd.org
$OpenBSD: faq2.html,v 1.103 2009/10/16 19:07:37 nick Exp $