Modulo 7: La ricompilazione del Kernel; la gestione dei log di sistema; il demone cron

A cosa serve il file .img di initrd ?

Consider a system with zero IDE disks and one SCSI disk containing a LINUX installation. There are BIOS interrupts to read the SCSI disk, just as there were for the IDE, so LILO can happily access a kernel image somewhere inside the SCSI partition. However, the kernel is going to be lost without a kernel module [lsqb ]See Chapter 42. The kernel doesn't support every possible kind of hardware out there all by itself. It is actually divided into a main part (the kernel image discussed in this chapter) and hundreds of modules (loadable parts that reside in /lib/modules/) that support the many type of SCSI, network, sound etc., peripheral devices.] that understands the particular SCSI driver. So although the kernel can load and execute, it won't be able to mount its root file system without loading a SCSI module first. But the module itself resides in the root file system in /lib/modules/. This is a tricky situation to solve and is done in one of two ways: either (a) using a kernel with preenabled SCSI support or (b) using what is known as an initrd preliminary root file system image.

The first method is what I recommend. It's a straightforward (though time-consuming) procedure to create a kernel with SCSI support for your SCSI card built-in (and not in a separate module). Built-in SCSI and network drivers will also autodetect cards most of the time, allowing immediate access to the device--they will work without being given any options [lsqb ]Discussed in Chapter 42.] and, most importantly, without your having to read up on how to configure them. This setup is known as compiled-in support for a hardware driver (as opposed to module support for the driver). The resulting kernel image will be larger by an amount equal to the size of module. Chapter 42 discusses such kernel compiles.

The second method is faster but trickier. LINUX supports what is known as an initrd image ( initial rAM disk image). This is a small, +1.5 megabyte file system that is loaded by LILO and mounted by the kernel instead of the real file system. The kernel mounts this file system as a RAM disk, executes the file /linuxrc, and then only mounts the real file system.

Anche per poter scaricare i moduli dal kernel è necessario attivare la rispettiva opzione durante la compilazione del kernel.

• 
  Uname –release serve per capire la versione del kernel e quindi anche il nome della directory da cui verranno prelevati i moduli sotto /lib/modules.
  
• 
  Se si hanno più kernel compilati e utilizzati sulla stessa macchina modprobe è in grado di capire dalla versione del kernel quali moduli andare a caricare dalla corretta directory in /lib/modules.
  
• 
  If the kernel fails to load a module (say loadable module for network card or other devices), then you may want to try to build the driver for device right into the kernel. Sometimes loadable module will NOT work and the driver needs to be built right inside the kernel. For example - some network cards do not support loadable module feature - you MUST build the driver of the network card right into linux kernel. Hence, in 'make xconfig' you MUST not select loadable module for this device.
  
• 
  Esercitazione: aggiornare il kernel all’ultima versione stabile disponibile scaricando i sorgenti da www.kernel.org (al momento dell’ultima revisione di questo documento la 2.4.28 e la 2.6.8).
  

Loadable modules are pieces of kernel code which are not linked (included) directly in the kernel. One compiles them separately, and can insert and remove them into the running kernel at almost any time. Due to its flexibility, this is now the preferred way to code certain kernel features. Many popular device drivers, such as the PCMCIA drivers and the QIC-80/40 tape driver, are loadable modules.

Su www.kernel.org si può trovare l’ultima versione del kernel da poter compilare (2.4.28 per la 2.4); I sorgenti possono essere scaricati in maniera completa oppure se esiste, sotto forma di patch da versione X a versione Y; le patch si applicano ai sorgenti e POI si recompila il kernel. (vedi comando patch).
gestione dei log

• 
  il demone responsabile della gestione dei log è syslogd (può essere controllato /etc/rc.d/init.d/syslog start|stop.
  
• 
  Cosa viene loggato ed in che modo è controllato in /etc/syslog.conf
  

# Logging much else clutters up the screen.

#kern.* /dev/console

(é commentato quindi i messaggi del kernel vanno nel file messages)

# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!

*.info;mail.none;authpriv.none;cron.none /var/log/messages

(tutti i messaggi di tipo info vanno in /var/log/messages tranne mail, authpriv e cron)

# The authpriv file has restricted access.

authpriv.* /var/log/secure

(Log per authpriv; contiene tutti le login fatte ad ftp, ssh, telnet ecc.)

# Log all the mail messages in one place.

mail.* /var/log/maillog

(Log per la posta)

# Log cron stuff

cron.* /var/log/cron

# Everybody gets emergency messages

*.emerg *

# Save news errors of level crit and higher in a special file.

uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log

local7.* /var/log/boot.log

• 
  /var/log/wtmp contiene i vari login effettuati con il tempo di durata (viene esaminato tramite il comando last).
  
• 
  /var/log/utmp contiene informazioni sugli utenti correntemente collegati (visibile con who, w).
  
• 
  /var/log/lastlog contiene informazioni sull’ultima login effettuata da ogni utente (si visualizza con lastlog).
  
• 
  Il programma che effettua la rotazione dei log è /usr/sbin/logrotate ed è configurato in /etc/logrotate.conf); nella configurazione può essere stabilito quante settimane di log mantenere ed ogni quanto effettuare la rotazione e se comprimere o meno i log.
  
• 
  rotate count
  
• 
  Log files are rotated times before being removed or mailed to the address specified in a mail directive. If count is 0, old versions are removed rather then rotated.
  
• 
  Normalmente i log vengono ruotati ogni settimana (comando weekly) e vengono effettuate rotazioni (a seconda del comando rotate) prima di essere distrutti (o copiati da qualche parte o inviati per posta).
  
• 
  Le impostazioni particolari per ogni tipo di log (ad esempio quello di Apache in /var/log/httpd/*) vengono definite nella directory /etc/logrotate.d con singoli script per ogni demone che decide come gestire i propri log (oltre alle impostazioni valide per tutti i log definite in /etc/logrotate.conf).
  

• 
  I job possono essere schedulati con il comando at oppure con il comando crontab tramite l’utilizzo del demone crond; job che devono girare sempre ad intervalli regolari è bene che utilizzino cron.
  
• 
  At è controllato dal demone atd: /etc/rc.d/init.d/atd start; la sintassi è at 16:50 , il comando at chiede i comandi da eseguire fino alla sequenza di caratteri CTRL-D; il risultato dell’esecuzione del job dovrebbe essere inviato all’utente sotto forma di mail (/etc/at.allow e /etc/at.deny stabiliscono restrizioni nell’utilizzo del comando at).
  
• 
  Ogni utente ha una propria crontab; crontab –l visualizza la crontab corrente per l’utente e crontab –e edita la crontab (crontab –r la rimuove).
  
• 
  01 17 * * * ls /home/david > /tmp/lista 2>&1 (ad esempio esegue il comando alle 17 e 01 tutti i giorni (il significato dei 5 parametri prima del comando da eseguire e’: minuti, ore, giorno del mese, mese, giorno della settimana; ‘*’ significa tutti).