No more maintained.
Now just a test in a lab.
Linux post-installation check-list
Operazioni da compiere su un sistema Linux dopo averlo installato dal CDROM. Security fixes e patches.
Procedure di post-installazione su server
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
L'installazione di un sistema Unix o Linux con il CD-ROM ufficiale è solo la prima fase della preparazione di un server per essere messo in produzione.
A questa vanno fatte seguire alcune customizzazioni quali:
- Aggiornamento dei pacchetti, per evitare di avere programmi con bug o buchi.
- Rimozione dei servizi non utilizzati e potenzialmente pericolosi
- Ricompilazione del kernel. Non indispensabile ma raccomandabile.
- Customizzazione del sistema secondo policy congruenti e generali.
- Intervento su alcune configurazioni riguardanti la sicurezza del sistema.
- Installazione e configurazione dei servizi di produzione.
Sono indicazioni di massima generiche che possono essere evitate su macchine desktop o sistemi senza problematiche di sicurezza ma che diventano fondamentali su sistemi direttamente su Internet.
Aggiornamento del software installato
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
Utilizzare software opensource ha vantaggi e svantaggi.
Uno degli svantaggi, o quantomeno effetti collaterali, è che relativamente spesso vengono rilasciati aggiornamenti di software comuni, caratteristica per'altro comune anche a software proprietario.
Le nuove versioni possono avere nuove feature, dei bug corretti o dei buchi di sicurezza tappati.
Abituarsi a sapere quali software vengono utilizzati sui server in produzione e sapere che è fisiologico doverli aggiornare è fondamentale per un approccio sicuro all'uso di Linux su server pubblici.
Ogni sistema Linux DEVE (dovrebbe?) essere aggiornato appena dopo l'installazione ed essere mantenuto costantemente aggiornato, almeno per i programmi che offrono servizi accessibili dalla rete.
Ogni distribuzione Linux seria prevede il rilascio regolare di pacchetti di aggiornamento (alcuni li chiamano "errata") per il software fornito con i CD ufficiali.
Possono essere diversi gli strumenti utilizzati in diverse distribuzioni (i principali sono: apt per Debian e derivate, yum per Fedora e derivate, swaret per Slackware, yast2 per Suse, urpmi per Mandrake...) ma simile è la loro logica: permettere l'aggiornamento, anche automatico, di tutti i pacchetti installati sul sistema, appoggiandosi a mirror pubblici ufficiali.
In linea con la logica conservativa dei sistemi di pacchettizzazione del software su Linux, gli aggiornamenti generalmente non generano disservizi:
- Se si sono dipendenze, queste vengono gestite coerentemente;
- I file di configurazione modificati dall'utente non vengono sovrascritti;
- I servizi vengono patchati e riavviati;
- Tutto funziona esattamente come è giusto che funzioni (e non si deve riavviare il sistema se non per l'aggiornamento del kernel stesso).
E' possibile valutare e decidere, sulla base della criticità, del numero e di quanto sia aderente agli standard della propria distribuzione, se gestire in modo automatico gli aggiornamento (tipicamente tramite schedulazione notturna) o farlo manualmente.
In ogni caso è buona norma, soprattutto se si devono amministrare più server Linux, avere in un proprio repository locale un mirror con tutti gli aggiornamenti che vengono rilasciati.
Fa risparmiare parecchio tempo e, se ben mantenuto, facilita l'ordinaria amministrazione e l'aggiornamento dei server.
Selezione dei servizi da avviare su Linux
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
Ogni distribuzione Linux installa una quantità di servizi che vengono automaticamente avviati al boot.
Alcuni sono necessari per il funzionamento generale del sistema, altri funzionali ai servizi che il server deve offrire, alcuni possono essere inutili per la sua attività e quindi andrebbero disattivati.
L'amministratore del sistema, a seconda della distribuzione usata, ha a disposizione diversi strumenti per gestire quali servizi far avviare al boot. Questi possono essere tool grafici, integrati nelle interfacce di amministrazione di default o comandi shell e variano:
Su Fedora, RedHat e derivati: ntsysv, chkconfig e tool grafico system-config-services
Su Debian: update-rc.d
Su Suse: chkconfig e Yast2
Su Mandrake: chkconfig e Mandrake Control Center
Su Gentoo: rc-update
Strumenti di ammnistrazione generici come Webmin o Linuxconf permettono altresì la gestione dei servizi da avviare ai vari run level del sistema.
Segue una lista, non completa, dei principali servizi che si trovano di default su installazioni Linux, alcuni nomi sono comuni anche in altri Unix. Viene indicato quando è il caso di disattivarli e quando sono sempre necessari, ovviamente sono indicazioni di massima, che vanno adattate alle singole situazioni.
E' basata sui servizi di una RedHat ormai datata, su nuove e altre distribuzioni possono variare i nomi e la quantità, ma in questo caso è importante considerare quali sono i servizi strettamente indispensabili.
anacron Controlla il demone di pianificazione anacron - Comodo su workstation, inutile su un server
apmd Controllo dell'alimentazione e del login - Utile in un portatile
arpwatch Monitora le variazioni di arp entry. Utile per individuare azioni di arp poisoning
atd Controlla il demone at - Evitabile in un server
autofs Controlla il demone per l'automount di Filesystem - Utile in una workstation
crond Controlla il demone di pianificazione di sistema cron - Sempre attivo
ctm SNMP Traffic monitor - Utile per monitoring
httpd Controlla il server Web Apache e i servizi HTTP - Solo su server web
identd Server Ident - Solo in casi particolari
(x)inet Superdemone Inet - Da attivare solo se configurato per lanciare altri servizi (telnet, ftp, ecc.)
innd Server News - Solo su server news
keytable Controlla il caricamento della mappa di tastiera - Sempre attivo
kudzu Controlla e verifica la presenza di nuovo hardware - Utile per una workstation
linuxconf Permette l'accesso via web all'interfaccia di linuxconf - Da evitare su un server
lpd Controlla i servizi dello spooling di stampa - Da evitare su un server
mars-nwe Controlla i servizi di sistema compatibili Netware - Da attivare solo se si utilizzano sistemi Netware
named Controlla l'avvio e l'arresto del Domain Name Service - Solo su server DNS
netfs Controlla i Mount e Umount di tutti i Network Filesystem - Solo se si usano FS di rete
network Controlla l'avvio e l'arresto dei sistemi di rete - Sempre attivo
nfs Controlla i servizi del Network File System - Solo su server NFS
nfslock Controlla i servizi del Network File System - Solo su server NFS
pcmcia Controlla i servizi delle schede per computer portatili - Solo su portatili
portmap Controlla i servizi per la procedura di chiamata remota - Necessario per NFS, NIS+ ecc.
postgresql Controlla il demone di PostgreSQL database - Solo su un SQL Server
random Controlla la generazione dei numeri casuali - Sempre attivo
routed Controlla un RIP router daemon - Solo su un router, se serve
rstatd Controlla il demone delle statistiche del kernel di rete rpc.statd. - Da evitare
rusersd Controlla i servizi di rete dell'rpc.rusersd. - Da evitare
rwhod Controlla il demone di rete rwhod per i servizi di rwho - Da evitare
sendmail Controlla i servizi di trasporto di posta - Solo su server SMTP
smb Controlla i demoni Samba smbd e nmbd - Solo su file server CIFS-SMB
snmpd Controlla il demone del protocollo Simple Network Management - Utile per monitoring
syslog Avvia e arresta i servizi di logging di sistema - Sempre attivo
xfs Avvia e arresta il server font X11 - Necessario per l'uso di Xwindows
*bind Controlla i servizi di binding NIS - Solo su sistemi NIS
Esempi di customizzazione del sistema
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
Esempi di customizzazioni post-installazione praticabili su sistemi Linux - Unix.
Sincronizzare l'ora con un time server
E' sempre buona cosa avere l'ora sincronizzata su tutti i server che si gestiscono. Il modo migliore di farlo è utilizzare un NTP server centrale per la propria rete (può essere un router Cisco, particolarmente semplice da configurare, o un ntp server Linux) e usarlo come time server da parte di tutti gli host.
Su Linux il comando ntpdate time.server.com (presente nel pacchetto ntp-*.rpm|dep ) esegue la sincronizzazione dell'ora locale con quella di time.server.com.
Si consiglia di crontabbare questo comando e di eseguirlo ad ogni boot.
Redirezionare le mail per root
La maggior parte delle mail che invia il sistema o i singoli programmi vengono redirezionate alla mailbox dell'utente root.
Se si hanno diverse macchine da amministrare risulta scomodo dover controllare la mail di root su ogni sistema.
Una possibilità è forwardare tutte tutte le mail destinate all'utente root ad un account di posta che si controlla regolarmente con il proprio client favorito. Per farlo basta creare il file /root/.forward e inserire nella prima riga l'indirizzo e-mail a cui si vuole forwardare la mail destinata a root, oppure aggiungere a /etc/alias una riga tipo: root: [email protected].
Invio periodico di mail di stato
Può capitare che un sistema venga "dimenticato" dopo essere stato messo in produzione. L'amministratore non lo controlla e eventuali problemi vengono a galla solo troppo tardi, quando sono già avvenuti. Il miglior modo per gestire diversi server sarebbe quello di avere un sistema centralizzato di management e monitoring.
In mancanza di una soluzione esistono comodi e rapidi strumenti che analizzano i log di sistema e mandano, per esempio, una mail di report. Uno dei più usati è Logwatch installato di default in qualche distribuzione, che genera un report quotidiano sullo stato del sistema e lo invia via mail a root (altro buon motivo per leggere le mail di root).
Se si vuole procedere con una soluzione custom, segue un esempio di cosa può essere contenuto nello script che raccoglie info sullo stato del sistema (in questo caso crea un file, con il nome uguale alla data corrente, nella directory /home/getdata, questo file può poi essere inviato via mail tramite cron con mail root < /home/getdata/nomefile):
#!/bin/sh Se è installato sar, fornisce numerose statistiche sull'utilizzo delle risorse
home=/home/getdata
file=$(date '+%Y-%m-%d')
touch $home/$file
/bin/uname -a >> $home/$file Nome del sistema
/bin/df -k >> $home/$file Spazio su disco disponibile
/bin/netstat -rn >> $home/$file Tabella di routing
/sbin/ifconfig >> $home/$file Statistiche su interfacce di rete
/bin/netstat -lp >> $home/$file Programmi con porte aperte
/bin/netstat -s >> $home/$file Statistiche sul TCP/IP
cat /etc/resolv.conf >> $home/$file Nameserver utilizzato
cat /etc/hosts >> $home/$file Mapping statici nome host - IP
ps -adef >> $home/$file Processi in esecuzione
/sbin/iptables -L -n -v >> $home/$file Stato del firewall
/usr/bin/who >> $home/$file Utenti connessi al sistema
/bin/cat /root/.bash_history >> $home/$file History dell'utente root
/usr/bin/sar -A >> $home/$file
Linux security check-list
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED
Riassumiamo qui una serie di configurazioni e ottimizzazioni post-installazione che possono aumentare il livello di sicurezza del sistema.
Non ci addentriamo nei particolari, ci si limita a dare indicazioni operative, lasciando a chi legge gli approfondimenti del caso.
Alcune indicazioni sono necessarie solo per server fisicamente posizionati in luoghi non sicuri ed in qualche modo accessibili da estranei (PHYSICAL), altre sono particolarmente pignole e dedicate a chi ha particolarmente a cuore la sicurezza del sistema o è particolarmente paranoico (PARANOID), altre ancora in qualche modo possono compromettere le funzionalità di parti del sistema per cui vanno adottate e testate adeguatamente (DISFUNCTION?), alcune sono particolarmente raccomandate (RECCOMENDED).
Queste impostazioni si riferiscono ad una distribuzione RedHat 7.2 standard. Su altre distribuzioni le posizioni dei file possono essere diverse e le indicazioni date vanno adattate.
In ogni caso queste indicazioni NON bastano a rendere un server sicuro, ma vanno affiancate ad altre precauzioni (aggiornamento costante di programmi e kernel - esposizione solo dei servizi strettamente necessari - utilizzo di IPTABLES adeguate - controllo della sicurezza dei servizi pubblici - installazione di un IDS e di un file integrity checker - log check regolare - BACKUP!).
Settare una password sul BIOS - PHYSICAL - RECCOMENDED
Necessario per impedire che si possa modificare il device di boot, impedendo la possibilità di fare password recovery o accesso non protetto ai dati bootando da floppy o CDROM estranei. Considerare che la password del BIOS è resettabile switchando un jumper sulla scheda madre. Il vero paranoico impedisce anche l'apertura del case se la macchina si trova in luoghi fisicamente non sicuri.
Strong password policy - RECCOMENDED
Le password di fatto sono il baluardo principale per permettere l'accesso al sistema. Se sono semplici, triviali, recuperabili da un dizionario o brevi sono password deboli.
E' possibile forzare il numero minimo di caratteri composti da una password editando /etc/login.defs e forzando a 8 il numero minimo di caratteri della password con PASS_MIN_LEN 8.
Altra opzione interessante presente nello stesso file è PASS_MAX_DAYS 99999 dove 99999 è la durata della password. Ha senso inserire un PASS_MAX_DAYS 180 per forzare il cambio della password ogni 180 giorni. Attenzione: Queste modifiche vanno fatte PRIMA di aggiungere utenti alla macchina. PASS_MAX_DAYS 99999 e altri parametri sono comunque modificabili successivamente in /etc/shadow.
Cript a lot - RECCOMENDED
E' fondamentale per un server pubblico che si gestisce via Internet rimuovere l'accesso telnet e sostituirlo con SSH, che cripta i dati trasmessi (e quindi login e password per l'accesso). SSH comunque non è esente da difetti, la versione 1 del protocollo ha potenziali buchi e in passato ci sono state serie vulnerabilities su alcuni software SSH. Si raccomanda di usare una versione recente di OpenSSH con supporto di SSH2, chiave di almeno 1024 bit e con accesso root diabilitato.
Permission restriction - PARANOID - DISFUNCTION?
In molte distribuzioni, spesso, alcuni file hanno di default permessi in lettura per tutti gli utenti anche quando non è necessario.
Non è una brutta idea restringere questi permessi, lasciando che sia root Colui Che Può:
chmod 600 /etc/inetd.conf Se presente inetd.conf. Ovviamente è pure necessario editarlo per rimuovere tutti i servizi inutili.
chmod 600 /etc/xinetd.conf Se presente Xinetd invece di inetd. Stesse raccomandazioni.
chmod 700 /etc/xinetd.d La directory dove Xinetd ha il file di configurazione per i singoli servizi.
chmod -R 700 /etc/&rc.d/init.d/* La directory dove sono presenti gli script di avvio. Perchè un normale utente dovrebbe vederlI?
Restrizione /etc/aliases - PARANOID - DISFUNCTION?
/etc/aliases gestisce gli alias di posta, spesso di default si forwardando a root la posta di altri utenti. E' opportuno commentare alcuni alias, inseriti di default, per evitare potenziali exploit tramite il loro utilizzo (in particolare l'alias decode). Segue una lista delle righe di /etc/aliases che si possono commentare o rimuovere. Dopo la modifica del file va eseguito il comando newaliases per rendarla effettiva:
# uucp: root
# operator: root
# games: root
# ingres: root
# system: root
# toor: root
# manager: root
# dumper: root
# decode: root
Boot loader password - PHYSICAL - RECCOMENDED
Impedire l'accesso alle opzioni del bootloader è fondamentale in un server fisicamente non custodito.
Se si usa lilo aggiungere a /etc/lilo.conf la riga password= e assicurarsi che lilo.conf sia leggibile solo da root.
Se si usa grub aggiungere a /etc/grub.conf la riga password e assicurarsi che grub.conf sia leggibile solo da root o, meglio, usare l'opzione password --md5
Disabilitare CTRL-ALT-CANC - PHYSICAL - RECCOMENDED
Sicuramente non ci piace l'idea che chiunque possa riavviare il nostro server con un comodo CTRL+ALT+CANC, per renderlo impossibile commentare in /etc/inittab la riga: ca::ctrlaltdel:/sbin/shutdown -t3 -r now
Stampare i log! - PARANOID
La prima cosa che fa un intrusore una volta preso possesso del sistema e coprire le proprie tracce, modificando e cancellando i log che ne possano rilevare l'entrata.
Questo è evitabile se si ha molta carta da sprecare: è possibile configurare syslog per stampare (su stampante a feed continuo) i log che si vogliono. E' semplice, basta aggiungere una riga come quella che segue ed avere una stampante funzionante su /dev/lp0
authpriv.* /dev/lp0
Usare un syslog server
Leggermente meno sicuro e definitivo del metodo precedente è quello di loggare i propri log su un syslog server remoto, opportunamente blindato, che risulti, per quanto possibile, inattaccabile per l'intrusore. Sul syslog locale aggiungere/modifcare:
authpriv.* @nomesyslogserver
Sul syslog server configurare /etc/rc.d/init.d/syslog per lanciare syslogd con l'opzione di accettare messaggi dalla rete, aggiungendo -r alle opzioni di startup.
In RedHat 7.2 modificare la riga: SYSLOGD_OPTIONS="-m 0" con SYSLOGD_OPTIONS="-r -m 0"
Buona scelta è anche usare alternative più sicure (paranoiche?) a syslogd.
Limitare la history della shell
E' possibile limitare la history predefinita della bash per ridurre i rischi che un hacker, leggendola, possa vederci delle password digitate per sbaglio.
Caso tipico è l'utente che prova a diventare superuser e scrive la password al momento sbagliato, passandola come comando shell (che probabilmente non verrà trovato) invece che come input alla richiesta della password. Tale leggerezza resta immortalata nella history della sua shell.
Editare /etc/profile per ridurre la dimensione della history. Modificare HISTSIZE=1000 in HISTSIZE=25 (o il valore che si preferisce).
Non urlare la proria identità - RECCOMENDED
Nonostante esistano tool come queso in grado di rivelare il sistema operativo installato su una macchina, è sempre buona norma fornire il minor numero possibile di informazioni sul sistema ed i suoi servizi. Questo non basta per fermare un bravo hacker, ma può essere abbastanza per fuorviare lo scan di uno script kiddie.
Per quanto riguarda i singoli servizi (web, dns, ssh, smtp ecc) riferirsi alle relative documentazioni per trovare il modo di nascondere versione e nome del programma utilizzato. Per quanto riguarda il sistema si può evitare di mostrare a console o via telnet/ssh un verboso banner introduttivo con nome distribuzione e versione del kernel.
Su RedHat7.2 editare rispettivamente /etc/issue e /etc/issue.net per mascherare versioni di kernel e distribuzione.
Su RedHat più vecchi uno sciagurato script di avvio (/etc/rc.d/rc.local) riscriveva ogni volta questi file con le informazioni originarie. In questo caso è necessario commentare le righe dello script che riscrivono /etc/issue e /etc/issue.net.
Rimuovere RPM, GCC e altri comandi utili - DISFUNCTION?
Se si vuole rendere la vita difficile ad un intrusore, e anche complicarsi un po' la propria, considerare la possibilità di spostare il comando RPM in una directory non standard (meglio cambiandogli anche il nome per evitare che un find lo trovi) o metterlo direttamente in un luogo inaccessibile (floppy estraibile).
Analogamente si può pensare di rimuovere dal sistema tutti i tool necessari per compilare del codice come gcc, make e le relative libraries (utili all'hacker che vuole crearsi delle backdoor) e i comandi che si possono usare per prendere un file dalle rete (lynx, ftp, irc, ncftp, wget, scp, rcp ...) e che si possono impropriamente essere utilizzare per caricare sulla macchina programmi estranei.
Queste precauzioni, seppur efficaci in un contesto di sicurezza estrema, rendono molto meno comoda e pratica la vita dell'amministratore.
Restringere le opzioni di mount del file-system - DISFUNCTION?
Il file /etc/fstab contiene le informazioni su quali dispotivi possono essere montati sulla macchina e può definire delle opzioni che introducono limitazioni sul file-system montato.
Per esempio un /etc/fstab con queste righe:
/dev/hda2 /tmp ext2 defaults 1 2
/dev/hdc1 /home ext2 defaults 1 1
può essere modificato con opzioni che restringono, sui file system montati, la possibilità di eseguire binari (noexec), di onorare i bit setUID e setGID su file che li hanno (nosuid), di interpretare caratteri o dispositivi a blocchi speciali (nodev):
/dev/hda2 /tmp ext2 nosuid,nodev,noexec 1 2
/dev/hdc1 /home ext2 nosuid,nodev 1 1
Limitare gli utenti che possono fare SU - RECCOMENDED
Qualsiasi utente con una shell sul sistema con il comando su, può diventare root (sapendo la password). Si può stroncare alla radice questa velleità editando il file /etc/pam.d/su e scommentando la riga:
auth required /lib/security/pam_wheel.so use_uid.
Una volta fatto, solo gli utenti appartenti al gruppo wheel (è un gruppo speciale, non si possono usare altri gruppi arbitrari per questa operazione) possono fare su, per cui editare /etc/group ed aggiungere al gruppo wheel gli utenti abilitati ad eseguire su.
Compilare un kernel linux
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
La compilazione del kernel è un passaggio importante per molti sistemi Linux.
Oltre ai vantaggi di performance che derivano dalla customizzazzione del kernel si possono evitare possibili problemi di sicurezza legati a features che non sono indispensabili per l'erogazione del servizio oppure al semplice funzionamento di un device particolare.
Di fatto, seppur non indispensabile, è sempre raccomandabile la ricompilazione di un kernel su un server destinato ad andare in produzione ed essere accessibile via Internet.
I passaggi per la compilazione di un kernel sono relativamente semplici e schematici:
Download e scompattazione dei sorgenti; configurazione; compilazione; installazione del kernel.
- DOWNLOAD DEI SORGENTI O DELLE PATCH
Il sito ufficiale per il kernel linux è http://www.kernel.org, dove si ha la possibilità di scaricare i sorgenti del kernel nelle sue varie versioni. Si può scaricare l'intero file dei sorgenti con documentazione che si presenta come un tar.gz o tar.bz2 di 20-30 Mbyte, oppure scaricare solo le patch, di dimensioni molto minori, che, di versione in versione, contengono solo le differenze nei sorgenti.
- SCOMPATTARE IL TARBALL SCARICATO
La directory in cui scompattarlo è /usr/src. E' necessario avere l'ambiente di compilazione in /usr/src/linux, per cui si usa, generalmente, creare un link simbolico di nome /usr/src/linux che punta alla directory che contiene effettivamente i sorgenti del kernel (es: ln -s /usr/src/linux-2.4.18 /usr/src/linux). Cambiando il puntamento del symlink /urc/src/linux è possibile passare velocemente a compilare kernel di diverse versioni.
- APPLICAZIONE DELLE EVENTUALI PATCH
In questo caso verrà applicata la patch 2.4.19 per patchare il kernel 2.4.18
[root@dido linux]# cat ../patch-2.4.19 | patch -p1
patching file COPYING
patching file CREDITS
patching file Documentation/Changes
patching file Documentation/Configure.help
[...]
- PULIZIA DEI SORGENTI
E' un operazione richiesta ogni volta che si compilano dei sorgenti precedentementa già compilati.
[root@dido linux]# make clean
make[1]: Entering directory `/usr/src/linux-2.4.17/arch/i386/boot'
rm -f tools/build
rm -f setup bootsect zImage compressed/vmlinux.out
[...]
rm -f procfs_example.sgml
make[1]: Leaving directory `/usr/src/linux-2.4.17/Documentation/DocBook'
- CONFIGURAZIONE DEL NUOVO KERNEL
Ci sono diverse interfacce per configurare il kernel. Il comando più utilizzato è make menuconfig, ma se si ha una macchina con X attivato si ha la possibilità di utilizzare un frontend grafico con il comando make xconfig, altrimenti si ha la possibilità di utilizzare un comando make config per utilizzare un front-end del tutto testuale.
[root@dido linux] make menuconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts/lxdialog all
make[1]: Entering directory `/usr/src/linux-2.4.17/scripts/lxdialog'
make[1]: Leaving directory `/usr/src/linux-2.4.17/scripts/lxdialog'
/bin/sh scripts/Menuconfig arch/i386/config.in
Using defaults found in .config
Preparing scripts: functions, parsing........................................................................done.
[root@dido linux] make xconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts kconfig.tk
make[1]: Entering directory `/usr/src/linux-2.4.17/scripts'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkparse.o tkparse.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkcond.o tkcond.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkgen.o tkgen.c
gcc -o tkparse tkparse.o tkcond.o tkgen.o
cat header.tk >> ./kconfig.tk
./tkparse < ../arch/i386/config.in >> kconfig.tk
echo "set defaults \"arch/i386/defconfig\"" >> kconfig.tk
echo "set ARCH \"i386\"" >> kconfig.tk
cat tail.tk >> kconfig.tk
chmod 755 kconfig.tk
make[1]: Leaving directory `/usr/src/linux-2.4.17/scripts'
wish -f scripts/kconfig.tk
[root@dido linux]# make config
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
/bin/sh scripts/Configure arch/i386/config.in
#
# Using defaults found in .config
#
*
* Code maturity level options
*
Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?]
[...]
Dopo aver configurato le singole componenti del kernel da attivare (è la fase più importante, in quanto una errata scelta può portare al blocco del sistema al reboot o al mancato supporto di alcuni device della propria macchina) si ha la possibilità di salvare la propria configurazione su un file alternativo, altrimenti quando si esce dal menu di configurazione verrà chiesto di salvare la configurazione in .config, file di default per la compilazione del kernel.
- MODIFICA DEL MAKEFILE - Solo se si usa make install per l'installazione automatica del kernel
Per semplificare le operazioni dell'installazione dell'immagine del kernel è sufficiente scommentare la seguente riga nel makefile, per ritrovarsi la copia dell'immagine e dei file relativi indispensabili al boot nel PATH configurato (abbinato al comando make install):
# INSTALL_PATH specifies where to place the updated kernel and system map
# images. Uncomment if you want to place them anywhere other than root.
export INSTALL_PATH=/boot
Se questa operazione non viene fatta i file compilati del nuovo kernel dovranno essere spostati a mano, secondo le indicazioni sotto riportate.
E' possibile inoltre aggiungere una EXTRAVERSION che permette di identificare compilazioni dello stesso kernel ma con configurazioni diverse.
EXTRAVERSION =-SARUMAN
- COMPILAZIONE DEI SORGENTI
Eseguire in sequenza i seguenti comandi:
make dep Crea le dipendenze per la compilazione dei sorgenti
make clean Esegue un clean
make bzImage Crea l'immagine del kernel che verra' caricata al boot
make modules Compila i moduli
make modules_install Copia i moduli in /lib/modules/$KERNEL_VERSION
- INSTALLAZIONE DEL NUOVO KERNEL
Eseguite tutte le operazioni per la compilazione si deve installare l'immagine del kernel, si hanno due alternative:
Manuale
All'interno della directory, /usr/src/linux/arch/$arch/boot/ si avrà l'immagine del kernel (Il file bzImage) la quale dovrà essere copiata manualmente in /boot possibilmente con un nuovo nome per evitare sovrascrizioni nelle prossime compilazioni.
Dove $arch corrisponde al nome dell'architettura del sistema per cui e' stato compilato il kernel:
neo@eva:~$ls -l /usr/src/linux/arch/
total 72
drwxr-xr-x 7 root root 4096 2004-02-23 11:13 alpha
drwxr-xr-x 21 root root 4096 2004-02-23 11:13 arm
drwxr-xr-x 7 root root 4096 2004-02-23 11:13 cris
drwxr-xr-x 7 root root 4096 2004-02-23 11:13 i386
drwxr-xr-x 14 root root 4096 2004-02-23 11:13 ia64
drwxr-xr-x 20 root root 4096 2004-02-23 11:13 m68k
drwxr-xr-x 34 root root 4096 2004-02-23 11:13 mips
drwxr-xr-x 6 root root 4096 2004-02-23 11:13 mips64
drwxr-xr-x 8 root root 4096 2004-02-23 11:13 parisc
drwxr-xr-x 13 root root 4096 2004-02-23 11:13 ppc
drwxr-xr-x 8 root root 4096 2004-02-23 11:13 ppc64
drwxr-xr-x 7 root root 4096 2004-02-23 11:13 s390
drwxr-xr-x 6 root root 4096 2004-02-23 11:13 s390x
drwxr-xr-x 8 root root 4096 2004-02-23 11:13 sh
drwxr-xr-x 9 root root 4096 2004-02-23 11:14 sh64
drwxr-xr-x 8 root root 4096 2004-02-23 11:14 sparc
drwxr-xr-x 9 root root 4096 2004-02-23 11:14 sparc64
drwxr-xr-x 9 root root 4096 2004-02-23 11:14 x86_64
Automatica
Tramite il comando make install, si ha la possibilità di spostare in modo automatico i file nella directory /boot:
make install Copia l'immagine del kernel nella posizione precedentemente definita nell'INSTALL_PATH
- CONFIGURAZIONE DEL BOOT LOADER
Configurare il boot loader inserendo la possibilità di eseguire il boot con il nuovo kernel.
Ricordarsi sempre di mantenere un'immagine di un kernel funzionante con la relativa entry nel boot loader come backup per evitare spiacevoli inconvenienti (può capitare di compilare un kernel senza il supporto di driver necessari, che si blocca al boot, per cui è sempre necessario aver la possibilità di bootare con il vecchio, funzionante, kernel).
- REBOOT