![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Indice FAQ] [Sezione 1 - Introduzione a OpenBSD] [Sezione 3 - Ottenere OpenBSD]
Il sito uffuciale del progetto OpenBSD si trova su: http://www.openbsd.org.
Molte informazioni riguardanti tutti gli aspetti del progetto OpenBSD possono essere trovate qui.
Il Giornale di OpenBSD è un sito dedicato a news e opinioni su OpenBSD.
OpenBSDsupport.org è un sito che raccoglie documentazione mantenuta dagli utenti di diversa qualità, ma che spesso riguarda argomenti non presenti in queste FAQ o altra documentazione ufficiale.
Molti utenti hanno creato siti e pagine con informazioni specifiche su OpenBSD. Come per tutto su Internet, un buon motore di ricerca può rendervi la vita più semplice, così come una sana dose di scetticismo. Come sempre, non eseguite ciecamente sul vostro computer comandi di cui non conoscete il significato.
Il progetto OpenBSD mantiene diverse popolari mailing list a cui gli utenti possono iscriversi. Per iscriversi ad una mailing list, basta inviare un'e-mail a majordomo@openbsd.org. Questo indirizzo è un servizio automatico per le iscrizioni. Nel corpo del vostro messaggio, formato da una singola riga, dovrete includere un comando di iscrizione e a quale lista volete essere aggiunti. Per esempio:
subscribe announce
Il processo che gestisce la lista vi risponderà, chiedendovi conferma, cosicché altri non possano iscrivervi ad una marea di e-mail che non desiderate ricevere. Il messaggio includerà le istruzioni per i diversi modi di dare conferma, compreso un link alle pagine web con una lista di server, come rispondere al messaggio di conferma o a majordomo@openbsd.org. Usate il metodo più comodo per voi. Noterete che tutte e tre le tecniche coinvolgono un numero identificativo unico e limitato nel tempo, come per esempio A56D-70D4-52C3, così da essere sicuri che voi siete realmente la persona che ha richiesto di iscriversi alla mailing list (questo è il vero "opt-in").
Una volta confermata la vostra intenzione di unirvi alla mailing list, verrete immediatamente aggiunti alla lista, e il processo gestore della lista vi notificherà che siete stati aggiunti con successo.
Per cancellare la propria iscrizione alla lista, dovrete mandare un'e-mail all'indirizzo majordomo@openbsd.org. Che potrebbe essere simile a questa:
unsubscribe announce
Se avete un qualche tipo di difficoltà col sistema di mailing list, per favore leggete prima il file help che può essere ottenuto inviando un'e-mail a majordomo@openbsd.org con il contenuto "help".
La vostra iscrizione alla mail list di OpenBSD può anche essere effettuata attraverso l'interfaccia web all'indirizzo http://lists.openbsd.org
Alcune delle più popolari mailing list di OpenBSD sono:
Prima di postare una domanda nella sezione misc o in qualsiasi altra mailing list, per favore controllate gli archivi, per molte delle più comuni domande è già stata data risposta ripetutamente. Mentre per voi potrebbe essere la prima volta che incontrate il problema o la domanda, per altri sulla mailing list potrebbero averla vista molte volte nell'ultima settimana e quindi potrebbero non apprezzare il fatto di doverla vedere ancora. Se fate una domanda relativa all'hardware, includete sempre un dmesg(8)!
Potrete trovare diversi archivi, altre mailing list che vi potranno guidare e molte altre informazioni sulla pagina mailing lists.
Una mailing list non ufficiale che potrebbe interessare i nuovi utenti di OpenBSD e Unix è OpenBSD Newbies.
OpenBSD raccoglie una documentazione molto consistente sotto forma di pagine di manuale (o man pages) come documentazione specifica per ogni applicazione. E' necessario un considerevole sforzo per esser sicuri che le pagine di manuale siano aggiornate e accurate. In tutti i casi, le pagine man sono considerate la fonte più autorevole di informazioni su OpenBSD.
Per accedere alle pagine man e altra documentazione, assicuratevi di aver installato i pacchetti man38.tgz e misc38.tgz.
Qui c'è una lista di alcune delle pagine di manuale più utili per i nuovi utenti:
Per iniziare
Potete trovare tutte le pagine man su OpenBSD all'indirizzo http://www.openbsd.org/cgi-bin/man.cgi così come sul vostro computer se avete installato il pacchetto man38.tgz.
In generale, se conoscete il nome del comnado o la pagina di manuale, potete leggere quest'ultima eseguendo "man comando". Per esempio: "man vi" per leggere informazioni sull'editor vi. Se non conoscete il nome del comando, o se "man comando" non trova la pagina di manuale specifica, potete cercare all'interno del database delle pagine man eseguendo il comando "apropos qualcosa" o "man -k qualcosa", dove "qualcosa" è una parola simile o che potrebbe comparire nel titolo della pagina man che state cercando. Per esempio:
# apropos "time zone" tzfile (5) - time zone information zdump (8) - time zone dumper zic (8) - time zone compiler
Il numero tra parentesi indica la sezione del manuale in cui quella pagina può essere trovata. In alcuni casi, potrete trovare pagine di manuale con lo stesso identico nome ma in una sezione diversa del manuale. Per esempio, assumete di voler sapere il formato del file di configurazione del demone cron. Una volta conosciuta la sezione del manuale per la pagina voluta , basta eseguire "man n comando", dove n è il numero della sezione di manuale.
# man -k cron cron (8) - clock daemon crontab (1) - maintain crontab files for individual users crontab (5) - tables for driving cron # man 5 crontab
In aggiunta alle pagine di manuale di UNIX, c'è un set di documenti stampabili (incluso nel fileset misc38.tgz). Esso risiede nella directory /usr/share/doc. Potete formattare ogni set di documenti facendo un "make" nella sottodirectory appropriata. La sottodirectory psd è la distribuzione della Documentazione Supplementare del Programmatore (Programmer's Supplementary Documents). La sottodirectory smm è il Manuale dell'Amministratore di Sistema (System Manager's Manual). La sottodirectory usd è la Documentazione Supplementare per l'Utente UNIX (User's Supplementary Documents). Potete eseguire il vostro "make" nelle tre sottodirectory delle distribuzioni, oppure potete selezionare una sezione specifica di una distribuzione e fare un `make' nella sua sottodirectory.
Alcune sottodirectory sono vuote. Di default, la formattazione del documento sarà in PostScript, adatto alla stampa. L'output in PostScript potrebbe essere un po' grande -- assumete un incremento del 250-300% del volume. Se non avete accesso ad una stampante PostScript o un display, potete formattare i documenti per essere letti su un terminale. Ogni sottodirectory ha un target per compilare copie ASCII di questi documenti (chiamato `paper.txt') che possono essere generate con make(1). Per esempio:
# cd /usr/share/doc/usd/04.csh # make paper.txt # more paper.txt
Possono essere richiesti i privilegi da superuser per costruire i documenti in queste directory, e provvedendo a fare un make clean rimuoveremo tutte le pagine generate da un precedente make. Guardate il file /usr/share/doc/README per maggiori dettagli riguardo alla documentazione in /usr/share/doc/.
Le pagine di manuale di UNIX sono generalmente più aggiornate e affidabili dei documenti stampabili. A volte, però, i documenti stampabili spiegano certe applicazioni complesse più dettagliatamente di quanto non facciano le pagine man.
Per molto utenti, avere una copia scritta delle pagine di manuale può essere utile. Qui ci sono le linee guida per rendere una pagina di manuale stampabile.
Si trovano nei sorgenti. Le pagine man si trovano nei sorgenti non formattate, e vengono aggiornate spesso per mezzo del CVS, Per vedere queste pagine, basta digitare:
# nroff -Tascii -mandoc <file> | more
E' utile ottenere una pagina man senza caratteri non stampabili.
Esempio:
# man <command> | col -b
Nota che <file> dev'essere il file sorgente della man page (probabilmente un file che finisce con un numero come tt>tcpdump.8). Le versioni PostScript delle pagine man hanno un bell'aspetto. Possono essere stampate o visualizzate con programmi come gv (GhostView). GhostView è presente fra i nostri package. Usa queste opzioni di nroff(1) per ottenere una versione PostScript di una pagina man di OpenBSD:
# nroff -Tps -mandoc <file> > outfile.ps
Per chi compila il proprio sistema a partire dai sorgenti, ci sono numerose opzioni per controllare come vengono costrruite le pagine man. Queste opzioni possono essere inserite in /etc/mk.conf (può essere necessario creare questo file) e incluse durante la compilazione del sistema. Un'opzione particolarmente utile permette di generare apgine man compresse per risparmiare spazio disco. Possono poi essere visualizzate normalmente, isando il comando man. Per impostare questa opzione, aggiungi questa riga a /etc/mk.conf:
Un'altra opzione utile permette di generare le pagine man in formato PostScript e ASCII. Lo si fa impostando l'opzione MANPS=yes in /etc/mk.conf. Vedi mk.conf(5) per ulteriori dettagli.MANZ=yes
Parte della documentazione di OpenBSD è nella forma di file info, generalmente all'interno di /usr/share/info. E' una forma di documentazione alternativa fornita da GNU. Molti di questi file sono più aggiornati delle pagine di manuale fornite da GNU e possono essere accedute con il comando info(1). Per esempio, per visualizzare le informazione sul compilatore GNU, gcc(1), digita:
Dopo aver usato info, apprezzerete ancora di più le nostre pagine man!# info gcc
Il file di configurazione di default di xterm(1) non visualizza le pagine man colorate. Per avere l'output colorato, copia il file /etc/X11/app-defaults/XTerm-color nella tua home directory e rinominalo ".Xdefaults". State attenti a non sovrascrivere le impostazioni correnti in ".Xdefaults". Questo file contiene tutte le impostazioni necessarie per abilitare il colore nell'XTerm. Comunque, tre righe devono essere scommentate perché funzioni:
Il resto del file permette di scegliere i colori per vari parametri. Quelli che riguardano le pagine man sono:!*VT100*colorULMode: on !*VT100*underLine: off !*VT100*colorBDMode: on
Questo produce pagine man dall'aspetto piuttosto infernale, per cui personalizzatelo come preferite: possiamo suggerire rosso per "colorUL" e magenta per "colorBD"? E' anche disponibile un visualizzatore di pagine man per X11, xman(1), che fornisce un'interfaccia (grafica) alternativa per le pagine di manuale. Vedi le pagine di manuale di xterm e xman per ulteriori dettagli.*VT100*colorUL: yellow *VT100*colorBD: white
Se desideri scrivere le pagine di manuale per un'applicazione che hai scritto, troverai un tutorial in mdoc.samples(7). C'è anche una pratico guida di riferimento in mdoc(7).
Alla fine, prima di sottoporre un bug report, si prega di leggere http://www.openbsd.org/report.html.
Riferire correttamente i bachi è una delle responsabilità più importanti degli utenti finali. Sono necessarie informazioni molto dettagliate per diagnosticare i bachi più seri. Spesso gli sviluppatori ricevono, via email, bug report come questo:
From: joeuser@example.com To: bugs@openbsd.org Subject: HELP!!! I have a PC and it won't boot!!!!! It's a 486!!!!! |
Per fortuna molti capiscono perché tali report vengono presto cancellati. Tutti i bug report dovrebbero contenere informazioni dettagliate. Se Joe User avesse veramente desiderato che qualcuno lo aiutasse a trovare il suo bug, avrebbe dovuto fornire più informazioni... Qualcosa come:
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!
|
Vedi report.html per maggiori informazioni su come creare o sottomettere bug report. Se pensi che il baco possa in qualche modo essere legato all'hardware, sono necessarie informazioni dettagliate sul tuo harware o la tua configurazione hardware. Di solito l'output del dmesg(8) è sufficente per questo. E'necessaria una descrizione dettagliata del tuo problema. Come vedi, il dmesg descriveva l'hardware, il testo spiegava perché Smart User pensava che il sistema non fosse difettoso (la 3.2 girava correttamente), cosa causava questo crah (lanciare X), e l'output dei comandi "ps" e "trace" del debugger. In questo caso, Smart User ci ha fornito l'output catturato da una console seriale; se non fosse possibile, dovrai usare carta e penna per annotare il crash. (Questo era un problema vero, e le informazioni nel report qui sopra ci hanno aiutato a sistemare questo problema che impattava i sistemi Sun4c).
Se Smart User avesse avuto un sistema OpenBSD funzionante dal quale mandare il bug report, avrebbe usato l'utility sendbug(1) per sottomettere il bug report al sistema di tracciamento dei problemi GNATS. Ovviamente non puoi usare sendbug(1) quando il tuo sistema non si avvia, ma dovresti sempre usarlo quando possibile. Dovrai comunque includere informazioni dettagliate su cosa è successo, la configurazione esatta del tuo sistema e come riprodurre il problema. Il comando sendbug(1) richiede che il tuo sistema sia in grado ti spedire email su internet. Tieni presente che il mail server usa il greylisting basato su spamd(8), per cui potrebbe volerci circa mezz'ora prima che il mail server accetti il tuo bug report, per cui sii paziente.
Dopo aver sottoposto un bug report con sendbug(1), verrai avvisato via mail dello stato del report. Potresti essere contattato dagli sviluppatori per maggiori informazioni o con le patch da testare. Puoi anche monitorare gli archivi della mailing list bugs@openbsd.org (i dettagli sono sulla pagina delle mailing list o interrogare il database dello stato dei bug report sul Sistema di Tracciamento dei Bug online.
Perso il "Panic message"?
In certe circostanze, puoi perdere il primissimo messaggio di un panico
di sistema, che dice il motivo del panico.
E' un messaggio importantissimo, per cui dev'essere riportato. Lo puoi
ricavare usando il comando "x/s *panicstr" (eXamine String
*panicstr) in ddb> in questo modo:
ddb> x/s *panicstr 0: kernel: page fault trap, code=0 ddb> |
In questo caso, la "panic string" era: "Kernel: page fault trap, code=0"
Nota speciale per i sistemi SMP:
Dovresti ottenere una "trace" per ogni processore da includere nel report:
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}>
|
Ripeti il comando "machine ddb x" seguito da "trace" per ogni processore sulla tua macchina.
[FAQ Index] [Sezione 1 - Introduzione a OpenBSD] [Sezione 3 - Ottenere OpenBSD]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org