A me però sta particolarmente sulle balle.
Così, visto che mi è già capitato due volte di chiudermi fuori da una box remota pistolando sul firewall a caso – ed è decisamente umilante rompere le balle al prossimo per il riavvio in loco del server – ho ben deciso di scrivere un semplice scriptino in bas in cron.daily, che rilancia periodicamente il file con la configurazione del firewall “standard”.

Che odio.

Se si ha libero accesso fino al bootloader (GRUB o LILO) che sia, si è a cavallo. Procediamo.

Quando il bootloader carica il kernel lancia init che è il processo padre di tutti i processi in ambiente Linux; init di conseguenza avvia getty per il login e il sistema è pronto.

Accedendo alle stringhe di GRUB (premendo “e”) possiamo invece modificare il comportamento all’avvio.

Definito il device di avvio con root, la stringa kernel identifica il percorso all’immagine del kernel da avviare, nonche’ la partizione dove si trova.
In fondo alla riga kernel possiamo aggiungere un parametro che forzi init ad iniziare dal programma che preferiamo:

In questo modo il sistema si avvierà lanciando la console come primo processo e non richiedera’ password all’avvio (sic).
Per reimpostare la password di root è sufficiente utilizzare il comando passwd, ma le cose potrebbero non andare per il verso giusto poichè a quel livello la partizione è montata read-only.

Sarà quindi necessario rimontare la partizione di root con

e poi cambiare la password.

Nel caso il bootloader fosse protetto, la modifica di GRUB non sarebbe possibile come ho descritto. In quel caso sarà comunque semplice aggirare l’ostacolo con un media di boot (chiavetta, floppy o cd che sia).

Se la password è messa a livello di bios, meglio resettare la scheda madre.

echo 3 > /proc/sys/vm/drop_caches

man proc

-r

recursivo

-b

mette direttamente in background. Spamma un log su wget-log

-nH

non voglio una dir col nome dell’host

–cut-dirs=4

taglia i primi 4 livelli (unix, linux, mirrors, slackware)

-X isolinux

esclude una lista di argomenti separati da virgola

wget è una utility che consente di scaricare files (o gerarchie di file) da riga di comando: un download rapido e comodo sui protocolli HTTP(S) e FTP; puo’ funzionare in background e ha notevoli potenzialità spiegate nel man.

Ci sono un sacco di guide sul web, e come sempre tirare le somme in maniera organica non è banale.
Una lista di comandi come segue SENZA spiegato che significa non ha senso (imho).

make clean
$ make dep
$ make bzImage
$ make modules
# make modules_install

Una scaletta un po’ più seria (ma sicuramente da perfezionare):
* prendete il kernel nuovo (kernel.org)

* mettete sotto /usr/src/ e scompattate

* il kernel viene “partorito” da una compilazione con # make. Make si appoggia ad un Makefile che si appoggia a sua volta ad un file testuale di configurazione (.config nella dir dove ci stanno i sorgenti).

* Si può cambiare qualche aspetto importante andando a modificare le variabili dentro il Makefile (quelle in stampatello all’inizio). Per esempio:

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 29
EXTRAVERSION = .1
NAME = Temporary Tasmanian Devil

Modificare EXTRAVERSION può risultare molto utile, poichè in /lib/modules/ vengono caricati i moduli necessari al kernel all’avvio, e la stringa che forma la dir concatena anche quel parametro (insomma, si possono tenere separati i vari moduli di versione in versione).

* L’operazione di configurazione del kernel è fondamentale, e io la realizzo con un comando: $ make menuconfig
NOTA: Io uso menu config perchè mi è comodo e usa le solite interfacce coloratine da terminale figlie di ncurses. Ovviamente esistono altre opzioni: dal più testuale config, ai grafici xconfig e gconfig (mai usati, ma sono certo siano esteticamente validi e ugualmente efficaci). Se si vuole caricare una configurazione vecchia (ie: esiste già un .config precedentemente redatto) si puo’ usare il comando $ make oldconfig.
NOTA2: Ci sono anche alcune opzioni per creare file .config con caratteristiche standard: $ make allnoconfig, $make allyesconfig, ecc. Per ulteriori info, leggere il README.

* Dopo aver create il .config, con $ make si compila il kernel vero e proprio (che comparirà magicamente sotto arch/x86/boot/bzImage .
ATTENZIONE: basta scrivere $ make per ottenere ciò che in molte guide e’ indicato come $ make dep, $ make bzImage, $ make modules. Insomma, il tutto si è evoluto, e non c’è più necessità di indicare che è necessario compilare le dipendenze (dep), l’immagine (bzImage, big compressed image) e i moduli; make già sa, e basta e avanza.
NOTA: Se si vuole avere più output con make, si può dare il comando $ make V=1 (o 2).

* Se si è configurato il kernel in maniera monolitica (cioè all-in-one), si deve spostare il tutto sotto /boot e via. Nel caso si siano indicati dei moduli, bisogna compilarli. il comando è # make modules_install e, come si evince facilmente, installa i moduli del kernel nel filesystem (sotto /lib/modules/linux-2.x.x.EXTRAVERSION-XXXX).

* Si potrebbe dare anche $ make install per installare il kernel compilato nel posto giusto, ma io non mi fido e lo copio a mano (ie: # cp /usr/src/linux-2.xx.xx/arch/x86/boot/bzImage /boot/kernel-2.xx.xx).
NOTA: $ make install si basa su /sbin/installkernel che viene lanciato da arch/x86/boot/install.sh coi parametri estrapolati dallo script.

system.map è una mappa di simboli utile al kernel che viene caricata all’avvio, ma non necessaria.

* Nel caso le cose vadano storte (e ci andranno, of course), è necessario ripulire i sorgenti appena compilati e tornare alla situazione iniziale. Soluzione stupida: cancellare tutto e scompattare l’archivio. Soluzione migliore: usare i comandi di make. Come si legge nel Makefile:

# Cleaning is done on three levels.
# make clean     Delete most generated files
#                Leave enough to build external modules
# make mrproper  Delete the current configuration, and all generated files
# make distclean Remove editor backup files, patch leftover files and the like

Di solito sono sufficienti i primi due: se si vuole tenere la configurazione, si lancia $ make clean; se si vuole cancellare tutto $ make mrproper.

In qualunque caso, ci vengono in aiuto il file README, il Makefile (si puo’ leggere, davvero!) e $ make help (le info di cosa puo’ fare il makefile, che forse è meglio che leggere il codice del Makefile. ).
Esiste anche la dir Documentation/ che tiene tante di quelle info da uscirne scoppiati (cominciare dal file HOWTO).

Visto che ultimamente ho smandruppato con slackware m’è toccato guardare un po’ LILO (LInux LOader). Preferisco GRUB, ma vabbè.
Dunque, lilo è l’altro (il primo) bootloader. A differenza di grub che si legge il file di configurazione menu.lst e questo gli basta, lilo necessita di un file di configurazione /etc/lilo.conf (che è molto semplice ed intuitivo da capire) e di una compilazione per essere a posto.
La compilazione la si ottiene dando il comando # lilo. Se si vuole fare un test (imho fondamentale), meglio postporre al comando il flag -t. Il flag -v aumenta la verbosità, ovviamente.

Un link da esplorare: kernel niubbi.

Robba (vecchia) da leggere:
Configurare, compilare e installare un kernel 2.6 per (open)SUSE Linux di Thomas Hertweck (2006)
KernelAnalysis-HOWTO di Roberto Arcomano (2003)
The Linux Installation HOWTO di Eric Steven Raymond (2002)

Le prime righe di solito sono abbastanza chiare (uptime, load average, processi in corso). La terza fornisce info riguardanti i processi della CPU al momento: us per i processi avviati nello userspace, sy per quelli del sistema-kernel, id indica il valore di “cazzeggio” della cpu – se è alto non è molto impiegata. Sui valori wa , hi, si e st attualmente preferisco non pronunciarmi, ma sono indici di interazione fra la cpu e (rispettivamente) il disco, l’hardware, il software, le virtualizzazioni; se sono bassi è meglio, se sono alti indicano problemi o iper-attività sui device.

La riga più significativa:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

PID, USER, %CPU e COMMAND non li spiego.

PR

Indica la priorità del processo – in termini di cicli di cpu. Un valore basso indica che il processo verrà buttato nella cpu più spesso.

NI

Valore di nice del processo. E’ un modificatore di priorità.

VIRT

Quantità di memoria richiesta dal processo. (Grazie a questo si puo’ verificare se è vero che firefox è pesante… si, lo è. )

RES

Memoria residente, cioè la memoria che il processo sta effettivamente usando.

SHR

Memoria condivisa fra processi, magari poichè ci sono librerie in comune.

S

Come nella seconda riga di top, indica quali processi stanno andando, quali dormienti, ecc…

%MEM

Indica la percentuale di memoria che il processo ha occupato nell’ultimo ciclo.

TIME+

Indica la quantità di tempo totale di sfruttamento della CPU ha il processo.

top modifica l’output in tempo reale e permette anche di modificarlo attraverso alcune key.

i

permette di visualizzare (o no) i processi in attesa (idle).

P

ordina i processi in funzione dell’uso della CPU.

M

ordina i processi in funzione dell’uso della memoria.

u

permette di visualizzare solo i processi di un determinato utente.

k

ci permette di killare un processo da top.

r

ci permette di ridefinire la priorità del processo (renice). (Cercherò di scrivere un post per spiegare nice e renice.)

n

per visualizzare un arbitrario numero di processi.

m

visualizzare (o no) la parte relativa alle memorie (mem e swap).

B

Potrebbe essere anche utile evidenziare le voci importanti.

s/d

Se la frequenza di aggiornamento non piace, si puo’ definire il numero di secondi (non negativo, e 0 potrebbe non dare i risultati sperati).

W

Dopo aver impostato tutto, se volete salvare le vostre impostazioni. (In /home/$user/.toprc)

Con man top si potranno vedere moltri altri comandi.

Un po’ come nella quantistica, dove la misurazione altera il sistema misurato (principio di indeterminazione FTW), top è molto bello ma influenza il sistema (del resto si aggiorna in tempo reale, interrogando tutto e tutti di continuo); per questo esistono anche altri strumenti “statici” di controllo: ps per i processi, uptime per vedere dati sul sistema, free per la memoria.

In generale si parla di dati di 4 categorie (2 a coppie): condivisibili e non condivisibili, statici o variabili.
I dati nelle home o le configurazioni di solito sono non condivisibili (/home), gli eseguibili sono condivisibili. I comandi eseguibili sono intesi come statici (/bin), i log come variabili (/var/mail).

Queste sottodirectory di root normalmente sono presenti:

bin	Essential command binaries
boot	Static files of the boot loader
dev	Device files
etc	Host-specific system configuration
lib	Essential shared libraries and kernel modules
media	Mount point for removeable media
mnt	Mount point for mounting a filesystem temporarily
opt	Add-on application software packages
sbin	Essential system binaries
srv	Data for services provided by this system
tmp	Temporary files
usr	Secondary hierarchy
var	Variable data

/usr è indicato come un filesystem gerarchico secondario, perchè anche se è una subdir di /, ha una sua struttura che replica fedelmente quella del parent. Di norma i file in /usr sono condivisibili e read-only.

/proc fornisce informazioni sul sistema ed è la parte del fs che contiene le operazioni del kernel (quindi non c’entra niente con quel che c’è nell’hdd).

sim@idrogeno:~$ ls /proc
1      2      2426  2900  3100   7328       cmdline      mtrr
10     2016   257   2902  31014  7329       config.gz    net
11     2109   2574  2930  351    7330       cpuinfo      pagetypeinfo
1111   2110   258   2931  354    7331       devices      partitions
1399   2133   259   2933  366    7332       diskstats    scsi
15364  21816  260   2936  369    7336       dma          self
1578   21817  261   2938  390    7560       driver       slabinfo
1579   21818  2624  2939  4      7569       execdomains  stat
1587   21819  2638  2940  418    7573       filesystems  swaps
16320  21820  2669  2942  5      7698       fs           sys
16365  22295  2682  2943  514    7813       ide          sysvipc
18215  2277   2683  2944  6      7887       interrupts   timer_list
183    2279   2684  2945  6699   8          iomem        tty
184    2280   2685  2949  6909   8090       ioports      uptime
185    2281   2686  2958  6918   86         irq          version
186    2282   2687  2970  6979   87         kallsyms     vmallocinfo
1886   2302   2698  2974  6980   88         kmsg         vmstat
1895   2309   2709  2995  7      8889       kpagecount   zoneinfo
1904   23686  2715  2997  7049   89         kpageflags
191    2385   2716  3     7070   9          loadavg
1914   23956  2744  3019  7079   9005       locks
1925   2399   2857  3040  7324   acpi       meminfo
1926   2409   2860  3041  7325   asound     misc
194    24186  2861  3060  7326   buddyinfo  modules
1943   24191  2899  3098  7327   bus        mounts

Le directory coi numeri danno informazioni riguardo i processi (il numero rappresenta il pid), e contengono al loro interno informazioni come il comando dato per lanciare il processo, i settori di memoria riservati, le variabili di sistema a disposizione, ecc.

Altri come /proc/cpuinfo, /proc/devices (e version, uptime, ecc.) si spiegano da soli.

Whypecché?

Il punto chiave è che l’interfaccia grafica visualizzava i filename attraverso samba, che per essere sicuro di non danneggiare nessuno (ie: Win), cambiava i filename in qualcosa di non contenente wildcard o altre stranezze.

• scaricate l’immagine della distro debian (5.0) con il DE che preferite da qui (io sono andato sulla i386, usb-hdd, xfce).
• copiate su una chiavetta con $ dd if=immagine_debian_live.img of=/dev /chiavetta /usb
  Attenzione: copiate sul device della chiavetta, non su quella della partizione (ie: /dev/sdc, non /dev/sdc1)
• Inserite la chiavetta in una porta usb e riavviate il pc, facendo il boot dalla chiavetta (ie: F8 per avere il menu di boot).

Facile e utile.

Essenzialmente Sua Maestà il K non mi prendeva la (fondamentale) riga che gestisce le connessioni già attive.

$IPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Poiché il firewall è in effetti gestito a livello di kernel, e l’errore era su uno stato specifico (-m state) era chiaro che m’ero dimenticato di includere un modulo… sic.

La prossima volta, meglio ricordarsi di inserire lo state match support sotto Core Netfilter Configuration (CONFIG_NETFILTER_XT_MATCH_STATE).

La diff fra le due configurazioni (ho aggiunto un paio di altre cose, in effetti):

<pre>idrogeno:/boot# diff config-2.6.29-H-090430 /usr/src/linux/.config
4c4
< # Thu Apr 30 21:03:34 2009
---
> # Sun May  3 14:15:51 2009
62c62
< CONFIG_LOCALVERSION="-H-090430-02"
---
> CONFIG_LOCALVERSION="-H-090430-04"
436c436
< # CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
---
> CONFIG_NETFILTER_XT_MATCH_COMMENT=m
445,446c445,446
< # CONFIG_NETFILTER_XT_MATCH_HELPER is not set
< # CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
---
> CONFIG_NETFILTER_XT_MATCH_HELPER=m
> CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
459c459
< # CONFIG_NETFILTER_XT_MATCH_STATE is not set
---
> CONFIG_NETFILTER_XT_MATCH_STATE=m
463c463
< # CONFIG_NETFILTER_XT_MATCH_TIME is not set
---
> CONFIG_NETFILTER_XT_MATCH_TIME=m