Kerneler

[Neon87]

Ciao!

Sono l'autore di Kerneler.

Compilare il Kernel su GNU/Linux spesso è difficile per i nuovi utenti che si affacciano per la prima volta su questo mondo.
Nasce quindi Kerneler! Un piccolo script che permette di semplificare notevolmente la compilazione del Kernel su distribuzioni debian-based

Kerneler è completamente testuale poiché ritengo abbastanza inutile la grafica per un programma che deve gestire la compilazione del Kernel. In realta' è presente una "grafica testuale" realizzata mediante l'uso di dialog che permette di avere dei menu interattivi che sono molto prossimi a quelli realizzati per X. Alcuni screenshot sono disponibili qui.

Il software è in fase di sviluppo ma attualmente è funzionante sulle seguenti distribuzioni:

* debian sarge (parzialmente, infatti monta una versione molto vecchia di make-kpkg)
* debian etch
* debian sid
* ubuntu dapper
* ubuntu edgy

Features:

* Downloader. Scarica automaticamente la versione scelta con il download manager scelto e ne controlla la dimensione
* Decompressione. Decomprime i file sorgenti e controlla che siano stati correttamente estratti.
* Patcher. Aggiorna i sorgenti all'ultima revisione automaticamente oppure aggiunge patch (con relativa funzione di rimozione) ck, mm e Beyond
* Configuratore. Copia il vecchio file .config in utilizzo e controlla che sia presente tutto il necessario perché make menuconfig possa venir lanciato
* Compilatore. Genera diversi tipi di pacchetti a partire dai sorgenti.
* Installatore. Installa i pacchetti .deb generati in questa, o in precedenti sessioni, della versione specificata
* Menu Hardware. Permette di avere una idea dell'hardware presente tramite un comodo menu
* Wizard. Processo che guida passo passo l'utente durante la compilazione del Kernel. Rispondendo a semplici domande sara' possibile ricompilare il Kernel.

Il link al sito ufficiale è http://www.kerneler.org
Per scaricarlo https://sourceforge.net/project/show...ease_id=472032

Vorrei sapere come lo trovate, se vi sembra una buona idea e cosa potrei migliorare!

Grazie a tutti!

[ilsensine]

Originariamente inviato da Neon87

* Configuratore. Copia il vecchio file .config in utilizzo

Non è la scelta ottimale; da un kernel all'altro possono spuntare o scomparire alcune voci, o - peggio - altre potrebbero cambiar nome.

Sarebbe interessante riuscire a rilevare l'hw presente e generare automaticamente un .config personalizzato, ma ovviamente non è banale

[ilsensine]

C'è un serio bug di sicurezza:

Utente esegue ln -s /dev/hda /tmp/kerneler.htm
Root esegue kerneler
Root piange perché hda è andato distrutto

Usa mktemp per creare il file temporaneo

[ilsensine]

Altro problema di sicurezza: dai una occhiata ai permessi della cartella contenente il kernel scompattato e dei file contenuti

[Cobra78]

Originariamente inviato da ilsensine

Sarebbe interessante riuscire a rilevare l'hw presente e generare automaticamente un .config personalizzato, ma ovviamente non è banale

In linea teorica non basterebbe verificare quali moduli siano caricati e abilitare quelli di conseguenza?

[Neon87]

Innanzi tutto grazie mille!

1) Il problema della copia del file .config viene meno quando l'utente lancia make menuconfig o roba simile e salva il nuovo config... in questo modo le voci in piu' vengono aggiunte e quelle che vengono tolte vengono eliminate... Posso magari rendere obbligatorio che il file .config e quello nuovo generato devono essere diversi...

2) Effettivamente non ci avevo pensato pongo subito rimedio

3) Allora cambio tar jxvf con qualche cosa che mantenga i permessi originali effettivamente è meglio

Non so come ringraziarti sei stato di prezioso aiuto!

[Neon87]

Originariamente inviato da Cobra78

In linea teorica non basterebbe verificare quali moduli siano caricati e abilitare quelli di conseguenza?

Teoricamente se il pc è configurato ad hoc si potrebbe bastare (teoricamente perche' potrebbero cambiare moduli e far cambiare tutto)

Pero' se il pc non è configurato a dovere nemmeno la nuova configurazione lo sara'...

[ilsensine]

Originariamente inviato da Neon87

3) Allora cambio tar jxvf con qualche cosa che mantenga i permessi originali effettivamente è meglio

C'è stato un mezzo flame sulla lkml per il fatto che i pacchetti contengono i privilegi 777. Se scompatti da utente non te ne accorgi (la umask è applicata), ma se esegui tar da root no (in quanto tar in questo caso è pensato per ripristinare un backup, esattamente com'era).
La soluzione è tar -xjf --no-same-permissions -f <file>

[ilsensine]

Ti do una piccola dritta per mostrare in un dialog l'output dei programmi (ad es. wget). Prova questo:

#!/bin/bash

FIFO=/root/.fifo
# TODO: Controllare che $FIFO non esista,
# oppure che esista ed è effettivamente un fifo
mkfifo "$FIFO" 2>/dev/null
exec 3<>"$FIFO"

wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.1.tar.bz2 -o "$FIFO" &
PID=$!
dialog --title "titolo" --backtitle "backtitolo" --progressbox 3 80 0<&3 &
DPID=$!
wait $PID
kill -TERM $DPID

E' molto rozzo, dovresti lavorarci un pò per migliorarlo. La cosa più fastidiosa è che utilizzando dialog in questa maniera distrugge le impostazioni del terminale (puoi effettuare un reset del terminale con "reset" all'uscita dello script).
Peccato che trap non cattura anche il SIGCHLD, avrebbe evitato di mettere dialog in background.

[Neon87]

Fantastico! Grazie mille!
Vedo di aggiungere il tutto nella prossima release!

Come idea ti sembra buona puo' avere un futuro o è un fallimento in partenza?

[ilsensine]

Direi che può essere comodo, anche solo per il fatto che scarica & applica patch automaticamente.

Alcuni consigli:
- .config in base alla configurazione attuale. Non è necessario generarlo "completamente", parti dal defconfig per i386 e autoconfigura le parti più importanti (processore, supporto smp/up/highmem, driver necessari per montare il rootfs senza l'ausilio di un initrd ecc.). Il resto dei driver lasciali nella configurazione di default (probabilmente "m"), penserà udev a caricarli a sistema avviato.
- Più fiscalità sul controllo di fallimento dei programmi lanciati
- Possibilità di eseguirlo da utente normale (ovviamente non potrai fare alcune cose, e non potrai usare /usr/src come directory di compilazione ma una dir dell'utente)
- Dividilo in più script, 35k di script bash sono inmantenibili! Usa anche le "funzioni" bash.
- Indenta lo script (sezioni if, ecc.), così è poco leggibile
- Supporto multilingua (almeno l'inglese!) tramite gettext

[Neon87]

La traduzione l'ho affidata ad un'amica a breve spero di riuscire a metterla su...

Sono sicuramente consigli d'oro...

L'unico problema sara' generare il .config anche sapendo processore ram e roba affina...
Ci lavorero' su

[ilsensine]

Originariamente inviato da Neon87

L'unico problema sara' generare il .config anche sapendo processore ram e roba affina...

Lascialo a bassa priorità, il riutilizzo di .config dovrebbe andar bene per la maggior parte dei casi. Fossi in te comincerei a dividere il progetto in più file e funzioni, in modo da renderlo più mantenibile.

[Neon87]

Originariamente inviato da ilsensine

Lascialo a bassa priorità, il riutilizzo di .config dovrebbe andar bene per la maggior parte dei casi. Fossi in te comincerei a dividere il progetto in più file e funzioni, in modo da renderlo più mantenibile.

io lo ho gia' diviso in vari file... poi quando lo rilascio li unisco tutti per aumentare la comodita' di chi lo usa... perche' credo che portarsi dietro un file unico sia meglio che portarsene 10... certo quando fai una modifica ti metti le mani nei capelli...

bel dilemma... magari faccio 2 pacchetti separati...

[ilsensine]

Originariamente inviato da ilsensine

Ti do una piccola dritta per mostrare in un dialog l'output dei programmi

Ma quanto sono deficiente...
Questo non ha effetti collaterali:

#!/bin/bash

wait_child()
{
  wait $1
  RET=$?
  return $RET
}

FIFO=/root/.fifo
# TODO: Controllare che $FIFO non esista,
# oppure che esista ed è effettivamente un fifo
mkfifo "$FIFO" 2>/dev/null

wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.1.tar.bz2 -o "$FIFO" &
WPID=$!
dialog --title "titolo" --backtitle "backtitolo" --progressbox 3 80 0<$FIFO
# In caso di morte non prevista di dialog, dobbiamo comunque aspettare che wget termini.
wait_child $WPID
RETCODE=$?
if [ $RETCODE -ne 0 ]; then
  # gestione errore in wget
fi

Ho provato anche con un reindirizzamento diretto di wget (tramite "|"), ma gli effetti non sono quelli desiderati.

[Neon87]

grande gira benissimo!

non so come ringraziarti!

[sjukdom]

Scusate se mi intrometto,ma sarebbe possibile in futuro implementare i diversi tipi di configurazione del kernel?
Certo non è che abbia tutta questa importanza,però potrebbe catturare un maggior numero di utilizzatori e rendere piu user-friendly il tutto.

[Neon87]

Originariamente inviato da sjukdom

Scusate se mi intrometto,ma sarebbe possibile in futuro implementare i diversi tipi di configurazione del kernel?
Certo non è che abbia tutta questa importanza,però potrebbe catturare un maggior numero di utilizzatori e rendere piu user-friendly il tutto.

in che senso diversi tipi di configurazione?

[Neon87]

Il patcher ora puo' aggiungere patch ck, mm e beyond oltre ad aggiornare all'ultima revisione....

conoscete qualche patch interessante che vale la pena di essere inserita?

[ilsensine]

Originariamente inviato da Neon87

Il patcher ora puo' aggiungere patch ck, mm e beyond oltre ad aggiornare all'ultima revisione....

conoscete qualche patch interessante che vale la pena di essere inserita?

Aggiungi il supporto per git:
http://linux.yyz.us/git-howto.html
e la possibilità di scaricare direttamente uno snapshot git del kernel (oppure lo snapshot di una determinata data, se possibile).
Sarebbe molto utile, anche se per un numero limitato di persone, poter applicare direttamente patch dai rami git dei diversi sviluppatori. Nota che il rischio che il patching automatico fallisca è più elevato, chi usa questa funzione deve sapere esattamente cosa sta facendo.