Slacky.eu - Contributi utente [it]

Slackware su pennina USB

2013-04-30T12:37:58Z

Targzeta:

[[Category:Install_e_Upgrade]]
=Introduzione=
Questo wiki vuole essere una guida, il più completa possibile, sui passi da fare per crearsi un propria distribuzione Slackware su un dispositivo di archiviazione di massa USB (che da ora in poi chiameremo più semplicemente, pennina).<BR>
Affronteremo tutti i vari passaggi strettamente necessari a far partire un kernel installato sulla pennina ed a creare/configurare la distribuzione Slackware.<BR>
Ovviamente, benché pensata e testata sulla Slackware, la teoria che acquisiremo alla fine di questo wiki sarà tale da permetterci di installare una qualsivoglia distribuzione, la differenza sarà solo sugli strumenti che useremo.

Tutti o quasi tutti i comandi che eseguiremo durante il wiki devono poter godere dei diritti dall'utente root, e per questo saranno caratterizzati dal carattere iniziale '#' che è tipico della shell del super-utente.

I path e i comandi verranno evidenziati rispettivamente dallo stile corsivo e dal font grassetto in questo modo:
* ''/questo/è/un/path''
* '''questo è un comando'''

=Perché installare la distribuzione su una pennina?=
Alcuni esempi d'uso verranno esposti alla fine del wiki, ma facciamo comunque alcune considerazioni importanti.<BR>
Questa guida è rivolta a tutti coloro che sono curiosi, affamati di conoscenza, che usano il PC non solo come strumento di lavoro, ma anche con la voglia di portare alla luce ciò che sembra arcano. Lo scopo del wiki non è la creazione della distribuzione tascabile, bensì la divulgazione della conoscenza, è importante che il lettore tenga presente questo concetto, perché è quello che ci preme rimanga più a lungo nella mente di chi legge questo wiki.<BR>
Oltre ad avere una pennina da portare nei negozi di informatica per testare i PC che solitamente hanno installato solo lo scadente Windows, acquisiremo una conoscenza più o meno approfondita di tutti i programmi necessari all'avvio di una distribuzione GNU/Linux.

=Software usato=
Gli strumenti software che sono stati usati per testare questo wiki sono:
* Slackware 12 (sebbene alcuni utenti l'abbiano testato con successo anche sulla 13.0, 13.1, 13.37 e sulla 14.0)
* kernel huge, presente nella directory della serie ''a/'' della Slackware
* comandi linux che verranno citati man mano, tutti comunque presenti nella distribuzione Slackware
L'elenco sopra citato è da tenere a mente sia perché citeremo nomi di pacchetti Slackware, sia perché il kernel huge fornisce un sopporto tale che alcuni problemi che si potrebbero incontrare verranno solo citati, in quanto risolti grazie alla sua configurazione statica.

=Fase 0: preparazione della pennina=
Noi installeremo la distribuzione Slackware direttamente sulla pennina, iniziamo allora preparando proprio il nostro supporto di archiviazione di massa USB.<BR>
L'unica cosa di cui abbiamo bisogno e di installarci dentro un file system ext3. Le pennine USB, proprio come gli hard disk, possono essere partizionate, supponiamo quindi che sulla pennina ci sia un unica partizione e che questa venga collegata dal kernel al device ''/dev/sda1''. Installiamoci dentro un file system ext3 con il seguente comando:
# mkfs.ext3 -L minislack /dev/sda1
Da Slackware 13 in poi è possibile usare ext4:
# mkfs.ext4 -L minislack /dev/sda1
bene, quella che abbiamo appena creato sarà la directory radice della nostra distribuzione.

Per salvaguardare la salute della nostra perdrive è una buona idea disattivare il journaling, che è predefinitivamente attivo su questi filesystem, in modo da ridurre le scritture su disco:
# tune2fs -O ^has_journal /dev/sda1
'''ATTENZIONE:''' tutti i file sulla pennina saranno ovviamente persi dopo l'esecuzione del comando '''mkfs.ext3''' o '''mkfs.ext4''', quindi facciamo in modo che la pennina sia vuota prima di lanciare il comando.

'''Nota:''' si noti l'uso dell'opzione -L per impostare un etichetta al file system appena creato, vedremo dopo a cosa ci servirà. L'etichetta del file system la si può impostare/modificare anche successivamente attraverso l'uso del comando '''e2label''' o '''tune2fs -L'''.

=Fase 1: creazione dell'initrd=
Più in là nel wiki, vedremo come far caricare il kernel di linux installato su una pennina, qui invece ci apprestiamo ad affrontare un problema inerente proprio al fatto che la distribuzione si trova su una periferica USB.

==Perché dobbiamo creare un initrd?==
Una volta caricato il kernel, esso si preoccupa di attivare tutti i driver che sono stati compilati in maniera statica al suo interno. L'attivazione avviene in maniera parallela, il kernel cioè non attiva un driver, aspetta che esso abbia finito di inizializzarsi e poi ne attiva un altro, ma li attiva tutti quanti "contemporaneamente". Dopo questa fase di inizializzazione dei driver il kernel deve montare quella che è la root directory (o directory radice) della distribuzione, la famosa directory ''/''. Una volta montata la directory radice, esegue quello che sarà l'unico processo avviato direttamente dal kernel (che in generale è il processo '''/sbin/init''').
* Ma i driver (o controller) USB potrebbero non essere stati compilati in maniera statica nel kernel, e senza i driver il kernel non si accorge neanche della presenza della pennina, come possiamo risolvere questo problema?
* Non solo, ma anche ammesso che il kernel abbia i driver compilati in maniera statica, questi devono avere il tempo di accorgersi che al PC è collegata una pennina USB, come si può dire al kernel di aspettare visto che i driver sono attivati in maniera parallela?
* Ancora, come facciamo a sapere su quale device si verrà a trovare la directory radice? Il driver USB collegherà la pennina al device sda o sdb, oppure ad un altro?
* E infine, la directory radice che abbiamo creato sulla pennina usa il file system ext3 (o ext4), il kernel per poter riconoscere e di conseguenza usare questo file system ha bisogno del driver, e se questo driver non è compilato in maniera statica?

Per tutti questi problemi esiste una soluzione unica, l'initrd. L'initrd fondamentalmente non è altro che una mini distribuzione la cui directory radice viene montata in ram, più precisamente collegata al device ''/dev/ram0'', con un programma o uno script (che si deve chiamare '''init''' o '''linuxrc''') che viene avviato dal kernel (il quale deve essere compilato con il supporto all'initrd) subito dopo aver inizializzato i driver. Il kernel in pratica non si occupa più di montare la root directory e di lanciare il processo '''/sbin/init''', ma semplicemente lancia il comando (o script) '''init''' che è nell'initrd e delega a lui tutto il resto.<BR>
Questo semplice meccanismo ci permette in pratica di creare uno script per risolvere tutti i problemi sopra citati.

'''Nota:''' Quando il kernel carica in memoria l'initrd e lancia il programma (o lo script) init, la root directory della nostra distribuzione non è ancora montata! Quindi la distribuzione non esiste, e con lei non esistono tutti i programmi usuali che uno pensa di usare nell'initrd. Se si vuole usare un programma, lo si deve copiare nell'ambiente dell'initrd e si devono copiare anche tutte quelle librerie condivise di cui il programma necessita.

==Initrd come archivio cpio==
Uno dei modi più semplici per creare un initrd è quello di inserire tutto il necessario in una directory vuota (programmi che si voglio usare nell'initrd, librerie di cui necessitano questi programmi, eventuali moduli del kernel, etc...etc...) e poi di creare un archivio cpio, magari compresso con gzip, di questa directory. Il kernel sarà poi in grado di decomprimere (se era compresso) l'archivio e di estrarne il contenuto.<BR>
Creiamoci allora una directory vuota ed entriamoci dentro con:
# mkdir /tmp/initrd
# cd /tmp/initrd

==Il pacchetto mkinitrd e la busybox==
Il pacchetto mkinitrd della Slackware (che si trova nella directory ''a/'') contiene lo script omonimo '''mkinitrd''', che generalmente viene usato da coloro che necessitano di un initrd e non vogliono (o non hanno le competenze adatte a) crearsene uno a mano.<BR>
Noi useremo il pacchetto, che quindi deve essere installato, non per lanciare l''''mkinitrd''' ma per prelevare il programma '''busybox''' che è al suo interno. Busybox è un programma che si può comportare in maniera diversa a seconda di come lo si invoca, se noi infatti creiamo un link simbolico chiamato mount a '''busybox''', allora questo si comporterà come '''mount'''. L'elenco di tutti i programmi che è in grado di simulare lo si può ottenere lanciando '''busybox''' senza parametri.

Il pacchetto mkinitrd ha la '''busybox''' inserita all'interno di un archivio tar.gz il cui path completo è:
''/usr/share/mkinitrd/initrd-tree.tar.gz''
preleviamo la busybox con:
# tar -C /tmp/initrd -zxf /usr/share/mkinitrd/initrd-tree.tar.gz './bin/busybox'
a questo punto la nostra directory ''/tmp/initrd'' avrà questa struttura:
# tree /tmp/initrd
/tmp/initrd
`-- bin
`-- busybox

==Creiamo lo script init==
Ora dobbiamo creare lo script '''init''', ovvero lo script che verrà eseguito dal kernel dopo l'inizializzazione dei driver e che è incaricato di risolvere i problemi su citati, cioè:
* caricare eventualmente i moduli del kernel per i controller USB e per il file system ext3/4
* dare il tempo ai controller USB di rilevare la pennina e montare, dopo averla scovata, la root directory
* eseguire il vero processo init della distribuzione

Prima di cimentarci nella risoluzione di questi problemi dobbiamo notare che '''init''', per come lo vogliamo utilizzare noi, è uno script, e in quanto tale ha bisogno di un interprete, la '''busybox''' può fare questo per noi visto che al suo interno ha anche una piccola shell. Andiamo nella directory ''/tmp/initrd/bin'' e creiamo un link simbolico a '''busybox''' in questo modo:
# ln -s busybox ash
e quindi con un qualsiasi editor di testo creiamo il file ''/tmp/initrd/init'' e mettiamoci come prima riga:
#!/bin/ash

===Caricare i moduli del kernel necessari al rilevamento della periferica USB e del file system ext3/4===
Il kernel huge è compilato con il supporto sia alle periferiche USB, sia al file system ext3 (o ext4) in maniera statica, e quindi ci permette di superare in maniera trasparente questo problema.<BR>
Si fa notare che il fatto di avere il supporto compilato in maniera statica nel kernel è un fattore da non sottovalutare. Infatti l'ambiente dell'initrd dovrebbe essere il più generale possibile, se spettasse all'initrd (e quindi allo script '''init''') caricare qualche modulo del kernel, allora l'initrd non sarebbe più indipendente, ma al suo interno dovrebbe avere i moduli compilati per il kernel specifico che lo ha eseguito.

===Dare il tempo ai controller USB di rilevare la pennina e montaggio della root directory===
Abbiamo installato sulla nostra pennina USB un file system del tipo ext3 (o ext4) che abbiamo anche etichettato con il nome di 'minislack'. Bene, grazie alla capacità del comando '''mount''' di utilizzare il nome di etichetta per identificare un file system, il problema può essere risolto semplicemente mettendo nello script '''init''' quanto segue:
mount -n proc -t proc /proc
while ! mount -n -r -L minislack /mnt 2> /dev/null;
do
sleep 1
done
umount -n /proc
Il "montaggio" del file system proc è necessario in quanto il comando '''mount''' fa uso di questo file system per scovare l'etichetta 'minislack'.<BR>
Il ciclo '''while''' con lo '''sleep''' non fa altro che dare il tempo necessario ai driver USB del kernel di rilevare la pennina.
Quindi la nostra root directory, o meglio il file system che noi abbiamo etichettato come 'minislack' sarà montato nella directory ''/mnt'' a prescindere dal device a cui il driver USB (e più precisamente il modulo che gestisce le periferiche di archiviazione di massa USB, l'usb_storage) lo ha collegato.

Nelle sei righe di codice precedenti abbiamo:
* usato il comando mount
* caricato il file system proc nella directory /proc
* usato il device null per ridirigere lo standard error del comando mount
* usato il comando sleep per far attendere alla shell 1 secondo
* montato la root directory in /mnt
* utilizzato il comando umount
per quanto potevano sembrare innocenti, quelle sei righe implicano:
* che il kernel al momento dell'esecuzione di queste righe, abbia il supporto al procfs e al tipo di file system della root directory che montiamo su ''/mnt'' (nel nostro caso il kernel huge ce li ha entrambi in maniera statica)
* che esistano i programmi mount, umount e sleep
* che esistano il device ''/dev/null'' e quello al quale sarà collegata la pennina USB (è vero che mount può scovare il device grazie all'etichetta del suo file system, ma è altrettanto vero che poi '''mount''' dovrà montare questo device)
* che esistano le directory ''/proc'' e ''/mnt''

La '''busybox''' può comportarsi come '''mount''' semplicemente facendo un link simbolico ad essa chiamato appunto ''mount'', il problema è che quello fornito dalla '''busybox''' non è in grado di scovare le etichette dei file system (non riconosce il flag -L). Abbiamo necessariamente bisogno del comando '''mount''' del pacchetto util-linux (dalla Slackware 12.1 e successive, il pacchetto si chiama util-linux-ng) contenuto
sempre nella directory della serie ''a/'' della Slackware.<BR>
Copiamo quindi il comando '''mount''' come segue:
# cp -p /bin/mount /tmp/initrd/bin
ora però dobbiamo copiare anche le librerie condivise di cui necessita. Vediamo quali sono lanciando:
# ldd /bin/mount
linux-gate.so.1 => (0xffffe000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7f80000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7f7d000)
libc.so.6 => /lib/libc.so.6 (0xb7e4e000)
/lib/ld-linux.so.2 (0x80000000)

Creiamoci la directory ''lib'' all'interno del nostro initrd con:
# mkdir /tmp/initrd/lib
e copiamoci dentro le librerie condivise con:
# cp -p /lib/libblkid.so.1 /lib/libuuid.so.1 /lib/libc.so.6 /lib/ld-linux.so.2 /tmp/initrd/lib
Si noti che i file originali probabilmente sono link simbolici, ma il comando '''cp''' copierà il file al quale puntano e non il link.

<nowiki>** NOTA **</nowiki>

Su slackware 13.1 il comando '''mount''' necessita di altre librerie:
# ldd /bin/mount
linux-gate.so.1 => (0xffffe000)
/usr/lib/libv4l/v4l1compat.so (0xb7838000)
/usr/lib/libv4l/v4l2convert.so (0xb7836000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb77eb000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb77e7000)
libc.so.6 => /lib/libc.so.6 (0xb7683000)
libv4l1.so.0 => /usr/lib/libv4l1.so.0 (0xb767e000)
libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0xb7674000)
/lib/ld-linux.so.2 (0xb783b000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb765b000)
libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0xb75ef000)
librt.so.1 => /lib/librt.so.1 (0xb75e5000)
libm.so.6 => /lib/libm.so.6 (0xb75bf000)

Quindi sarà necessario copiare anche le nuove librerie:
# cp -p /usr/lib/libv4l/v4l1compat.so /usr/lib/libv4l/v4l2convert.so /usr/lib/libv4l1.so.0 /usr/lib/libv4l2.so.0 /tmp/initrd/lib
# cp -p /lib/libpthread.so.0 /usr/lib/libv4lconvert.so.0 /lib/librt.so.1 /lib/libm.so.6 /tmp/initrd/lib

Su Slackware 13.37 le dipendenze di '''mount''' sembrano essere le stesse della 12, ma anche se non risulta con '''ldd''', serve anche ''/lib/libm.so.6''.
Quindi rispetto alla 12 bisognerà copiare anche libm.so.6:
# cp -p /lib/libm.so.6 /tmp/initrd/lib

Su Slackware 14.0 le dipendenze diventano:
# ldd /bin/mount
linux-gate.so.1 (0xf771b000)
libblkid.so.1 => /lib/libblkid.so.1 (0xf76b3000)
libmount.so.1 => /lib/libmount.so.1 (0xf7687000)
libuuid.so.1 => /lib/libuuid.so.1 (0xf7683000)
libc.so.6 => /lib/libc.so.6 (0xf74fe000)
/lib/ld-linux.so.2 (0xf771c000)

Anche qui non risulta /lib/libm.so.6, ma è necessaria per far funzionare '''mount'''.
Vanno copiate tutte in questo modo:
# cp -p /lib/libblkid.so.1 /lib/libmount.so.1 /lib/libuuid.so.1 /lib/libc.so.6 /lib/libm.so.6 /lib/ld-linux.so.2 /tmp/initrd/lib
<nowiki>** FINE NOTA **</nowiki>

Per il comando '''umount''' e '''sleep''' invece possiamo tranquillamente usare quelli della '''busybox''', quindi andiamo nella directory ''/tmp/initrd/bin'' e facciamo:
# ln -s busybox umount
# ln -s busybox sleep

Il programma '''mount''' l'abbiamo utilizzato passandogli anche il flag -n, dicendogli quindi di non scrivere quello che sarà il file ''/etc/mtab'', benché esso non lo scriva, vuole comunque leggerlo per controllare se il file system che si sta tentando di montare non sia già stato montato. Dobbiamo quindi creare il file vuoto ''/tmp/initrd/etc/mtab'':
# mkdir /tmp/initrd/etc
# touch /tmp/initrd/etc/mtab

Proseguiamo quindi con la creazione del device null e dei possibili device a cui sarà collegata la pennina USB. In generale la pennina USB viene vista come una periferica SCSI disk e quindi sarà attaccata ad un device del tipo ''/dev/sdXY'' dove X varia a seconda di quante periferiche di archiviazione rilevate come SCSI (ad esempio i dischi sata) sono state trovate prima della pennina, mentre Y rappresenta una qualsiasi partizione.<BR>
Se, ad esempio, un PC non ha nessun disco rilevato come SCSI e ci si inserisce una pennina con tre partizioni, queste tre partizioni saranno collegate rispettivamente ai device: sda1, sda2 e sda3.

Y allora la possiamo ricavare facilmente, infatti all'inizio abbiamo supposto che la nostra pennina avesse solo una partizione e che essa (la partizione) venisse attaccata ad device ''/dev/sda1'', allora Y=1 e la pennina sarà sempre collegata ad un device dal nome ''/dev/sdX1''.<BR>
Quindi creiamoci la directory in cui inserire i device:
# mkdir /tmp/initrd/dev
e copiamoci subito dentro il device ''/dev/null'' con:
# cp -R /dev/null /tmp/initrd/dev

Al momento attuale gli SCSI disk sono gestiti dal device driver con major number 8. Questo device driver è in grado di gestire sino a 15 partizioni per ogni disco, questo vuol dire che due device con X consecutive e con uguale Y hanno una distanza (in termini di minor number) pari a 16. Ad esempio il device sda avrà un minor number uguale a 0 laddove il device sdb avrà invece minor number uguale a 16, e così via.

Possiamo allora creare i device con:
# mknod /tmp/initrd/dev/sda1 b 8 1
# mknod /tmp/initrd/dev/sdb1 b 8 17
# mknod /tmp/initrd/dev/sdc1 b 8 33
# mknod /tmp/initrd/dev/sdd1 b 8 49

Ora per rendere tutto coerente con quanto scritto sempre nelle sei innocenti righe di codice inserite nel file ''init'', non ci resta che creare due directory vuote nelle quali verranno montati i file system proc e quello contenente la nostra directory radice.
# mkdir /tmp/initrd/proc /tmp/initrd/mnt

===Eseguire il vero processo init===
L'ultimo passo che deve eseguire lo script '''init''' dell'initrd è quello di lanciare il vero processo '''init''' situato nella directory radice della distribuzione e poi liberare la memoria allocata.<BR>
I passi teorici da eseguire sono:
* spostare la directory radice dell'initrd sulla directory radice della distribuzione
* smontare l'initrd
* deallocare la memoria allocata dal kernel per l'initrd
* eseguire il vero processo '''init'''
Che poi praticamente, dato che per ognuno dei passi precedenti esiste uno specifico programma che lo esegue, diventa:
* cd /mnt; mkdir initrd; pivot_root . initrd
* umount /initrd
* blockdev --flushbufs /dev/ram0
* exec chroot . /sbin/init $@

Il comando '''pivot_root''' ultimamente sembra non comportarsi bene nell'ambiente dell'initrd. Fortunatamente la '''busybox''' ha al suo interno un programma che dovrebbe eseguire tutti i passi precedenti, il comando si chiama '''switch_root ''' e come al solito quindi basta fare un link simbolico a '''busybox''' entrando in ''/tmp/initrd/bin''
ed eseguendo:
# ln -s busybox switch_root

Ora non resta che inserire nello script init quanto segue:
exec switch_root /mnt /sbin/init $@

'''NOTA:''' si noti il passaggio a '''/sbin/init''' dei parametri $@, questi sono i parametri che il kernel non ha riconosciuto nella sua riga di comando (quella passatagli dal loader), e che quindi passa al comando che esegue.

===Lo script init nella sua interezza===
Riassumendo, lo script ''/tmp/initrd/init'' è questo:
<PRE>
#!/bin/ash
# Aspetto finché i driver USB non rilevano la pennina e monto la vera directory radice
mount -n proc /proc -t proc
while ! mount -n -r -L minislack /mnt 2> /dev/null;
do
sleep 1;
done
umount /proc

# Avvio il vero /sbin/init
exec switch_root /mnt /sbin/init $@
</PRE>
questo script deve essere eseguito dal kernel è quindi dobbiamo assicurarci che abbia i diritti di esecuzione:
# chmod u+x /tmp/initrd/init

==Creazione dell'archivio cpio compresso initrd.gz==
La directory ''/tmp/initrd'' ora dovrebbe essere così strutturata:
# tree /tmp/initrd
/tmp/initrd/
|-- bin
| |-- ash -> busybox
| |-- busybox
| |-- mount
| |-- sleep -> busybox
| |-- switch_root -> busybox
| `-- umount -> busybox
|-- dev
| |-- null
| |-- sda1
| |-- sdb1
| |-- sdc1
| `-- sdd1
|-- etc
| `-- mtab
|-- init
|-- lib
| |-- ld-linux.so.2
| |-- libblkid.so.1
| |-- libc.so.6
| `-- libuuid.so.1
|-- mnt
`-- proc

6 directories, 17 files
Non resta altro da fare che creare un archivio cpio di questa directory, comprimerla con il comando '''gzip''' e renderla disponibile al loader di linux.<BR>

Partendo dal solito presupposto che la pennina sia collegata dal kernel al device sda1, la si monti ad esempio nella directory ''/mnt/memory'' con:
# mount /dev/sda1 /mnt/memory
si crei poi una directory in cui inserire l'archivio cpio compresso che è l'initrd con:
# mkdir /mnt/memory/boot
ed infine si crei l'archivio cpio compresso (il tanto sudato initrd):
# cd /tmp/initrd
# find . | cpio -o -H newc | gzip -9 -n > /mnt/memory/boot/initrd.gz

Quando, più in là nel wiki, si configurerà il loader di linux, si vedrà come utilizzare questo file.

=Fase 2: installazione della distribuzione sulla pennina=
Ora ci si occuperà di installare e configurare una serie minimale ma importantissima di pacchetti Slackware.<BR>
Ovviamente non ci sono limitazioni, se non quelle fisiche della pennina, al numero di pacchetti che il lettore può installare, ma per lo scopo di questo wiki è sufficiente installare i pacchetti essenziali a far partire la distribuzione.<BR>
I pacchetti che verranno installati si trovano tutti nella directory ''a/'' della Slackware, quindi, supponendo che il CD o DVD della Slackware sia stato montato nella directory ''/mnt/dvd/'', per prima cosa ci si deve spostare dentro questa directory con:
# cd /mnt/dvd/slackware/a

==Un piccolo accorgimento==
I pacchetti verranno installati sfruttando l'opzione -root dello script '''installpkg''', alcuni dei pacchetti hanno uno script aggiuntivo, il famoso '''doinst.sh''', che viene avviato dopo l'installazione del pacchetto. Gli script '''doinst.sh''' sono "chrootati" sulla pennina e devono poter eseguire comandi, quali ad esempio '''cd''', '''rm''' o
'''ln'''. Questo implica che:
* il programma che il '''doinst.sh''' vuole eseguire deve essere presente sulla pennina
* si abbiano i diritti di esecuzione sulla pennina

La prima implicazione è risolta installando i pacchetti in un ordine ben preciso, facendo in modo di installare prima i pacchetti che contengono i programmi usuali usati dai '''doinst.sh'''.

La seconda implicazione viene verificata se si esegue un piccolo accorgimento, ovvero smontare la pennina e rimontarla con l'opzione 'exec' del '''mount''', in questo modo:
# umount /mnt/memory
# mount -o exec -rw /dev/sda1 /mnt/memory

==I pacchetti da installare==
La domanda è semplice, come si determinano i pacchetti che si devono installare?<BR>
La risposta non è altrettanto semplice, sicuramente ci sarà il programma ''/sbin/init'' per avere un collegamento all'initrd creato nella 'Fase 1', ma poi? Poi bisogna seguire l''''init''' e capire cosa esegue, in modo da fargli trovare i programmi che tenta di eseguire. Se è necessario, bisogna anche seguire i programmi che '''init''' esegue per capire cosa fanno e se hanno bisogno di altri programmi o file di configurazione.<BR>
In generale quindi, il primo file da analizzare è ''/etc/inittab'', file di configurazione di '''init''', ci si accorge quindi che '''init''' esegue una serie di script di inizializzazione, e quindi bisogna seguire questi script per capire cosa fanno.

Per lo scopo di questo wiki il lavoro è stato già fatto dall'autore e quindi verranno segnalati solo i passi fondamentali da fare affinché la distribuzione possa partire.

Qui si riporta l'elenco dei pacchetti che devono essere installati nell'ordine di seguito riportato (l'ordine è importante solo per i primi tre pacchetti). Accanto al nome del pacchetto vi è una piccola descrizione di cosa contiene:
a/aaa_base ---> Crea tutte le directory base
a/coreutils ---> Programmi utilizzati dagli script '''doisnt.sh'''
a/glibc-solibs ---> La libreria glibc, usata da molti eseguibili (tra cui '''init''')
a/glibc-zoneinfo ---> Contiene lo script '''timeconfig''' che verrà usato in seguito
a/dialog ---> Usato per visualizzare i box dei dialoghi da altri programmi
(tra cui '''timeconfig''')
a/bash ---> La shell
a/etc ---> File di configurazione dei programmi utilizzati
a/util-linux ---> Contiene, tra l'altro, il programma '''mount'''. Dalla Slackware 12.1 alla 13.1,
il pacchetto si chiama util-linux-ng
a/sysvinit ---> Contiene il programma '''init'''
a/sysvinit-scripts ---> I famosi script '''rc.d''' della Slackware, invocati da '''init'''
a/module-init-tools ---> '''modprobe''' e altri programmi per gestire i moduli
a/e2fsprogs ---> Comandi per i filesystem ext2/3/4
a/devs ---> I device, senza di questi....
a/findutils ---> '''find''', usato dagli script di inizializzazione
a/aaa_elflibs ---> Libreria libtermcap per i terminali
a/aaa_terminfo ---> File di informazione sui terminali usati dalla libreria libtermcap
a/shadow ---> Contiene, tra l'altro, i programmi '''login''' e '''sulogin'''
a/grep ---> '''grep''', usato dagli script di inizializzazione
a/procps ---> '''ps''', usato dagli script di inizializzazione
a/kernel-huge ---> Il kernel...
a/kernel-modules ---> ... i suoi moduli

<nowiki>** NOTA **</nowiki>

Su slackware 13.1 è necessario anche il seguente pacchetto
l/v4l-utils ---> Librerie necessarie ai programmi di sistema (ad es: '''mount''')

<nowiki>** FINE NOTA **</nowiki>

Per installare questi pacchetti si deve eseguire '''installpkg''' con l'opzione -root ''/mnt/memory'', ad esempio:
# installpkg -root /mnt/memory aaa_base-12.0.0-noarch-1.tgz

==Una facile configurazione==
Come per la domanda 'Quali pacchetti si devono installare?', così la risposta alla domanda 'Cosa si deve configurare?' dipende sempre dall'amministratore del sistema e da cosa esso intenda far eseguire all'avvio della macchina.<BR>
Nel wiki si intende lasciare intatti gli script di inizializzazione fatti da Patrick J. Volkerding, creatore della Slackware, e quindi si procederà nella minima configurazione necessaria proprio a questi script di inizializzazione.

===/etc/fstab===
Si comincia con il creare il file ''/etc/fstab'' come segue:
# echo -e "LABEL=minislack\t\t/\text3\trw,noatime\t0 1" > /mnt/memory/etc/fstab
Nel caso si abbia scelto ext4 diventa:
# echo -e "LABEL=minislack\t\t/\text4\trw,noatime\t0 1" > /mnt/memory/etc/fstab

===/etc/hardwareclock===
Un altro file richiesto dagli script di inizializzazione della Slackware è il file ''/etc/hardwareclock'' che indica come è impostato l'orologio hardware. In effetti questo file non contiene granché, ma viene consigliato di editarlo/crearlo tramite lo script '''/usr/sbin/timeconfig''', quindi bisogna eseguire lo script spostandogli la directory root, in questo modo:
# cd /mnt/memory
# chroot . usr/sbin/timeconfig

=Fase 3: impostare il boot loader e testare il tutto=
L'ultima cosa da fare è quella di rendere la pennina "bootabile", ovvero di inserire nel suo primo settore, il famoso settore di boot. Per fare questo basta creare un file ''lilo.conf'' ad-hoc, e poi lanciare LILO passandogli il file appena creato.<BR>
Si crei quindi il file, ad esempio ''/mnt/memory/etc/lilo.conf'', direttamente sulla pennina in modo che rimanga con essa, con all'interno quanto segue:
<PRE>
boot = /dev/sda
backup = ""
map=/mnt/memory/boot/map

compact
lba32
large-memory

image = /mnt/memory/boot/vmlinuz
initrd = /mnt/memory/boot/initrd.gz
</PRE>

Si noti l'opzione 'initrd', con la quale si indica al kernel che deve usare l'initrd creato nella 'Fase 1'. Ora non resta quindi che lanciare LILO come segue:
# lilo -C /mnt/memory/etc/lilo.conf
e riavviare il PC facendogli fare il boot dalla pennina USB.<BR>
Con la configurazione minimale che si è fatta nella 'Fase 2', basta, al momento del login, inserire l'username di 'root' per avere una shell con tutti i privilegi del super-utente.

=Esempi d'uso=
Una volta che si ha una pennina USB "bootabile", con all'interno un intera distribuzione, serve solo la fantasia per farci quello che ci pare.<BR>
Esempi d'uso potrebbero essere quello di crearsi una distribuzione adatta alla lettura di contenuti multimediali, in questo modo basta trovare un PC per vedere un DVD o ascoltare della musica, senza preoccuparsi che il PC sia dotato di tutti i programmi o codec adatti.

Un altro esempio è che si ha sempre a portata di mano un "disco di ripristino". Se la distribuzione installata sul PC non dovesse partire perché ci si è divertiti un po' troppo con i file di configurazione, si può sempre fare il boot del PC con la pennina e provvedere a rimediare agli eventuali danni che si è combinati.

=Appendice=
==A: altri pacchetti utili==
Se si vuole rendere la distribuzione che si è installata sulla pennina un po' più indipendente, bisogna essere in grado di manipolare i pacchetti della Slackware, non solo, ma sarebbe anche carino poter utilizzare tutta una serie di comandi utili ad un sistemista. Quindi, oltre all'insieme minimo di pacchetti menzionati nella sezione
'[[#I_pacchetti_da_installare|I pacchetti da installare]]', qui di seguito c'è un elenco dei pacchetti che rendono la distribuzione sulla pennina, più user-friendly:
a/pkgtools ---> Per gestire i pacchetti della Slackware
a/bin ---> Usato dagli script di pkgtools
a/sed ---> Usato dagli script di pkgtools
a/gzip ---> Usato dagli script di pkgtools
a/tar ---> Usato dagli script di pkgtools
a/xz ---> Usato dagli script di pkgtools per il nuovo formato '.txz' della Slackware 13

ap/man ---> Il comando man più tornare molto utile
ap/man-pages ---> Le pagine di manuale di molti comandi
ap/groff ---> Il formattatore usato da man
a/cxxlibs ---> Libreria c++ standard usata da groff
a/less ---> Il comando che man usa per visualizzare le pagine di manuale

a/udev ---> Utile se si vogliono usare driver che necessitano di firmware

ap/nano ---> Il famoso e semplice editor di testo

a/bzip2 ---> Sempre più spesso si trovano archivi bzip

a/reiserfsprogs ---> Per gestire il famoso file system reiser

=Ringraziamenti=
Ringrazio ZeroUno per i suoi consigli e le sue prove.

Note per Slackware 13.1 a cura di [[Utente:Ansa89|Ansa89]].

Integrazioni per Slackware 13.37-14.0, ext4 e tune2fs a cura di sya54M.

Per qualsiasi cosa scrivetemi pure:<BR>
[[Utente:targzeta|targzeta]]

Pagina principale

2013-03-31T17:34:18Z

Targzeta: Test mobie

<div id="mf-home">
__NOTITLE__
__NOTOC__
{{:Pagina_principale/Header}}
{|style="width:100%;margin-top:10px;"
|-
|colspan="2" valign="top" style="width:70%;margin:0;padding:0;"|
<div class="boxblue">News</div>
<div style="overflow-x:hidden; overflow-y:auto; position: relative; max-height: 350px; margin-top: 10px;background-color:#ebebeb;padding:10px;border-radius: 0.3em;">
{{Template:Latest News}}
</div>
| valign="top" rowspan="4" style="width:30%; padding:0 10px 0;" class="forumnews"|
<div class="boxblue">Ultimi post dal forum</div>
<div class="external"><rss time="300" number="25" desc="off" title="off">rss/lastopic.xml</rss></div>
|-
|<div style="margin-top:20px;" class="rssboxt">[[ChangeLog_Repository|Our packages for Slackware-14.0]]</div>
<rss number="8" desc="off" title="off">rss/Slacky-ChangeLog-32.xml</rss>
|<div style="margin-top:20px;" class="rssboxt">[[ChangeLog_Repository|Our packages for Slackware64-14.0]]</div>
<rss number="8" desc="off" title="off">rss/Slacky-ChangeLog-64.xml</rss>
|-
|<div style="margin-top:10px;" class="rssboxt">[[ChangeLog_Slackware|ChangeLog Slackware-14.0]]</div>
<rss number="3" desc="off" title="off">rss/Slackware-ChangeLog-32.rss</rss>
|<div style="margin-top:10px;" class="rssboxt">[[ChangeLog_Slackware|ChangeLog Slackware64-14.0]]</div>
<rss number="3" desc="off" title="off">rss/Slackware-ChangeLog-64.rss</rss>
|-
|<div style="margin-top:10px;" class="rssboxt">[[ChangeLog_Slackware|ChangeLog Slackware-current]]</div>
<rss number="3" desc="off" title="off">rss/Slackware-ChangeLog-current32.rss</rss>
|<div style="margin-top:10px;" class="rssboxt">[[ChangeLog_Slackware|ChangeLog Slackware64-current]]</div>
<rss number="3" desc="off" title="off">rss/Slackware-ChangeLog-current64.rss</rss>
|-
|}
</div>

Redmine e apache via fcgi

2012-11-25T12:05:27Z

Targzeta: Creata pagina con ' Category: Ufficio_e_Web = Introduzione = In questo articolo vedremo come installare ...'

[[Category: Ufficio_e_Web]]
= Introduzione =
In questo articolo vedremo come installare Redmine sulla Slackware (testato su Slackware 14.0 e 13.37 con gli accorgimenti riportati in seguito) e come configurare il server apache (httpd) in modo da renderlo accessibile via fcgi.

Redmine salva i propri dati su di un database e può gestire diversi tipi di DBMS ma, dato che Slackware ha come DBMS di defaul MySQL, noi useremo quest'ultimo.

= Installare Redmine =
L'installazione avviene senza problemi seguendo la [http://www.redmine.org/projects/redmine/wiki/RedmineInstall#Installation-procedure guida ufficiale]. Di seguito, comunque, riporto un sunto di quello che va fatto per installarlo su Slackware.

== Step 0: installare fcgi e mod_fcgi ==
Per poter usare httpd via fcgi (Fast CGI) va installata nel sistema sia la libreria '''fcgi''' che il modulo '''mod_fcgid''' (per httpd stesso).

=== fcgi versione 2.4.1-SNAP-0910052249 ===
Il progetto è molto vecchio (2009), ma [http://www.fastcgi.com/ gli sviluppatori] dicono che le modifiche sono minime perché il protocollo è stabile. Il sorgente lo trovate [http://www.fastcgi.com/dist/ qui], ma noi creeremo il pacchetto per Slackware grazie ai comandi seguenti (l'ultimo va eseguito come root):
<pre>
cd /tmp
mkdir fcgi
cd fcgi
wget http://www.fastcgi.com/dist/fcgi-2.4.1-SNAP-0910052249.tar.gz
wget http://www.slacky.eu/wikislack/upload/1/13/Fcgi-SlackBuild.tar.bz2
tar -xf Fcgi-SlackBuild.tar.bz2
sh fcgi.SlackBuild
</pre>
Il pacchetto verrà creato nella directory corrente (''/tmp/fcgi'').

=== mod_fcgid versione 2.3.7 ===
Per controllare l'uscita di versioni più recenti si veda [https://httpd.apache.org/download.cgi#mod_fcgid questo link]. Di seguito, i comandi necessari alla costruzione del pacchetto per Slackware (al solito, l'ultimo va eseguito come root):
<pre>
cd /tmp
mkdir mod_fcgid
cd mod_fcgid
wget http://apache.panu.it//httpd/mod_fcgid/mod_fcgid-2.3.7.tar.bz2
wget http://www.slacky.eu/wikislack/upload/8/8a/Mod_fcgid-SlackBuild.tar.bz2
tar -xf Mod_fcgid-SlackBuild.tar.bz2
sh mod_fcgid.SlackBuild
</pre>
Il pacchetto verrà creato nella directory corrente (''/tmp/mod_fcgid'').

Una volta installato il pacchetto, va anche detto al server httpd di usarlo:
echo 'LoadModule fcgid_module lib64/httpd/modules/mod_fcgid.so' >> /etc/httpd/httpd.conf
{{Information
|Note
|Una volta lanciato il server apache, noterete nel suo log ''/var/log/httpd/error_log'', se il modulo è stato caricato correttamente, una riga simile a questa:
AH00489: Apache/2.4.3 (Unix) PHP/5.4.7 mod_fcgid/2.3.7 configured
Alternativamente, si può controllare tra i moduli caricati da apache con:
httpd -M | grep fcgid
dovrebbe comparire la riga:
fcgid_module (shared)
}}

== Step 1: scaricare Redmine ==
Scaricate redmine dal [http://www.redmine.org/projects/redmine/wiki/Download sito ufficiale] ed estraete l'archivio nella directory che preferite. Tenete conto che la sotto-directory ''public'' (contenuta nell'archivio) è quella che verrà gestita dal server web. Per questa wiki, l'archivio è stato scaricato nella directory ''/tmp'' ed è stato estratto sotto ''/var/www/htdocs/'' con i comandi (per Redmine 2.1.4):
<pre>
cd /tmp
wget http://rubyforge.org/frs/download.php/76578/redmine-2.1.4.tar.gz
cd /var/www/htdocs/
tar -xf /tmp/redmine-2.1.4.tar.gz
mv redmine-2.1.4 redmine
chown root.root -R redmine
chmod go-w -R redmine/
</pre>
{{Information
|Note
|Visto che abbiamo installato redmine sotto ''/var/www/htdocs/'', tutti i comandi vanno eseguiti con i diritti dell'utente root. In realtà, se si installa redmine in una directory accessibile all'utente non amministratore, i comandi possono anche essere eseguiti senza l'ausilio del superutente.
}}

== Step 2: installare i requisiti ==
Installate il pacchetto '''bundler''' per Ruby eseguendo, come root:
gem install bundler
{{Warning
|Slackware 13.37 o precedenti
|Il pacchetto '''bundler''' necessita di una versione recente di '''gem''' non installata nel pacchetto Slackware di Ruby. Si può comunque provare ad installare la versione di Ruby presente nella Slackware 14.0 usando direttamente lo SlackBuild di Pat. Prima di compilare ed installare Ruby, comunque, va compilata e installata anche la libreria '''libyaml''', sempre presenta nella Slackware 14.0. Ecco i link agli SlackBuild ufficiali:
* [http://slackware.org.uk/slackware/slackware-14.0/source/l/libyaml/ libyaml]
* [http://slackware.org.uk/slackware/slackware-14.0/source/d/ruby/ ruby]
}}

{{Information
|Note
|Dato che redmine necessita di tutta una serie di dipendenze per Ruby di cui è difficile trovare i pacchetti Slackware, qui useremo il package manager per Ruby di default, '''gem'''. Tutti i pacchetti installati, comunque, saranno inseriti da '''gem''' nella directory (su una slackware64-14.0) ''/usr/lib64/ruby/gems/1.9.1/gems''.
}}

Ora, assicuratevi di essere all'interno della directory di redmine:
cd /var/www/htdocs/redmine

Tramite '''bundler''' e il file '''Gemfile''' fornito con redmine, si possono installare tutte le dipendenze necessarie a quest'ultimo. Prima però bisogna eseguire il comando:
echo "gem 'fcgi'" > Gemfile.local
per dire a '''bundler''' che deve installare anche il pacchetto '''fcgi''' (per Ruby). Ora siamo pronti ad installare il tutto tramite il comando:
bundle install --without development test postgresql sqlite
le opzioni dicono a '''bundler''' di non installare i pacchetti necessari al ramo di sviluppo, a quello di test, e di ignorare anche i pacchetti necessari ai DBMS PostgreSQL e SQLite.

== Step 3: preparare il database MySQL ==
Ora dobbiamo creare sia un database che un utente per MySQL a cui garantire pieno accesso. Come suggerito nella [http://www.redmine.org/projects/redmine/wiki/RedmineInstall#MySQL guida ufficiale] creiamo il database '''redmine''' e l'utente '''redmine''' (con password '''redminepass''') via mysql:
mysql -u'root' -p'root_pass'
create database redmine character set utf8;
create user 'redmine'@'localhost' identified by 'redminepass';
grant all privileges on redmine.* to 'redmine'@'localhost';
exit

== Step 4: configurare redmine all'uso del database ==
Per dire a redmine di usare il database creato al passo precedente bisogna creare il file ''config/database.yml'' con all'interno le seguenti righe:
<pre>
production:
adapter: mysql2
database: redmine
host: localhost
username: redmine
password: redminepass
</pre>

Possiamo farlo eseguendo il comando seguente:
echo -e 'production:\n adapter: mysql2\n database: redmine\n host: localhost\n username: redmine\n password: redminepass' > config/database.yml

== Step 5: generare il secret token ==
Questo passo genera una chiave random usata da '''Rails''' (il framework Ruby usato da Redmine) per codificare i cookie di sessione:
rake generate_secret_token

== Step 6: creare le tabelle del database ==
Ora create le tabelle di redmine con il comando:
RAILS_ENV=production rake db:migrate
{{Information
|Note
|La variabile di ambiente RAILS_ENV serve a dire a '''Rails''' quale ramo deve usare, quello che abbiamo configurato noi (vedi file ''config/database.yml'') è quello di produzione (c'è anche quello di test e di sviluppo).
}}

== Step 7: popolare le tabelle con i dati di default ==
RAILS_ENV=production REDMINE_LANG=it rake redmine:load_default_data
{{Information
|Note
|REDMINE_LANG=it dice a redmine di installare la traduzione in lingua italiana.
}}

== Step 8: permessi a file e directory ==
Ora dobbiamo garantire l'accesso al server httpd ad alcuni file e directory:
mkdir -p tmp/pdf public/plugin_assets
chown -R apache.apache files log tmp public/plugin_assets

== Step 9: testare il tutto ==
Per controllare se redmine è stato installato correttamente, basta eseguire il comando:
ruby script/rails server webrick -e production
e poi andare all'indirizzo http://localhost:3000/

== Step 10: login ==
Nello step 7 redmine ha creato anche un utente amministratore di default con le seguenti credenziali:
* login: admin
* password: admin

= Usare fcgi =
Una volta installato redmine, possiamo "integrarlo" nel server web apache ('''httpd''') via '''fcgi'''. Prima assicuriamoci di aver seguito lo [[#Step_0:_installare_fcgi_e_mod_fcgi|Step 0]] del paragrafo precedente e di aver installato via '''gem''' il pacchetto '''fcgi''' anche per Ruby ([[#Step_2:_installare_i_requisiti|Step 2]] del paragrafo precedente).

Prima di eseguire i passi seguenti, assicuriamoci ancora una volta di stare nella directory in cui abbiamo decompresso redmine:
cd /var/www/htdocs/redmine

== Step 0: preparare redmine e apache ==
Redmine viene fornito di uno script FCGI che esegue il vero processo. Lo script si chiama ''public/dispatch.fcgi.example'', rinominiamolo (o copiamolo) eliminando l'estensione ''.example''.
mv public/dispatch.fcgi.example public/dispatch.fcgi

Ora che abbiamo il wrapper fcgi, abbiamo anche bisogno di istruire apache in modo che lo esegua. Anche per questo redmine ha un file htaccess di esempio, ''public/htaccess.fcgi.example''. Rinominiamo anche questo:
mv public/htaccess.fcgi.example public/.htaccess
{{Information
|Note
|Se date uno sguardo al file ''public/.htaccess'' appena spostato, noterete che ci sono una serie di '''IfModule'''. Questo perché redmine può essere eseguito via fcgi sia con il modulo per apache '''mod_fcgid''' (il nostro caso) sia con '''mod_fastcgi'''. Per l'ultimo caso si veda [http://www.redmine.org/projects/redmine/wiki/HowTo_configure_Apache_to_run_Redmine#mod_fastcgi la guida sul sito di redmine]. Per le nostre esigenze, il file ''public/.htaccess'' potrebbe essere anche riscritto nel modo seguente:
<pre>
# General Apache options
AddHandler fcgid-script .fcgi

Options +FollowSymLinks +ExecCGI

RewriteEngine On

RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

ErrorDocument 500 "<h2>Application error</h2>Rails application failed to start properly"
</pre>
}}

{{Warning
|Attenzione
|La Slackware non ha, di default, il modulo apache '''mod_rewrite''' attivo, necessario per poter usare i file ''.htaccess''. Per attivarlo assicuriamoci che la relativa riga nel file ''/etc/httpd/httpd.conf'' sia decommentata (qui la riga per la Slackware64 14.0):
LoadModule rewrite_module lib64/httpd/modules/mod_rewrite.so
}}

Quello che resta da fare è dire a '''Rails''' di eseguire l'ambiente di produzione, altrimenti di default verrà eseguito l'ambiente di sviluppo. Per fare questo bisogna inserire all'inizio del file ''config/environment.rb'' le seguenti righe:
<pre>
# Force the rails environment to production
ENV['RAILS_ENV'] ||= 'production'
</pre>
Possiamo farlo direttamente eseguendo il seguente comando:
<pre>
sed -i '1i \
# Force the rails environment to production \
ENV["RAILS_ENV"] ||= "production" \
' config/environment.rb
</pre>

== Step 1: configurare il virtual host di apache ==
Ci sono due modi per rendere disponibile redmine via apache. Possiamo settargli un virtual host dedicato, oppure renderlo disponibile come sotto-directory di un virtual host già esistente.

=== Virtual host dedicato ===
Aggiungiamo al file che contiene le impostazioni sui virtual host, ''/etc/httpd/extra/httpd-vhosts.conf'', seguenti righe:
<pre>
# Redmine
<VirtualHost *:80>
DocumentRoot "/var/www/htdocs/redmine/public"
ServerName redmine
<Directory "/var/www/htdocs/redmine/public">
AllowOverride FileInfo Options
Require all granted
</Directory>
</VirtualHost>
</pre>
{{Information
|Note
|Le due direttive di '''AllowOverride''' servono rispettivamente, per abilitare l'uso del file ''.htaccess'' e per dare la possibilità a quest'ultimo di aggiungere le opzioni di cui necessita ('''+FollowSymLinks''' e '''+ExecCGI''').
}}
Dopo aver riavviato il server apache, basta collegarsi a http://redmine per vedere se il server è attivo (la prima volta ci vorrà un po' tempo affinché il framework '''Rails''' faccia il setup completo).
{{Warning
|Attenzione
|Affinché il link http://redmine funzioni, c'è bisogno che la richiesta venga rediretta al nostro server apache. Nel nostro caso, dato che stiamo provando tutto in locale, questo può essere fatto aggiungendo la riga seguente al file ''/etc/hosts'':
127.0.0.1 redmine
}}

=== Usare un virtual host esistente ===
Possiamo installare redmine sotto un virtual host esistente. Per fare questo, però, dato che la directory pubblica è una sotto-directory di redmine (la directory ''public/''), per non dover scrivere nel URL ''/redmine/public/'' è più conveniente settare un alias.

Supponiamo che ci sia già il seguente virtual host configurato nel file ''/etc/httpd/extra/httpd-vhosts.conf'' (notate il '''ServerName''' come '''localhost'''):
<pre>
<VirtualHost *:80>
DocumentRoot "/srv/httpd/htdocs"
ServerName localhost
</VirtualHost>
</pre>

Per settare l'alias per redmine bisogna modificare la precedente configurazione, con questa:
<pre>
<VirtualHost *:80>
DocumentRoot "/srv/httpd/htdocs"
ServerName localhost

# Redmine
Alias "/redmine" "/var/www/htdocs/redmine/public"
<Directory "/var/www/htdocs/redmine/public">
AllowOverride FileInfo Options
Require all granted
</Directory>
</VirtualHost>
</pre>

Ora però va modificato il file ''public/.htaccess'' settando la '''RewriteBase''' come ''/redmine'', altrimenti le richieste a http://localhost/redmine saranno riscritte in maniera errata (in particolare, non andranno verso ''public/dispatch.fcgi'' ma direttamente verso ''dispatch.fcgi''). Possiamo farlo con il comando seguente:
<pre>
sed -i '/^RewriteEngine/a \
RewriteBase /redmine' public/.htaccess
</pre>

Prima di testare il tutto, bisogna correggere [http://www.redmine.org/issues/12102 un piccolo bug] del framework '''Rails''' che gli impedisce di avviarsi in maniera corretta quando l'applicazione è un alias di un virtual host. Quindi modifichiamo il file ''config/environment.rb'' sostituendo le righe:
<pre>
# Initialize the rails application
RedmineApp::Application.initialize!
</pre>
in:
<pre>
# Initialize the rails application
RedmineApp::Application.routes.default_scope = { :path => '/redmine', :shallow_path => '/redmine' }
RedmineApp::Application.initialize!
Redmine::Utils::relative_url_root = '/redmine'
</pre>

Ora tutto dovrebbe essere pronto e redmine dovrebbe rispondere correttamente all'indirizzo http://localhost/redmine.

== Possibili problemi ==
Se redmine non dovesse funzionare a dovere, potete provare a guardare il file di log ''log/production.log''.

=== `require': no such file to load -- fcgi (LoadError) ===
Se trovate questo errore, provate a modificare il file ''public/dispatch.fcgi'' inserendovi all'inizio le seguenti righe:
<pre>
require 'rubygems'
require 'fcgi'
</pre>

Ovviamente dovete anche aver installato il pacchetto '''fcgi''' per Ruby, come visto nello [[#Step_2:_installare_i_requisiti|Step 2]] fatto durante l'installazione di redmine. Se non l'avete fatto, potete sempre farlo con:
gem install fcgi

= Rimuovere il tutto =
Durante l'installazione di redmine, abbiamo modificato qualche file di configurazione ed installato un bel po' di software. Vediamo come poter tornare indietro.

== Rimozione pacchetti installati ==
I pacchetti da rimuovere, con removepkg, sono:
* mod_fcgid
* fcgi
(eventualmente anche ruby e libyaml).
removepkg mod_fcgid fcgi

Vanno anche cancellati, il file:
/var/run/fcgid_shm
e la directory:
/var/run/fcgidsock/
con:
rm -r /var/run/fcgid_shm /var/run/fcgidsock/

== Pacchetti per Ruby ==
Via '''gem''' e '''bundler''' abbiamo installato i seguenti pacchetti sotto (per Slackware64-14.0) ''/usr/lib64/ruby/gems/1.9.1/gems/'':
* actionmailer-3.2.8
* actionpack-3.2.8
* activemodel-3.2.8
* activerecord-3.2.8
* activeresource-3.2.8
* activesupport-3.2.8
* arel-3.0.2
* builder-3.0.0
* bundler-1.2.2
* coderay-1.0.8
* erubis-2.7.0
* fcgi-0.8.8
* hike-1.2.1
* i18n-0.6.1
* journey-1.0.4
* jquery-rails-2.0.3
* json-1.7.5
* mail-2.4.4
* mime-types-1.19
* multi_json-1.3.7
* mysql2-0.3.11
* net-ldap-0.3.1
* polyglot-0.3.3
* rack-1.4.1
* rack-cache-1.2
* rack-openid-1.3.1
* rack-ssl-1.3.2
* rack-test-0.6.2
* rails-3.2.8
* railties-3.2.8
* rake-10.0.2
* rdoc-3.12
* rmagick-2.13.1
* ruby-openid-2.1.8
* sprockets-2.1.3
* thor-0.16.0
* tilt-1.3.3
* treetop-1.4.12
* tzinfo-0.3.35

Tutti questi pacchetti possono essere rimossi con il comando seguente (occhio che se qualche altro software per Ruby li usa ...):
<pre>
cd /usr/lib64/ruby/gems/1.9.1
rm -r */actionmailer-3.2.8* */actionpack-3.2.8* */activemodel-3.2.8* \
*/activerecord-3.2.8* */activeresource-3.2.8* */activesupport-3.2.8* \
*/arel-3.0.2* */builder-3.0.0* */bundler-1.2.2* */coderay-1.0.8* */erubis-2.7.0* \
*/fcgi-0.8.8* */hike-1.2.1* */i18n-0.6.1* */journey-1.0.4* */jquery-rails-2.0.3* \
*/json-1.7.5* */mail-2.4.4* */mime-types-1.19* */multi_json-1.3.7* \
*/mysql2-0.3.11* */net-ldap-0.3.1* */polyglot-0.3.3* */rack-1.4.1* \
*/rack-cache-1.2* */rack-openid-1.3.1* */rack-ssl-1.3.2* */rack-test-0.6.2* \
*/rails-3.2.8* */railties-3.2.8* */rake-10.0.2* */rdoc-3.12* */rmagick-2.13.1* \
*/ruby-openid-2.1.8* */sprockets-2.1.3* */thor-0.16.0* */tilt-1.3.3* \
*/treetop-1.4.12* */tzinfo-0.3.35*
</pre>

== Redmine ==
Ovviamente va anche eliminato redmine stesso:
<pre>
cd /var/www/htdocs/
rm -r redmine
</pre>

== Database ==
Il database e l'utente creati si possono eliminare con:
<pre>
mysql -u'root' -p'root_pass'
drop database redmine;
drop user redmine@localhost;
exit
</pre>

== File modificati ==
* ''/etc/httpd/httpd.conf'': eliminare la riga
LoadModule fcgid_module lib64/httpd/modules/mod_fcgid.so

* ''/etc/httpd/extra/httpd-vhosts.conf'': dipende se abbiamo settato [[#Virtual_host_dedicato|un virtual host dedicato]] o se abbiamo [[#Usare_un_virtual_host_esistente|usato un virtual host esistente]].

* ''/etc/hosts'': solo se l'abbiamo modificato inserendo la riga:
127.0.0.1 redmine

= Autore =
[[Utente:Targzeta|Targzeta]] ([[Discussioni utente:Targzeta|discussioni]]) 13:05, 25 nov 2012 (CET)

File:Fcgi-SlackBuild.tar.bz2

2012-11-23T16:45:24Z

Targzeta: Targzeta ha caricato una nuova versione di "File:Fcgi-SlackBuild.tar.bz2": Eliminato il '-j 3' nell'esecuzione del make.

Contiene il necessari per compilare il pacchetto fcgi su Slackware

File:Mod fcgid-SlackBuild.tar.bz2

2012-11-18T21:22:18Z

Targzeta: Contiene il necessario per creare il pacchetto mod_fcgid su Slackware

Contiene il necessario per creare il pacchetto mod_fcgid su Slackware

File:Fcgi-SlackBuild.tar.bz2

2012-11-18T21:13:12Z

Targzeta: Contiene il necessari per compilare il pacchetto fcgi su Slackware

Contiene il necessari per compilare il pacchetto fcgi su Slackware

Indice delle categorie

2012-11-16T22:39:17Z

Targzeta: Eliminata categoria vuota "Configurazioni"

{| class="wikitable" width="100%"

| valign="top" |

[[Image:configurazione.png|center|48px|link=]]<categorytree mode=all showcount class="">Configurazione</categorytree>
----
[[Image:installa e upgrade.png|center|48px|link=]]<categorytree mode=all showcount class="">Install e Upgrade</categorytree>
----
[[Image:laptop.png|center|48px|link=]]<categorytree mode=all showcount class="">Laptop</categorytree>
----
[[Image:multimediale.png|center|48px|link=]]<categorytree mode=all showcount class="">Multimediale</categorytree>
----
[[Image:networking.png|center|48px|link=]]<categorytree mode=all showcount class="">Networking</categorytree>
----
[[Image:packages.png|center|48px|link=]]<categorytree mode=all showcount class="">Packages</categorytree>
----
[[Image:periferiche.png|center|48px|link=]]<categorytree mode=all showcount class="">Periferiche</categorytree>

| valign="top" |

[[Image:slacky.png|center|56px|link=]]<categorytree mode=all showcount class="">Slacky e Slackware</categorytree>
----
[[Image:server x.png|center|48px|link=]]<categorytree mode=all showcount class="">Server X</categorytree>
----
[[Image:scritti misti.png|center|48px|link=]]<categorytree mode=all showcount class="">Scritti misti</categorytree>
----
[[Image:stampanti.png|center|48px|link=]]<categorytree mode=all showcount class="">Stampanti</categorytree>
----
[[Image:ufficio e web.png|center|48px|link=]]<categorytree mode=all showcount class="">Ufficio e Web</categorytree>
----
[[Image:script.png|center|48px|link=]]<categorytree mode=all showcount class="">Script</categorytree>
----
[[Image:kernel.png|center|48px|link=]]<categorytree mode=all showcount class="">Kernel</categorytree>

|}

Utente:Targzeta

2012-10-28T13:04:51Z

Targzeta:

Emanuele Tomasi aka targzeta <targzeta AT gmail DOT com>

Wallpapers

2012-10-28T13:01:08Z

Targzeta:

{{#sgallery:
|width=800
|height=600
|showarrows=true
|showcarousel=true
|showinfopane=false
|timed=true
|delay=6000
|imagelist=mayan-1024x768.jpg
Slackware_maja_kalendar.jpg
Maja_slack.jpg
Wallpaper_lampaaa.jpg
Wallpaper_slackgirl.jpg
Wallpaper_slackk.jpg
Wallpaper_slackware.jpg
Wallpaper_slackware-balon-1.jpg
Wallpaper_slackware-balon-2.jpg
Wallpaper_slackware-glass-break.jpg
Wallpaper_slackware-sace.jpg
Wallpaper_slackware-subgenius.jpg
Wallpaper_slackware_14.jpg
Higgs-slackware.jpg
My_black_slack_wallpaper.png
Onlyslackware.jpg
Slack14wall2.png
Slackwarecurrent2.png
Slackschoolwallpaper.png
Slackwallpaper.png
Slackware14_wallpaper1.png
Slackware_by_zealkane-d3bg6f9.jpg
}}
Per aggiungere un'immagine basta [[Speciale:Carica|caricarla]] e poi aggiungerla all'elenco. Tenete presente che il carousel ha uno sfondo nero, quindi non usate immagini trasparenti con scritte nere, piuttosto convertitele in JPEG.

Lo staff.

Wallpapers

2012-10-28T00:23:34Z

Targzeta:

{{#sgallery:
|width=800
|height=600
|showarrows=true
|showcarousel=true
|showinfopane=false
|timed=true
|delay=6000
|imagelist=mayan-1024x768.jpg
Slackware_maja_kalendar.jpg
Maja_slack.jpg
Wallpaper_lampaaa.jpg
Wallpaper_slackgirl.jpg
Wallpaper_slackk.jpg
Wallpaper_slackware.jpg
Wallpaper_slackware-balon-1.jpg
Wallpaper_slackware-balon-2.jpg
Wallpaper_slackware-glass-break.jpg
Wallpaper_slackware-sace.jpg
Wallpaper_slackware-subgenius.jpg
Wallpaper_slackware_14.jpg
}}
Per aggiungere un'immagine basta [[Speciale:Carica|caricarla]] e poi aggiungerla all'elenco. Tenete presente che il carousel ha uno sfondo nero, quindi non usate immagini trasparenti con scritte nere, piuttosto convertitele in JPEG.

Lo staff.

File:Wallpaper slackware 14.jpg

2012-10-28T00:16:29Z

Targzeta:

File:Wallpaper slackware-subgenius.jpg

2012-10-28T00:15:37Z

Targzeta:

File:Wallpaper slackware-sace.jpg

2012-10-28T00:14:56Z

Targzeta:

File:Wallpaper slackware-glass-break.jpg

2012-10-28T00:13:08Z

Targzeta:

File:Wallpaper slackware-balon-2.jpg

2012-10-28T00:11:18Z

Targzeta:

File:Wallpaper slackware-balon-1.jpg

2012-10-28T00:09:56Z

Targzeta:

File:Wallpaper slackware.jpg

2012-10-28T00:08:40Z

Targzeta:

File:Wallpaper slackk.jpg

2012-10-28T00:08:11Z

Targzeta:

File:Wallpaper lampaaa.jpg

2012-10-28T00:04:58Z

Targzeta:

Propaganda

2012-10-26T23:17:08Z

Targzeta: Aggiunte le immagini di Zeljko f (thanks!!!)

{{#sgallery:
|width=700
|height=600
|showarrows=true
|showcarousel=true
|showinfopane=false
|timed=true
|delay=4000
|imagelist=Mistowhite.jpg
slackywhite.png
Latowhite.png
palla.jpg
mayan-1024x768.jpg
Slackware_maja_kalendar.jpg
Maja_slack.jpg
}}
Per aggiungere un'immagine basta [[Speciale:Carica|caricarla]] e poi aggiungerla all'elenco. Tenete presente che il carousel ha uno sfondo nero, quindi non usate immagini trasparenti con scritte nere, piuttosto convertitele in JPEG.

Lo staff.

Info repository

2012-10-24T21:50:16Z

Targzeta: Cambiati gli rss.

L'Associazione Slacky mette a disposizione diversi repository contenenti centinaia di pacchetti precompilati e quindi già pronti per l'installazione. I repository partono dalla versione 11.0 e sono tutti corredati dei sorgenti di compilazione (SlackBuild & slack-desc). Chi pacchettizza, di solito, parte dalla compilazione in ambiente temporaneo per poi trascrivere tutte le operazioni eseguite su uno script con suffisso .SlackBuild, questo script sarà poi usato per compilare ed eventualmente ricompilare il pacchetto finale. Ulteriori informazioni sull'uso e la creazione dello SlackBuild si possono reperire [[Slackware & SlackBuild|qui]] e [[Creare pacchetti txz per Slackware|qui]]. Il nostro sistema di analisi dei pacchetti permette di eseguire ricerche semplificate solo sulle ultime due release stabili della Slackware a 32 o 64. Per accedere ai pacchetti delle versioni precedenti dovete procedere manualmente consultando le categorie oppure aiutandosi con il FILELIST.TXT presenti a questo indirizzo http://repository.slacky.eu/

Se volete contribuire come pacchettizzatori inviate una mail all'indirizzo packages@slacky.it

{| align="center"
|style="width:33%; vertical-align: top;"|
<div style="border: 1px solid #89e589; background-color:#f2fff2; padding: 3px; margin: 3px; float:left;text-align:left">
<rss max=20>rss/Slacky-ChangeLog-32.xml</rss>
</div>
|style="width:33%; vertical-align: top;"|
<div style="border: 1px solid #307aa9; background-color:#f5fbff; padding: 3px; margin: 3px; float:left;text-align:left">
<rss max=20>rss/Slacky-ChangeLog-64.xml</rss>
</div>
|}

ChangeLog Slackware

2012-10-24T21:49:15Z

Targzeta: Cambiati gli rss.

Questa pagina raccoglie tutti i Changelog del ramo stabile e di sviluppo sia a 32 sia a 64 Bit.

{|style="width:100%; margin-top:10px;"
|-
|<div class="rssboxt">ChangeLog Slackware-14.0</div>
<rss number="10" desc="off" title="off">rss/Slackware-ChangeLog-32.rss</rss>
[http://www.slacky.eu/slackwarefeed/slackware-14.0/ChangeLog.rss Guarda tutto]
|<div class="rssboxt">ChangeLog Slackware64-14.0</div>
<rss number="10" desc="off" title="off">rss/Slackware-ChangeLog-64.rss</rss>
[http://www.slacky.eu/slackwarefeed/slackware64-14.0/ChangeLog.rss Guarda tutto]
|-
|colspan="2"|
|-
|<div class="rssboxt">ChangeLog Slackware-current</div>
<rss number="10" desc="off" title="off">rss/Slackware-ChangeLog-current32.rss</rss>
[http://www.slacky.eu/slackwarefeed/slackware-current/ChangeLog.rss Guarda tutto]
|<div class="rssboxt">ChangeLog Slackware64-current</div>
<rss number="10" desc="off" title="off">rss/Slackware-ChangeLog-current64.rss</rss>
[http://www.slacky.eu/slackwarefeed/slackware64-current/ChangeLog.rss Guarda tutto]
|-
|}

ChangeLog Repository

2012-10-24T21:47:23Z

Targzeta: Cambiati gli rss.

Questa pagina raccoglie tutti i Changelog del repository Slacky.eu

{|style="width:100%; margin-top:10px;"
|-
|<div class="rssboxt">Our packages for Slackware-14.0</div>
<rss number="25" desc="off" title="off">rss/Slacky-ChangeLog-32.xml</rss>
[http://repository.slacky.eu/slackware-14.0/ChangeLog.xml Guarda tutto]
|<div class="rssboxt">Our packages for Slackware64-14.0</div>
<rss number="25" desc="off" title="off">rss/Slacky-ChangeLog-64.xml</rss>
[http://repository.slacky.eu/slackware64-14.0/ChangeLog.xml Guarda tutto]
|-
|}

Pagina principale

2012-10-24T21:37:28Z

Targzeta: Cambiati gli rss.

__NOTITLE__
__NOTOC__
{{:Pagina_principale/Header}}
{|style="width:100%;margin-top:10px;"
|-
|colspan="2" valign="top" style="width:70%;margin:0;padding:0;"|
<div class="boxblue">News</div>
<div style="overflow-x:hidden; overflow-y:auto; position: relative; max-height: 350px; margin-top: 10px;background-color:#ebebeb;padding:10px;border-radius: 0.3em;">
{{Template:Latest News}}
</div>
| valign="top" rowspan="4" style="width:30%; padding:0 10px 0;" class="forumnews"|
<div class="boxblue">Ultimi post dal forum</div>
<div class="external"><rss time="300" number="25" desc="off" title="off">rss/lastopic.xml</rss></div>
|-
|<div style="margin-top:20px;" class="rssboxt">[[ChangeLog_Repository|Our packages for Slackware-14.0]]</div>
<rss number="8" desc="off" title="off">rss/Slacky-ChangeLog-32.xml</rss>
|<div style="margin-top:20px;" class="rssboxt">[[ChangeLog_Repository|Our packages for Slackware64-14.0]]</div>
<rss number="8" desc="off" title="off">rss/Slacky-ChangeLog-64.xml</rss>
|-
|<div style="margin-top:10px;" class="rssboxt">[[ChangeLog_Slackware|ChangeLog Slackware-14.0]]</div>
<rss number="3" desc="off" title="off">rss/Slackware-ChangeLog-32.rss</rss>
|<div style="margin-top:10px;" class="rssboxt">[[ChangeLog_Slackware|ChangeLog Slackware64-14.0]]</div>
<rss number="3" desc="off" title="off">rss/Slackware-ChangeLog-64.rss</rss>
|-
|<div style="margin-top:10px;" class="rssboxt">[[ChangeLog_Slackware|ChangeLog Slackware-current]]</div>
<rss number="3" desc="off" title="off">rss/Slackware-ChangeLog-current32.rss</rss>
|<div style="margin-top:10px;" class="rssboxt">[[ChangeLog_Slackware|ChangeLog Slackware64-current]]</div>
<rss number="3" desc="off" title="off">rss/Slackware-ChangeLog-current64.rss</rss>
|-
|}

Propaganda

2012-10-23T18:21:11Z

Targzeta: Aggiunto testo informativo sull'aggiunta di una nuova immagine

{{#sgallery:
|width=600
|height=500
|showarrows=true
|showcarousel=true
|showinfopane=false
|timed=true
|delay=4000
|imagelist=Mistowhite.jpg
slackywhite.png
Latowhite.png
palla.jpg
mayan-1024x768.jpg
}}
Per aggiungere un'immagine basta [[Speciale:Carica|caricarla]] e poi aggiungerla all'elenco. Tenete presente che il carousel ha uno sfondo nero, quindi non usate immagini trasparenti con scritte nere, piuttosto convertitele in JPEG.

Lo staff.

Pagina principale

2012-10-18T16:20:47Z

Targzeta:

File:Installa iwl4695 rev01.sh

2012-10-08T22:18:32Z

Targzeta: Targzeta ha caricato una nuova versione di "File:Installa iwl4695 rev01.sh"

File:Xorg-Asus M2N-E.conf

2012-10-08T21:41:28Z

Targzeta: Targzeta ha caricato una nuova versione di "File:Xorg-Asus M2N-E.conf"

MediaWiki:Sidebar

2012-10-07T15:06:42Z

Targzeta: Aggiunto il repository della 14.0 e tolto il 13.1

* Navigazione
** mainpage|mainpage-description
** Speciale:UltimeModifiche | Ultime Modifiche

* Slackware
** Slackware | Cos'è Slackware
** ChangeLog Slackware | ChangeLog
** Ottenere Slackware | Ottenere Slackware
** Open Source | Cos'è l'open source?

* Associazione
** Associazione|Info Associazione
** http://www.slacky.eu/associazione/form.php | Richiesta iscrizione
** http://www.slacky.eu/associazione/modulo_iscrizione.pdf | Modulo iscrizione
** http://www.slacky.eu/associazione/statuto_slacky.pdf | Statuto
** Dettaglio uscite | Dettaglio uscite
** Donazione | Donazione
** Collabora | Collabora
** Propaganda | Propaganda

* Documenti
** Documentazione | Info Documentazione
** http://docs.slackware.com | Documentazione ufficiale SlackDocs
** Indice_delle_categorie | Indice generale
** Nuovo_articolo | Nuovo articolo
** category:Slacky e Slackware | Slacky e Slackware
** category:Configurazione | Configurazione
** category:Install_e_Upgrade | Install e Upgrade
** category:Scritti_misti | Scritti misti
** category:Script | Script
** category:Networking | Networking
** category:Packages | Packages
** category:Periferiche | Periferiche
** category:Laptop | Laptop
** category:Multimediale | Multimediale
** category:Server_X | Server X
** category:Kernel | Kernel
** category:Stampanti | Stampanti
** category:Ufficio_e_Web | Ufficio e Web

* Archivio Storico
** category:Archivio-Slackware-12.x | Slackware 12.x
** category:Archivio-Slackware-11.x | Slackware 11.x
** category:Archivio-Slackware-10.x | Slackware 10.x
** category:Archivio| Archivio (other)

* Repository
** Info repository | Info repository
** http://www.slacky.eu/asche/pkgs/index.php?ver=16 | Slackware-14.0
** http://www.slacky.eu/asche64/pkgs/index.php?ver=16 | Slackware64-14.0
** http://www.slacky.eu/asche/pkgs/index.php?ver=15 | Slackware-13.37
** http://www.slacky.eu/asche64/pkgs/index.php?ver=15 | Slackware64-13.37
** ChangeLog Repository | ChangeLog Repository
** http://repository.slacky.eu | Tutti i repository
** Segnala un problema | Segnala un problema
** Mirror | Mirror
** Altre risorse | Altre risorse
** GPG Key | GPG Key

* Nostri progetti
** Nostri progetti | Info nostri progetti
** Slackyd | Slackyd
** Gslacky | GSlacky
** Slackware4Dummies | Slackware 4 Dummies

* Feed di Slacky
** Feed_di_Slacky | Feed RSS

* Canale IRC
** Canale IRC | Info Canale IRC

Pagina principale

2012-10-06T08:15:53Z

Targzeta:

ChangeLog Slackware

2012-10-06T08:13:36Z

Targzeta: passato alla 14.0

Info repository

2012-10-06T08:07:17Z

Targzeta: passato alla 14.0

ChangeLog Repository

2012-10-06T08:01:41Z

Targzeta: passato alla 14.0

Discussione:Slackware su pennina USB

2012-10-02T23:01:33Z

Targzeta:

Ma non sarebbe meglio usare un file-system ext2 per evitare le scritture e riscritture del giornale, che -- da quanto ho capito -- accorciano la vita della pennina?

Ottima osservazione!!! -- targzeta

Discussione:Slackware su pennina USB

2012-10-02T23:01:03Z

Targzeta:

Ma non sarebbe meglio usare un file-system ext2 per evitare le scritture e riscritture del giornale, che -- da quanto ho capito -- accorciano la vita della pennina?

Ottima osservazione!!!

Find external SlackPkg files

2012-10-02T22:28:44Z

Targzeta: Caricato i file esterni all'interno di wikislacky

[[Category:Script]]
= Introduzione =
I "maniaci delle pulizie" - come me - a volte hanno la
necessità di scovare quei file, presenti nella root directory,
che non appartengono a nessun pacchetto installato. Questo infatti
permette di stabilire se quei file sono vecchi e vanno rimossi oppure
sono file di configurazione (o altro) creati dai programmi a run-time.

Spesso e volentieri qualcuno installa un pacchetto ma poi si accorge
che non gli serviva, quindi lo rimuove. Il dubbio si insinua nella
mente di un "maniaco delle pulizie": "ho rimosso tutto? il sistema
è ritornato come se il pacchetto non fosse mai stato
installato?". Generalmente i dubbi sono infondati, quasi tutti i
pacchetti vengono rimossi completamente e non lasciano tracce, ma
è proprio quel 'quasi tutti' che non fa dormire sonni
tranquilli.

Lo script find_external_SlackPkg_files.sh esegue una scansione di
tutta la root directory e controlla, file per file, se esso è
stato installato da un pacchetto Slackware oppure no. Quindi
visualizza in output tutti quei file "estranei" ai pacchetti.

Lo script può essere eseguito sia come root che come utente
normale. In quest'ultimo caso, ovviamente, lo script non potrà
scandire quelle directory di proprietà di altri utenti, ma
darà comunque dei buoni risultati.

= L'algoritmo =
L'algoritmo è molto semplice, lo script esegue un '''find'''
sulla root directory filtrando alcuni path (si veda la sezione
[[#Filtrare dei percorsi]]). Una volta creata questa 'file list', lo
script individua anche tutti i link simbolici creati dagli script
'''doinst.sh''' dei vari pacchetti. Quindi, controlla quali tra i file
presenti nella 'file list' non appartiene ad un pacchetto e non
è neanche un link simbolico creato da un '''doinst.sh'''.

{{Information
|Informazione:
|L'algoritmo è semplice ma la sia esecuzione è bella lunga. Diciamo che la vostra CPU non vi ringrazierà.
}}

== Filtrare dei percorsi ==
Lo script non scandisce tutta la root directory, ma filtra i seguenti
percorsi speciali:
* /dev
* /proc
* /root
* /sys
* /var/log/packages
* /var/log/scripts
* /var/log/removed_packages
* /var/log/removed_scripts

Si possono inoltre (ed è consigliato farlo) impostare dei
filtri utente semplicemente creando il file
''~/.find_external_SlackPkg_files''. Il formato del file è il
seguente:
* tutte le righe vuote e le righe che iniziano con un '#' sono ignorate.
* ogni riga non ignorata deve contenere esattamente un percorso e, opzionalmente, un comando da controllare. In quest'ultimo caso, il comando deve essere separato dal percorso da almeno un carattere di spaziatura; il percorso associato sarà filtrato se, e solo se, il comando esiste nel PATH.

Quindi ad esempio, se il file contiene le seguenti righe:
<pre>
# My comments

/home
/mnt
/media
/usr/share/fonts/*/fonts.scale
/usr/share/mime update-mime-database
</pre>
Allora lo script ignorerà:
* la directory ''/home''
* le directory contenenti i filesystem montati, ma che sono estranei alla distribuzione (''/mnt'' e ''/media'').
* tutti i file generati dal comando '''mkfontscale'''
* la directory ''/usr/share/mime'' se, e solo se, esiste il comando '''update-mime-database'''

{{Warning
|Nota:
|Se il path da filtrare contiene uno spazio, allora lo script penserà che ciò che si trova dopo lo spazio sia un comando da controllare. In questo caso, affinché tutto funzioni, bisogna aggiungere un altro spazio e poi un comando sicuramente esistente (ad esempio la bash, visto che lo script è interpretato proprio da questa shell).
Es:
/my path with spaces bash
}}

{{Hint
|Nota:
|I percorsi da filtrare sono passati al comando '''find''' tramite l'uso della sua opzione '''-path'''. Si veda il manuale di '''find''' per conoscere il formato accettato.
}}

= Le opzioni =
== -h ==
Mostra l'help ed esce.

== -f ==
Mostra in output i percorsi filtrati ed esce.

= I link simbolici alle librerie =
Alcuni link simbolici alle librerie, che lo script mostra in output,
vengono creati dal comando '''ldconfig'''. In generale eliminare
questi link non comporta danno poiché basta eseguire di nuovo
il comando citato (e la Slackware di default lo fa ad ogni avvio) per
ricrearli. E' ovvio però che sarebbe meglio lasciarli.

= Le glibc =
Le librerie '''glibc''' non sono installate in maniera canonica. Il
pacchetto installa queste librerie in una directory temporanea
chiamata ''incoming'' e poi lo script di post-installazione sposta
tutte le librerie nella locazione opportuna. Questo viene fatto
proprio per impedire che le librerie vengano eliminate insieme al
pacchetto. Se questo accadesse, infatti, un aggiornamento 'a caldo'
delle '''glibc''' farebbe sì che tutti i comandi linkati con le
vecchie librerie non funzionino più. Questo vorrebbe dire un
blocco del sistema poiché non si avrebbero più a
disposizione i comandi basilari come '''rm''', '''ls''', etc...

{{Warning
|Attenzione:
|Lo script individua correttamente le librerie installate dal pacchetto '''glibc''', ma questo rappresenta comunque un classico caso di '''doinst.sh''' non banale (si veda la sezione [[#Bug]]). Si faccia quindi attenzione ad eliminare 'a priori' tutti i file segnalati dallo script.
}}

= KDE =
KDE usa la directory ''/var/tmp'' per inserire le cache utenti. In
particolare, per ogni utente crea la directory
''/var/tmp/kdecache-username''. Essendo queste directory create a
run-time da KDE lo script le individuerà come "estranee" a
tutti i pacchetti.

Si può quindi inserire la seguente regola di filtraggio per
evitare che lo script mostri in output tutte queste directory:
/var/tmp/kdecache-* kde-mv
il comando '''kde-mv''' viene installato con il pacchetto
'kdebase-runtime'. Grazie a questa regola, quindi, tutte le cache
utenti di KDE saranno ignorate sino a che si decide di mantenere nel
sistema tutto il desktop environment. Alla rimozione di KDE (e quindi
anche del comando '''kde-mv'''), lo script consiglierà di
eliminare anche tutte la sua cache.

= Bug =
Per quanto lo script si sforzi di trovare tutti e soli quei file e
directory "estranei" ai pacchetti installati, alcuni '''doinst.sh'''
sono scritti in maniera particolare e fanno ben altro che creare
semplici link simbolici. Ad esempio uno script di post installazione
potrebbe creare nuove directory, oppure copiare e/o spostare dei file da
una directory ad un'altra. Tutti questi rappresentano casi non banali
che lo script non è in grado di individuare.

= Lo script =
Bene, è ora giunto il momento di scaricare e provare lo script, che
può essere trovato [[Media:Find_external_SlackPkg_files.sh|qui]].

Un buon file da usare come filtro invece lo potete trovare [[Media:Find_external_SlackPkg_files_filter.txt|qui]].

una volta scaricato basta rinominarlo usando il comando seguente:
mv find_external_SlackPkg_files_filter.txt ~/.find_external_SlackPkg_files
Se secondo voi ci sono altri path che varrebbe la pena inserire in
questo file, non esitate a scrivermi.

= Vedere anche =
[http://www.slacky.eu/wikislack/index.php?title=Unused_SlackPkg unused_SlackPkg.sh]

= Copyright - License =
Autore (ultima modifica): [[Utente:targzeta|targzeta]] 00:54, 3 ott 2011 (CEST)

Ringrazio gli utenti di Slacky.eu, Procopio e ZeroUno per i loro
feedback e suggerimenti. Se lo script è migliorato nel tempo
è soprattutto grazie a loro.
{{Information
|GNU Free Documentation Licence
|This article is released under the GNU Free Documentation Licence. You are welcome to copy and redistribute it (subject to certain conditions).
}}

File:Find external SlackPkg files filter.txt

2012-10-02T22:27:10Z

Targzeta:

File:Find external SlackPkg files.sh

2012-10-02T22:24:48Z

Targzeta:

Unused SlackPkg

2012-10-02T22:23:23Z

Targzeta: Caricato i file esterni all'interno di wikislacky

[[Category:Script]]
= Introduzione =
La Slackware, come sappiamo, non ha un sistema per il controllo
automatico delle dipendenze. Questo vuol dire che se oggi installiamo
il pacchetto X che necessita del pacchetto Y, e domani eliminiamo il
pacchetto X, il pacchetto Y potrebbe non essere più utilizzato
da nessun altro, diventando così un pacchetto orfano: installato
ma non utilizzato.

Lo script unused_SlackPkg.sh si occupa di controllare tutti i
pacchetti presenti sulla nostra Slackware in cerca di quelli
orfani. Per fare questo, lo script verifica la data di ultimo accesso
di tutti i file installati da ogni pacchetto e, se questa data
risulta essere troppo vecchia, allora desume che il pacchetto è
inutilizzato e stampa in output il suo nome.

= Le opzioni =
== -h ==
Questa opzione ha il solo scopo di mostrare l'help.

== -d <date> ==
Lo script controlla la data di ultimo accesso dei file installati da
un pacchetto e la confronta con una data di riferimento che di default
è un mese nel passato. Ovvero, lo script decide che un
pacchetto è inutilizzato se la data di ultimo accesso di tutti
i file installati è più vecchia di un mese (cioé,
il pacchetto non è stato utilizzato per un mese).

Con questa opzione si può modificare la data di riferimento. Il
parametro è lo stesso parametro dell'opzione '''-d''' del
comando '''date(1)'''.

== -s ==
Se viene specificata questa opzione, lo script, oltre a stampare a
video il nome del pacchetto ritenuto inutilizzato, ne stampa anche la
dimensione su disco.

= Filtrare i pacchetti =
Lo script a volte potrebbe indicare come inutilizzato un pacchetto
fondamentale della Slackware. Uno tra tutti il pacchetto
'''aaa_base''', il quale contiene solo la struttura della root
directory e non fa altro che creare tutte le directory necessarie. Il
pacchetto '''aaa_base''' contiene solo due file:
/etc/slackware-version
/var/spool/mail/root.new
e va da se che diventerà presto inutilizzato.

Per ovviare a questo tipo di inconveniente, specie se si utilizza
l'output dello script per eseguire una pulitura automatica del
sistema, si può creare il file ''~/.unused_SlackPkg'' ed
inserirvi, uno per ogni riga, i nomi dei pacchetti che si vogliono
filtrare. Così, ad esempio, se vogliamo filtrare il pacchetto
'''aaa_base''' basterà eseguire questo comando:
$> echo aaa_base >> ~/.unused_SlackPkg

= Lo script =
Bene, è ora giunto il momento di scaricare e provare lo script, che
può essere trovato [[Media:Unused_SlackPkg.sh‎|qui]].

= Non-Bug =
Lo script si rifiuta di funzionare se la root directory viene montata con
l'opzione '''noatime'''. Infatti, come cita mount(8):
'''noatime'''
Do not update inode access times on this filesystem (e.g, for faster access on the news spool to speed up news servers).
con questa opzione la data di ultimo accesso ai file non viene mai
modificata, quindi l'algoritmo seguito dallo script non funziona.

= Vedere anche =
[http://www.slacky.eu/wikislack/index.php?title=Find_external_SlackPkg_files find_external_SlackPkg_files.sh]

= Copyright - License =
Autore (ultima modifica): [[Utente:targzeta|targzeta]] 13:49, 18 set 2011 (CEST)
{{Information
|GNU Free Documentation Licence
|This article is released under the GNU Free Documentation Licence. You are welcome to copy and redistribute it (subject to certain conditions).
}}

File:Unused SlackPkg.sh

2012-10-02T22:22:23Z

Targzeta:

Check For Updated

2012-10-02T22:19:41Z

Targzeta: Caricato i file esterni all'interno di wikislacky

[[category:Script]]
=Introduzione=
Lo script '''check_for_updates.sh''' controlla se una determinata pagina internet è stata modificata. Lo si può pensare come un'alternativa ai feed RSS.

Lo script è stato creato con lo scopo di scoprire se un determinato progetto è stato modificato oppure no, dall'ultima volta che lo si è controllato.

=Download=
Lo script lo potete trovare [[Media:Check_for_updates.sh‎|qui]].

==NOTA per le versioni dalla 1.5 in poi==
Se si passa da una versione precedente ad una >= della 1.5, dato che lo script ha cambiato nome (da '''check_upgrade.sh''' a '''check_for_updates.sh'''), si dovrebbero anche rinominare tutte le sottodirectory ''.check_upgrade'' in ''.check_for_updates''. Ecco uno script che potrebbe essere d'aiuto:
<pre>
for file in *;
do
if [ -d $file ] && [ -d ${file}/.check_upgrade ];
then
mv ${file}/.check_upgrade ${file}/.check_for_updates;
fi;
done
</pre>

'''Se invece è la prima volta che si usa lo script, questo non è necessario!!'''

=L'ambiente di lavoro=
Lo script lavora su directory, l'idea è che per ogni progetto che l'utente segue, ci sia una directory associata, ad esempio:
<pre>
$> ls -1F software/
FileZilla/
a52dec/
aircrack-ng/
amrnb/
amrwb/
audacity/
...
check_for_updates.sh*
...
</pre>
come si nota, lo script è all'interno della directory ''software'', la quale contiene una directory per ogni progetto che si vuole seguire (FileZilla, aicrack-ng, etc...).

=Lo script e le varie modalità=
Lo script opera in diversi modi a seconda di quale modalità si scelga di eseguire. L'elenco delle modalità lo si trova con l'uso dell'opizione ''--help''
<pre>
$> check_for_updates.sh --help
Uso: check_for_updates.sh [opzioni] MODALITA [mod_opzioni] arg1...
check_for_updates.sh MODALITA -h|--help
check_for_updates.sh -v|--version

Opzioni:
-c Non colora l'output

MODALITA e' una tra:
check
db
init
not_conform
update
url

by Emanuele Tomasi aka targzeta <targzeta@gmail.com>
</pre>

==Modalità init==
Questa è la prima modalità che si usa per iniziare a seguire un progetto. L'help per questa
modalità è il seguente:
<pre>
$> check_for_updates.sh init --help
Uso: check_for_updates.sh init [opzioni] dir URL

Inizializza la directory dir tramite l'URL passatogli.

Opzioni:
-g forza l'uso del protocollo git
-q quiet
-s forza l'uso del protocollo svn
-v verbose

L'URL va quotato se contiene caratteri speciali per la shell,
come ad esempio il carattere '&'.
</pre>
gli argomenti sono quindi soltanto due:
* Il nome della directory associata al progetto da seguire;
* L'URL della pagina web in cui vengono annunciati i cambiamenti o nuove release;
{{Be Careful|Nota|Come dice anche l'help, l'URL va quotato se contiene caratteri che la shell può interpretare o espandere. Vedi appunto il carattere '&' che per la shell significa: "manda in background".}}

Ad esempio, per il progetto FileZilla si ha:
* Il nome della directory == ''FileZilla/''
* URL = http://filezilla-project.org/download.php?type=client

quindi per iniziare a seguire il progetto basta eseguire:
<pre>
$> check_for_updates.sh init FileZilla/ http://filezilla-project.org/download.php?type=client
# Directory: FileZilla
INIZIALIZZATA
</pre>
{{Hint|Nota|Il nome della directory non deve finire necessariamente con il carattere '/'.}}

Una volta che la directory è stata inizializzata la si definisce "conforme" allo script, ovvero lo script al suo interno ha creato una sottodirectory di nome ''.check_for_updates'' con all'interno due file:
; page : la pagina web indirizzata dall'URL (scaricata tramite il comando '''wget''');
; url : l'URL che si è passato come parametro;
<pre>
$> tree FileZilla/.check_for_updates/
FileZilla/.check_for_updates/
|-- page
`-- url

0 directories, 2 files
</pre>

===Protocolli===
Ci sono vari tipi di protocolli accettati dallo script, il protocollo da usare viene individuato analizzando l'inizio dell'URL oppure attraverso l'uso delle opzioni '''-g''' e '''-s''' della modalità '''init'''.

====http(s) o ftp====
Il download delle pagine per questi protocolli avviene tramite il comando:
wget --no-check-certificate

L'uso di questi protocolli è di default quando l'URL inizia con http(s):// oppure ftp.

====svn====
L'uso di subversion avviene scaricando, come pagina da confontare, il log, e viene fatto usando:
svn info -r HEAD

L'uso di questo protocollo è di default quando l'URL inizia con svn://. Poichè però subversion si appoggia anche su altri protocolli, si può forzare l'uso di questo protocollo anche con URL che non iniziano con svn://. Per fare questo basta semplicemente usare l'opzione '''-s''' della modalità '''init'''.

====git====
L'uso di git avviene scaricando, come pagina da confrontare, il log, e viene fatto usando:
git ls-remote HEAD

L'uso di questo protocollo è di default quando l'URL inizia con git://. Poichè però git si appoggia anche su altri protocolli, si può forzare l'uso di questo protocollo anche con URL che non iniziano con git://. Per fare questo basta semplicemente usare l'opzione '''-g''' della modalità '''init'''.

==Modalità check==
Una volta inizializzata la directory, si può seguire il progetto facendo un '''check''' su di essa. L'help per questa modalità è:
<pre>
$> check_for_updates.sh check --help
Uso: check_for_updates.sh check [opzioni] dir1...

Controlla se la pagina e' aggiornata.

Opzioni:
-d mostra l'output di 'diff' quando controlla l'aggiornamento
-e non mostra gli errori di download
-f mostra la pagina filtrata (non effettua controlli sull'aggiornamento)
-k non elimina i file temporanei all'uscita
-n mostra l'output di 'diff' stampando solo le nuove righe. Ignora '-d'
-o produce output solo se la pagina e' stata aggiornata. Implica '-s'
-q quiet. Implica '-s'
-s non stampa errori sulle directory non conformi
-v verbose
</pre>
come si vede, si può fare il '''check''' anche su più directory contemporaneamente, in effetti lo si può fare anche su directory non conformi o file, lo script salterà i file, e tramimte l'opzione '-s' non stamperà nulla neanche sulle directory non conformi. Questo è utile se si vuole eseguire il check su di un'intera directory con:
$> check_for_updates.sh check *

Lo script, quando è invocato con questa modalità segue il seguente algoritmo (a meno che non venga eseguito con l'opzione '-f'):
* scarica la pagina web (identificata dall'indirizzo trovato nel file ''.check_for_updates/url'') in un file temporaneo;
* fa una copia della pagina web ''.check_for_updates/page'' in un altro file temporaneo;
* se ci sono filtri, allora filtra entrambe le pagine temporanee;
* esegue il comando '''diff''' per vedere se ci sono differenze tra le due pagine temporanee;

Un esempio di invocazione è il seguente:
<pre>
$> check_for_updates.sh check FileZilla/
# Directory: FileZilla
OK
</pre>
il valore di ritorno 'OK' indica che la pagina ''.check_for_updates/page'' (filtrata) non differisce dalla pagina internet (filtrata).

===Opzione -d===
Tramite questa opzione, lo script mostrerà l'output del comando '''diff''' sulle pagine temporanee. Questo è utile per vedere se effettivamente la differenza è significativa oppure no. Se non è significativa, si può migliorare il controllo creando appositi filtri (si vedrà in seguito l'uso dei filtri).

===Opzione -f===
In questo caso lo script non esegue l'algoritmo spiegato in precedenza, ma si limita a filtrare la pagina '''.check_for_updates/page'' e a mostrare l'esito dei filtri e, quindi, la porzione di pagina che si verrà controllata.

===Opzione -k===
Con questa opzione, lo script non eliminerà i file temporanei creati per il confronto.

===Opzione -n===
Questa opzione è simile (e ne è un alternativa) all'opzione '''-d''', con la differenza che mostra soltanto le nuove righe. E' utile nel caso la pagina che si tiene sotto controllo sia effettivamente un log con entry che vengono eliminate in favore di nuove.

===Opzione -o===
Lo script, per ogni directory che gli si passa, produce una serie di output tipo quello visto negli esempi precedenti. Questa opzione inibisce lo script a produrre output se il comando '''diff''' torna che le due pagine temporanee sono identiche. Nell'esempio, dato che la directory FileZilla viene trovata 'OK', lo script, con questa opzione, non produce output. E' molto utile se si invoca lo script passandogli molte directory, o addirittuta '*'.

Ad esempio:
<pre>
$> check_for_updates.sh check -o FileZilla/ amrwb/
# Directory: amrwb
DA AGGIORNARE
</pre>
{{Information|NOTA|L'uso di questa opzione implica l'opzione '-s'.}}

===Opzione -q (caso particolare)===
Questa opzione inibisce lo script a produrre output, in pratica rende incompresibile l'uso dello script. L'unico motivo per cui esiste ancora è che in associazione con l'opzione '-o', si ha l'elenco delle directory per le quali lo script produrrebbe 'DA AGGIORNARE'.

Ad esempio:
<pre>
$> check_for_updates.sh check -qo FileZilla/ amrwb/
amrwb
</pre>
{{Information|NOTA|L'uso di questa opzione implica l'opzione '-s'.}}

===Opzione -s===
Normalmente se allo script gli si passa una directory non conforme esso produrra in output una scritta simile a questa:
<pre>
$> check_for_updates.sh check Kernel/
# Directory: Kernel
Attenzione: Kernel non ha:
* o la sottodirectory .check_for_updates
* o il file .check_for_updates/url
* o il file .check_for_updates/page
</pre>

Tramite l'uso di questa opzione, lo script salta queste directory e quindi non produce nessun output. Questa opzione è utile se si invoca lo script su più directory in contemporanea o su '*'.

==Modalità update==
L'unico modo per far sapere allo script che una directory è di nuovo aggiornata, è quello di invocarlo con questa modalità. Lo script scaricherà la nuova pagina web e la sostituirà con quella in ''.check_for_updates/page''. L'help è il seguente:
<pre>
$>check_for_updates.sh update --help
Uso: check_for_updates.sh update [opzioni] dir1...

Aggiorna, riscaricando la pagina, la directory dir.

Opzioni:
-q quiet
-v verbose
</pre>

Ad esempio, se si aggiorna la directory ''amrwb'', per il quale lo script ha ritornato 'DA AGGIORNARE', invocando lo script con questa modalità si ottiene:
<pre>
$> check_for_updates.sh update amrwb/
# Directory: amrwb
AGGIORNATA
</pre>

==Modalità not_conform==
La modalità si limita ad elencare, tra le directory passategli, quelle non conformi. L'help è il seguente:
<pre>
$> check_for_updates.sh not_conform --help
Uso: check_for_updates.sh not_conform dir1...

Stampa il nome delle dir non conformi (non inizializzate).
</pre>

Ad esempio:
<pre>
$> check_for_updates.sh not_conform FileZilla/ amrwb/ Kernel/
Kernel
</pre>

==Modalità url==
Per ogni directory passatagli, se la directory è conforme, lo script stampa l'URL trovato nel file ''.check_for_updates/url''. L'help è il seguente:
<pre>
$> check_for_updates.sh url --help
Uso: check_for_updates.sh url dir1...

Stampa l'URL impostato per la directory dir.

Opzioni:
-q quiet
</pre>

Ad esempio:
<pre>
$> check_for_updates.sh url FileZilla/ amrwb/ Kernel/
# Directory: FileZilla
http://filezilla-project.org/download.php?type=client

# Directory: amrwb
http://www.penguin.cz/~utx/amr
</pre>

=Filtri=
I filtri sono un modo per far si che lo script esegua il comando '''diff''' solo su una porzione anziché sull'intera pagina.

Attualmente i filtri si devono creare a mano e vanno messi in dei file nella sottodirectory ''.check_for_updates/'' del progetto. Ci sono cinque tipi di filtri, caratterizzati da altrettanti nomi file.

Quando lo script viene invocato con la modalità '''check''', prima di eseguire il comando '''diff''', se trova i file dei filtri, filtra i file temporanei.
{{Hint|Nota|I filtri sono applicati usando '''sed''' con le basic regex.}}
Nella scrittura di alcuni filtri si può usare la direttiva '''#DIR#''' che viene sostituita dal nome della directory su cui lo script stà lavorando.
{{Be Careful|Nota|Poiché il filtro '''sed_script''' può sostituire tutti gli altri, nelle prossime versioni sarà l'unico filtro ammesso.}}

==Il filtro compare_only_line (obsoleto)==
Se esiste un file chiamato ''.check_for_updates/compare_only_line'', questo file deve contenere, una per riga, un'espressione regolare. Solo le righe dei file temporanei che hanno il match con queste espressioni regolari saranno confrontate.

Ad esempio, se si guarda il link impostato per FileZilla, si noterà che in quella pagina vengono linkati sia i sorgenti per linux, sia l'installer per Windows, per Mac OS, etc. etc. Se si vuole controllare solo i sorgenti per linux, basta creare il file ''.check_for_updates/compare_only_line'' con all'interno questa espressione regolare:
FileZilla.*src.*bz2

Per vedere cosa effettivamente compara il comando '''diff''', basta eseguire lo script con modalità '''check''' e opzione '-f':
<pre>
$> check_for_updates.sh check -f FileZilla/
# Directory: FileZilla
<p><a href="https://www.ohloh.net/projects/filezilla/download?filename=FileZilla_3.1.5.1_src.tar.bz2">FileZilla_3.1.5.1_src.tar.bz2</a> </p>
</pre>
come si può notare, il filtro ha lasciato passare solo la riga che contiene il link ai sorgenti.

Per questo filtro si può usare la direttiva '''#DIR#''', quindi se il nome della directory che contiene il progetto FileZilla si chiama proprio ''FileZilla/'', una regex del tutto analoga a quella mostrata prima è:
#DIR#.*src.*bz2

==Il filtro filter_line_number (obsoleto)==
Se esiste un file chiamato ''.check_for_updates/filter_line_number'', questo file deve contenere, per ogni riga, un numero. Lo script sopprimerà le righe corrispondenti dalla pagina, prima di eseguire '''diff'''.

==Il filtro filter_line_regex (obsoleto)==
Se esiste un file chiamato ''.check_for_updates/filter_line_regex'', questo file deve contenere, per ogni riga, un'espressione regolare. Lo script sopprimerà le righe della pagina che hanno il match con una di queste espressioni regolari, prima di eseguire '''diff'''.

Per questo filtro si può usare la direttiva '''#DIR#'''.

==Il filtro filter_word (obsoleto)==
Se esiste un file chiamato ''.check_for_updates/filter_word'', questo file deve contenere, per ogni riga, un'espressione regolare. Lo script sopprimerà, per ogni riga che ha il match con una di queste espressione regolari, l'espressione regolare stessa.

Ad esempio, con riferimento all'output prodotto già dal filtro '''compare_only_line''' nell'esempio precedente, se si volesse eliminare dall'unica riga prodotta dal filtro, anche tutte le parole dall'inizio della riga sino al protocollo https, basta fare:
<pre>
$> echo '^.*href="' > FileZilla/.check_for_updates/filter_word

$> check_for_updates.sh check -f FileZilla/
# Directory: FileZilla
https://www.ohloh.net/projects/filezilla/download?filename=FileZilla_3.1.5.1_src.tar.bz2">FileZilla_3.1.5.1_src.tar.bz2</a> </p>
</pre>

Per questo filtro si può usare la direttiva '''#DIR#'''.

== Il filtro sed_script ==
Se esiste un file chiamato ''.check_for_updates/sed_script'', questo file deve contenere un vero e proprio script per sed. '''check_for_updates.sh''' esegue il comando '''sed -n -f .check_for_updates/sed_script''', quindi si faccia attenzione poiché non verrà generato nessun output a meno che non si sia usato il comando '''p''' di sed.

Per questo filtro si può usare la direttiva '''#DIR#'''.

==L'ordine di esecuzione dei filtri==
I filtri sopra citati vengono eseguiti nel seguente ordine:
* sed_script
* compare_only_line
* filter_line_number
* filter_line_regex
* file_filter_word

L'ordine degli ultimi tre filtri non è importante, ma si deve tenere ben presente che prima si filtrano i file temporanei con il filtro '''sed_script''', quindi sull'output di questo filtro viene applicato, se esiste, il filtro '''compare_only_line''', ed infine sull'output di quest'altro filtro, vengono applicati, se ci sono, i filtri per sopprimere altre righe o parole.

=Progetti su Sourceforge=
Il link ai file di un progetto hostato su Sourceforge hanno tutti la stessa forma:
http://sourceforge.net/projects/NOME_PROGETTO/files/
dove NOME_PROGETTO è proprio il nome del progetto hostato.

Quindi un modo per inizializzare lo script, ad esempio per p7zip è:
$> check_for_updates.sh init p7zip http://sourceforge.net/projects/p7zip/files/

E, per filtrare la pagina scaricata basta fare:
<pre>
$> echo '/#DIR#.*class="folder/b get_date;d;:get_date /date/{s/.*title="$[[:digit:]-]\+$.*/#DIR# \1/p;q};n;b get_date'\
> p7zip/.check_for_updates/sed_script
</pre>

il quale fa passare solo la data dell'ultimo file aggiornamento, come si può vedere dall'output della modalità '''check''' con l'opzione '-f':
<pre>
$> check_for_updates.sh check -f p7zip/
# Directory: p7zip
p7zip 2010-05-30
</pre>

=Working in progress...=
Lo script necessita ancora di ottimizzazioni, ritocchi ed espansioni. Per ora, ad esempio, il comportamento con le opzioni delle varie modalità è un po' bizzarro, basti pensare che l'opzione '-q' e '-v' non generano un errore di incompatibilità.

La madalità '''db''' per ora non fa nulla, ma l'idea è quella di poter esportare ed importare URL e/o filtri. In questo modo basterebbe avere un pacchetto il più completo possibile di queste informazioni per far si che più utenti possano controllare gli stessi progetti senza doversi ogni volta scovare URL e filtri adatti.

=Ringraziamenti e conclusioni=
Ringrazio:
* conraid per l'ottimo feedback

Autore (data dell'ultimo aggiornamento):<br/>
[[Utente:targzeta|targzeta]] ([[Discussioni utente:targzeta|discussioni]]) 00:08, 1 ago 2012 (CEST)

File:Check for updates.sh

2012-10-02T22:18:31Z

Targzeta:

Analyze SlackPkg.sh

2012-10-02T22:17:40Z

Targzeta: Caricato i file esterni all'interno di wikislacky

[[category:Script]]
=Introduzione=
Questo script visualizza alcune informazioni interessanti riguardanti i pacchetti Slackware installati e può essere usato per mantenere aggiornata una current. Lo script deve essere eseguito in una directory contenente il file FILE_LIST fornito dal CD/DVD.
=Cosa fa e come si usa=
==Senza opzioni==
Lo script, per ogni pacchetti installato va a controllare se è nominato nel file FILE_LIST controllandone la versione, dove per versione si intende sia la versione del software che la marca di compilazione. Se le due versioni differiscono allora lo script stampa a video il percorso dove poter trovare il pacchetto con la versione differente. Ad esempio sulla mia macchina:
<pre>
$> analyze_SlackPkg.sh
./a/aaa_elflibs-13.013-x86_64-5.txz
./l/cairo-1.8.8-x86_64-3.txz
./n/stunnel-4.33-x86_64-1.txz
</pre>
questo vuol dire che nella mia Slackware sono installati i tre pacchetti elencati ma con versioni differenti, infatti ad esempio:
<pre>
$> ls /var/log/packages/stunnel-*
/var/log/packages/stunnel-4.17-x86_64-1
</pre>
Quindi se si ha a disposizione un repository locale della current si può aggiornare il PC semplicemente eseguendo:
<pre>
for package in $(analyze_SlackPkg.sh)
do
upgradepkg $package
done
</pre>
==Le opzioni==
===-h===
Mostra l'help dello script.
===-n===
Stampa l'elenco dei pacchetti nominati nel FILE_LIST, ma che non sono stati installati.
===-m===
Stampa l'elenco dei pacchetti che non sono stati trovati nel file FILE_LIST o che sono stati filtrati dal [[#Il file di filtraggio|file di filtro]]. Questi pacchetti generalmente sono i pacchetti di terze parti (ad esempio quelli di Slacky.eu) ed i pacchetti che sono stati rimossi dalla Slackware.
===-s===
Stampa l'elenco dei pacchetti che hanno la stessa versione di quelli trovati nel file FILE_LIST.
===-v===
A volte è utile sapere la versione attuale dei pacchetti installati, questa opzione oltre a visualizzare il percorso del pacchetto con la versione diversa, stampa anche la versione attualmente installata.

<pre>
$>analyze_SlackPkg.sh -v
./a/aaa_elflibs-13.013-x86_64-5.txz the current version is aaa_elflibs-13.013-x86_64-4
./l/cairo-1.8.8-x86_64-3.txz the current version is cairo-1.8.10-x86_64-1
./n/stunnel-4.33-x86_64-1.txz the current version is stunnel-4.17-x86_64-1
</pre>

=Il file di filtraggio=
Può capitare che di alcuni software si voglia seguire una versione current e non quella fornita dalla Slackware, usando il ciclo for descritto precedentemente per aggiornare il PC evidentemente questi pacchetti risulteranno con una versione differente e saranno quindi aggiornati. Per evitare questo comportamento basta creare un file nella propria home chiamato ''.analyze_SlackPkg'' e inserirci al proprio interno il nome del software da saltare e quest'ultimo non sarà stampato in output. Ad esempio se inserisco nel mio file il software '''cairo''' e poi rieseguo lo script:
<pre>
$> echo 'cairo' >> ~/.analyze_SlackPkg

$> analyze_SlackPkg.sh
./a/aaa_elflibs-13.013-x86_64-5.txz
./n/stunnel-4.33-x86_64-1.txz
</pre>
si nota che rispetto a prima, '''cairo''' non viene visualizzato.
=Lo script=
Dulcis in fundo, lo script potete trovarlo [[Media:Analyze_SlackPkg.sh‎|qui]].

Autore (data dell'ultimo aggiornamento):
[[Utente:targzeta|targzeta]] 07:38, 28 ott 2010 (UTC)

File:Analyze SlackPkg.sh

2012-10-02T22:09:28Z

Targzeta:

Find external SlackPkg files

2012-10-02T21:59:08Z

Targzeta: Cambiato nick

[[Category:Script]]
= Introduzione =
I "maniaci delle pulizie" - come me - a volte hanno la
necessità di scovare quei file, presenti nella root directory,
che non appartengono a nessun pacchetto installato. Questo infatti
permette di stabilire se quei file sono vecchi e vanno rimossi oppure
sono file di configurazione (o altro) creati dai programmi a run-time.

Spesso e volentieri qualcuno installa un pacchetto ma poi si accorge
che non gli serviva, quindi lo rimuove. Il dubbio si insinua nella
mente di un "maniaco delle pulizie": "ho rimosso tutto? il sistema
è ritornato come se il pacchetto non fosse mai stato
installato?". Generalmente i dubbi sono infondati, quasi tutti i
pacchetti vengono rimossi completamente e non lasciano tracce, ma
è proprio quel 'quasi tutti' che non fa dormire sonni
tranquilli.

Lo script find_external_SlackPkg_files.sh esegue una scansione di
tutta la root directory e controlla, file per file, se esso è
stato installato da un pacchetto Slackware oppure no. Quindi
visualizza in output tutti quei file "estranei" ai pacchetti.

Lo script può essere eseguito sia come root che come utente
normale. In quest'ultimo caso, ovviamente, lo script non potrà
scandire quelle directory di proprietà di altri utenti, ma
darà comunque dei buoni risultati.

= L'algoritmo =
L'algoritmo è molto semplice, lo script esegue un '''find'''
sulla root directory filtrando alcuni path (si veda la sezione
[[#Filtrare dei percorsi]]). Una volta creata questa 'file list', lo
script individua anche tutti i link simbolici creati dagli script
'''doinst.sh''' dei vari pacchetti. Quindi, controlla quali tra i file
presenti nella 'file list' non appartiene ad un pacchetto e non
è neanche un link simbolico creato da un '''doinst.sh'''.

{{Information
|Informazione:
|L'algoritmo è semplice ma la sia esecuzione è bella lunga. Diciamo che la vostra CPU non vi ringrazierà.
}}

== Filtrare dei percorsi ==
Lo script non scandisce tutta la root directory, ma filtra i seguenti
percorsi speciali:
* /dev
* /proc
* /root
* /sys
* /var/log/packages
* /var/log/scripts
* /var/log/removed_packages
* /var/log/removed_scripts

Si possono inoltre (ed è consigliato farlo) impostare dei
filtri utente semplicemente creando il file
''~/.find_external_SlackPkg_files''. Il formato del file è il
seguente:
* tutte le righe vuote e le righe che iniziano con un '#' sono ignorate.
* ogni riga non ignorata deve contenere esattamente un percorso e, opzionalmente, un comando da controllare. In quest'ultimo caso, il comando deve essere separato dal percorso da almeno un carattere di spaziatura; il percorso associato sarà filtrato se, e solo se, il comando esiste nel PATH.

Quindi ad esempio, se il file contiene le seguenti righe:
<pre>
# My comments

/home
/mnt
/media
/usr/share/fonts/*/fonts.scale
/usr/share/mime update-mime-database
</pre>
Allora lo script ignorerà:
* la directory ''/home''
* le directory contenenti i filesystem montati, ma che sono estranei alla distribuzione (''/mnt'' e ''/media'').
* tutti i file generati dal comando '''mkfontscale'''
* la directory ''/usr/share/mime'' se, e solo se, esiste il comando '''update-mime-database'''

{{Warning
|Nota:
|Se il path da filtrare contiene uno spazio, allora lo script penserà che ciò che si trova dopo lo spazio sia un comando da controllare. In questo caso, affinché tutto funzioni, bisogna aggiungere un altro spazio e poi un comando sicuramente esistente (ad esempio la bash, visto che lo script è interpretato proprio da questa shell).
Es:
/my path with spaces bash
}}

{{Hint
|Nota:
|I percorsi da filtrare sono passati al comando '''find''' tramite l'uso della sua opzione '''-path'''. Si veda il manuale di '''find''' per conoscere il formato accettato.
}}

= Le opzioni =
== -h ==
Mostra l'help ed esce.

== -f ==
Mostra in output i percorsi filtrati ed esce.

= I link simbolici alle librerie =
Alcuni link simbolici alle librerie, che lo script mostra in output,
vengono creati dal comando '''ldconfig'''. In generale eliminare
questi link non comporta danno poiché basta eseguire di nuovo
il comando citato (e la Slackware di default lo fa ad ogni avvio) per
ricrearli. E' ovvio però che sarebbe meglio lasciarli.

= Le glibc =
Le librerie '''glibc''' non sono installate in maniera canonica. Il
pacchetto installa queste librerie in una directory temporanea
chiamata ''incoming'' e poi lo script di post-installazione sposta
tutte le librerie nella locazione opportuna. Questo viene fatto
proprio per impedire che le librerie vengano eliminate insieme al
pacchetto. Se questo accadesse, infatti, un aggiornamento 'a caldo'
delle '''glibc''' farebbe sì che tutti i comandi linkati con le
vecchie librerie non funzionino più. Questo vorrebbe dire un
blocco del sistema poiché non si avrebbero più a
disposizione i comandi basilari come '''rm''', '''ls''', etc...

{{Warning
|Attenzione:
|Lo script individua correttamente le librerie installate dal pacchetto '''glibc''', ma questo rappresenta comunque un classico caso di '''doinst.sh''' non banale (si veda la sezione [[#Bug]]). Si faccia quindi attenzione ad eliminare 'a priori' tutti i file segnalati dallo script.
}}

= KDE =
KDE usa la directory ''/var/tmp'' per inserire le cache utenti. In
particolare, per ogni utente crea la directory
''/var/tmp/kdecache-username''. Essendo queste directory create a
run-time da KDE lo script le individuerà come "estranee" a
tutti i pacchetti.

Si può quindi inserire la seguente regola di filtraggio per
evitare che lo script mostri in output tutte queste directory:
/var/tmp/kdecache-* kde-mv
il comando '''kde-mv''' viene installato con il pacchetto
'kdebase-runtime'. Grazie a questa regola, quindi, tutte le cache
utenti di KDE saranno ignorate sino a che si decide di mantenere nel
sistema tutto il desktop environment. Alla rimozione di KDE (e quindi
anche del comando '''kde-mv'''), lo script consiglierà di
eliminare anche tutte la sua cache.

= Bug =
Per quanto lo script si sforzi di trovare tutti e soli quei file e
directory "estranei" ai pacchetti installati, alcuni '''doinst.sh'''
sono scritti in maniera particolare e fanno ben altro che creare
semplici link simbolici. Ad esempio uno script di post installazione
potrebbe creare nuove directory, oppure copiare e/o spostare dei file da
una directory ad un'altra. Tutti questi rappresentano casi non banali
che lo script non è in grado di individuare.

= Lo script =
Bene, è ora giunto il momento di scaricare e provare lo script, che
può essere trovato a questo link:
[http://www.slacky.eu/~targzeta/script/find_external_SlackPkg_files.sh find_external_SlackPkg_files.sh]

Un buon file da usare come filtro invece lo potete trovare a questo
link:
[http://www.slacky.eu/~targzeta/script/find_external_SlackPkg_files_filter find_external_SlackPkg_files_filter]

una volta scaricato basta rinominarlo usando il comando seguente:
mv find_external_SlackPkg_files_filter ~/.find_external_SlackPkg_files
Se secondo voi ci sono altri path che varrebbe la pena inserire in
questo file, non esitate a scrivermi.

= Vedere anche =
[http://www.slacky.eu/wikislack/index.php?title=Unused_SlackPkg unused_SlackPkg.sh]

= Copyright - License =
Autore (ultima modifica): [[Utente:targzeta|targzeta]] 00:54, 3 ott 2011 (CEST)

Ringrazio gli utenti di Slacky.eu, Procopio e ZeroUno per i loro
feedback e suggerimenti. Se lo script è migliorato nel tempo
è soprattutto grazie a loro.
{{Information
|GNU Free Documentation Licence
|This article is released under the GNU Free Documentation Licence. You are welcome to copy and redistribute it (subject to certain conditions).
}}

Unused SlackPkg

2012-10-02T21:58:32Z

Targzeta: Cambiato nick

[[Category:Script]]
= Introduzione =
La Slackware, come sappiamo, non ha un sistema per il controllo
automatico delle dipendenze. Questo vuol dire che se oggi installiamo
il pacchetto X che necessita del pacchetto Y, e domani eliminiamo il
pacchetto X, il pacchetto Y potrebbe non essere più utilizzato
da nessun altro, diventando così un pacchetto orfano: installato
ma non utilizzato.

Lo script unused_SlackPkg.sh si occupa di controllare tutti i
pacchetti presenti sulla nostra Slackware in cerca di quelli
orfani. Per fare questo, lo script verifica la data di ultimo accesso
di tutti i file installati da ogni pacchetto e, se questa data
risulta essere troppo vecchia, allora desume che il pacchetto è
inutilizzato e stampa in output il suo nome.

= Le opzioni =
== -h ==
Questa opzione ha il solo scopo di mostrare l'help.

== -d <date> ==
Lo script controlla la data di ultimo accesso dei file installati da
un pacchetto e la confronta con una data di riferimento che di default
è un mese nel passato. Ovvero, lo script decide che un
pacchetto è inutilizzato se la data di ultimo accesso di tutti
i file installati è più vecchia di un mese (cioé,
il pacchetto non è stato utilizzato per un mese).

Con questa opzione si può modificare la data di riferimento. Il
parametro è lo stesso parametro dell'opzione '''-d''' del
comando '''date(1)'''.

== -s ==
Se viene specificata questa opzione, lo script, oltre a stampare a
video il nome del pacchetto ritenuto inutilizzato, ne stampa anche la
dimensione su disco.

= Filtrare i pacchetti =
Lo script a volte potrebbe indicare come inutilizzato un pacchetto
fondamentale della Slackware. Uno tra tutti il pacchetto
'''aaa_base''', il quale contiene solo la struttura della root
directory e non fa altro che creare tutte le directory necessarie. Il
pacchetto '''aaa_base''' contiene solo due file:
/etc/slackware-version
/var/spool/mail/root.new
e va da se che diventerà presto inutilizzato.

Per ovviare a questo tipo di inconveniente, specie se si utilizza
l'output dello script per eseguire una pulitura automatica del
sistema, si può creare il file ''~/.unused_SlackPkg'' ed
inserirvi, uno per ogni riga, i nomi dei pacchetti che si vogliono
filtrare. Così, ad esempio, se vogliamo filtrare il pacchetto
'''aaa_base''' basterà eseguire questo comando:
$> echo aaa_base >> ~/.unused_SlackPkg

= Lo script =
Bene, è ora giunto il momento di scaricare e provare lo script, che
può essere trovato a questo link:
[http://www.slacky.eu/~targzeta/script/unused_SlackPkg.sh unused_SlackPkg.sh]

= Non-Bug =
Lo script si rifiuta di funzionare se la root directory viene montata con
l'opzione '''noatime'''. Infatti, come cita mount(8):
'''noatime'''
Do not update inode access times on this filesystem (e.g, for faster access on the news spool to speed up news servers).
con questa opzione la data di ultimo accesso ai file non viene mai
modificata, quindi l'algoritmo seguito dallo script non funziona.

= Vedere anche =
[http://www.slacky.eu/wikislack/index.php?title=Find_external_SlackPkg_files find_external_SlackPkg_files.sh]

= Copyright - License =
Autore (ultima modifica): [[Utente:targzeta|targzeta]] 13:49, 18 set 2011 (CEST)
{{Information
|GNU Free Documentation Licence
|This article is released under the GNU Free Documentation Licence. You are welcome to copy and redistribute it (subject to certain conditions).
}}

Apache+PHP+MySQL in chroot jail

2012-10-02T21:57:45Z

Targzeta: Cambiato nick

[[Category:Networking]]
= Introduzione =
In questo Wiki verrà spiegato come installare un server apache,
l'interprete di scripting PHP e il server MySQL in un ambiente
chroot. Tutto ciò che serve è una distribuzione
Slackware con i suoi tool di installazione dei pacchetti.
{{Information
|Nota:
|Questa procedura è stata eseguita con una Slackware 13.37, ma dovrebbe funzionare con qualsiasi versione di Slackware. Ovviamente bisogna stare attenti alle modifiche fatte ai file di configurazione e ai pacchetti che vengono listati, poiché sia i primi che i secondi potrebbero differire da versione a versione.
}}

== Perché farlo? ==
Se si vuole eseguire un server apache accedibile da qualsiasi utente
sul web è utile che esso giri all'interno di una prigione
(jail) in modo che se qualche malintenzionato riesce ad avere un
accesso al filesystem tramite, ad esempio, di un bug di qualche
software PHP installato (uno per tutti, Joomla), il nostro aggressore
si ritroverà in un ambiente senza diritti e senza la
possibilità di fare grandi danni.

== In cosa differesce questo wiki dalle altre guide? ==
Leggendo su internet le varie guide che suggeriscono come effettuare
l'imprigionamento del server apache in un ambiente chroot (chroot
jail, per l'appunto) si può notare come tutte tendano a rendere
difficile una simile operazione cercando di rendere l'ambiente chroot
il più ristretto possibile. Tutte le guide, quindi,
suggeriscono di copiare e/o spostare solo i file necessari e nulla
più. Ora, se da un certo punto di vista è preferibile
avere nell'ambiente chroot il minor numero di software possibile e il
minimo indispensabile per far eseguire al server apache tutte le sue
funzioni, dall'altro lato copiare e spostare solo i file necessari
rende scomoda l'aggiunta o l'aggiornamento del server stesso ad una
versione più sicura.

Questo wiki invece punta a rendere la vita semplice a chi deve
mantenere l'ambiente chroot aggiornato e facilmente modificabile. Lo
scopo viene raggiunto tramite l'installazione, non di singoli file ma
di interi pacchetti Slackware.

Inoltre, qui verrà installato nell'ambiente anche il server
MySQL e l'interprete PHP, procedura che in genere non viene spiegata
dalle guide per il chroot jail di apache. In effetti un server apache
senza il supporto a MySQL non serve a molto nei giorni d'oggi.
{{Information
|Nota per i pignoli:
|E' vero che il server MySQL è anche in grado di ascoltare connessioni via web e di accettare solo quelle dello stesso host. In questo caso invece si vuole rendere più sicuro il tutto facendo dialogare apache con mysql solo attraverso il socket locale.
}}

= La procedura =
Come prima cosa bisogna creare un directory che conterrà
l'ambiente chroot per i server che vogliamo installare:
# mkdir /chroot_jail

== L'installazione dei pacchetti ==
Una volta creata la directory destinata a contenere tutto il nostro
software, non ci resta che installare l'insieme minimo di pacchetti
necessari a fare eseguire nel nostro ambiente:
* il server apache con l'interprete PHP
* il server MySQL
I pacchetti, relativi alla distribuzione Slackware 13.37 (viene
indicata anche la directory che li contiene), sono:
* a/aaa_base
* a/aaa_elflib
* a/coreutils
* a/bash
* a/etc
* a/glibc-solib
* a/grep
* a/sed
* a/util-linux
* ap/mysql
* l/apr
* l/apr-util
* l/libmcrypt
* l/libxml2
* n/cyrus-sasl
* n/httpd
* n/openssl
* n/php
Questi pacchetti vanno installati eseguendo il comando:
# installpkg --root /chroot_jail nome_pacchetto

== La configurazione post-installazione ==
In linea teorica è tutto fatto. La directory /chroot_jail
contiene tutto il software necessario in circa 190MB di dati. Restano
però ancora alcune piccole configurazioni da fare.
{{Warning
|Attenzione:
|In questo contesto non ci preoccupiamo di configurare il server apache o il server mysqld. Il wiki spiega come creare l'ambiente adatto a farli partire, non come configurarli al meglio.
}}

=== Gli rc per l'halt dei server ===
Purtroppo i file rc dei due server eseguono il comando killall per
fermarli. Questo comando in un ambiente chroot non ha senso
poiché in questo ambiente non esiste niente nella directory
/proc. Vanno quindi modificati gli script rc in modo da fermare i
server usando il comando kill.

==== Il server apache (rc.httpd) ====
Il file in questione è /chroot_jail/etc/rc.d/rc.httpd e vanno
eliminate le due righe:
killall httpd
rm -f /var/run/httpd/*.pid
in questo caso il file rc ferma correttamente il server apache
eseguendo il comando:
/usr/sbin/apachectl -k stop
quindi le due righe eliminate servono solo come meccanismo di
sicurezza in più...noi invece siamo fiduciosi ;).

==== Il serve MySQL (rc.mysqld) ====
Si deve modificare il file /chroot_jail/etc/rc.d/rc.mysqld sostituendo
la riga:
killall mysqld
con:
kill $(cat /var/run/mysql/mysql.pid)

=== I fusi orari ===
Affinché i nostri server riportino l'orario in maniera
corretta occorre copiare nell'ambiente il file /etc/localtime con:
# cp /etc/localtime /chroot_jail/etc/localtime

=== Il generatore di numeri casuali ===
Il server apache necessita di generare dei numeri casuali per mitivi
di sicurezza. Per fare questo è necessario copiare il device
urandom:
# cp -a /dev/urandom /chroot_jail/dev/urandom

=== La risoluzione degli indirizzi ===
Molti script PHP necessitano l'uso del DNS per risolvere i domini
internet. Questo sotto linux viene effettuato semplicemente facendo
conoscere alle librerie (già installate) l'indirizzo IP del
nostro DNS. Bisogna quindi copiare i file:
# cp /etc/resolv.conf /chroot_jail/etc/resolv.conf
# cp /etc/hosts /chroot_jail/etc/hosts
{{Hint
|In oltre:
|Ovviamente si possono copiare anche i file /etc/hosts.allow, /etc/hosts.deny e /etc/hosts.equiv.
}}

=== Hostname ===
I log di apache e di MySQL contengono anche l'hostname della macchina su cui gira
il server, quindi se vogliamo dare un nome al tutto possiamo anche
copiare (e modificare) il file:
# cp /etc/HOSTNAME /chroot_jail/etc/HOSTNAME

=== Loggare l'output dei programmi usando syslogd ===
I programmi, sotto linux, inviano i propri messaggi al server syslogd
attraverso l'uso del socket /dev/log=. Per far sì
che anche i nostri programmi che vengono eseguiti nell'ambiente chroot
possano inviare i messaggi al server syslogd bisogna avvisare
quest'ultimo facendogli creare un socket anche nell'ambiente
creato. Per fare questo bisogna modificare il file /etc/rc.d/rc.syslog
facendo invocare il demone, anziché senza opzioni, con
l'aggiunta dell'opzione '''-a'''. Quindi invece della riga:
/usr/sbin/syslogd
va inserita la riga:
/usr/sbin/syslogd -a /chroot_jail/dev/log
(la riga è corretta, non ci vuole il segno '=' dopo log).
{{Information
|Nota:
|La creazione del socket non è necessaria per l'utilizzo dei soli server apache e MySQL, dato che questi ultimi hanno già i loro file di log.
}}

= La sicurezza non è mai troppa =
Come si è visto, usando questa procedura l'ambiente chroot
contiene un sacco di software (anche inutile) che potrebbe essere
sfruttato da un malintenzionato che riesce ad ottenere l'accesso
al filesystem. E' vero che il malintenzionato si trova in un ambiente
chiuso, però possiamo rendergli la vita ancora più
difficile rendendo tutto il software installato eseguibile solo
all'utente root. Per fare questo basta eseguire il comando:
# chroot /chroot_jail bash -c 'IFS=:; for dir in $PATH; do [ -d $dir ] && chmod go-rx ${dir}/*; done'

Dobbiamo anche eliminare tutti gli utenti e tutti gruppi, a parte
'mysqld' e 'apache', dai relativi file /chroot_jail/etc/passwd,
/chroot_jail/etc/shadow e /chroot_jail/etc/group. Questa operazione
può essere fatta a mano oppure eseguendo il semplice comando:
# sed -i -n '/apache/p;/mysql/p' /chroot_jail/etc/passwd /chroot_jail/etc/shadow /chroot_jail/etc/group

= Testare il tutto =
Per testare se tutto è andato per il meglio non resta che
avviare i relativi server con:
# chroot /chroot_jail/ /etc/rc.d/rc.mysqld start
# chroot /chroot_jail/ /etc/rc.d/rc.httpd start

== Start e stop al boot/shutdown ==
Se vogliamo che i nostri server siano attivi al momento del boot e si
fermino automaticamente allo shutdown, basta:
* inserire i due comandi precedenti per l'avvio dei server nel file /etc/rc.d/rc.local
* inserire i due comandi di stop dei server inserendo le righe seguenti nel file /etc/rc.d/rc.local_shutdown (se il file non esiste va creato):
chroot /chroot_jail/ /etc/rc.d/rc.httpd stop
chroot /chroot_jail/ /etc/rc.d/rc.mysqld stop
{{Hint
|Appunto:
|Si noti l'oridine inverso rispetto allo 'start'. All'avvio va prima eseguito il server mysql e poi apache. Durante lo shutdown invece bisogna fermare prima il server apache e poi mysql.
}}

= Manutenzione =
Come detto all'inizio, la forza di questa procedura sta nella
manutenzione dei vari server. Se il server apache, ad esempio,
necessita di qualche software aggiuntivo richiesto dai vari programmi
PHP installati, allora non resterà altro da fare che
installarglieli tramite il comando:
# installpkg --root /chroot_jail nome_pacchetto

Se uno dei server va aggiornato ad una versione successiva, allora si
potrà eseguire semplicemente un:
# ROOT=/chroot_jail upgradepkg nome_pacchetto

Nel caso in cui vogliamo anche la possibilità di disinstallare
alcuni pacchetti dall'ambiente, bisogna installare anche i pacchetti:
a/pkgtools
a/findutils
Questo perché il comando removepkg non accetta l'opzione
'''--root'''. Una volta fatta questa operazione, per rimuovere un
qualsiasi pacchetto installato nell'ambiente chroot sarà
sufficiente dare un:
# chroot /chroot_jail removepkg nome_pacchetto

= Software PHP e mail =
Molti programmi PHP usano la funzione mail() per inviare posta. Questa
funzione, sotto linux, fa uso del programma sendmail. E' ovvio quindi
che se vogliamo far sì che anche questa funzione possa essere
eseguita con successo, in linea teorica dovremmo installare anche il
pacchetto sendmail nell'ambiente chroot.

Se non si vuole installare tutto sendmail, invece, si può
optare per il più leggero [http://www.acme.com/software/mini_sendmail/ mini_sendmail].
A
[http://www.cyberciti.biz/tips/howto-setup-sendmail-php-mail-chrooted-apache-lighttpd.html questo indirizzo]
trovate un'ottima spiegazione su come installarlo, configurare PHP in
modo da farglielo usare ed eseguire un test.

Infine, come alternativa alle soluzione precedente, si pu&ograve anche
la classe SMTP per spedire le email, questa classe si connette ad un
server SMTP invece che usare il comando sendmail. Dove è
possibile settare i programmi PHP in modo da usare questa classe
invece che la funzione mail(), si potrebbe anche optare per questa
soluzione invece che installare sendmail nell'ambiente chroot.

= Un'alternativa interessante =
Per completezza di informazione va detto che il server apache ha
già di suo la capacità di avviarsi in un ambiente
chroot. Basta installargli il software aggiuntivo
[http://core.segfault.pl/~hobbit/mod_chroot/ mod_chroot]. Questa
è un'ottima alternativa al problema della sicurezza del server
apache. Comunque l'ambiente creato attraverso la proceduta spiegata in
questo wiki rende possibile una separazione netta, in termini di
software installato, tra ciò che vogliamo esporre al mondo via
web e ciò che invece fa parte della nostra partizione root standard.

= Copyright - License =
Autore: [[Utente:targzeta|targzeta]] 05:50, 6 set 2011 (CEST)
{{Information
|GNU Free Documentation Licence
|This article is released under the GNU Free Documentation Licence. You are welcome to copy and redistribute it (subject to certain conditions).
}}

Xorg - hal - synaptics touchpad

2012-10-02T21:57:15Z

Targzeta: Cambiato nick

[[Category:Server X]]
= ATTENZIONE =
Con la "morte" del progetto hal il server Xorg si autoconfigura tramite il demone udev ('''udevd'''). Questo wiki per tanto può considerarsi obsoleto.

Per configurare il driver synaptics sui server Xorg (versione => 1.9) che fanno uso di udev, dopo aver installato il pacchetto:

xf86-input-synaptics

si controlli il file:

/usr/share/X11/xorg.conf.d/50-synaptics.conf

=Introduzione=
Questo wiki spiega come settare i touchpad synaptics attraverso hal e il nuovo '''xorg''' >= 1.5.x. I nuovi server xorg supportano l'hotplugging attraverso le informazioni
prelevate grazie al demone hal ('''hald''').
Si può vedere il sottosistema hal come un database di informazioni sui vari device presenti nel PC, il server xorg quindi lo contatta attraverso il message bus di sistema
('''dbus-daemon --system''') e preleva ciò di cui ha bisogno per "auto-configurarsi". In questo modo i futuri server xorg (ma anche lo stesso 1.5.x) potranno quasi
certamente
fare a meno del famoso file di configurazione ''/etc/X11/xorg.conf''.<BR>
In questo wiki spiegheremo come aggiungere al database di hal le informazioni relative ai touchpad synaptics in modo tale che il server xorg le possa prelevare per
configurare il driver stesso (il driver synaptics).

=Cosa ci serve=
Tutto il software necessario si trova di default sulla slackware a partire già dalla versione current di oggi, 16 Giugno 2009. In pratica ci si deve solo assicurare di avere
installato i pacchetti (le versioni sono riferite alla distribuzione current di slackware):
* hal-0.5.11
* dbus-1.2.14
* xorg-server-1.6.1
* xf86-input-evdev-2.2.2
* xf86-input-synaptics-1.1.2

I due demoni '''hald''' e '''dbus-daemon --system''' sono eseguiti all'avvio della slackware dai relativi file:
''/etc/rc.d/rc.hald''
''/etc/rc.d/rc.messagebus''

'''NOTA''': evdev deve essere compilato anche nel kernel! Ma nei kernel della Slackware è già presente.

=Come aggiungere le informazioni al database di hal per il driver synaptics di xorg=
Per aggiungere le informazioni sulla configurazione che vogliamo ottenere per il touchpad bisogna creare un file per hal, ad esempio il file:
''/etc/hal/fdi/policy/11-x11-synaptics.fdi''
con all'interno quanto segue:
<PRE>
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.touchpad">
...
...
...
</match>
</device>
</deviceinfo>
</PRE>
Tutto ciò che è nei ... sarà la nostra configurazione, e vedremo in seguito cosa e come possiamo settarla.<BR>
Intanto cerchiamo di capire cosa abbiamo fatto creando questo file. Innanzitutto il path ''/etc/hal/fdi/policy'' ci assicura che il file verrà letto dal demone '''hald'''
al suo prossimo riavvio. Il contenuto del file segue la DTD (Document Type Definition) dei file XML per hal, noi stiamo dicendo che vogliamo effettuare delle operazioni (sono
quelle nei ...) se tra le '''info.capabilities''' individuate nel PC c'è un entry che contiene il valore '''input.touchpad'''.

==Controllare le informazioni sul device presenti nel database di hal==
Come abbiamo visto, quello che noi faremo è semplicemente aggiungere informazioni al database di hal per il driver synaptics. Inoltre abbiamo anche visto che le
informazioni verranno aggiunte al device in cui compare la stringa '''input.touchpad''' come '''info.capabilities'''.<BR>
Il sistema hal prevede una serie di software con il quale è possibile interrogare il database da riga di comando, e ora noi ne sfrutteremo due per controllare le
informazioni già presenti nel database. Eseguendo:
<PRE>
$> hal-find-by-capability --capability input.touchpad
/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input
</PRE>
si ottiene l'udi (Unique Device Id) del device che contiene '''input.touchpad''' come '''info.capabilities'''.<BR>
Ora eseguendo '''hal-device''' passando come parametro l'udi ottenuto:
<PRE>
$> hal-device '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input'
udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input'
input.originating_device = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port' (string)
info.subsystem = 'input' (string)
linux.sysfs_path = '/sys/class/input/input4/event4' (string)
info.category = 'input' (string)
info.product = 'SynPS/2 Synaptics TouchPad' (string)
info.parent = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port' (string)
info.capabilities = { 'input', 'input.touchpad' } (string list)
info.udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input' (string)
linux.hotplug_type = 2 (0x2) (int)
input.device = '/dev/input/event4' (string)
linux.subsystem = 'input' (string)
input.product = 'SynPS/2 Synaptics TouchPad' (string)
linux.device_file = '/dev/input/event4' (string)
</PRE>
otteniamo le informazioni contenute nel database di hal relative al nostro touchpad (si noti che tra le info.capabilities c'è anche input.touchpad).

=I primi passi per la configurazione=
Ora limitiamoci ad inserire nel database di hal le informazioni minimali in modo da avere il nostro touchpad attivo, quindi inseriamo nel file
''/etc/hal/fdi/policy/11-x11-synaptics.fdi'' quanto segue:
<PRE>
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.touchpad">
<merge key="input.x11_driver" type="string">synaptics</merge>
<merge key="input.x11_options.SHMConfig" type="string">true</merge>
</match>
</device>
</deviceinfo>
</PRE>
dicendo quindi ad hal che se trova una chiave '''info.capabilities''' che contiene la stringa '''input.touchpad''' deve aggiungere nel database le coppie chiave = valore:
input.x11_driver = synaptics
input.x11_options.SHMConfig = true
La prima chiave (input.x11_driver) viene cercata dal server xorg al momento dell'avvio per sapere quali driver deve caricare per gestire l'input, quindi noi gli diciamo di
caricare anche il driver synaptics.
La seconda chiave (input.x11_options.SHMConfig) viene invece cercata dal driver synaptics e gli serve per sapere come configurarsi. Tutte le chiavi di configurazione del
driver synaptics iniziano con ''input.x11_options.'' e al momento sono tutte di tipo ''string''. Quindi per ora abbiamo detto al driver che vogliamo sfruttare la memoria
condivisa (SHM - Shared Memory), vedremo dopo il perchè.

Quindi, una volta riavviato il demone '''hald''' con:
#> /etc/rc.d/rc.hald restart
rieseguendo:
<PRE>
$> hal-device '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input'
udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input'
...
input.x11_driver = 'synaptics' (string)
...
input.x11_options.SHMConfig = 'true' (string)
...
</PRE>
vediamo che nel database di hal, relativamente al touchpad, sono presenti anche le nostre impostazioni.

Allora quando noi avvieremo il server xorg, lui troverà la chiave '''input.x11_driver''' e capirà che dovrà caricare il driver synaptics, il quale a sua volta troverà la
chiave '''input.x11_options.SHMConfig''' e saprà che dovrà configurarsi in modo tale da poter essere configurato tramite la memoria condivisa.
=Usare synclient per configurare il driver synaptics a runtime=
Con la semplice impostazione precedente
<merge key="input.x11_options.SHMConfig" type="string">true</merge>
abbiamo detto al driver synaptics che deve poter essere configurabile a runtime attraverso la memoria condivisa, e questo ci permette di eseguire, a server xorg attivo, il
comando '''synclient'''.

'''NOTA''': l'opzione 'SHMConfig = true' è considerata un rischio per la sicurezza, visto che tutti coloro che hanno accesso al PC possono
configurare il driver synaptics semplicemente tramite SHM.

Lanciando:
<PRE>
$> synclient -l
Parameter settings:
LeftEdge = 1752
RightEdge = 5192
TopEdge = 1620
BottomEdge = 4236
....
</PRE>
si può vedere come è configurato il driver synaptics al momento attuale. Tutte le proprietà sono spiegate nel manuale del driver, accessibile con:
man 4 synaptics

Ad esempio per abilitare lo scrolling verticale si esegua:
$> synclient VertEdgeScroll=1
e controllando con:
$> synclient -l| grep VertEdgeScroll
VertEdgeScroll = 1
si nota che è abilitato.

==Alcune proprità interessanti del driver synaptics==
Oltre allo scrolling verticale il driver synaptics mette a disposizione un sacco di proprietà tra cui:
* I TapButton
* I CornerButton
I TapButton servono per dire al driver quali pulsanti deve considerare come premuti quando si 'clicca' nel centro del touchpad, ad esempio con:
$> synclient TapButton1=1 TapButton2=2 TapButton3=3
diciamo al driver, rispettivamente, che:
* quando clicchiamo nel centro del touchpad con un dito, si deve comportare come se fosse stato premuto il 1° pulsante (generalmente il tasto sinistro).
* quando clicchiamo nel centro del touchpad con due dita, si deve comportare come se fosse stato premuto il 2° pulsante.
* quando clicchiamo nel centro del touchpad con tre dita, si deve comportare come se fosse stato premuto il 3° pulsante.

I CornerButton servono per dire al driver quali pulsanti deve considerare come premuti quando si 'clicca' negli angoli del touchpad, ad esempio con:
$> synclient RTCornerButton=2 RBCornerButton=3
diciamo al driver, rispettivamente, che:
* quando clicchiamo nell'angolo in alto a destra (RT - right top) del touchpad deve comportarsi come se fosse stato premuto il 2° pulsante.
* quando clicchiamo nell'angolo in basso a destra (RB - right bottom) del touchpad deve comportarsi come se fosse stato premuto il 3° pulsante.

=Un file per hal di esempio=
Una volta trovata la giusta configurazione per il nostro touchpad a runtime grazie a '''synclient''', possiamo renderla attiva ad ogni avvio del server xorg modificando il file ''/etc/hal/fdi/policy/11-x11-synaptics.fdi''.<BR>
Ad esempio il mio file contiene:
<PRE>
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.touchpad">
<merge key="input.x11_driver" type="string">synaptics</merge>
<merge key="input.x11_options.SHMConfig" type="string">true</merge>
<merge key="input.x11_options.VertEdgeScroll" type="string">true</merge>
<merge key="input.x11_options.MaxTapTime" type="string">180</merge>
<merge key="input.x11_options.FingerLow" type="string">25</merge>
<merge key="input.x11_options.FingerHigh" type="string">30</merge>
<merge key="input.x11_options.TapButton1" type="string">1</merge>
<merge key="input.x11_options.TapButton2" type="string">3</merge>
<merge key="input.x11_options.TapButton3" type="string">2</merge>
<merge key="input.x11_options.RTCornerButton" type="string">3</merge>
<merge key="input.x11_options.RBCornerButton" type="string">2</merge>
</match>
</device>
</deviceinfo>
</PRE>
Si noti come tutte le chiavi per il driver synaptics iniziano con 'input.x11_options.' mentre il nome delle proprietà ('SHMConfig', 'VertEdgeScroll' 'MaxTapTime', etc..)
sono prese direttamente dal manuale del driver (synaptics(4)) e sono le stesse che abbiamo passato al comando '''synclient'''.

=Errori=
==hal-find-by-capability --capability input.touchpad non mostra niente==
Questo tipo di errore può essere causato dal passaggio del parametro '''proto=imp''' al modulo del kernel '''psmouse'''. Per ovviare a questo
problema, assicuratevi che nel file:
/etc/modprobe.d/psmouse.conf
sia commentata la riga:
# options psmouse proto=imps

===NOTA===
Alcuni utenti per essere sicuri di non fare danni usano generalmente creare dei file di backup. Se volete fare un backup di questo
file prima di modificarlo, fate attenzione a non farlo nella directory ''/etc/modprobe.d/'', altrimenti l'opzione viene passata ugualmente.
Per verificare che il parametro non sia stato passato, potete scaricare il modulo e ricaricarlo come segue:
#> modprobe -r psmouse
#> modprobe -v psmouse
facendo attenzione che il secondo comando '''non''' mostri qualcosa del tipo:
proto=imps
Se lo mostra, allora vuol dire che qualche altro file nella directory su citata ha questa opzione non commentata.

=Conclusione=
Grazie alla lettura di questo piccolo wiki dovremmo essere in grado di capire:
* come avverrà la futura configurazione dei server xorg (grazie ad hal e dbus)
* e quindi come poter intervenire per modificarla

Se notate qualche incorrettezza scrivetemi pure, generalmente accetto ben volentieri critiche o proposte di matrimonio :)<BR>
[[Utente:targzeta|targzeta]]

Check For Updated

2012-10-02T21:56:34Z

Targzeta: Cambiato nick

[[category:Script]]
=Introduzione=
Lo script '''check_for_updates.sh''' controlla se una determinata pagina internet è stata modificata. Lo si può pensare come un'alternativa ai feed RSS.

Lo script è stato creato con lo scopo di scoprire se un determinato progetto è stato modificato oppure no, dall'ultima volta che lo si è controllato.

=Download=
Lo script si trova all'indirizzo:<br/>
http://www.slacky.eu/~targzeta/script/check_for_updates.sh

==NOTA per le versioni dalla 1.5 in poi==
Se si passa da una versione precedente ad una >= della 1.5, dato che lo script ha cambiato nome (da '''check_upgrade.sh''' a '''check_for_updates.sh'''), si dovrebbero anche rinominare tutte le sottodirectory ''.check_upgrade'' in ''.check_for_updates''. Ecco uno script che potrebbe essere d'aiuto:
<pre>
for file in *;
do
if [ -d $file ] && [ -d ${file}/.check_upgrade ];
then
mv ${file}/.check_upgrade ${file}/.check_for_updates;
fi;
done
</pre>

'''Se invece è la prima volta che si usa lo script, questo non è necessario!!'''

=L'ambiente di lavoro=
Lo script lavora su directory, l'idea è che per ogni progetto che l'utente segue, ci sia una directory associata, ad esempio:
<pre>
$> ls -1F software/
FileZilla/
a52dec/
aircrack-ng/
amrnb/
amrwb/
audacity/
...
check_for_updates.sh*
...
</pre>
come si nota, lo script è all'interno della directory ''software'', la quale contiene una directory per ogni progetto che si vuole seguire (FileZilla, aicrack-ng, etc...).

=Lo script e le varie modalità=
Lo script opera in diversi modi a seconda di quale modalità si scelga di eseguire. L'elenco delle modalità lo si trova con l'uso dell'opizione ''--help''
<pre>
$> check_for_updates.sh --help
Uso: check_for_updates.sh [opzioni] MODALITA [mod_opzioni] arg1...
check_for_updates.sh MODALITA -h|--help
check_for_updates.sh -v|--version

Opzioni:
-c Non colora l'output

MODALITA e' una tra:
check
db
init
not_conform
update
url

by Emanuele Tomasi aka targzeta <targzeta@gmail.com>
</pre>

==Modalità init==
Questa è la prima modalità che si usa per iniziare a seguire un progetto. L'help per questa
modalità è il seguente:
<pre>
$> check_for_updates.sh init --help
Uso: check_for_updates.sh init [opzioni] dir URL

Inizializza la directory dir tramite l'URL passatogli.

Opzioni:
-g forza l'uso del protocollo git
-q quiet
-s forza l'uso del protocollo svn
-v verbose

L'URL va quotato se contiene caratteri speciali per la shell,
come ad esempio il carattere '&'.
</pre>
gli argomenti sono quindi soltanto due:
* Il nome della directory associata al progetto da seguire;
* L'URL della pagina web in cui vengono annunciati i cambiamenti o nuove release;
{{Be Careful|Nota|Come dice anche l'help, l'URL va quotato se contiene caratteri che la shell può interpretare o espandere. Vedi appunto il carattere '&' che per la shell significa: "manda in background".}}

Ad esempio, per il progetto FileZilla si ha:
* Il nome della directory == ''FileZilla/''
* URL = http://filezilla-project.org/download.php?type=client

quindi per iniziare a seguire il progetto basta eseguire:
<pre>
$> check_for_updates.sh init FileZilla/ http://filezilla-project.org/download.php?type=client
# Directory: FileZilla
INIZIALIZZATA
</pre>
{{Hint|Nota|Il nome della directory non deve finire necessariamente con il carattere '/'.}}

Una volta che la directory è stata inizializzata la si definisce "conforme" allo script, ovvero lo script al suo interno ha creato una sottodirectory di nome ''.check_for_updates'' con all'interno due file:
; page : la pagina web indirizzata dall'URL (scaricata tramite il comando '''wget''');
; url : l'URL che si è passato come parametro;
<pre>
$> tree FileZilla/.check_for_updates/
FileZilla/.check_for_updates/
|-- page
`-- url

0 directories, 2 files
</pre>

===Protocolli===
Ci sono vari tipi di protocolli accettati dallo script, il protocollo da usare viene individuato analizzando l'inizio dell'URL oppure attraverso l'uso delle opzioni '''-g''' e '''-s''' della modalità '''init'''.

====http(s) o ftp====
Il download delle pagine per questi protocolli avviene tramite il comando:
wget --no-check-certificate

L'uso di questi protocolli è di default quando l'URL inizia con http(s):// oppure ftp.

====svn====
L'uso di subversion avviene scaricando, come pagina da confontare, il log, e viene fatto usando:
svn info -r HEAD

L'uso di questo protocollo è di default quando l'URL inizia con svn://. Poichè però subversion si appoggia anche su altri protocolli, si può forzare l'uso di questo protocollo anche con URL che non iniziano con svn://. Per fare questo basta semplicemente usare l'opzione '''-s''' della modalità '''init'''.

====git====
L'uso di git avviene scaricando, come pagina da confrontare, il log, e viene fatto usando:
git ls-remote HEAD

L'uso di questo protocollo è di default quando l'URL inizia con git://. Poichè però git si appoggia anche su altri protocolli, si può forzare l'uso di questo protocollo anche con URL che non iniziano con git://. Per fare questo basta semplicemente usare l'opzione '''-g''' della modalità '''init'''.

==Modalità check==
Una volta inizializzata la directory, si può seguire il progetto facendo un '''check''' su di essa. L'help per questa modalità è:
<pre>
$> check_for_updates.sh check --help
Uso: check_for_updates.sh check [opzioni] dir1...

Controlla se la pagina e' aggiornata.

Opzioni:
-d mostra l'output di 'diff' quando controlla l'aggiornamento
-e non mostra gli errori di download
-f mostra la pagina filtrata (non effettua controlli sull'aggiornamento)
-k non elimina i file temporanei all'uscita
-n mostra l'output di 'diff' stampando solo le nuove righe. Ignora '-d'
-o produce output solo se la pagina e' stata aggiornata. Implica '-s'
-q quiet. Implica '-s'
-s non stampa errori sulle directory non conformi
-v verbose
</pre>
come si vede, si può fare il '''check''' anche su più directory contemporaneamente, in effetti lo si può fare anche su directory non conformi o file, lo script salterà i file, e tramimte l'opzione '-s' non stamperà nulla neanche sulle directory non conformi. Questo è utile se si vuole eseguire il check su di un'intera directory con:
$> check_for_updates.sh check *

Lo script, quando è invocato con questa modalità segue il seguente algoritmo (a meno che non venga eseguito con l'opzione '-f'):
* scarica la pagina web (identificata dall'indirizzo trovato nel file ''.check_for_updates/url'') in un file temporaneo;
* fa una copia della pagina web ''.check_for_updates/page'' in un altro file temporaneo;
* se ci sono filtri, allora filtra entrambe le pagine temporanee;
* esegue il comando '''diff''' per vedere se ci sono differenze tra le due pagine temporanee;

Un esempio di invocazione è il seguente:
<pre>
$> check_for_updates.sh check FileZilla/
# Directory: FileZilla
OK
</pre>
il valore di ritorno 'OK' indica che la pagina ''.check_for_updates/page'' (filtrata) non differisce dalla pagina internet (filtrata).

===Opzione -d===
Tramite questa opzione, lo script mostrerà l'output del comando '''diff''' sulle pagine temporanee. Questo è utile per vedere se effettivamente la differenza è significativa oppure no. Se non è significativa, si può migliorare il controllo creando appositi filtri (si vedrà in seguito l'uso dei filtri).

===Opzione -f===
In questo caso lo script non esegue l'algoritmo spiegato in precedenza, ma si limita a filtrare la pagina '''.check_for_updates/page'' e a mostrare l'esito dei filtri e, quindi, la porzione di pagina che si verrà controllata.

===Opzione -k===
Con questa opzione, lo script non eliminerà i file temporanei creati per il confronto.

===Opzione -n===
Questa opzione è simile (e ne è un alternativa) all'opzione '''-d''', con la differenza che mostra soltanto le nuove righe. E' utile nel caso la pagina che si tiene sotto controllo sia effettivamente un log con entry che vengono eliminate in favore di nuove.

===Opzione -o===
Lo script, per ogni directory che gli si passa, produce una serie di output tipo quello visto negli esempi precedenti. Questa opzione inibisce lo script a produrre output se il comando '''diff''' torna che le due pagine temporanee sono identiche. Nell'esempio, dato che la directory FileZilla viene trovata 'OK', lo script, con questa opzione, non produce output. E' molto utile se si invoca lo script passandogli molte directory, o addirittuta '*'.

Ad esempio:
<pre>
$> check_for_updates.sh check -o FileZilla/ amrwb/
# Directory: amrwb
DA AGGIORNARE
</pre>
{{Information|NOTA|L'uso di questa opzione implica l'opzione '-s'.}}

===Opzione -q (caso particolare)===
Questa opzione inibisce lo script a produrre output, in pratica rende incompresibile l'uso dello script. L'unico motivo per cui esiste ancora è che in associazione con l'opzione '-o', si ha l'elenco delle directory per le quali lo script produrrebbe 'DA AGGIORNARE'.

Ad esempio:
<pre>
$> check_for_updates.sh check -qo FileZilla/ amrwb/
amrwb
</pre>
{{Information|NOTA|L'uso di questa opzione implica l'opzione '-s'.}}

===Opzione -s===
Normalmente se allo script gli si passa una directory non conforme esso produrra in output una scritta simile a questa:
<pre>
$> check_for_updates.sh check Kernel/
# Directory: Kernel
Attenzione: Kernel non ha:
* o la sottodirectory .check_for_updates
* o il file .check_for_updates/url
* o il file .check_for_updates/page
</pre>

Tramite l'uso di questa opzione, lo script salta queste directory e quindi non produce nessun output. Questa opzione è utile se si invoca lo script su più directory in contemporanea o su '*'.

==Modalità update==
L'unico modo per far sapere allo script che una directory è di nuovo aggiornata, è quello di invocarlo con questa modalità. Lo script scaricherà la nuova pagina web e la sostituirà con quella in ''.check_for_updates/page''. L'help è il seguente:
<pre>
$>check_for_updates.sh update --help
Uso: check_for_updates.sh update [opzioni] dir1...

Aggiorna, riscaricando la pagina, la directory dir.

Opzioni:
-q quiet
-v verbose
</pre>

Ad esempio, se si aggiorna la directory ''amrwb'', per il quale lo script ha ritornato 'DA AGGIORNARE', invocando lo script con questa modalità si ottiene:
<pre>
$> check_for_updates.sh update amrwb/
# Directory: amrwb
AGGIORNATA
</pre>

==Modalità not_conform==
La modalità si limita ad elencare, tra le directory passategli, quelle non conformi. L'help è il seguente:
<pre>
$> check_for_updates.sh not_conform --help
Uso: check_for_updates.sh not_conform dir1...

Stampa il nome delle dir non conformi (non inizializzate).
</pre>

Ad esempio:
<pre>
$> check_for_updates.sh not_conform FileZilla/ amrwb/ Kernel/
Kernel
</pre>

==Modalità url==
Per ogni directory passatagli, se la directory è conforme, lo script stampa l'URL trovato nel file ''.check_for_updates/url''. L'help è il seguente:
<pre>
$> check_for_updates.sh url --help
Uso: check_for_updates.sh url dir1...

Stampa l'URL impostato per la directory dir.

Opzioni:
-q quiet
</pre>

Ad esempio:
<pre>
$> check_for_updates.sh url FileZilla/ amrwb/ Kernel/
# Directory: FileZilla
http://filezilla-project.org/download.php?type=client

# Directory: amrwb
http://www.penguin.cz/~utx/amr
</pre>

=Filtri=
I filtri sono un modo per far si che lo script esegua il comando '''diff''' solo su una porzione anziché sull'intera pagina.

Attualmente i filtri si devono creare a mano e vanno messi in dei file nella sottodirectory ''.check_for_updates/'' del progetto. Ci sono cinque tipi di filtri, caratterizzati da altrettanti nomi file.

Quando lo script viene invocato con la modalità '''check''', prima di eseguire il comando '''diff''', se trova i file dei filtri, filtra i file temporanei.
{{Hint|Nota|I filtri sono applicati usando '''sed''' con le basic regex.}}
Nella scrittura di alcuni filtri si può usare la direttiva '''#DIR#''' che viene sostituita dal nome della directory su cui lo script stà lavorando.
{{Be Careful|Nota|Poiché il filtro '''sed_script''' può sostituire tutti gli altri, nelle prossime versioni sarà l'unico filtro ammesso.}}

==Il filtro compare_only_line (obsoleto)==
Se esiste un file chiamato ''.check_for_updates/compare_only_line'', questo file deve contenere, una per riga, un'espressione regolare. Solo le righe dei file temporanei che hanno il match con queste espressioni regolari saranno confrontate.

Ad esempio, se si guarda il link impostato per FileZilla, si noterà che in quella pagina vengono linkati sia i sorgenti per linux, sia l'installer per Windows, per Mac OS, etc. etc. Se si vuole controllare solo i sorgenti per linux, basta creare il file ''.check_for_updates/compare_only_line'' con all'interno questa espressione regolare:
FileZilla.*src.*bz2

Per vedere cosa effettivamente compara il comando '''diff''', basta eseguire lo script con modalità '''check''' e opzione '-f':
<pre>
$> check_for_updates.sh check -f FileZilla/
# Directory: FileZilla
<p><a href="https://www.ohloh.net/projects/filezilla/download?filename=FileZilla_3.1.5.1_src.tar.bz2">FileZilla_3.1.5.1_src.tar.bz2</a> </p>
</pre>
come si può notare, il filtro ha lasciato passare solo la riga che contiene il link ai sorgenti.

Per questo filtro si può usare la direttiva '''#DIR#''', quindi se il nome della directory che contiene il progetto FileZilla si chiama proprio ''FileZilla/'', una regex del tutto analoga a quella mostrata prima è:
#DIR#.*src.*bz2

==Il filtro filter_line_number (obsoleto)==
Se esiste un file chiamato ''.check_for_updates/filter_line_number'', questo file deve contenere, per ogni riga, un numero. Lo script sopprimerà le righe corrispondenti dalla pagina, prima di eseguire '''diff'''.

==Il filtro filter_line_regex (obsoleto)==
Se esiste un file chiamato ''.check_for_updates/filter_line_regex'', questo file deve contenere, per ogni riga, un'espressione regolare. Lo script sopprimerà le righe della pagina che hanno il match con una di queste espressioni regolari, prima di eseguire '''diff'''.

Per questo filtro si può usare la direttiva '''#DIR#'''.

==Il filtro filter_word (obsoleto)==
Se esiste un file chiamato ''.check_for_updates/filter_word'', questo file deve contenere, per ogni riga, un'espressione regolare. Lo script sopprimerà, per ogni riga che ha il match con una di queste espressione regolari, l'espressione regolare stessa.

Ad esempio, con riferimento all'output prodotto già dal filtro '''compare_only_line''' nell'esempio precedente, se si volesse eliminare dall'unica riga prodotta dal filtro, anche tutte le parole dall'inizio della riga sino al protocollo https, basta fare:
<pre>
$> echo '^.*href="' > FileZilla/.check_for_updates/filter_word

$> check_for_updates.sh check -f FileZilla/
# Directory: FileZilla
https://www.ohloh.net/projects/filezilla/download?filename=FileZilla_3.1.5.1_src.tar.bz2">FileZilla_3.1.5.1_src.tar.bz2</a> </p>
</pre>

Per questo filtro si può usare la direttiva '''#DIR#'''.

== Il filtro sed_script ==
Se esiste un file chiamato ''.check_for_updates/sed_script'', questo file deve contenere un vero e proprio script per sed. '''check_for_updates.sh''' esegue il comando '''sed -n -f .check_for_updates/sed_script''', quindi si faccia attenzione poiché non verrà generato nessun output a meno che non si sia usato il comando '''p''' di sed.

Per questo filtro si può usare la direttiva '''#DIR#'''.

==L'ordine di esecuzione dei filtri==
I filtri sopra citati vengono eseguiti nel seguente ordine:
* sed_script
* compare_only_line
* filter_line_number
* filter_line_regex
* file_filter_word

L'ordine degli ultimi tre filtri non è importante, ma si deve tenere ben presente che prima si filtrano i file temporanei con il filtro '''sed_script''', quindi sull'output di questo filtro viene applicato, se esiste, il filtro '''compare_only_line''', ed infine sull'output di quest'altro filtro, vengono applicati, se ci sono, i filtri per sopprimere altre righe o parole.

=Progetti su Sourceforge=
Il link ai file di un progetto hostato su Sourceforge hanno tutti la stessa forma:
http://sourceforge.net/projects/NOME_PROGETTO/files/
dove NOME_PROGETTO è proprio il nome del progetto hostato.

Quindi un modo per inizializzare lo script, ad esempio per p7zip è:
$> check_for_updates.sh init p7zip http://sourceforge.net/projects/p7zip/files/

E, per filtrare la pagina scaricata basta fare:
<pre>
$> echo '/#DIR#.*class="folder/b get_date;d;:get_date /date/{s/.*title="$[[:digit:]-]\+$.*/#DIR# \1/p;q};n;b get_date'\
> p7zip/.check_for_updates/sed_script
</pre>

il quale fa passare solo la data dell'ultimo file aggiornamento, come si può vedere dall'output della modalità '''check''' con l'opzione '-f':
<pre>
$> check_for_updates.sh check -f p7zip/
# Directory: p7zip
p7zip 2010-05-30
</pre>

=Working in progress...=
Lo script necessita ancora di ottimizzazioni, ritocchi ed espansioni. Per ora, ad esempio, il comportamento con le opzioni delle varie modalità è un po' bizzarro, basti pensare che l'opzione '-q' e '-v' non generano un errore di incompatibilità.

La madalità '''db''' per ora non fa nulla, ma l'idea è quella di poter esportare ed importare URL e/o filtri. In questo modo basterebbe avere un pacchetto il più completo possibile di queste informazioni per far si che più utenti possano controllare gli stessi progetti senza doversi ogni volta scovare URL e filtri adatti.

=Ringraziamenti e conclusioni=
Ringrazio:
* conraid per l'ottimo feedback

Autore (data dell'ultimo aggiornamento):<br/>
[[Utente:targzeta|targzeta]] ([[Discussioni utente:targzeta|discussioni]]) 00:08, 1 ago 2012 (CEST)

Slackware su pennina USB

2012-10-02T21:54:18Z

Targzeta:

[[Category:Install_e_Upgrade]]
=Introduzione=
Questo wiki vuole essere una guida, il più completa possibile, sui passi da fare per crearsi un propria distribuzione Slackware su un dispositivo di archiviazione di massa USB (che da ora in poi chiameremo più semplicemente, pennina).<BR>
Affronteremo tutti i vari passaggi strettamente necessari a far partire un kernel installato sulla pennina ed a creare/configurare la distribuzione Slackware.<BR>
Ovviamente, benché pensata e testata sulla Slackware, la teoria che acquisiremo alla fine di questo wiki sarà tale da permetterci di installare una qualsivoglia distribuzione, la differenza sarà solo sugli strumenti che useremo.

Tutti o quasi tutti i comandi che eseguiremo durante il wiki devono poter godere dei diritti dall'utente root, e per questo saranno caratterizzati dal carattere iniziale '#' che è tipico della shell del super-utente.

I path e i comandi verranno evidenziati rispettivamente dallo stile corsivo e dal font grassetto in questo modo:
* ''/questo/è/un/path''
* '''questo è un comando'''

=Perché installare la distribuzione su una pennina?=
Alcuni esempi d'uso verranno esposti alla fine del wiki, ma facciamo comunque alcune considerazioni importanti.<BR>
Questa guida è rivolta a tutti coloro che sono curiosi, affamati di conoscenza, che usano il PC non solo come strumento di lavoro, ma anche con la voglia di portare alla luce ciò che sembra arcano. Lo scopo del wiki non è la creazione della distribuzione tascabile, bensì la divulgazione della conoscenza, è importante che il lettore tenga presente questo concetto, perché è quello che ci preme rimanga più a lungo nella mente di chi legge questo wiki.<BR>
Oltre ad avere una pennina da portare nei negozi di informatica per testare i PC che solitamente hanno installato solo lo scadente Windows, acquisiremo una conoscenza più o meno approfondita di tutti i programmi necessari all'avvio di una distribuzione GNU/Linux.

=Software usato=
Gli strumenti software che sono stati usati per testare questo wiki sono:
* Slackware 12 (sebbene alcuni utenti l'abbiano testato con successo anche sulla 13 e sulla 13.1)
* kernel huge, presente nella directory della serie ''a/'' della Slackware
* comandi linux che verranno citati man mano, tutti comunque presenti nella distribuzione Slackware
L'elenco sopra citato è da tenere a mente sia perché citeremo nomi di pacchetti Slackware, sia perché il kernel huge fornisce un sopporto tale che alcuni problemi che si potrebbero incontrare verranno solo citati, in quanto risolti grazie alla sua configurazione statica.

=Fase 0: preparazione della pennina=
Noi installeremo la distribuzione Slackware direttamente sulla pennina, iniziamo allora preparando proprio il nostro supporto di archiviazione di massa USB.<BR>
L'unica cosa di cui abbiamo bisogno e di installarci dentro un file system ext3. Le pennine USB, proprio come gli hard disk, possono essere partizionate, supponiamo quindi che sulla pennina ci sia un unica partizione e che questa venga collegata dal kernel al device ''/dev/sda1''. Installiamoci dentro un file system ext3 con il seguente comando:
# mkfs.ext3 -L minislack /dev/sda1
bene, quella che abbiamo appena creato sarà la directory radice della nostra distribuzione.

'''ATTENZIONE:''' tutti i file sulla pennina saranno ovviamente persi dopo l'esecuzione del comando '''mkfs.ext3''', quindi facciamo in modo che la pennina sia vuota prima di lanciare il comando.

'''Nota:''' si noti l'uso dell'opzione -L per impostare un etichetta al file system appena creato, vedremo dopo a cosa ci servirà. L'etichetta del file system la si può impostare/modificare anche successivamente attraverso l'uso del comando '''e2label'''.

=Fase 1: creazione dell'initrd=
Più in là nel wiki, vedremo come far caricare il kernel di linux installato su una pennina, qui invece ci apprestiamo ad affrontare un problema inerente proprio al fatto che la distribuzione si trova su una periferica USB.

==Perché dobbiamo creare un initrd?==
Una volta caricato il kernel, esso si preoccupa di attivare tutti i driver che sono stati compilati in maniera statica al suo interno. L'attivazione avviene in maniera parallela, il kernel cioè non attiva un driver, aspetta che esso abbia finito di inizializzarsi e poi ne attiva un altro, ma li attiva tutti quanti "contemporaneamente". Dopo questa fase di inizializzazione dei driver il kernel deve montare quella che è la root directory (o directory radice) della distribuzione, la famosa directory ''/''. Una volta montata la directory radice, esegue quello che sarà l'unico processo avviato direttamente dal kernel (che in generale è il processo '''/sbin/init''').
* Ma i driver (o controller) USB potrebbero non essere stati compilati in maniera statica nel kernel, e senza i driver il kernel non si accorge neanche della presenza della pennina, come possiamo risolvere questo problema?
* Non solo, ma anche ammesso che il kernel abbia i driver compilati in maniera statica, questi devono avere il tempo di accorgersi che al PC è collegata una pennina USB, come si può dire al kernel di aspettare visto che i driver sono attivati in maniera parallela?
* Ancora, come facciamo a sapere su quale device si verrà a trovare la directory radice? Il driver USB collegherà la pennina al device sda o sdb, oppure ad un altro?
* E infine, la directory radice che abbiamo creato sulla pennina usa il file system ext3, il kernel per poter riconoscere e di conseguenza usare questo file system ha bisogno del driver, e se questo driver non è compilato in maniera statica?

Per tutti questi problemi esiste una soluzione unica, l'initrd. L'initrd fondamentalmente non è altro che una mini distribuzione la cui directory radice viene montata in ram, più precisamente collegata al device ''/dev/ram0'', con un programma o uno script (che si deve chiamare '''init''' o '''linuxrc''') che viene avviato dal kernel (il quale deve essere compilato con il supporto all'initrd) subito dopo aver inizializzato i driver. Il kernel in pratica non si occupa più di montare la root directory e di lanciare il processo '''/sbin/init''', ma semplicemente lancia il comando (o script) '''init''' che è nell'initrd e delega a lui tutto il resto.<BR>
Questo semplice meccanismo ci permette in pratica di creare uno script per risolvere tutti i problemi sopra citati.

'''Nota:''' Quando il kernel carica in memoria l'initrd e lancia il programma (o lo script) init, la root directory della nostra distribuzione non è ancora montata! Quindi la distribuzione non esiste, e con lei non esistono tutti i programmi usuali che uno pensa di usare nell'initrd. Se si vuole usare un programma, lo si deve copiare nell'ambiente dell'initrd e si devono copiare anche tutte quelle librerie condivise di cui il programma necessita.

==Initrd come archivio cpio==
Uno dei modi più semplici per creare un initrd è quello di inserire tutto il necessario in una directory vuota (programmi che si voglio usare nell'initrd, librerie di cui necessitano questi programmi, eventuali moduli del kernel, etc...etc...) e poi di creare un archivio cpio, magari compresso con gzip, di questa directory. Il kernel sarà poi in grado di decomprimere (se era compresso) l'archivio e di estrarne il contenuto.<BR>
Creiamoci allora una directory vuota ed entriamoci dentro con:
# mkdir /tmp/initrd
# cd /tmp/initrd

==Il pacchetto mkinitrd e la busybox==
Il pacchetto mkinitrd della Slackware (che si trova nella directory ''a/'') contiene lo script omonimo '''mkinitrd''', che generalmente viene usato da coloro che necessitano di un initrd e non vogliono (o non hanno le competenze adatte a) crearsene uno a mano.<BR>
Noi useremo il pacchetto, che quindi deve essere installato, non per lanciare l''''mkinitrd''' ma per prelevare il programma '''busybox''' che è al suo interno. Busybox è un programma che si può comportare in maniera diversa a seconda di come lo si invoca, se noi infatti creiamo un link simbolico chiamato mount a '''busybox''', allora questo si comporterà come '''mount'''. L'elenco di tutti i programmi che è in grado di simulare lo si può ottenere lanciando '''busybox''' senza parametri.

Il pacchetto mkinitrd ha la '''busybox''' inserita all'interno di un archivio tar.gz il cui path completo è:
''/usr/share/mkinitrd/initrd-tree.tar.gz''
preleviamo la busybox con:
# tar -C /tmp/initrd -zxf /usr/share/mkinitrd/initrd-tree.tar.gz './bin/busybox'
a questo punto la nostra directory ''/tmp/initrd'' avrà questa struttura:
# tree /tmp/initrd
/tmp/initrd
`-- bin
`-- busybox

==Creiamo lo script init==
Ora dobbiamo creare lo script '''init''', ovvero lo script che verrà eseguito dal kernel dopo l'inizializzazione dei driver e che è incaricato di risolvere i problemi su citati, cioè:
* caricare eventualmente i moduli del kernel per i controller USB e per il file system ext3
* dare il tempo ai controller USB di rilevare la pennina e montare, dopo averla scovata, la root directory
* eseguire il vero processo init della distribuzione

Prima di cimentarci nella risoluzione di questi problemi dobbiamo notare che '''init''', per come lo vogliamo utilizzare noi, è uno script, e in quanto tale ha bisogno di un interprete, la '''busybox''' può fare questo per noi visto che al suo interno ha anche una piccola shell. Andiamo nella directory ''/tmp/initrd/bin'' e creiamo un link simbolico a '''busybox''' in questo modo:
# ln -s busybox ash
e quindi con un qualsiasi editor di testo creiamo il file ''/tmp/initrd/init'' e mettiamoci come prima riga:
#!/bin/ash

===Caricare i moduli del kernel necessari al rilevamento della periferica USB e del file system ext3===
Il kernel huge è compilato con il supporto sia alle periferiche USB, sia al file system ext3 in maniera statica, e quindi ci permette di superare in maniera trasparente questo problema.<BR>
Si fa notare che il fatto di avere il supporto compilato in maniera statica nel kernel è un fattore da non sottovalutare. Infatti l'ambiente dell'initrd dovrebbe essere il più generale possibile, se spettasse all'initrd (e quindi allo script '''init''') caricare qualche modulo del kernel, allora l'initrd non sarebbe più indipendente, ma al suo interno dovrebbe avere i moduli compilati per il kernel specifico che lo ha eseguito.

===Dare il tempo ai controller USB di rilevare la pennina e montaggio della root directory===
Abbiamo installato sulla nostra pennina USB un file system del tipo ext3 che abbiamo anche etichettato con il nome di 'minislack'. Bene, grazie alla capacità del comando '''mount''' di utilizzare il nome di etichetta per identificare un file system, il problema può essere risolto semplicemente mettendo nello script '''init''' quanto segue:
mount -n proc -t proc /proc
while ! mount -n -r -L minislack /mnt 2> /dev/null;
do
sleep 1
done
umount -n /proc
Il "montaggio" del file system proc è necessario in quanto il comando '''mount''' fa uso di questo file system per scovare l'etichetta 'minislack'.<BR>
Il ciclo '''while''' con lo '''sleep''' non fa altro che dare il tempo necessario ai driver USB del kernel di rilevare la pennina.
Quindi la nostra root directory, o meglio il file system che noi abbiamo etichettato come 'minislack' sarà montato nella directory ''/mnt'' a prescindere dal device a cui il driver USB (e più precisamente il modulo che gestisce le periferiche di archiviazione di massa USB, l'usb_storage) lo ha collegato.

Nelle sei righe di codice precedenti abbiamo:
* usato il comando mount
* caricato il file system proc nella directory /proc
* usato il device null per ridirigere lo standard error del comando mount
* usato il comando sleep per far attendere alla shell 1 secondo
* montato la root directory in /mnt
* utilizzato il comando umount
per quanto potevano sembrare innocenti, quelle sei righe implicano:
* che il kernel al momento dell'esecuzione di queste righe, abbia il supporto al procfs e al tipo di file system della root directory che montiamo su ''/mnt'' (nel nostro caso il kernel huge ce li ha entrambi in maniera statica)
* che esistano i programmi mount, umount e sleep
* che esistano il device ''/dev/null'' e quello al quale sarà collegata la pennina USB (è vero che mount può scovare il device grazie all'etichetta del suo file system, ma è altrettanto vero che poi '''mount''' dovrà montare questo device)
* che esistano le directory ''/proc'' e ''/mnt''

La '''busybox''' può comportarsi come '''mount''' semplicemente facendo un link simbolico ad essa chiamato appunto ''mount'', il problema è che quello fornito dalla '''busybox''' non è in grado di scovare le etichette dei file system (non riconosce il flag -L). Abbiamo necessariamente bisogno del comando '''mount''' del pacchetto util-linux (dalla Slackware 12.1 e successive, il pacchetto si chiama util-linux-ng) contenuto
sempre nella directory della serie ''a/'' della Slackware.<BR>
Copiamo quindi il comando '''mount''' come segue:
# cp -p /bin/mount /tmp/initrd/bin
ora però dobbiamo copiare anche le librerie condivise di cui necessita. Vediamo quali sono lanciando:
# ldd /bin/mount
linux-gate.so.1 => (0xffffe000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7f80000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7f7d000)
libc.so.6 => /lib/libc.so.6 (0xb7e4e000)
/lib/ld-linux.so.2 (0x80000000)

Creiamoci la directory ''lib'' all'interno del nostro initrd con:
# mkdir /tmp/initrd/lib
e copiamoci dentro le librerie condivise con:
# cp -p /lib/libblkid.so.1 /lib/libuuid.so.1 /lib/libc.so.6 /lib/ld-linux.so.2 /tmp/initrd/lib
Si noti che i file originali probabilmente sono link simbolici, ma il comando '''cp''' copierà il file al quale puntano e non il link.

<nowiki>** NOTA **</nowiki>

A partire dalla slackware 13.1 il comando '''mount''' necessita di altre librerie:
# ldd /bin/mount
linux-gate.so.1 => (0xffffe000)
/usr/lib/libv4l/v4l1compat.so (0xb7838000)
/usr/lib/libv4l/v4l2convert.so (0xb7836000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb77eb000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb77e7000)
libc.so.6 => /lib/libc.so.6 (0xb7683000)
libv4l1.so.0 => /usr/lib/libv4l1.so.0 (0xb767e000)
libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0xb7674000)
/lib/ld-linux.so.2 (0xb783b000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb765b000)
libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0xb75ef000)
librt.so.1 => /lib/librt.so.1 (0xb75e5000)
libm.so.6 => /lib/libm.so.6 (0xb75bf000)

Quindi sarà necessario copiare anche le nuove librerie:
# cp -p /usr/lib/libv4l/v4l1compat.so /usr/lib/libv4l/v4l2convert.so /usr/lib/libv4l1.so.0 /usr/lib/libv4l2.so.0 /tmp/initrd/lib
# cp -p /lib/libpthread.so.0 /usr/lib/libv4lconvert.so.0 /lib/librt.so.1 /lib/libm.so.6 /tmp/initrd/lib
<nowiki>** FINE NOTA **</nowiki>

Per il comando '''umount''' e '''sleep''' invece possiamo tranquillamente usare quelli della '''busybox''', quindi andiamo nella directory ''/tmp/initrd/bin'' e facciamo:
# ln -s busybox umount
# ln -s busybox sleep

Il programma '''mount''' l'abbiamo utilizzato passandogli anche il flag -n, dicendogli quindi di non scrivere quello che sarà il file ''/etc/mtab'', benché esso non lo scriva, vuole comunque leggerlo per controllare se il file system che si sta tentando di montare non sia già stato montato. Dobbiamo quindi creare il file vuoto ''/tmp/initrd/etc/mtab'':
# mkdir /tmp/initrd/etc
# touch /tmp/initrd/etc/mtab

Proseguiamo quindi con la creazione del device null e dei possibili device a cui sarà collegata la pennina USB. In generale la pennina USB viene vista come una periferica SCSI disk e quindi sarà attaccata ad un device del tipo ''/dev/sdXY'' dove X varia a seconda di quante periferiche di archiviazione rilevate come SCSI (ad esempio i dischi sata) sono state trovate prima della pennina, mentre Y rappresenta una qualsiasi partizione.<BR>
Se, ad esempio, un PC non ha nessun disco rilevato come SCSI e ci si inserisce una pennina con tre partizioni, queste tre partizioni saranno collegate rispettivamente ai device: sda1, sda2 e sda3.

Y allora la possiamo ricavare facilmente, infatti all'inizio abbiamo supposto che la nostra pennina avesse solo una partizione e che essa (la partizione) venisse attaccata ad device ''/dev/sda1'', allora Y=1 e la pennina sarà sempre collegata ad un device dal nome ''/dev/sdX1''.<BR>
Quindi creiamoci la directory in cui inserire i device:
# mkdir /tmp/initrd/dev
e copiamoci subito dentro il device ''/dev/null'' con:
# cp -R /dev/null /tmp/initrd/dev

Al momento attuale gli SCSI disk sono gestiti dal device driver con major number 8. Questo device driver è in grado di gestire sino a 15 partizioni per ogni disco, questo vuol dire che due device con X consecutive e con uguale Y hanno una distanza (in termini di minor number) pari a 16. Ad esempio il device sda avrà un minor number uguale a 0 laddove il device sdb avrà invece minor number uguale a 16, e così via.

Possiamo allora creare i device con:
# mknod /tmp/initrd/dev/sda1 b 8 1
# mknod /tmp/initrd/dev/sdb1 b 8 17
# mknod /tmp/initrd/dev/sdc1 b 8 33
# mknod /tmp/initrd/dev/sdd1 b 8 49

Ora per rendere tutto coerente con quanto scritto sempre nelle sei innocenti righe di codice inserite nel file ''init'', non ci resta che creare due directory vuote nelle quali verranno montati i file system proc e quello contenente la nostra directory radice.
# mkdir /tmp/initrd/proc /tmp/initrd/mnt

===Eseguire il vero processo init===
L'ultimo passo che deve eseguire lo script '''init''' dell'initrd è quello di lanciare il vero processo '''init''' situato nella directory radice della distribuzione e poi liberare la memoria allocata.<BR>
I passi teorici da eseguire sono:
* spostare la directory radice dell'initrd sulla directory radice della distribuzione
* smontare l'initrd
* deallocare la memoria allocata dal kernel per l'initrd
* eseguire il vero processo '''init'''
Che poi praticamente, dato che per ognuno dei passi precedenti esiste uno specifico programma che lo esegue, diventa:
* cd /mnt; mkdir initrd; pivot_root . initrd
* umount /initrd
* blockdev --flushbufs /dev/ram0
* exec chroot . /sbin/init $@

Il comando '''pivot_root''' ultimamente sembra non comportarsi bene nell'ambiente dell'initrd. Fortunatamente la '''busybox''' ha al suo interno un programma che dovrebbe eseguire tutti i passi precedenti, il comando si chiama '''switch_root ''' e come al solito quindi basta fare un link simbolico a '''busybox''' entrando in ''/tmp/initrd/bin''
ed eseguendo:
# ln -s busybox switch_root

Ora non resta che inserire nello script init quanto segue:
exec switch_root /mnt /sbin/init $@

'''NOTA:''' si noti il passaggio a '''/sbin/init''' dei parametri $@, questi sono i parametri che il kernel non ha riconosciuto nella sua riga di comando (quella passatagli dal loader), e che quindi passa al comando che esegue.

===Lo script init nella sua interezza===
Riassumendo, lo script ''/tmp/initrd/init'' è questo:
<PRE>
#!/bin/ash
# Aspetto finché i driver USB non rilevano la pennina e monto la vera directory radice
mount -n proc /proc -t proc
while ! mount -n -r -L minislack /mnt 2> /dev/null;
do
sleep 1;
done
umount /proc

# Avvio il vero /sbin/init
exec switch_root /mnt /sbin/init $@
</PRE>
questo script deve essere eseguito dal kernel è quindi dobbiamo assicurarci che abbia i diritti di esecuzione:
# chmod u+x /tmp/initrd/init

==Creazione dell'archivio cpio compresso initrd.gz==
La directory ''/tmp/initrd'' ora dovrebbe essere così strutturata:
# tree /tmp/initrd
/tmp/initrd/
|-- bin
| |-- ash -> busybox
| |-- busybox
| |-- mount
| |-- sleep -> busybox
| |-- switch_root -> busybox
| `-- umount -> busybox
|-- dev
| |-- null
| |-- sda1
| |-- sdb1
| |-- sdc1
| `-- sdd1
|-- etc
| `-- mtab
|-- init
|-- lib
| |-- ld-linux.so.2
| |-- libblkid.so.1
| |-- libc.so.6
| `-- libuuid.so.1
|-- mnt
`-- proc

6 directories, 17 files
Non resta altro da fare che creare un archivio cpio di questa directory, comprimerla con il comando '''gzip''' e renderla disponibile al loader di linux.<BR>

Partendo dal solito presupposto che la pennina sia collegata dal kernel al device sda1, la si monti ad esempio nella directory ''/mnt/memory'' con:
# mount /dev/sda1 /mnt/memory
si crei poi una directory in cui inserire l'archivio cpio compresso che è l'initrd con:
# mkdir /mnt/memory/boot
ed infine si crei l'archivio cpio compresso (il tanto sudato initrd):
# cd /tmp/initrd
# find . | cpio -o -H newc | gzip -9 -n > /mnt/memory/boot/initrd.gz

Quando, più in là nel wiki, si configurerà il loader di linux, si vedrà come utilizzare questo file.

=Fase 2: installazione della distribuzione sulla pennina=
Ora ci si occuperà di installare e configurare una serie minimale ma importantissima di pacchetti Slackware.<BR>
Ovviamente non ci sono limitazioni, se non quelle fisiche della pennina, al numero di pacchetti che il lettore può installare, ma per lo scopo di questo wiki è sufficiente installare i pacchetti essenziali a far partire la distribuzione.<BR>
I pacchetti che verranno installati si trovano tutti nella directory ''a/'' della Slackware, quindi, supponendo che il CD o DVD della Slackware sia stato montato nella directory ''/mnt/dvd/'', per prima cosa ci si deve spostare dentro questa directory con:
# cd /mnt/dvd/slackware/a

==Un piccolo accorgimento==
I pacchetti verranno installati sfruttando l'opzione -root dello script '''installpkg''', alcuni dei pacchetti hanno uno script aggiuntivo, il famoso '''doinst.sh''', che viene avviato dopo l'installazione del pacchetto. Gli script '''doinst.sh''' sono "chrootati" sulla pennina e devono poter eseguire comandi, quali ad esempio '''cd''', '''rm''' o
'''ln'''. Questo implica che:
* il programma che il '''doinst.sh''' vuole eseguire deve essere presente sulla pennina
* si abbiano i diritti di esecuzione sulla pennina

La prima implicazione è risolta installando i pacchetti in un ordine ben preciso, facendo in modo di installare prima i pacchetti che contengono i programmi usuali usati dai '''doinst.sh'''.

La seconda implicazione viene verificata se si esegue un piccolo accorgimento, ovvero smontare la pennina e rimontarla con l'opzione 'exec' del '''mount''', in questo modo:
# umount /mnt/memory
# mount -o exec -rw -t ext3 /dev/sda1 /mnt/memory

==I pacchetti da installare==
La domanda è semplice, come si determinano i pacchetti che si devono installare?<BR>
La risposta non è altrettanto semplice, sicuramente ci sarà il programma ''/sbin/init'' per avere un collegamento all'initrd creato nella 'Fase 1', ma poi? Poi bisogna seguire l''''init''' e capire cosa esegue, in modo da fargli trovare i programmi che tenta di eseguire. Se è necessario, bisogna anche seguire i programmi che '''init''' esegue per capire cosa fanno e se hanno bisogno di altri programmi o file di configurazione.<BR>
In generale quindi, il primo file da analizzare è ''/etc/inittab'', file di configurazione di '''init''', ci si accorge quindi che '''init''' esegue una serie di script di inizializzazione, e quindi bisogna seguire questi script per capire cosa fanno.

Per lo scopo di questo wiki il lavoro è stato già fatto dall'autore e quindi verranno segnalati solo i passi fondamentali da fare affinché la distribuzione possa partire.

Qui si riporta l'elenco dei pacchetti che devono essere installati nell'ordine di seguito riportato (l'ordine è importante solo per i primi tre pacchetti). Accanto al nome del pacchetto vi è una piccola descrizione di cosa contiene:
a/aaa_base ---> Crea tutte le directory base
a/coreutils ---> Programmi utilizzati dagli script '''doisnt.sh'''
a/glibc-solibs ---> La libreria glibc, usata da molti eseguibili (tra cui '''init''')
a/glibc-zoneinfo ---> Contiene lo script '''timeconfig''' che verrà usato in seguito
a/dialog ---> Usato per visualizzare i box dei dialoghi da altri programmi
(tra cui '''timeconfig''')
a/bash ---> La shell
a/etc ---> File di configurazione dei programmi utilizzati
a/util-linux ---> Contiene, tra l'altro, il programma '''mount'''. Dalla Slackware 12.1 in poi,
il pacchetto si chiama util-linux-ng
a/sysvinit ---> Contiene il programma '''init'''
a/sysvinit-scripts ---> I famosi script '''rc.d''' della Slackware, invocati da '''init'''
a/module-init-tools ---> '''modprobe''' e altri programmi per gestire i moduli
a/e2fsprogs ---> Comandi per i filesystem ext2/3
a/devs ---> I device, senza di questi....
a/findutils ---> '''find''', usato dagli script di inizializzazione
a/aaa_elflibs ---> Libreria libtermcap per i terminali
a/aaa_terminfo ---> File di informazione sui terminali usati dalla libreria libtermcap
a/shadow ---> Contiene, tra l'altro, i programmi '''login''' e '''sulogin'''
a/grep ---> '''grep''', usato dagli script di inizializzazione
a/procps ---> '''ps''', usato dagli script di inizializzazione
a/kernel-huge ---> Il kernel...
a/kernel-modules ---> ... i suoi moduli

<nowiki>** NOTA **</nowiki>

A partire da slackware 13.1 è necessario anche il seguente pacchetto
l/v4l-utils ---> Librerie necessarie ai programmi di sistema (ad es: '''mount''')

<nowiki>** FINE NOTA **</nowiki>

Per installare questi pacchetti si deve eseguire '''installpkg''' con l'opzione -root ''/mnt/memory'', ad esempio:
# installpkg -root /mnt/memory aaa_base-12.0.0-noarch-1.tgz

==Una facile configurazione==
Come per la domanda 'Quali pacchetti si devono installare?', così la risposta alla domanda 'Cosa si deve configurare?' dipende sempre dall'amministratore del sistema e da cosa esso intenda far eseguire all'avvio della macchina.<BR>
Nel wiki si intende lasciare intatti gli script di inizializzazione fatti da Patrick J. Volkerding, creatore della Slackware, e quindi si procederà nella minima configurazione necessaria proprio a questi script di inizializzazione.

===/etc/fstab===
Si comincia con il creare il file ''/etc/fstab'' come segue:
# echo -e "LABEL=minislack\t\t/\text3\trw\t1 1" > /mnt/memory/etc/fstab

===/etc/hardwareclock===
Un altro file richiesto dagli script di inizializzazione della Slackware è il file ''/etc/hardwareclock'' che indica come è impostato l'orologio hardware. In effetti questo file non contiene granché, ma viene consigliato di editarlo/crearlo tramite lo script '''/usr/sbin/timeconfig''', quindi bisogna eseguire lo script spostandogli la directory root, in questo modo:
# cd /mnt/memory
# chroot . usr/sbin/timeconfig

=Fase 3: impostare il boot loader e testare il tutto=
L'ultima cosa da fare è quella di rendere la pennina "bootabile", ovvero di inserire nel suo primo settore, il famoso settore di boot. Per fare questo basta creare un file ''lilo.conf'' ad-hoc, e poi lanciare LILO passandogli il file appena creato.<BR>
Si crei quindi il file, ad esempio ''/mnt/memory/etc/lilo.conf'', direttamente sulla pennina in modo che rimanga con essa, con all'interno quanto segue:
<PRE>
boot = /dev/sda
backup = ""
map=/mnt/memory/boot/map

compact
lba32
large-memory

image = /mnt/memory/boot/vmlinuz
initrd = /mnt/memory/boot/initrd.gz
</PRE>

Si noti l'opzione 'initrd', con la quale si indica al kernel che deve usare l'initrd creato nella 'Fase 1'. Ora non resta quindi che lanciare LILO come segue:
# lilo -C /mnt/memory/etc/lilo.conf
e riavviare il PC facendogli fare il boot dalla pennina USB.<BR>
Con la configurazione minimale che si è fatta nella 'Fase 2', basta, al momento del login, inserire l'username di 'root' per avere una shell con tutti i privilegi del super-utente.

=Esempi d'uso=
Una volta che si ha una pennina USB "bootabile", con all'interno un intera distribuzione, serve solo la fantasia per farci quello che ci pare.<BR>
Esempi d'uso potrebbero essere quello di crearsi una distribuzione adatta alla lettura di contenuti multimediali, in questo modo basta trovare un PC per vedere un DVD o ascoltare della musica, senza preoccuparsi che il PC sia dotato di tutti i programmi o codec adatti.

Un altro esempio è che si ha sempre a portata di mano un "disco di ripristino". Se la distribuzione installata sul PC non dovesse partire perché ci si è divertiti un po' troppo con i file di configurazione, si può sempre fare il boot del PC con la pennina e provvedere a rimediare agli eventuali danni che si è combinati.

=Appendice=
==A: altri pacchetti utili==
Se si vuole rendere la distribuzione che si è installata sulla pennina un po' più indipendente, bisogna essere in grado di manipolare i pacchetti della Slackware, non solo, ma sarebbe anche carino poter utilizzare tutta una serie di comandi utili ad un sistemista. Quindi, oltre all'insieme minimo di pacchetti menzionati nella sezione
'[[#I_pacchetti_da_installare|I pacchetti da installare]]', qui di seguito c'è un elenco dei pacchetti che rendono la distribuzione sulla pennina, più user-friendly:
a/pkgtools ---> Per gestire i pacchetti della Slackware
a/bin ---> Usato dagli script di pkgtools
a/sed ---> Usato dagli script di pkgtools
a/gzip ---> Usato dagli script di pkgtools
a/tar ---> Usato dagli script di pkgtools
a/xz ---> Usato dagli script di pkgtools per il nuovo formato '.txz' della Slackware 13

ap/man ---> Il comando man più tornare molto utile
ap/man-pages ---> Le pagine di manuale di molti comandi
ap/groff ---> Il formattatore usato da man
a/cxxlibs ---> Libreria c++ standard usata da groff
a/less ---> Il comando che man usa per visualizzare le pagine di manuale

a/udev ---> Utile se si vogliono usare driver che necessitano di firmware

ap/nano ---> Il famoso e semplice editor di testo

a/bzip2 ---> Sempre più spesso si trovano archivi bzip

a/reiserfsprogs ---> Per gestire il famoso file system reiser

=Ringraziamenti=
Ringrazio ZeroUno per i suoi consigli e le sue prove.

Note per slackware 13.1 a cura di [[Utente:Ansa89|Ansa89]].

Per qualsiasi cosa scrivetemi pure:<BR>
[[Utente:targzeta|targzeta]]

Analyze SlackPkg.sh

2012-10-02T21:53:54Z

Targzeta: Cambiato nick

[[category:Script]]
=Introduzione=
Questo script visualizza alcune informazioni interessanti riguardanti i pacchetti Slackware installati e può essere usato per mantenere aggiornata una current. Lo script deve essere eseguito in una directory contenente il file FILE_LIST fornito dal CD/DVD.
=Cosa fa e come si usa=
==Senza opzioni==
Lo script, per ogni pacchetti installato va a controllare se è nominato nel file FILE_LIST controllandone la versione, dove per versione si intende sia la versione del software che la marca di compilazione. Se le due versioni differiscono allora lo script stampa a video il percorso dove poter trovare il pacchetto con la versione differente. Ad esempio sulla mia macchina:
<pre>
$> analyze_SlackPkg.sh
./a/aaa_elflibs-13.013-x86_64-5.txz
./l/cairo-1.8.8-x86_64-3.txz
./n/stunnel-4.33-x86_64-1.txz
</pre>
questo vuol dire che nella mia Slackware sono installati i tre pacchetti elencati ma con versioni differenti, infatti ad esempio:
<pre>
$> ls /var/log/packages/stunnel-*
/var/log/packages/stunnel-4.17-x86_64-1
</pre>
Quindi se si ha a disposizione un repository locale della current si può aggiornare il PC semplicemente eseguendo:
<pre>
for package in $(analyze_SlackPkg.sh)
do
upgradepkg $package
done
</pre>
==Le opzioni==
===-h===
Mostra l'help dello script.
===-n===
Stampa l'elenco dei pacchetti nominati nel FILE_LIST, ma che non sono stati installati.
===-m===
Stampa l'elenco dei pacchetti che non sono stati trovati nel file FILE_LIST o che sono stati filtrati dal [[#Il file di filtraggio|file di filtro]]. Questi pacchetti generalmente sono i pacchetti di terze parti (ad esempio quelli di Slacky.eu) ed i pacchetti che sono stati rimossi dalla Slackware.
===-s===
Stampa l'elenco dei pacchetti che hanno la stessa versione di quelli trovati nel file FILE_LIST.
===-v===
A volte è utile sapere la versione attuale dei pacchetti installati, questa opzione oltre a visualizzare il percorso del pacchetto con la versione diversa, stampa anche la versione attualmente installata.

<pre>
$>analyze_SlackPkg.sh -v
./a/aaa_elflibs-13.013-x86_64-5.txz the current version is aaa_elflibs-13.013-x86_64-4
./l/cairo-1.8.8-x86_64-3.txz the current version is cairo-1.8.10-x86_64-1
./n/stunnel-4.33-x86_64-1.txz the current version is stunnel-4.17-x86_64-1
</pre>

=Il file di filtraggio=
Può capitare che di alcuni software si voglia seguire una versione current e non quella fornita dalla Slackware, usando il ciclo for descritto precedentemente per aggiornare il PC evidentemente questi pacchetti risulteranno con una versione differente e saranno quindi aggiornati. Per evitare questo comportamento basta creare un file nella propria home chiamato ''.analyze_SlackPkg'' e inserirci al proprio interno il nome del software da saltare e quest'ultimo non sarà stampato in output. Ad esempio se inserisco nel mio file il software '''cairo''' e poi rieseguo lo script:
<pre>
$> echo 'cairo' >> ~/.analyze_SlackPkg

$> analyze_SlackPkg.sh
./a/aaa_elflibs-13.013-x86_64-5.txz
./n/stunnel-4.33-x86_64-1.txz
</pre>
si nota che rispetto a prima, '''cairo''' non viene visualizzato.
=Lo script=
Dulcis in fundo, lo script potete trovarlo [http://www.slacky.eu/~targzeta/script/analyze_SlackPkg.sh qui].

Autore (data dell'ultimo aggiornamento):
[[Utente:targzeta|targzeta]] 07:38, 28 ott 2010 (UTC)