Come aggiornare il sistema

Da Wiki di NetBSD Italia.

Versione delle 21:27, 29 mar 2008, autore: NetBSD-it Bot (Discussione | contributi)

(diff) ← Versione meno recente | Versione corrente (diff) | Versione più recente → (diff)

Questo documento introduce brevemente la principale procedura e, forse la più semplice, per mantenere un sistema aggiornato dove per "aggiornato" si intende completo di eventuali correzioni inerenti a fix di sicurezza e bug di varia natura. Il sistema così ottenuto corrisponderà all'ultima versione ufficiale del ramo scelto.

Requisiti

Al fine di evitare inutili complicazioni a voi e un utilizzo "improprio" di questo documento, i seguenti requisiti sono richiesti all'utente:

conoscenza di un editor testuale "puro" come vi (o derivati);
conoscenza della lingua inglese o, in alternativa, di un buon traduttore;
il pacchetto adjustkernel;
il pacchetto CVSup, naturalmente;
una decente potenza di calcolo.

In realtà non tutti i requisiti richiesti sono necessari per completare la procedura ma sono indispensabili se avete deciso di capire quello che state facendo e se non avete troppa voglia di aspettare ore (in qualche caso disperato giorni) prima che il processo di build termini.

NOTA: per installare i pacchetti è consigliato l'utilizzo di pkgsrc il cui uso non è spiegato in questo testo.

Sorgenti

Prima di cominciare con la configurazione e in seguito, con la compilazione del sistema, è chiaramente necessario procurarsene uno. Il metodo più semplice ed immediato in realtà non è quello descritto in questo testo. Tuttavia, essendo questo un documento relativo al "tracking" del sistema, la scelta è stata quasi obbligata.

Tarball

Considerando che, sebbene l'intasamento dei repository CVS a causa dell'apertura di migliaia di connessioni per il download dei sorgenti sia una condizione che non può essere evitata del tutto, è possibile ridurne notevolmente gli effetti scaricando "il grosso" sottoforma di tarball instaurando un'unica connessione al server HTTP/FTP. Per scaricare i sorgenti basta utilizzare ftp(1) specificando il branch desiderato (in questo caso NetBSD-4.0_RC5), come segue:

$ ftp ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-4.0_RC5/source/sets/syssrc.tgz

Una volta ottenuti i sorgenti basta esploderli (di norma nella directory '/'):

Per shell Bourne-like si può procedere nel seguente modo:

# tarex="/tmp/.tarex" ; echo "usr/src/sys/arch" > $tarex ; tar zxf syssrc.tgz -X $tarex -C / ; rm $tarex

Se invece si sta usando una shell csh:

# set tarex "/tmp/.tarex" ; echo "usr/src/sys/arch" > $tarex ; tar zxf syssrc.tgz -X $tarex -C / ; rm $tarex

'NOTA: i file così estratti risiederanno nella directory /usr/src, e non su '/'. Inoltre l'albero dei sorgenti sarà incompleto per tanto la compilazione non può avere luogo. Per effettuare l'aggiornamento consultare le sezioni seguenti.

In questo modo, escludendo i sorgenti dipendenti dalle architetture specifiche, si risparmieranno tempo e spazio. Purtroppo non è attualmente possibile escluderne solo alcune a causa delle limitazioni di tar(1). Tra l'altro è necessario creare un file temporaneo al fine di utilizzare la flag -X in quanto il tool in questione non consente di passare una stringa come argomento (risolvendo, grazie al globbing, anche il problema precedente).

Tuttavia, così facendo si bypassa in modo più o meno elegante il problema delegando il download dei file mancanti a CVSup, il quale si occupa di sincronizzare i sorgenti con l'ultima versione dei repository CVS, come spiegato nel paragrafo relativo.

CVSup

Per aggiornare l'intero albero dei sorgenti è sufficiente creare un file di configurazione ad-hoc per CVSup il quale si occupa di scaricare tutto il necessario richiesto per il build.

Configurazione: file principale

Per "dire" a CVSup come e dove prendere i sorgenti basta creare un file di testo con un editor qualsiasi purché sia fra quelli cosiddetti "puri" (non OpenOffice Writer o Kword o simili ma nvi, vim, emacs - anche cat(1) a limite - ecc.) e scrivergli dentro quanto segue:

# File di configurazione di CVSup.
# Per ulteriori informazioni consultare il manuale di
# riferimento e/o i file di esempio forniti con il software.

# La direttiva "tag" specifica il branch del sistema.
# Per -current commentare questa direttiva.
*default tag=netbsd-4

#
# Parametri di base (i quali dovrebbero essere auto-esplicativi)
#
*default release=cvs
*default delete use-rel-suffix
*default compress
*default umask=00
*default host=cvsup.us.NetBSD.org
*default base=/usr
*default prefix=/usr

#
# Collezioni di considerare
#
netbsd-src # Kernel + Userland
#netbsd-xsrc # Sorgenti di X11
#netbsd-pkgsrc # Sistema dei pacchetti
#netbsd-othersrc # "Tutto il resto"

# Fine del file

A questo punto non resta che salvare il file. Il percorso e il nome sono irrilevanti; tuttavia, per convenzione, in questo documento sarà sato /usr/sup/supfile.

Configurazione: file refuse

Una volta cominciato il "fetching" dei sorgenti l'intero albero delle directory viene copiato dal server CVS sul sistema locale. Questo comporta la copia dei file inerenti alle altre architetture quali amd64, alpha, Xen, ecc. A meno che il lettore non sia uno sviluppatore, e dal momento che stà eggendo questa guida suppongo non lo sia, tutti questi file rappresentano solamente una perdita in termini di tempo per il download e di spazio su disco. L'unico "vero" modo per evitare che questo avvenga è di dire a CVSup di non scaricare a priori questi file. Vediamo come.

NOTA: non è obbiettivo di questo testo spiegare le basi di CVSup quindi andremo subito "al sodo"

Basta aprire nuovamente un file di testo ed inserirvi le seguenti righe al fine di informare CVSup che "queste cose" non servono e che quindi non devono essere scaricate (lista non completa):

src/sys/arch/acorn26
src/sys/arch/acorn32
src/sys/arch/algor
src/sys/arch/alpha
src/sys/arch/amd64
[ .. ]

E così via per tutte le directory relative alle architetture diverse da quella sulla quale si stà avorando. Per una lista completa è possibile consultare la directory src/sys/arch direttamente sull'interfaccia web del CVS ufficiale.

NOTA: gli utenti di macchine IBM compatibili (i386, x86) non devono includere la directory arch/x86 nel file refuse in quanto è necessaria al fine di evitare errori in fase di configurazione come il seguente:

../../../../arch/i386/conf/files.i386:1: cannot open
../../../../arch/x86/conf/files.x86 for reading: No such file or directory

Un altro modo più elegante di scrivere il file refuse è quello di utilizzare le wildcard. Nel caso di i386 una possibile soluzione è la seguente:

src/sys/arch/[!MR][!38]*
src/sys/arch/m88k
src/sys/arch/x86_64

La prima riga includerà ella lista tutti i pattern che non cominciano con 'M' o 'R' e non contengono i numeri 3 od 8 come secondo carattere. In pratica tutto eccetto i file README e Makefile, e gli elementi delle righe successive, le quali sono incluse esplicitamente. Purtroppo CVSup segue lo standard POSIX 1003.2-1992 il quale prevede degli operatori ed una sintassi molto limitata rispetto alle espressioni regolari. Inoltre essendo una lista basata su pattern da NON includere, bisogna pensare in logica negativa e questo rende la situazione leggermente più complessa. Insomma, allo stato attuale bisogna accontentarsi.

A questo punto salvare il file con il nome refuse e metterlo nella directory /usr/sup la quale probabilmente non esisterà e dovrà quindi essere creata.

Sincronizzazione

L'ultimo passo, quello più semplice, è l'avvio della sincronizzazione dei sorgenti la quale potrebbe richiedere diversi minuti dipendentemente dalla potenza di calcolo e banda disponibili. Inoltre, per ovvi motivi, sarebbe bene evitare di eseguire la procedura da utente privilegiato. Questo consente di non dover reimpostare successivamente i permessi prima di effettuare il build dei sorgenti, il quale dovrebbe essere eseguito anche da utente non privilegiato. Quindi i passi da eseguire sono i seguenti:

Impostare i permessi

# chown -R USER /usr/src /usr/sup ; chmod -R u+rwX,go-rwx /usr/src /usr/sup

dove USER corrisponde al nome di login dell'utente non privilegiato.

Sincronizzazione dei sorgenti

$ cvsup /usr/sup/supfile

Eventualmente per maggiori o minori dettagli utilizzare la flag -L rispettivamente con i valori 0 e 2 (1 è quello standard).

Kernel

La compilazione del kernel si divide in 3 fasi: configurazione (scelta delle opzioni), ricerca delle dipendenze (per il linking) e creazione del kernel vero e proprio in un file eseguibile "statico". Le sezioni seguenti spiegano brevemente come configurare ed installare un kernel ad-hoc per la nostra macchina.

Configurazione

Tra requisiti richiesti per eseguire questa procedura è stato incluso un tool (adjustkernel) necessario, anche se non indispensabile, per effettuare le operazioni preliminari relative alla configurazione delle periferiche di sistema. In realtà è uno script in perl che non fa altro che "generare" un file di configurazione modificato basandosi sull'output di dmesg(8); questo è fondamentalmente quello che ognuno di noi avrebbe dovuto fare a mano.

# cd /usr/src/sys/arch/i386/conf
# adjustkernel GENERIC > RELEASE

Nel file RELEASE verrà messo "tutto" il contenuto di GENERIC con le dovute modifiche effettuate da adjustkernel. Questo eviterà di dover perdere tempo a disabilitare periferiche "inutili". Qualcuno potrebbe chiedersi quali, ecco qualche esempio:

pci* at pchb? bus ?
elansc* at pci? dev ? function ? # AMD Elan SC520 System Controller
tcic0 at isa? port 0x240 iomem 0xd0000 iosiz 0x10000
cbb* at pci? dev ? function ?
amdpm* at pci? dev ? function ? # RNG and SMBus 1.0 interface
iopsp* at iop? tid ? # SCSI/FC-AL ports
dpti* at iop? tid 0 # DPT/Adaptec control interface
uha* at eisa? slot ? # UltraStor 24f SCSI
adv0 at isa? port ? irq ? drq ? # AdvanSys APB-514[02] SCSI

Qualche altro esempio potrebbe essere rappresentato così:

st* at scsibus? target ? lun ? # SCSI tape drives
ss* at scsibus? target ? lun ? # SCSI scanners
uk* at scsibus? target ? lun ? # SCSI unknown
ld* at aac? unit ? # logical disk devices
cac* at pci? dev ? function ? # Compaq PCI array controllers
aac* at pci? dev ? function ? # Adaptec AAC family
icpsp* at icp? unit ? # SCSI pass-through

E molti altri inutili supporti abilitati di default. Chiaramente non mancheranno i casi in cui alcuni di questi potrebbero servire, ma una vasta gamma di utenti non utilizza niente di tutto ciò quindi è bene alleggerire ulteriormente il kernel.

Informazioni più dettagliate e pagine consigliate per la lettura sono adjustkernel(1), dmesg(8) e options(4).

Molto probabilmente adjustkernel metterà dei commenti alla fine del suo output (nel file RELEASE). Questi commenti denotano il fatto che l'output di dmesg(8) non trova riscontro all'interno del file di configurazione e di conseguenza i supporti relativi saranno ignorati.

# NOTE: NoMatch: atapibus0 at atabus3: 2 targets
# NOTE: NoMatch: atabus0 at viaide0 channel 0
# NOTE: NoMatch: atabus1 at viaide0 channel 1
# NOTE: NoMatch: atabus2 at viaide1 channel 0
# NOTE: NoMatch: atabus3 at viaide1 channel 1
# NOTE: NoMatch: audio0 at auvia0: full duplex, mmap, independent
# NOTE: NoMatch: atapibus0 at atabus3: 2 targets
# NOTE: NoMatch: atabus0 at viaide0 channel 0
# NOTE: NoMatch: atabus1 at viaide0 channel 1
# NOTE: NoMatch: atabus2 at viaide1 channel 0
# NOTE: NoMatch: atabus3 at viaide1 channel 1
# NOTE: NoMatch: audio0 at auvia0: full duplex, mmap, independent
# NOTE: NoMatch: atapibus0 at atabus3: 2 targets

E' consigliabile riabilitare tutti i supporti.

NOTA: le opzioni ``atabus* at ata?, ``atapibus* at atapi? e ``scsibus* at scsi? verranno disabilitate in ogni caso ignorando l'output di dmesg(8) a causa di un bug dello script (come descritto in adjustkernel(1)). Tali opzioni dovranno quindi essere riabilitate "a mano", qualora fosse necessario.

Infine i seguenti supporti sono necessari per utilizzare periferiche quali flash memory, hard disk USB, eccetera.

umass* at uhub? port ? configuration ? interface ?
wd* at umass?
scsibus* at scsi?

A questo punto è possibile passare alla compilazione "reale" del kernel.

Compilazione

Il metodo più semplice per compilare il kernel su NetBSD è quello di usare lo script build.sh. In realtà questo serve per cross-compilare il sistema, quindi risulta molto comodo aggiornare il sistema all'ultima -current. Utilizzarlo per compilare un rilascio stabile partendo da un rilascio stabile (quindi senza cross-compilare) è comunque possibile usarlo, ma visto che sono stati riscontrati diversi problemi utilizzeremo il metodo "manuale". Ciò nonostante, per chi volesse provare è stata comunque inclusa la procedura di build.

Manuale

Dopo aver finito la configurazione del file del kernel non resta che compilarlo. Ma prima è necessario creare l'occorrente per la compilazione utilizzando config(1), in questo modo:

$ config /usr/src/sys/arch/i386/conf/RELEASE

Al termine un messaggio mostrerà agicamente le operazioni da effettuare in seguito che, per completezza, sono riportati di seguito:

$ cd /usr/src/sys/arch/i386/compile/RELEASE
$ make depend
$ make

Con build.sh

Quanto segue è frutto di diversi esperimenti e attualmente sembra essere il modo universalmente funzionale:

# cd /usr/src
# mkdir ../obj
# chown USER ../obj ; chmod u+rwX,go-rwx ../obj

dove USER corrisponde all'utente non privilegiato. Questo minimizza al massimo gli interventi dell'amministratore, consentendo fra l'altro di effettuare il build da utente non privilegiato, come segue:

$ ./build.sh -O ../obj -U tools
$ ./build.sh -O ../obj -U kernel=RELEASE

Escludendo complicazioni varie, il kernel è pronto! A questo punto non resta che installarlo.

Installazione

# mv /netbsd /netbsd.old

Senza build.sh

# gzip -c /usr/src/sys/arch/i386/compile/RELEASE/netbsd > /netbsd

Con build.sh

# gzip -c /usr/obj/sys/arch/i386/compile/RELEASE/netbsd > /netbsd

Dopo aver riavviato il sistema, salvo complicazioni in ogni caso risolvibili, il kernel è installato ed il sistema sar/à, finalmente, l'ultimo rilascio stabile completo di fix vari e varie patch di sicurezza. Complimenti! :-)

Eventuali problemi

Se qualcosa andasse storto il sistema potrebbe anche non avviarsi disarmando drammaticamente qualsiasi utente. Naturalmente a meno che questo non sappia che esiste una soluzione semplicissima al problema :-)

Procedura per il boot del kernel precedente e ripristino della "situazione":

Prima che il kernel venga avviato premere la barra spaziatrice per fermare il processo ed attivare il prompt di boot. Questo và fatto durante il conto alla rovescia:

booting wd0a:netbsd - starting in 5

Adesso bisogna dire al loader di caricare il vecchio kernel anzichè l'ultimo compilato:

> boot /netbsd.old

Il sistema si avvierà normalmente e potrere tentare di risolvere il problema compilando nuovamente il kernel.

Descrizione della procedura standard illustrata nella documentazione ufficiale del progetto NetBSD:

> boot -s /netbsd.old

Inserire la pass di root
Premere return per accettare la shell /bin/sh
Eseguire i seguenti comandi per ripristinare la versione precedente del kernel

# fsck /
# mount /
# mv netbsd.old netbsd
# reboot

Detto questo, la documentazione basilare relativa al kernel è conclusa. Per ulteriori e dettagliate informazioni si consiglia di consultare il paragrafo approfondimenti.

Userland

Una volta effettuato il build dei tool per la compilazione del kernel non è necessario rieseguirlo nuovamente per compilare l'userland. Questo ci fa risparmiare buona parte del tempo che impiegheremo piuttosto per fare il build dell'userland stessa. Questo si può fare come segue:

$ ./build.sh -O ../obj -U distribution
# ./build.sh -O ../obj -U install=/

Al termine verrà chiesto di eseguire qualche piccola operazione di controllo. Il comando da usare viene scritto da build.sh stesso e l'output sarà simile a questo:

postinstall checks passed: gid hosts named pam sendmail ssh wscons x11 uid obsolete
postinstall checks failed: defaults makedev mtree periodic postfix rc
To fix, run:
     /usr/src/usr.sbin/postinstall/postinstall -s /usr/src -d // fix defaults \
     makedev mtree periodic postfix rc

A questo punto eseguire:

# /usr/src/usr.sbin/postinstall/postinstall -s /usr/src -d // fix defaults \
  makedev mtree periodic postfix rc

E l'output risultante dovrebbe terminare con due righe simili a queste:

postinstall fixes passed: defaults makedev mtree periodic postfix rc
postinstall fixes failed:

Ciò evidenzia il fatto che l'operazione è andata a buon fine in quanto sulla seconda riga (failed) non vi è elencato nulla.

Prima di riavviare il sistema o di chiudere la sessione root è consigliabile eseguire etcupdate(8) e, visto che risulterebbe eccessivamente fastidioso e inutile eseguirlo in un secondo momento, facciamolo subito lanciando il comando etcupdate.

NOTA: l'utilizzo di etcupdate(8) non è argomento di questo testo per tanto si consiglia di consultare il manuale di riferimento.

# etcupdate -s /usr/src

Per "simpatia" dirò solo che etcupdate(8) confronta i file del "set etc" con quelli presenti nel sistema e usa sdiff(1) per visualizzare le differenze. Per ogni file mostra una serie di opzioni e le rispettive descrizioni. Maggiori informazioni possono essere trovate sul manuale.

Al termine della configurazione verrà chiesto di eliminare la directory temporanea (/tmp/temproot) a di creare i nodi per le periferiche (devices nodes) in /dev. Rispondere 'y' ad entrambe le domande:

Remove /tmp/temproot? (y/[n]) y
*** Removing /tmp/temproot
Do you want to rebuild the device nodes in /dev? (y/[n]) y
*** Running /usr/sbin/postinstall
Source directory: /usr/src
Target directory: /
defaults check:
gid check:
hosts check:
makedev check:
mtree check:
named check:
pam check:
periodic check:
postfix check:
rc check:
sendmail check:
ssh check:
wscons check:
x11 check:
uid check:
obsolete check:
postinstall checks passed: defaults gid hosts makedev mtree named pam
periodic post
fix rc sendmail ssh wscons x11 uid obsolete
postinstall checks failed:
*** All done
#

Dopo l'eventuale riavvio, il sistema sarà efinitivamente aggiornato.

Binari

Questo sezione spiega il metodo più rapido per aggiornare il sistema operativo NetBSD utilizzando l'ultima versione dei binari ufficiali disponibili.

Teoria

Download dei set e del kernel: la prima cosa da fare è procurarsi tutti i componenti aggiornati (sottoforma di file compressi - i set e il kernel) contenenti il sistema operativo, i quali possono essere scaricati liberamente da uno dei mirror ufficiali di NetBSD.

Installazione del kernel: prima di aggiornare il sistema è indispensabile aggiornare il kernel al fine di gestire correttamente i nuovi supporti messi a disposizione. Dopo il riavvio del sistema si potrà procedere all'aggiornamento per mezzo dell'esplosione dei set.

Esplosione dei set: a questo punto non resta che esplodere i set nella root directory rimpiazzando i file del sistema corrente, aggiornandolo.

Controllo e correzione dei file di configurazione: una volta installato il nuovo sistema è necessario eseguire postinstall(8) per controllare la correttezza dei file di configurazione e sistemare eventuali errori.

Aggiornamento della configurazione: è il momento di copiare i file di configurazione i quali, sebbene con qualche piccolo accorgimento potrebbero essere rimpiazzati totalmente, risulta più comodo aggiornarli per mezzo di etcupdate(8) che consente, attraverso una procedura guidata, di effettuare un aggiornamento controllato.

Riavvio del sistema: l'ultimo passo richiesto è il riavvio del sistema, dopo il quale si può essere certi della correttezza della procedura seguita. Qualora ci fossero problemi il sistema potrebbe non avviarsi correttamente, motivo per cui rimando alla documentazione ufficiale per maggiori dettagli.

Pratica

Creo la directory

$ mkdir binary ; cd binary

Scarico i set

$ ftp ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200708260002Z/i386/binary/sets/

NOTA: questo percorso è soggetto a variazioni. La forma generica è la seguente:

ftp://HOST/pub/NetBSD-daily/netbsd-BRANCH/SNAPSHOT/ARCH/binary/sets

dove le parole scritte in maiuscolo hanno i seguenti significati:

HOST: l'host del server FTP dalla quale prelevare i file
BRANCH: il ramo di rilascio (3.x, 4.x, etc.)
SNAPSHOT: il nome della directory della snapshot (ricavata dalla data)
ARCH: l'architettura (i386, sparc64, etc.)

ftp> mget base.tgz comp.tgz etc.tgz games.tgz man.tgz misc.tgz text.tgz kern-GENERIC.tgz 
mget base.tgz [anpqy?]? a
Prompting off for duration of mget.
229 Entering Extended Passive Mode (|||51146|)
[ .. ]

Installo il kernel

# tar zxf kern-GENERIC.tgz ; ln -fh /netbsd /netbsd.old ; gzip -c netbsd > /netbsd

Riavvio il sistema
Esplodo i set (eccetto etc.tgz ed il kernel, ovviamente)

# cd binary
# for set in [!ek]*.tgz ; do tar zxfp $set -C / ; done

Eseguo etcupdate(8)

NOTA: al fine di prevenire la corruzione del sistema è consigliabile non installare i file passwd, master.passwd e rc.conf. Questo è un problema molto diffuso fra i nuovi utenti i quali, sebbene spesso non sia necessario, si trovano costretti a reinstallare l'intero sistema operativo.

# etcupdate -s etc.tgz

Riavvio il sistema

Conclusioni

In genere questa tipologia di aggiornamento è indicata per utenti non molto avanzati che vogliono una -current rapida su cui mettere sù tutto il software di cui hanno bisogno. Questo può essere installato attraverso il sistema dei pacchetti di NetBSD compilando il software su misura per le proprie esigenze o utilizzando i pacchetti binari (precompilati) disponibili online sui mirror FTP ufficiali, installandoli attraverso pkg_add(1). Naturalmente i due sistemi sono totalmente interscambiabili (l'utilizzo di uno non preclude l'altro) per tanto è consigliata la lettura della documentazione relativa a entrambe i metodi di gestione dei pacchetti.

Approfondimenti

Al fine di ottenere una maggiore dimestichezza con le procedure di gestione del software, dal kernel all'interfaccia utente ai programmi di terze parti, è consigliata la lettura di alcuni documenti che serviranno a completare la formazione dell'utente.

Come compilare il kernel: guida specifica e dettagliata che tratta unicamente l'aggiornamento del kernel e argomenti ad esso correlati
Primi passi con NetBSD: interessante how to che introduce gradualmente il sistema operativo NetBSD con un approccio semplice e comprensivo. Il documento tratta l'installazione, la configurazione e l'utilizzo (di base) di NetBSD, inclusa la gestione dei pacchetti, con riferimenti esterni volti a rendere totale la comprensione del testo e di argomenti correlati.
Il sistema dei pacchetti: guida completa sull'utilizzo, l'estensione, lo sviluppo e l'hacking di pkgsrc. Il testo copre tutte le caratteristiche di questa struttura software, inclusi i pacchetti binari.