FUSS - Manuale per lo sviluppatore

Il presente manuale è una guida alla manutenzione ed allo sviluppo della distribuzione FUSS GNU/Linux basata, lato server e client su Debian 12 «Bookworm».

La versione più recente di questo manuale è leggibile all’indirizzo https://fuss-dev-guide.readthedocs.io/it/latest/

Guide del progetto FUSS

Le guide del progetto fuss (user, referent, tech e dev) sono scritte in reStructuredText e pubblicate usando il generatore di documentazione sphinx

Repository

I sorgenti delle guide sono in repository git hostati su gitlab; avendo un’account sulla piattaforma ed una chiave ssh configurata possono essere clonati con:

git clone git@gitlab.com:fusslab/fuss-user-guide.git
git clone git@gitlab.com:fusslab/fuss-referent-guide.git
git clone git@gitlab.com:fusslab/fuss-tech-guide.git
git clone git@gitlab.com:fusslab/fuss-dev-guide.git

altrimenti si può usare l’accesso https:

git clone https://gitlab.com/fusslab/fuss-user-guide.git
git clone https://gitlab.com/fusslab/fuss-referent-guide.git
git clone https://gitlab.com/fusslab/fuss-tech-guide.git
git clone https://gitlab.com/fusslab/fuss-dev-guide.git

Creazione di nuove pagine

Per aggiungere una pagina ad una guida:

• Creare un nuovo file con estensione .rst, ad esempio titolo-dell-articolo.rst; è opportuno che il nome del file contenga solo lettere minuscole, numeri e il trattino -, senza lettere accentate, spazi né altri caratteri speciali.

• Aggiungere l’articolo al doctree in index.rst, aggiungendo il nome del file senza estensione (es. titolo-dell-articolo) nella posizione opportuna rispetto agli altri articoli.

Build locale

Mentre si stanno facendo modifiche, può essere utile generare localmente le pagine html per avere un’anteprima di quanto sarà poi pubblicato.

Setup

Per la generazione è necessario installare le seguenti dipendenze (su FUSS client, o una versione recente di Debian o derivate):

apt install python3-sphinx python3-sphinx-rtd-theme python3-stemmer

Build

Per generare le pagine html:

cd <path/del/repository>/docs
make html

e si può poi vedere il risultato con:

sensible-browser _build/html/index.html

Aggiornamento versione pubblicata

La versione pubblicata su readthedocs viene aggiornata automaticamente ogni volta che viene aggiornato il branch master su gitlab; se si ha accesso in scrittura ai repository è sufficiente:

cd <path/del/repository>
git push origin master

(oppure semplicemente git push se ci si trova già sul branch master)

Se non si ha accesso in scrittura al repository si può invece creare una merge request

Linee di guida per lo stile

Screenshot ed esempi di terminale

Per guide che si riferiscono a programmi grafici, è opportuno aggiungere screenshot.

Per quanto riguarda esempi tratti dal terminale, meglio riportare comandi ed output come testo, per maggiore accessibilità, usando dei blocchi di codice, ad esempio:

testo introduttivo::

    $ comando
    output del comando
    # /sbin/comando
    output del comando lanciato da root

Nota

I doppi due punti del codice reStructuredText vengono convertiti in un punto unico nelle versioni pubblicate, a meno che non sia preceduto da spazi (o in un paragrafo da solo), nel qual caso viene rimosso.

Livelli di struttura

reStructuredText permette di usare caratteri diversi per i vari livelli di struttura di un documento, purché siano coerenti all’interno del singolo file.

È però meglio attenersi alla convenzione della Python’s Style Guide for documenting, che prevede:

• # con doppia riga per le parti (non usate in questi manuali);

• * con doppia riga per i capitoli (corrisponenti per noi ai file);

• = per le sezioni;

• - per le sottosezioni;

• ^ per le sotto-sottosezioni;

• " per i paragrafi.

Tips e tricks

Migrazione dalla wiki di Redmine

I documenti presenti sulla wiki di redmine usano il formato (sorgente) textile; per convertirlo in reStructuredText può essere utile il programma Pandoc

Una volta copiato il sorgente della pagina in un file locale articolo.txt si può usare il seguente comando per ottenerne una versione in reStructuredText nel file articolo.rst:

pandoc -f textile -t rst -o articolo.rst articolo.txt

Tale file è un buon punto di partenza, ma non è pronto per l’inclusione diretta nelle guide FUSS senza prima verificare manualmente i contenuti; in particolare sarà sicuramente necessario sistemare manualmente alcune caratteristiche.

• I livelli di struttura andranno corretti per adeguarsi allo standard specificato qui sopra, facendo attenzione alla posizione in cui viene inserito il documento (ad esempio se si sta convertendo una pagina della wiki in una sezione o sottosezione di una pagina della guida).

• Le immagini vengono caricate dal file originale sulla wiki; per la mantenibilità futura è invece opportuno caricarle localmente all’interno della guida.

  Dopo aver scaricato le immagini, ad esempio nella directory images/articolo/, e spostati i riferimenti generati da pandoc dalla fine del documento alla posizione dove dovrà apparire l’immagine, li si può convertire in direttive figure col seguente comando di vim:

  :%s/|image.*| image:: https:\/\/work.fuss.bz.it\/attachments\/download\/.*\//figure:: images\/articolo\//
  

• pandoc genera dei blocchi di codice introdotti da una riga contenente solo ::, anche quando il paragrafo precedente termina con :; per migliore eleganza e leggibilità del sorgente questi si possono convertire mettendo :: solo sul paragrafo precedente.

  Entrambi i casi sono comunque costruzioni reST valide che vengono compilate in una presentazione simile.

• Alcuni articoli della wiki contengono sezioni con indicazioni tipo “attenzione” o “nota”: in questi casi può valere la pena convertirli nella relativa direttiva specifica reStructuredText

Screenshot

Redimensionare una finestra con precisione

Per fare screenshot della finestra di un programma è utile ridimensionarla alla dimensione precisa che si vuole dare allo screenshot; per farlo si può usare il comando seguente:

sleep 3 ; xdotool getactivewindow windowsize 1024 768

che aspetta 3 secondi, nel corso del quale si può cambiare la finestra attiva dal terminale alla finestra desiderata, e quindi effettua il resize.

Pacchetti e Repository

La distribuzione FUSS comprende un repository di pacchetti aggiuntivi rispetto alla base (Debian), disponibile all’indirizzo https://archive.fuss.bz.it/ ed ospitato su isolda.fuss.bz.it nella directory /iso/repo.

Build dei pacchetti

Nei repository del software sviluppato per FUSS è presente la directory debian contenente i file necessari per la generazione dei pacchetti .deb.

Nei progetti sufficientemente recenti, tale directory è presente solo in un branch dedicato, con un nome tipo fuss/<versione>; per questi casi vedere anche la sezione Verifica delle versioni presenti sul repository .

Setup

Per effettuare build locali dei pacchetti è necessario installare alcuni strumenti di sviluppo:

# apt install devscripts dput-ng dh-systemd dh-python

Nota

Assicurarsi di aver installato anche i Recommends dei pacchetti (questo è il comportamento di default di apt, a meno che non lo si sia disabilitato manualmente), in particolare nel caso di dput-ng.

Inoltre è necessario impostare le variabili di ambiente DEBEMAIL e DEBFULLNAME, contenenti rispettivamente il nome completo e l’email dello sviluppatore, che verranno usate per aggiornare alcuni metadati.

Per usare dput-ng per effettuare gli upload serve configurarlo creando il file ~/.dput.d/profiles/fuss-<versione>.json contenente:

{
    "method": "sftp",
    "fqdn": "archive.fuss.bz.it",
    "incoming": "/iso/incoming/<versione>",
    "allow_dcut": false,
    "allowed-distribution": {},
    "codenames": null,
    "post_upload_command": "ssh -S none isolda.fuss.bz.it 'sudo /iso/bin/post-upload'",
    "hooks": [
        "allowed-distribution",
        "checksum",
        "suite-mismatch"
    ]
}

dove <versione> è bookworm e bookworm-proposed-updates per la versione corrente di FUSS server e client, e buster e buster-proposed-updates per la versione legacy del server e bullseye e bullseye-proposed-updates per quella del client.

Suggerimento

in alcune versioni di dput-ng è presente un bug, #952576 per cui eventuali errori di post-upload non vengono riportati, rendendo silenzioso il fallimento. Se si incappa in quella situazione, un possibile workaround è sostituire la configurazione di post_upload_command con la seguente:

"post_upload_command": "ssh -S none isolda.fuss.bz.it '/iso/bin/post-upload 2>&1'",

in modo che eventuali errori vengano rediretti su stdout e vengano visualizzati.

Assicurarsi inoltre di poter accedere via ssh ad archive.fuss.bz.it senza ulteriori opzioni; ad esempio potrebbe essere necessario aggiungere quanto segue a ~/.ssh/config:

Host archive.fuss.bz.it
    User root

Nota

dput-ng usa paramiko per effettuare le connessioni ssh; questo implica che le opzioni impostate direttamente in ~/.ssh/config vengono lette correttamente, ma non c’è supporto per l’uso di Include per suddividere la configurazione su più file.

Inoltre non verrà salvato il fingerprint dei server, ma verrà chiesto ogni volta di verificarlo.

A marzo 2019 i fingerprint di isolda sono:

256 SHA256:aLTgA+Trj5iYo0dl0i8Q82aigs3K/dPwDbazrvG95YY root@isolda (ECDSA)
256 SHA256:7i6j0jXPWRrW6LXDGbR+HWr3AFJi6gGSmdW41uBRJV4 root@isolda (ED25519)
2048 SHA256:OkP1maDf0pSIGCdq1mph8oI8CTADMrFXfe3aty608SA root@isolda (RSA)

256 MD5:b1:a1:ec:cb:a5:39:c8:8d:39:f1:dd:ba:aa:be:38:11 root@isolda (ECDSA)
256 MD5:21:41:8b:19:1b:25:b5:9c:f2:5c:e8:b9:8b:08:07:f8 root@isolda (ED25519)
2048 MD5:bd:88:bd:5f:bc:52:03:0b:88:d9:0c:2b:86:59:dc:92 root@isolda (RSA)

Cowbuilder

Nota

cowbuilder e pbuilder sono degli strumenti per gestire delle chroot all’interno delle quali effettuare build di pacchetti in un ambiente pulito e abbastanza isolato dal sistema base.

Buildare pacchetti all’interno di un sistema isolato è utile per evitare influenze da parte del proprio sistema (con librerie ed altre dipendenze già installate, magari in versioni non standard), ma è anche comodo nel caso si vogliano generare pacchetti per distribuzioni diverse da quelle in uso (ad esempio buildare per buster su un sistema bookworm)

Oltre a quanto indicato sopra, installare cowbuilder, pbuilder e git-buildpackage:

# apt install pbuilder cowbuilder git-buildpackage

ed assicurarsi che l’utente che si vuole usare per lanciare le build faccia parte del gruppo sudo.

Quindi creare le chroot base per le distribuzioni attualmente (gennaio 2023) in uso buster, bullseye e bookworm:

# cowbuilder --create --distribution buster --debootstrap debootstrap \
  --basepath /var/cache/pbuilder/base-fuss-buster.cow
# cowbuilder --create --distribution bullseye --debootstrap debootstrap \
  --basepath /var/cache/pbuilder/base-fuss-bullseye.cow
# cowbuilder --create --distribution bookworm --debootstrap debootstrap \
  --basepath /var/cache/pbuilder/base-fuss-bookworm.cow

Suggerimento

cowbuilder può essere usato anche sotto distribuzioni derivate da debian, come ubuntu; in questo caso è necessario però specificare esplicitamente l’uso di un mirror debian aggiungendo ai comandi sopra le opzioni:

--mirror http://<un mirror debian valido>/debian --components main

inoltre per il funzionamento è necessario disporre delle chiavi di firma GPG di Debian, che in genere si installano con:

apt-get install -y debian-archive-keyring

Aggiungere i repository di backports e fuss alle chroot base appena create: copiare il file di chiave nella chroot:

# wget -O \
  /var/cache/pbuilder/base-fuss-bookworm.cow/usr/share/keyrings/fuss-keyring.gpg \
  https://archive.fuss.bz.it/apt.gpg

quindi fare login nella chroot:

# cowbuilder --login --save-after-login \
  --basepath /var/cache/pbuilder/base-fuss-bookworm.cow

ed effettuare le modifiche a /etc/apt/sources.list (sostituendo <mirror> con un mirror debian opportuno, ad esempio quello già presente in /etc/apt/sources.list:

# echo 'deb <mirror> bookworm-backports main' >> /etc/apt/sources.list
# echo 'deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm main contrib' \
  >> /etc/apt/sources.list
# apt update
# exit

fino alla versione buster le istruzioni erano leggermente diverse:

# echo 'deb <mirror> buster-backports main' >> /etc/apt/sources.list
# echo 'deb http://archive.fuss.bz.it/ buster main contrib' \
  >> /etc/apt/sources.list
# apt install gnupg
# apt-key add - # incollare i contenuti di
                # https://archive.fuss.bz.it/apt.key seguiti da ctrl-d
# apt remove gnupg
# apt autoremove
# apt update
# exit

Nota

nella chroot minimale da stretch in poi non è presente gnupg, che è necessario per l’uso di apt-key add: lo installiamo per l’operazione e rimuoviamo subito dopo per essere certi che l’immagine sia sempre minimale e continuare ad accorgersi di eventuali dipendenze non esplicitate nei pacchetti che generiamo.

Ripetere la stessa cosa per le altre eventuali chroot.

Nel caso in cui le chroot siano state create da un po” di tempo è opportuno aggiornarle, coi seguenti comandi:

# cowbuilder --update --basepath /var/cache/pbuilder/base-fuss-buster.cow/
# cowbuilder --update --basepath /var/cache/pbuilder/base-fuss-bullseye.cow/
# cowbuilder --update --basepath /var/cache/pbuilder/base-fuss-bookworm.cow/

Clone e/o aggiornamento del repository

Clonare il repository del progetto desiderato:

$ git clone https://work.fuss.bz.it/git/<progetto>

Nei vecchi progetti il branch da buildare per l’upload è master, in quelli recenti fuss/* (fuss/master o altro a seconda del target), in entrambi i casi da aggiornare nel caso in cui si abbia già un clone locale del repository:

$ git checkout [fuss/]master
$ git pull

Nel caso si stia facendo una release per un pacchetto recente (pacchettizzazione in fuss/*) ricordarsi di aggiornare il branch con le modifiche che si vogliono integrare nella release.

Suggerimento

Ad esempio, per fare una release della versione di sviluppo attivo di un pacchetto recente, si inizia assicurandosi di avere la versione corrente del branch di sviluppo, master:

$ git checkout master
$ git pull

si controlla eventualmente che il numero di versione in setup.py sia corretto, ed eventualmente lo si aggiorna e committa:

$ $EDITOR setup.py
$ git add -p setup.py
[...]
$ git commit -m 'Bump version to <version>'
$ git push

si passa al branch con la pacchettizzazione, assicurandosi che anche questo sia aggiornato:

$ git checkout fuss/master
$ git pull

e si fa il merge del branch di sviluppo:

$ git merge master
$ git push

a questo punto si procede come descritto al prossimo punto aggiornando il changelog del pacchetto, eccetera.

Versionamento

Per poter pubblicare il pacchetto, è necessario incrementare il numero di versione nel file debian/changelog.

Il numero di versione da dare dipende dal tipo di pacchetto, come descritto nella sezione Policy di versionamento e nelle guide di sviluppo degli specifici pacchetti, ma nella maggior parte dei casi sarà da incrementare il patch level (es. da 10.0.5-1 a 10.0.6-1).

Nota

Nei pacchetti contenenti programmi in python è generalmente necessario mantenere aggiornato il numero di versione anche in setup.py; come per debsrc sopra questo dovrebbe essere citato nel README dei pacchetti.

Notare che l’aggiornamento del numero di versione in setup.py va effettuato nel branch di sviluppo, e non in quello di pacchettizzazione.

Il programma dch, permette di automatizzare l’editing del file debian/changelog che contiene la versione del pacchetto.

• Quando si iniziano a fare modifiche usare il comando dch -v <nuova_versione> per creare una nuova stanza ed aprire il changelog nell’editor di default.

  Verrà impostato il numero di versione richiesto e la release speciale UNRELEASED che indica che le modifiche sono ancora in lavorazione.

  Si può anche usare dch senza opzioni: in questo modo se l’ultima stanza risulta UNRELEASED il file verrà aperto così com’è, mentre se l’ultima stanza riporta una release come unstable ne viene creata una nuova incrementando il numero di versione.

  Attenzione che in quest’ultimo caso dch potrebbe non essere in grado di indovinare la versione corretta: verificare e nel caso correggere. Inoltre, nel caso in cui non si sia elencati tra i Maintainer e Uploaders in debian/control verrà aggiunta una riga Non Maintainer Upload che per noi non è rilevante e va tolta.

  Nel caso in cui più persone facciano modifiche, dch provvederà a suddividerle in sezioni intestate con il nome della persona che ha effettuato la modifica.

• Descrivere le modifiche effettuate, possibilmente indicando i ticket di riferimento da cui nascono le richieste di modifica.

• Man mano che si fanno modifiche, descriverle se necessario nel changelog, usando dch senza opzioni, come descritto sopra.

• Quando si è pronti a pubblicare il pacchetto, modificare UNRELEASED con unstable nella prima riga; questo si può fare anche con il comando dch -r.

Verifica dello stato del repository e push

Prima di effettuare la build, accertarsi di aver committato tutte le modifiche effettuate, di non avere file spuri e di essere sul branch corretto (master o fuss/* a seconda dell’età del progetto), ad esempio con il comando:

$ git status

Committare quindi eventuali modifiche rimanenti, facendo attenzione a mantenere distinte le modifiche di sviluppo da quelle di pacchettizzazione, indicando se possibile nel commit log il numero di ticket associato alla modifica, con la dicitura «refs #NUMERO»:

$ git add -p <file modificati>
$ git add <file aggiunti>
$ git commit -m "<modifiche effettuate>. refs #NumeroTicket"

Inoltre o subito prima o subito dopo la build, ma prima dell’upload, è importante pushare tali commit, in modo da essere sicuri che nel frattempo non avvengano conflitti con commit altrui:

$ git push

Build

Alcuni pacchetti, come octofussd necessitano della preventiva creazione del tar dei sorgenti originali, come specificato nel README dei rispettivi repository; in tal caso prima di eseguire il comando precedente è necessario eseguire, nella directory principale del repository:

$ debian/rules debsrc

A questo punto si può usare pdebuild per eseguire la build del pacchetto all’interno di una chroot opportuna gestita da cowbuilder (sostituendo bookworm con buster o bullseye nei casi opportuni):

$ DIST=bookworm pdebuild --use-pdebuild-internal --pbuilder cowbuilder -- --basepath /var/cache/pbuilder/base-fuss-bookworm.cow/

pdebuild provvederà autonomamente ad installare le dipendenze necessarie all’interno della chroot e ad effettuare la build.

Generalmente, l’infrastruttura di build [1] è in grado di capire dal numero di versione ed altri indizi se sia necessario o meno includere la tarball .orig tra ciò che va uploadato. Nel caso in cui però si stia effettuando un backport questo non è automatico: per il primo backport di una certa versione upstream è necessario prevedere l’inclusione della tarball sorgente con l’opzione --debbuildopts "-sa", ovvero:

$ DIST=bookworm pdebuild --buildresult ../build/ --use-pdebuild-internal --pbuilder cowbuilder --debbuildopts "-sa" -- --basepath /var/cache/pbuilder/base-fuss-bookworm.cow/

Nota

Alla fine della build si riceverà un warning cannot create regular file /var/cache/pbuilder/result/<nomepacchetto>_<versione>.dsc; questo è irrilevante e i file necessari che sono stati generati si trovano nella directory superiore a quella da cui è stato lanciato pdebuild.

[1]

In particolare, l’inclusione o meno della tarball sorgente è decisa ed effettuata da dpkg-genchanges, richiamato da dpkg-buildpackage al quale pdebuild passa le opzioni specificate con il parametro --debbuildopts.

Generalmente questo avviene in automatico, senza bisogno di preoccuparsi di chi faccia cosa.

Build con git-buildpackage

In alternativa all’uso diretto di pdebuild, ma solo per i progetti il cui repository lo supporti tramite l’uso di un branch separato per la pacchettizzazione, è possibile usare git-buildpackage (o gbp): oltre ad effettuare la build in una chroot minimale questo si assicura anche che non ci siano differenze tra quanto committato (localmente) e quanto viene usato per la build.

Per effettuare la build in questo caso è necessario spostarsi sul branch di pacchettizzazione, ad esempio:

$ git checkout fuss/master

eventualmente riportare in tale branch le modifiche effettuate su master:

$ git merge master

e quindi si può buildare, nel caso generale con:

gbp buildpackage --git-pbuilder --git-debian-branch=fuss/master \
   --git-dist=fuss-bookworm --git-no-pristine-tar

Per forzare l’inclusione della tarball sorgente dei backports, come spiegato sopra, in questo caso è sufficiente aggiungere -sa.

Test

Tramite apt install ./<nomefile>.deb si puo” installare e testare il pacchetto. Notare l’uso di ./ per specificare un file locale.

Un altro comando utile è dpkg -c <nomefile>.deb per verificare i file presenti nel pacchetto.

lintian

Uno strumento di diagnostica molto dettagliato è lintian, che analizza i pacchetti generati alla ricerca di problemi di vario tipo e si lancia con:

lintian --pedantic -Iiv <pacchetto>.changes

Un limite di questo strumento è che è basato sugli standard di Debian e in alcuni casi gli errori potrebbero essere falsi positivi per gli standard fuss.

In particolare si possono ignorare i seguenti tag.

• changelog-should-mention-nmu

• source-nmu-has-incorrect-version-number

ed altri che verranno successivamente aggiunti a questo elenco.

Upload

Per uploadare il pacchetto buildato con dput-ng è sufficiente usare il comando:

$ dput fuss-<versione> nomepacchetto_versione_arch.changes

Nel caso si voglia procedere manualmente invece si possono copiare i file generati su isolda nella directory /iso/incoming/<versione> ed aggiornare il repository con il comando:

# /iso/bin/post-upload

Verificare poi che in /iso/incoming/<versione> non siano rimasti file spuri, e nel caso cancellarli a mano.

Tagging

Nel momento in cui tutto è pronto per un upload, taggare il commit corrispondente a quanto verrà uploadato con il comando:

$ git tag -s -m 'Fuss release <versione>' fuss/<versione>

in questo modo il tag verrà firmato con la propria chiave gpg di default; per non firmare il tag:

$ git tag -a -m 'Fuss release <versione>' fuss/<versione>

Ricordarsi di effettuare il push dei tag verso il server:

$ git push --tags

Build dei pacchetti in chroot

Nel caso ci siano problemi con l’uso di cowbuilder, è anche possibile usare una semplice chroot all’interno della quale installare gli strumenti di build e clonare il pacchetto.

Setup

Per creare una chroot ed installare gli strumenti di base:

# mkdir <versione>_build
# debootstrap <versione> <versione>_build (<mirror>)
# chroot <versione>_build
# apt install debhelper devscripts dpkg-dev

dove <versione> è al momento (gennaio 2023) bookworm per FUSS server e client correnti, buster per la versione legacy del FUSS server e bullseye per quella del FUSS client.

Build

Una volta clonato il repository (dentro la chroot), incrementato il numero di versione come sopra ed eventualmente generato il tar sorgente, per eseguire il build del pacchetto eseguire, nella directory principale del repository:

# dpkg-buildpackage -us -uc

Se la procedura va a buon fine, nella directory superiore si troveranno i pacchetti .deb generati, e anche i file .changes, .dsc e .tar.gz con il sorgente del pacchetto.

La procedura potrebbe fallire con un errore contenente:

Unmet build dependencies: <pacchetto1> <pacchetto2>

in tal caso installare semplicemente i pacchetti e riprovare. Tali dipendenze sono elencate nel campo Build-Depends del file debian/control, nel caso ci si voglia assicurare di averle già installate prima di buildare.

A questo punto si può procedere con test, commit+push ed upload come nel caso generale.

Policy di versionamento

Software sviluppato per FUSS

Per i pacchetti sviluppati specificatamente per FUSS possono esserci policy specifiche indicate nella relativa guida sviluppatori e/o nei README dei progetti.

In generale, lo schema usato prevede che la major version corrisponda alla versione di fuss per cui è rilasciato il pacchetto (che a sua volta corrisponde alla versione di debian su cui è basta). Un pacchetto per FUSS 9 avrà quindi versione tipo 9.X.Y, uno per FUSS 10 10.X.Y eccetera.

I pacchetti possono essere nativi o meno: nel primo caso il numero di versione è del tipo 10.X.Y sia per il pacchetto che in setup.py, mentre nel secondo si aggiunge un numero di revisione, es. 10.X.Y-Z; quest’ultimo va incrementato quando la nuova versione presenta modifiche nella pacchettizzazione (ovvero nella directory debian), ma non nel codice.

I pacchetti nativi devono anche avere 3.0 (native) nel file debian/source/format, mentre i pacchetti non-nativi devono avere 3.0 (quilt) e per buildarli è necessario generare una tarball sorgente (<nome>_<10.X.Z>.orig.tar.gz), ad esempio tramite debsrc.

Rebuild di pacchetti di debian

Per i pacchetti presi da debian e ribuildati da noi seguiamo una convenzione simile a quella usata dai backports aggiungendo ~fussN-X al numero di versione, dove N è la versione di FUSS per la quale stiamo preparando il pacchetto e X la revisione del backport.

Se si fa una rebuild di un pacchetto che ad esempio ha versione 1.2.3-4 la nostra versione sarà 1.2.3-4~fuss10+1 (+2 per una rebuild successiva con modifiche alla sola pacchettizzazione, eccetera).

Configurazione del repository

Il file /iso/repo/conf/distributions definisce le distribuzioni utilizzate nel repository, con snippet di configurazione come:

Origin: FUSS
Label: FUSS
Suite: bookworm
Codename: bookworm
Version: 10.0
Architectures: i386 amd64 source
Components: main contrib
Description: FUSS 10.0
SignWith: C00D47EF47AA6DE72DFE1033229CF7A871C7C823

inoltre nello stesso file sono definite le versioni precedenti e future della distribuzione. Al momento attuale la configurazione riguarda fino alla versione 12 di Debian (codename bookworm).

Le varie distribuzioni sono raggiungibili da apt usando, in /etc/apt/sources.list:

deb http://archive.fuss.bz.it CODENAME_DISTRIBUZIONE main contrib

e la chiave con la quale viene firmato il repository si può installare su una macchina debian o derivate eseguendo, da root:

# wget -qO /usr/share/keyrings/fuss-keyring.gpg https://archive.fuss.bz.it/apt.key

Aggiunta di nuova distribuzione e/o nuovo repository

Oltre al file /iso/repo/conf/distributions per indicare la nuova distribuzione e/o nuovo repository, è necessario:

• Creare una cartella per lo spool di incoming dei pacchetti in /iso/incoming/<nuova distribuzione>

• Aggiungere la descrizione e il path relativo al punto precedente nel file /iso/repo/conf/incoming

• Aggiungere allo script /iso/bin/post-upload l’esecuzione del processing del nuovo path di incoming. In questo script vanno tolte quelle non più usate quando è certo che non ci saranno più nuovi pacchetti per una specifica distribuzione.

Copia di pacchetti tra distribuzioni diverse

reprepro permette di copiare dei pacchetti già caricati per una distribuzione in una distribuzione diversa; questo è utile ad esempio per portare un pacchetto da <distro>-proposed-updates a <distro> una volta che si è appurato il corretto funzionamento.

Il comando è:

root@isolda:/iso/repo# reprepro copy bookworm bookworm-proposed-updates <nome_pacchetto>

dove si deve fare attenzione che la prima distribuzione specificata è quella di destinazione, seguida dalla distribuzione di origine.

Verifica delle versioni presenti sul repository

Per sapere che versioni di un pacchetto sono presenti in che distribuzione basta usare il comando:

reprepro ls <nomepacchetto>

Pacchettizzazione gestita con git

Come descritto nelle istruzioni, nei progetti più recenti si è adottata una delle convenzioni in uso in Debian per la pacchettizzazione basata su git.

• I branch di sviluppo del progetto, incluso master non contengono la directory debian, come da raccomandazione della UpstreamGuide di Debian.

• I branch il cui nome inizia per fuss/ contengono la directory debian; generalmente il branch usato per gli upload della versione corrente sarà fuss/master.

• Ad ogni rilascio, il branch master viene mergiato in fuss/master (ma mai il contrario) e il pacchetto può essere generato con i metodi descritti sopra.

Nel caso si voglia effettuare la build con gbp (pacchetto git-buildpackage il comando da usare sarà:

gbp buildpackage \
--git-pbuilder \
--git-no-pristine-tar \
--git-debian-branch=fuss/<versione> \
--git-dist=fuss-bookworm

aggiungendo --git-export=WC per fare build di prova dello stato attuale della working directory (anziché dello stato all’ultimo commit) oppure --git-ignore-new per fare una build corrispondente all’ultimo commit, ignorando le modifiche eventualmente presenti.

Configurazioni standard e nuovi pacchetti

Maintainer

Il campo Maintainer di debian/control deve avere come valore FUSS team <packages@fuss.bz.it>, in modo da indicare che il pacchetto è manutenuto da un team.

Pacchetti particolari

coova-chilli

Il pacchetto coova-chilli presente su archive.fuss.bz.it è generato da un nostro repository https://gitlab.fuss.bz.it/fuss/coova-chilli/ copia del repository upstream https://github.com/coova/coova-chilli.git alla quale abbiamo aggiunto alcune modifiche di pacchettizzazione.

In particolare, per la release 1.6 è presente un branch 1.6-patched basato sul tag upstream 1.6 con l’aggiunta dell’opzione di compilazione --enable-wpad, necessaria per il corretto funzionamento del fuss-server.

Per effettuare nuove build della versione 1.6 è quindi necessario usare il branch 1.6-patched, mergiandovi eventuali modifiche upstream desiderate; usando git-buildpackage si dovrà usare:

$ gbp buildpackage --git-debian-branch=1.6-patched [--git-pbuilder]

Per versioni successive si deve creare un branch simile dai tag upstream, riportando le modifiche ancora necessarie.

Altri branch presenti sul nostro repository contengono la pacchettizzazione per versioni precedenti di FUSS, di utilità solo storica.

gspeech

Il pacchetto di gspeech presente su archive.fuss.bz.it deriva direttamente dalla pacchettizzazione presente sul repository upstream, da cui prendere eventuali versioni aggiornate. È stata aggiunta soltanto una stanza con il nostro numero di versione, tipo:

gspeech (0.9.2.0-1) buster; urgency=medium

  * Rebuild for FUSS 10

 -- Elena Grandi <elena@truelite.it>  Tue, 02 Feb 2021 13:42:20 +0100

avendo cura di incrementare il numero di versione rispetto alle precedenti.

Vedere anche

• https://wikitech.wikimedia.org/wiki/Reprepro#HOWTO

Appunti su Git

Lo sviluppo di fuss viene gestito tramite repository git pubblicati sull’istanza gitlab https://gitlab.fuss.bz.it. Per le basi dell’uso di git si rimanda ai link presenti nella sezione Vedere anche, ma questo documento contiene indicazioni su come svolgere alcuni compiti specifici.

Branch per il supporto di più distribuzioni

Lo sviluppo nel branch master si riferisce sempre alla distribuzione più recente tra quelle supportate per quel pacchetto; qualora vengano supportate anche distribuzioni più vecchie tale supporto avviene in un branch chiamato con il nome della distribuzione (ad esempio buster).

Avvertimento

In alcuni pacchetti il nome del branch è ancora nella forma fuss/<distribuzione>: questo è da evitare, perché conflitta con il nome del branch usato per la pacchettizzazione in un branch separato, ma ancora non è stato interamente uniformato.

Modifiche da applicare a tutte le distribuzioni

Nel caso in cui si debbano fare modifiche che devono essere presenti in tutte le versioni, la buona pratica è di effettuare la modifica nella versione più recente (branch master), la si committi e quindi si faccia il cherry pick del commit sul branch delle versioni più vecchie.

Ad esempio, essendo nella seguente situazione:

fuss-foo (master)$ git log --graph --abbrev-commit --pretty=oneline
* 7bc3fd2 (HEAD -> master) Start working on bullseye
* 0f46c37 (buster) Readme for the fuss-foo project

Si fa una modifica, la si committa con il comando:

fuss-foo (master)$ git commit -m 'Add project description.'

E ci si trova nella situazione seguente:

fuss-foo (master)$ git log --graph --abbrev-commit --pretty=oneline
* 36c12d2 (HEAD -> master) Add project description.
* 7bc3fd2 Start working on bullseye
* 0f46c37 (buster) Readme for the fuss-foo project

A questo punto passiamo sul branch della vecchia distribuzione, e facciamo cherry-pick del commit, ovvero lo copiamo nel nuovo branch:

fuss-foo (master)$ git checkout buster
fuss-foo (buster)$ git cherry-pick 36c12d2
Auto-merging README.rst
CONFLICT (content): Merge conflict in README.rst
error: could not apply 36c12d2... Add project description.
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".

Purtroppo non è andato tutto bene e la modifica non si applica in modo pulito; apriamo il file README.rst e troviamo quanto segue:

Fuss FOO
========

<<<<<<< HEAD
This is FOO for buster
=======
This is FOO for bullseye

It is an example project.
>>>>>>> 36c12d2 (Add project description.)

risolviamo il conflitto manualmente, portando i contenuti ad essere:

Fuss FOO
========

This is FOO for buster

It is an example project.

e infine proseguiamo il cherry-pick come suggerito dal messaggio di errore:

fuss-foo (buster)$ git add README.rst
fuss-foo (buster)$ git cherry-pick --continue
[...]
[buster c21a51e] Add project description.
 Date: Fri Jun 10 11:03:35 2022 +0200
 1 file changed, 2 insertions(+)

Confermando il messaggio di commit nell’editor che si è aperto.

A questo punto la situazione è diventata:

fuss-foo (buster)$ git log --graph --abbrev-commit --pretty=oneline --all
* c21a51e (HEAD -> buster) Add project description.
| * 36c12d2 (master) Add project description.
| * 7bc3fd2 Start working on bullseye
|/
* 0f46c37 Readme for the fuss-foo project

che è quanto desideravamo.

Nota

Nella maggior parte dei casi git è abbastanza furbo ed è raro trovarsi nella situazione sopra in cui il cherry-pick richiede intervento manuale per risolvere conflitti, tranne che in un caso specifico: il file debian/changelog.

Se si tiene la pacchettizzazione debian dentro ad un branch separato questo non è un problema, ma se si ha ancora la pacchettizzazione assieme al codice, ci si trova in una situazione in cui non c’è una buona soluzione.

Se si mettono le modifiche a debian/changelog nello stesso commit in cui le modifiche sono state fatte si ottiene una storia del repository più pulita, ma si ha la certezza di trovare a dover risolvere un conflitto in fase di cherry-pick.

Committare invece debian/changelog a parte previene quei conflitti, ma lascia una storia più sporca, con almeno due commit per ciascuna modifica: non è un gran problema quando ad una riga di changelog corrispondono magari una decina di commit di uno sviluppo importante, ma quando una riga di changelog corrisponde ad un solo semplice commit, come spesso è il caso, può essere fastidioso.

Vedere anche

• Pro Git di Scott Chacon libro consultabile online.

• Git Happens di Jessica Kerr video di un talk introduttivo a git.

Metapacchetti

La distribuzione FUSS comprende alcuni metapacchetti per semplificare l’installazione di programmi didattici o comunque utili in ambito scolastico, gestiti nel progetto fuss-software

Repository

Il repository dei metapacchetti si può clonare con:

$ git clone https://work.fuss.bz.it/git/fuss-software

Il branch master si riferisce all’ultima release di FUSS, le versioni precedenti sono nei branch chiamati con il codename della distribuzione relativa.

Modifica dei metapacchetti

I file della cartella metapackages si riferiscono al metapacchetto con lo stesso nome e contengono le dipendenze, una per riga e preferibilmente in ordine alfabetico.

Avvertimento

Le dipendenze devono essere presenti all’interno dei repository configurati, altrimenti il pacchetto non sarà più installabile.

A luglio 2018 questo significa che i pacchetti che si desidera installare devono essere presenti in Debian 9 “stretch” nelle sezioni main e contrib.

Numero di versione

La major version dei metapacchetti deve rispecchiare la versione della distribuzione Debian utilizzata; ad esempio un pacchetto per la versione “stretch” avrà come major version 9.

Il patch level va aumentato di uno ad ogni versione, come di consueto.

I metapacchetti sono nativi, quindi non deve essere presente una versione debian, ma solo le tre componenti MAJOR.MINOR.PATCH.

Per build del pacchetto e upload delle modifiche vedere Pacchetti e Repository

FUSS Server

fuss-server è uno script python che lancia un playbook ansible che configura una macchina per poter funzionare come server in una rete FUSS.

fuss-server

Lo script fuss-server è scritto per essere compatibile con python 2 e 3; nel momento in cui ansible passerà ad usare python 3 si potrà eliminare la compatibilità python 2.

I vari sottocomandi corrispondono alle funzioni con lo stesso nome e generalmente si concludono con l”os.execvp di un comando di shell per lanciare ansible; notare che questo termina l’esecuzione del programma python, eventuale codice successivo non viene eseguito.

Playbook

Ansible viene chiamato con uno dei seguenti playbook, a seconda del sottocomando usato:

create.yml

per configurare da zero un fuss-server.

upgrade.yml

per aggiornare la configurazione di un fuss-server.

captive_portal.yml

per applicare la configurazione aggiuntiva necessaria sui captive portal.

purge.yml

per eliminare la configurazione del fuss-server.

Quest’ultimo ripristina alcuni file di configurazione dai backup, gli altri non compiono direttamente azioni, ma richiamano ruoli dalla directory roles, in modo da poter condividere il codice, in particolare tra create e upgrade.

Pacchetti Debian

Il repository prevede la generazione di due pacchetti .deb, fuss-server e fuss-server-dependencies; il primo contiene il fuss-server vero e proprio, mentre il secondo è un metapacchetto che dipende da tutti i pacchetti installati dal playbook ansible.

fuss-server-dependencies non è necessario per l’uso di fuss-server, ma è aggiunto per comodità per pre-installare (e soprattutto pre-scaricare) tutti i pacchetti necessari.

Per le istruzioni su come buildare i pacchetti e caricarli su archive.fuss.bz.it si può vedere l’articolo Pacchetti e Repository

Numeri di versione

Il pacchetto fuss-server è nativo, quindi il numero di versione è del tipo X.Y.Z dove X è il numero di versione debian corrispondente (ad esempio 8 per jessie, 9 per stretch, 10 per buster).

Dipendenze

Alcune delle dipendenze del pacchetto fuss-server, in particolare ansible (nella versione richiesta) e python-ruamel.yaml sono disponibili solo in jessie-backports; per installare il pacchetto è necessario aver abilitato quel repository, e per usarlo è necessario avere anche il repository di FUSS.

FUSS Client

fuss-client è uno script python che lancia un playbook ansible che configura una macchina come client in una rete FUSS.

fuss-client

Lo script fuss-client è scritto per python 3.

Le opzioni -a | -U | -r | -l sono mutualmente esclusive e corrispondono rispettivamente ai metodi add, upgrade, remove e listavail; ad eccezione di quest’ultimo si concludono con l”os.execvp di un comando di shell per lanciare ansible; notare che questo termina l’esecuzione del programma python, eventuale codice successivo non viene eseguito.

Prima della configurazione, l’opzione -a ricerca e contatta un fuss-server (metodi _test_connection e _get_cluster) per aggiungere la macchina corrente ad un cluster, tramite l’api di octofuss.

Notare che non esiste un’api corrispondente per rimuovere una macchina da un cluster, operazione che va svolta lato server.

Il passo successivo è la generazione di una chiave kerberos per il client: questa operazione viene svolta sul server dallo script add_client_principal, richiamato tramite ssh, quindi la chiave viene copiata localmente tramite scp. Per l’autenticazione sul server, sono supportati vari casi: accesso come root, accesso come utente con permessi sudo, oppure accesso con chiave con permessi limitati alle sole operazioni necessarie per lo script.

Playbook

Ansible viene chiamato con uno dei seguenti playbook, a seconda del sottocomando usato:

connect.yml

per configurare un fuss-client

remove.yml

per eliminare la configurazione del fuss-client.

Quest’ultimo ripristina alcuni file di configurazione dai backup, il primo non compie direttamente azioni, ma richiama ruoli dalla directory roles.

Compatibilità raspbian

Alcuni task, ed in particolare quelli relativi a lightdm, non vanno eseguiti quando la distribuzione base non è fuss-client (o una normale Debian), ma Raspbian, che richiede alcune personalizzazioni specifiche; per questi si usa la condizione when: ansible_lsb.id != "Raspbian".

Pacchetti Debian

Il repository prevede la generazione di due pacchetti .deb, fuss-client e fuss-client-dependencies; il primo contiene il fuss-client vero e proprio, mentre il secondo è un metapacchetto che dipende da tutti i pacchetti installati dal playbook ansible.

fuss-client-dependencies non è necessario per l’uso di fuss-client, ma è aggiunto per comodità per pre-installare (e soprattutto pre-scaricare) tutti i pacchetti necessari.

Numeri di versione

Il pacchetto fuss-client è nativo, quindi il numero di versione è del tipo X.Y.Z dove X è il numero di versione debian corrispondente (ad esempio 8 per jessie, 9 per stretch, 10 per buster).

HOWTO

Script all’avvio

Per installare su fuss-client degli script che vengano eseguiti all’avvio il metodo raccomantato è di usare delle unit systemd.

Per farlo, installare lo script desiderato in /usr/local/bin (o sbin, se ha senso che venga eseguito solo da root), ad esempio come /usr/local/bin/my_script.sh con permessi di esecuzione, quindi creare il file /etc/systemd/system/my-script.service con i seguenti contenuti:

[Unit]
Description=My script doing things
After=network.target

[Service]
ExecStart=/usr/local/bin/my_script.sh

[Install]
WantedBy=multi-user.target

ed abilitare la unit.

In ansible, serviranno dei task tipo i seguenti:

- name: Script to do things
  copy:
      dest: /usr/local/bin/my_script.sh
      src: my_script.sh
      mode: 0755
- name: Do things at startup
  copy:
      dest: /etc/systemd/system/my-script.service
      src: my-script.service
- name: Enable doing things at startup
  systemd:
      enabled: yes
      name: do-things

Creazione dell’immagine cloud-init

A partire da FUSS 10 (Debian Buster) si genereranno delle immagini complete per macchina virtuale del server nel formato dei dump della piattaforma Proxmox adottata dal progetto, in modo da semplificare l’installazione e la configurazione iniziale di un FUSS server.

Le immagini si appoggiano a cloud-init in modo da consentire la gestione della rete direttamente dall’interfaccia web, una volta che le si siano importate e gli si sia associato un volume per cloud-init (i dettagli sono illustrati nella fuss-tech-guide.

Creazione macchina virtuale

Si crei una nuova macchina virtuale (VM) su Proxmox, in fase iniziale è sufficiente l’interfaccia di rete singola creata dal wizard, si usi il bridge associato alla rete esterna.

Sulla macchina virtuale si deve fare una installazione ordinaria di Debian con netinstall (ci si procuri l’ultima versione della ISO e la si carichi dentro /var/lib/vz/template/iso):

# cd /var/lib/vz/template/iso/
# wget https://cdimage.debian.org/cdimage/bookworm_di_rc4/amd64/iso-cd/debian-bookworm-DI-rc4-amd64-netinst.iso

Nella creazione si utilizzi la precedente immagine come CDROM e per il resto si usino i valori di default per tutto, compresi i 32 G di dimensione del disco, avendo però cura di fare installare quest’ultimo sullo storage local in formato qcow (che consente eventualmente di distribuire direttamente il file che si otterrà come immagine del disco per l’uso da parte di altre piattaforme).

Una volta completato il wizard, aggiungere la seconda interfaccia per la rete interna, e la eventuale terza per il captive portal, ed assicurarsi che sia queste che la prima interfaccia non abbiano spunta per l’uso del firewall.

Inoltre, modificare il disco ed attivare la spunta di Discard.

Installare Debian

Si esegua l’installazione in maniera ordinaria; per la rete si può anche usare un eventuale DHCP, la configurazione scelta in fase di installazione verrà comunque sovrascritta da quella che si imposterà in fase di deploy con cloud-init.

Le operazioni specifiche che occorre fare in fase di installazione sono:

• si imposti per root la password di default: fuss

• si usi un utente normale: fuss (o altro, andrà comunque cancellato)

• si configuri la rete nella maniera più semplice per accedere sulla macchina

• scegliere il partizionamento manuale del disco,

  • creare una prima partizione primaria di 4G come swap

  • creare una seconda partizione primaria con resto del disco come radice

• nella schermata Selezione del software scegliere solo Server SSH e Utilità di sistema standard (il resto si installerà dopo).

Preparazione dell’installazione base

Una volta completata l’installazione base si potrà passare a preparare il server. Dato che l’installazione di default blocca l’accesso in SSH a root, o si usa l’utente normale provvisorio creato in fase di installazione e si usa su o sudo, o ci si collega sulla console via web. Tutte le operazioni seguenti sono da eseguirsi dall’utente root.

Il primo passo è abilitare da subito l’accesso di SSH a root, inserendo dentro /etc/ssh/sshd_config.d/root.conf:

# enable root password access
PermitRootLogin yes

e riavviare sshd con service ssh restart; non è necessario configurare in questa fase l’uso di chiavi in authorized_keys, queste possono essere impostate in qualunque momento successivo tramite cloud-init.

Si rimuova poi l’utente creato in fase di installazione con:

# userdel -r fuss

Occorrerà anzitutto installare cloud-init ed alcuni programmi:

• gnupg per poter importare le chiavi di APT di FUSS;

• resolvconf per poter gestire la configurazione del DNS attraverso cloud-init;

• bind9 per poter configurare da subito la macchina in modalità compatibile con la configurazione che verrà impostata da fuss-server

• quotatool per attivare le quote nel caso si aggiunga un disco separato per le home;

# apt install cloud-init gnupg resolvconf bind9 quotatool

Per evitare i problemi di risoluzione con indirizzi IPv6 che si sono verificati in alcuni casi, è opportuno che Bind sia configurato da subito per usare solo IPv4, pertanto si modifichi in /etc/default/named l’ultima riga in:

OPTIONS="-4 -u bind"

e si riavvii Bind con systemctl restart named.

Occorre poi configurare opportunamente /etc/apt/sources.list per usare i repository di fuss, si utilizzi un contenuto analogo al seguente:

# bookworm sources
deb http://deb.debian.org/debian/ bookworm main
deb-src http://deb.debian.org/debian/ bookworm main

deb http://security.debian.org/debian-security bookworm-security main
deb-src http://security.debian.org/debian-security bookworm-security main

# fuss-sources
deb [signed-by=/etc/apt/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm main
#deb [signed-by=/etc/apt/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm-proposed-updates main

(in genere basta aggiungere le ultime due righe), inoltre si deve importare la chiave GPG di firma dei pacchetti, con:

# wget -qO - https://archive.fuss.bz.it/apt.gpg | gpg --dearmor > /etc/apt/keyrings/fuss-keyring.gpg

Con il passaggio a Debian Buster e seguenti di default le interfacce di rete assumono i nuovi nomi dipendenti dall’hardware, per cui al posto di eth0 ed eth1 si avranno nomi come ens18 o ens19. La configurazione delle stesse con cloud-init riporta però automaticamente in uso i nomi tradizionali, per cui non serve preoccuparsi di questo cambiamento nelle configurazioni, con una eccezione: la eventuale terza interfaccia dedicata al captive portal, che non deve essere configurata.

Non essendo configurata questa prenderà il nome di default, variando rispetto a quello che si avrebbe con una Debian Jessie. Si può però evitare il cambiamento (consentendo il riutilizzo senza cambiamenti dei nomi usati in un precedente fuss-server.yaml) configurando opportunamente le opzioni di avvio del kernel, inserendo in /etc/default/grub la riga:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

ed eseguendo update-grub; in questo modo le interfacce verranno comunque chiamate eth0, eth1 ed eth2.

Infine per evitare che la voce di configurazione per lo presente in /etc/network/interfaces sovrascriva la stessa voce che cloud-init configura con un suo file sotto /etc/network/interfaces.d (50-cloud-init.cfg) si sposti la riga che include le configurazioni da questa directory in fondo al file, in sostanza /etc/network/interfaces dovrà essere qualcosa del tipo:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

source /etc/network/interfaces.d/*

Nota

si tenga presente che con questo /etc/network/interfaces non verrà configurata automaticamente nessuna interfaccia di rete, e se non si configura la stessa via cloud-init la macchina risulterà raggiungibile solo sulla console, pertanto se vi si deve accedere via rete per lavorarci sopra prima di creare l’immagine di cloud-init si lasci presente la configurazione dell’interfaccia che si intende utilizzare, rimuovendola nella fase di pulizia.

Nota

si tenga presente che con questa configurazione si gestisce il contenuto di /etc/resolv.conf con cloud-init, ma questo file viene anche scritto direttamente dal comando fuss-server, per cui si abbia cura di impostare via cloud-init lo stesso nome a dominio che si imposterà poi nel fuss-server e di indicare sempre come server DNS 127.0.0.1.

Configurazione di cloud-init

La configurazione di default installata da cloud-init prevede la creazione di un utente di default ed il blocco dell’accesso come root. La scelta del progetto è di fornire un accesso diretto a root a chiavi, con la possibilità di usare una password, per questo vanno fatte alcune modifiche in /etc/cloud/cloud.cfg. Anzitutto si devono cambiare le due righe relative alla gestione degli utenti locali creati di default come nell’esempio seguente:

# A set of users which may be applied and/or used by various modules
# when a 'default' entry is found it will reference the 'default_user'
# from the distro configuration specified below
users:
   - name: root

e poi bisogna evitare che venga applicata la configurazione che disabilita l’uso dell’utente root, configurando disable_root a false come in:

# If this is set, 'root' will not be able to ssh in and they
# will get a message to login instead as the above $user (debian)
disable_root: false

infine si aggiungano poi in coda al file la ulteriore configurazione che consente a cloud-init di gestire /etc/hosts:

manage_etc_hosts: true

Si aggiunga poi sotto /etc/cloud/cloud.cfg.d/ il file 10_fuss.cfg, con il contenuto seguente (attenzione: le spaziature non devono contenere tabulazioni):

apt:
    preserve_sources_list: true
packages:
  - fuss-server

Pulizia

Una volte effettuate le configurazioni precedenti si proceda a ripulire l’immagine da tutti i dati spuri, ci si sconnetta e ci si riconnetta eseguendo il comando:

# set +o history

per disabilitare la history.

Se si è lasciato la configurazione dell’interfaccia di rete principale usata in fase di installazione dentro /etc/network/interfaces la si rimuova.

Si eseguano poi (come root) i comandi:

> .bash_history
apt clean
find /etc -name "*~" -delete
journalctl --rotate
journalctl --vacuum-time=1s
fstrim /
cd /var/log/
> syslog
> auth.log
> cloud-init.log
> cloud-init-output.log
> debug
> dpkg.log
> messages
> kern.log
> user.log
> daemon.log
> installer/syslog
> wtmp
> btmp

per fare una pulizia finale, compreso ricreare vuoti i file modificati dal sistema mentre era in uso.

Generazione dell’immagine

Una volte effettuate le configurazioni precedenti, si fermi la macchina virtuale e se ne esegua un backup, chiedendo la compressione (coi valori predefiniti in formato zst). Si troverà il file del backup sotto /var/lib/vz/dump (o nella directory che si è configurato come storage di backup) nella forma:

vzdump-qemu-VMID-ANNO_ME_GI-OR_MI_SE.vma.zst

Pubblicazione

Dopo eventuali test, caricare il file sulla macchina dove verrà pubblicato, ad esempio nella home dell’utente root con il comando:

$ scp /var/lib/vz/dump/vzdump-qemu-106-2023_06_05-16_06_42.vma.zst \
      root@iso.fuss.bz.it:

quindi collegarsi alla macchina stessa (ssh root@iso.fuss.bz.it) e lanciare il comando:

# cd /root
# ./release_cloud_image.sh vzdump-qemu-106-2023_06_05-16_06_42.vma.zst

che provvede a spostare il file nella destinazione corretta e generarne checksum e relative firme.

Quindi aggiornare il file /var/www/iso/cloud-init/changelog.txt con l’elenco delle modifiche presenti nella release corrente.

L’immagine è ora disponibile per lo scaricamento su https://iso.fuss.bz.it/cloud-init/

ISO FUSS 9

In FUSS 9 (Debian stretch) le ISO live (complete di installer testuale e grafico) si generavano usando live-wrapper.

Vengono usate le versioni presenti in Debian buster, ovvero ad agosto 2018:

live-wrapper (0.7)
vmdebootstrap (1.11-1)

Build

Setup

• Su un’installazione di Debian buster o successive, installare live-wrapper:

  # apt install live-wrapper
  

• Copiare il file /usr/share/live-wrapper/customise.sh:

  # cp /usr/share/live-wrapper/customise.sh fuss-customise.sh
  

  sotto alla riga:

  . /usr/share/vmdebootstrap/common/customise.lib
  

  aggiungere:

  # overriden from the above for FUSS
  prepare_apt_source() {
      # handle the apt source
      mv ${rootdir}/etc/apt/sources.list.d/base.list ${rootdir}/etc/apt/
      echo "deb $1 $2 main contrib non-free" > ${rootdir}/etc/apt/sources.list
      echo "deb-src $1 $2 main contrib non-free" >> ${rootdir}/etc/apt/sources.list
      echo "deb http://archive.fuss.bz.it/ stretch main" >> ${rootdir}/etc/apt/sources.list
      wget -qO ${rootdir}/tmp/fuss-apt.key https://archive.fuss.bz.it/apt.key
      chroot ${rootdir} apt-key add /tmp/fuss-apt.key
      chroot ${rootdir} apt -qq -y update > /dev/null 2>&1
  }
  

Build

Per generare la ISO di FUSS 9 per architettura amd64, lanciare il seguente comando:

lwr -o fuss9-live-amd64.iso -d stretch --architecture=amd64 --customise=./fuss-customise.sh -m http://ftp.de.debian.org/debian/ -e "fuss-client fuss-kids fuss-children fuss-education fuss-graphics fuss-language-support fuss-multimedia fuss-extra-multimedia fuss-net fuss-office fuss-various"

Per generare la ISO di FUSS 9 per architettura i386, lanciare il seguente comando:

lwr -o fuss9-live-i386.iso -d stretch --architecture=i386 --customise=./fuss-customise.sh -m http://ftp.de.debian.org/debian/ -e "fuss-client fuss-kids fuss-children fuss-education fuss-graphics fuss-language-support fuss-multimedia fuss-extra-multimedia fuss-net fuss-office fuss-various"

Vedi anche

• https://live-wrapper.readthedocs.io/en/latest/

• https://wiki.debian.org/vmdebootstrap

ISO FUSS 10

Con FUSS 10, il tool adottato per personalizzare una immagine ISO esistente si chiama remaster-iso (https://github.com/unixabg/remaster-iso).

Creare la ISO live di FUSS

remaster-iso è disponibile come pacchetto solo a partire da Debian 11 «bullseye». Se si lavora con Debian 10 è necessario, peretanto, clonare il progetto remaster-iso da GitHub e spostarsi nella cartella creata:

git clone https://github.com/unixabg/remaster-iso.git
cd remaster-iso

Di seguito viene mostrato come personalizzare l’immagine di Debian Live amd64 Xfce reperibile da https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-10.10.0-amd64-xfce.iso con

wget https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-10.10.0-amd64-xfce.iso

Qualora servissero anche i firmware non-free, l’immagine dalla quale partire è la seguente: https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/current-live/amd64/iso-hybrid/debian-live-10.10.0-amd64-xfce+nonfree.iso ed il comando da dare per scaricarla è:

wget https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/current-live/amd64/iso-hybrid/debian-live-10.10.0-amd64-xfce+nonfree.iso

Modificare il file di configurazione remaster-iso.conf. Di seguito un esempio:

######################
## remaster settings
######################
_BASEDIR=$(pwd)
_ISOExtractPath="${_BASEDIR}/iso-extract"
_ISOLivePath="live"
_ISOMountPoint="${_BASEDIR}/iso-mount"
_ISOName=""
_ISOTargetName="fuss-10-amd64-live-light"
_ISOTargetTitle="FUSS 10 amd64 live light"

_VER="0.9.4"

Estrarre il file .iso

./remaster-extract -i debian-live-10.10.0-amd64-xfce.iso

Lanciare poi il comando remaster-squashfs-editor e selezionare «C» premendo INVIO:

./remaster-squashfs-editor

#################################
    remaster-squashfs-editor
    remaster-iso version 0.9.3
#################################
  (C)hroot - Chroot in to the filesystem.squashfs + psu-*.squashfs stack.
  (J)oin   - Join the partial squashfs update files to new single psu-DATE.squashfs
  (N)ew    - New master filesystem.squashfs file which joins all *.squashfs file to new single filesystem.squashfs
  E(x)it   - Exit the program with no action
Enter choice [C , J , N , X] C

Modifiare il file dei repository se necessario

nano /etc/apt/sources.list

# ##### Debian Main Repos
deb http://ftp.it.debian.org/debian/ buster main
deb-src http://ftp.it.debian.org/debian/ buster main

deb http://ftp.it.debian.org/debian/ buster-updates main
deb-src http://ftp.it.debian.org/debian/ buster-updates main

deb http://security.debian.org/debian-security buster/updates main
deb-src http://security.debian.org/debian-security buster/updates main

deb http://ftp.debian.org/debian buster-backports main
deb-src http://ftp.debian.org/debian buster-backports main

# ##### FUSS Main Repo
deb http://archive.fuss.bz.it/ buster main
deb-src http://archive.fuss.bz.it/ buster main

Se servono anche pacchetti contrib e non-free, il file dev’essere

# ##### Debian Main Repos
deb http://ftp.it.debian.org/debian/ buster main contrib non-free
deb-src http://ftp.it.debian.org/debian/ buster main contrib non-free

deb http://ftp.it.debian.org/debian/ buster-updates main contrib non-free
deb-src http://ftp.it.debian.org/debian/ buster-updates main contrib non-free

deb http://security.debian.org/debian-security buster/updates main contrib non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib non-free

deb http://ftp.debian.org/debian buster-backports main contrib non-free
deb-src http://ftp.debian.org/debian buster-backports main contrib non-free

# ##### FUSS Main Repo
deb http://archive.fuss.bz.it/ buster main contrib non-free
deb-src http://archive.fuss.bz.it/ buster main contrib non-free

Aggiornare i pacchetti

apt update
apt install curl wget apt-transport-https dirmngr
wget -qO - https://archive.fuss.bz.it/apt.key | sudo apt-key add -
apt update && apt full-upgrade

Installare fuss-client

apt install fuss-client

Lanciare il comando per la configurazione di FUSS standalone (desktop)

fuss-client --iso --standalone [--light] [--unofficial] [--locale=LOCALE] --domain fuss.bz.it

dove

• --light mantiene l’immagine leggera senza installare i metapacchetti didattici;

• --unofficial permette di installare i firmware non-free di debian;

• --locale=LOCALE permette di scegliere la lingua di default, dove LOCALE è, a titolo d’esempio, nella forma de_DE.UTF-8.

Scaricare la chiave del repository archive.fuss.bz.it che verrà utilizzata da Calamares (https://calamares.io/) durante l’installazione:

curl https://archive.fuss.bz.it/apt.key | gpg --dearmor > /usr/share/keyrings/fuss-keyring.gpg

Modificare lo script /usr/sbin/sources-final che scriverà i repository durante l’installazione:

#!/bin/sh
#
# Writes the final sources.list files
#

CHROOT=$(mount | grep proc | grep calamares | awk '{print $3}' | sed -e "s#/proc##g")
RELEASE="buster"
FUSS_KEY="/usr/share/keyrings/fuss-keyring.gpg"

cat << EOF > $CHROOT/etc/apt/sources.list
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian $RELEASE main
deb-src http://deb.debian.org/debian $RELEASE main

deb http://deb.debian.org/debian $RELEASE-updates main
deb-src http://deb.debian.org/debian $RELEASE-updates main

deb http://security.debian.org/debian-security/ $RELEASE/updates main
deb-src http://security.debian.org/debian-security/ $RELEASE/updates main
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/deb_debian_org_debian.list
deb http://deb.debian.org/debian $RELEASE-backports main
deb-src http://deb.debian.org/debian $RELEASE-backports main
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/archive_fuss_bz_it.list
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main contrib
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main contrib
EOF

if [ -f $FUSS_KEY ] ; then
    cp $FUSS_KEY $CHROOT/usr/share/keyrings/fuss-keyring.gpg
fi

exit 0

Per le immagini unofficial il file dev’essere

#!/bin/sh
#
# Writes the final sources.list files
#

CHROOT=$(mount | grep proc | grep calamares | awk '{print $3}' | sed -e "s#/proc##g")
RELEASE="buster"
FUSS_KEY="/usr/share/keyrings/fuss-keyring.gpg"

cat << EOF > $CHROOT/etc/apt/sources.list
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian $RELEASE main contrib non-free
deb-src http://deb.debian.org/debian $RELEASE main contrib non-free

deb http://deb.debian.org/debian $RELEASE-updates main contrib non-free
deb-src http://deb.debian.org/debian $RELEASE-updates main contrib non-free

deb http://security.debian.org/debian-security/ $RELEASE/updates main contrib non-free
deb-src http://security.debian.org/debian-security/ $RELEASE/updates main contrib non-free
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/deb_debian_org_debian.list
deb http://deb.debian.org/debian $RELEASE-backports main contrib non-free
deb-src http://deb.debian.org/debian $RELEASE-backports main contrib non-free
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/archive_fuss_bz_it.list
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main contrib contrib non-free
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main contrib contrib non-free
EOF

if [ -f $FUSS_KEY ] ; then
    cp $FUSS_KEY $CHROOT/usr/share/keyrings/fuss-keyring.gpg
fi

exit 0

Rimuovere i pacchetti inutilizzati e ripulire la cache pacchetti

apt-get autoremove
apt-get clean

Configurare la live

nano /etc/live/config.conf.d/fuss.conf

LIVE_HOSTNAME="fuss"
LIVE_USERNAME="user"
LIVE_USER_FULLNAME="FUSS Live user"
LIVE_LOCALES="en_US.UTF-8,it_IT.UTF-8,de_AT.UTF-8"
LIVE_TIMEZONE="Europe/Rome"
LIVE_KEYBOARD_LAYOUTS="it,de"

Cambiare l’hostname di default

nano /etc/hostname

fuss

Per prendere le impostazioni del pannello come previsto da FUSS, modificare una riga dello script /lib/live/config/1170-xfce4-panel:

nano /lib/live/config/1170-xfce4-panel

sudo -u "${LIVE_USERNAME}" cp /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml /home/"${LIVE_USERNAME}"/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml

Qualora servisse, nella cartella /lib/live/config ci sono tutti gli script richiamati dalla live per le diverse configurazioni. Come documentazione c’è la man page di live-config dov’è tutto abbastanza ben documentato.

Uscire e salvare le modifiche fatte in chroot digitando Y ed invio

root@jarvis:~# exit
Exited the chroot so time to clean up.
Restore original overlay/etc/hosts.
Restore overlay/etc/resolv.conf.
Remove overlay/root/.bash_history.
#############################################################
 (Y)es save my chroot modifications.
 (N)o do not save my chroot modifications.
Select to save your chroot modifications (default is N):

Y
Now making the updated squashfs 20200614-013407.
Parallel mksquashfs: Using 8 processors
Creating 4.0 filesystem on psu-20200614-013407.squashfs, block size 131072.

Lanciare nuovamente ./remaster-squashfs-editor e scegliere l’opzione N confermando poi con Y la creazione di filesystem.squashfs:

./remaster-squashfs-editor

#################################
    remaster-squashfs-editor
    remaster-iso version 0.9.3
#################################
  (C)hroot - Chroot in to the filesystem.squashfs + psu-*.squashfs stack.
  (J)oin   - Join the partial squashfs update files to new single psu-DATE.squashfs
  (N)ew    - New master filesystem.squashfs file which joins all *.squashfs file to new single filesystem.squashfs
  E(x)it   - Exit the program with no action
Enter choice [C , J , N , X] N
I: New option selected!
I: change directory to target live folder
I: strting mount list and points operations
I: found ./psu-20200614-020636.squashfs ... setting up mount point of psu-20200614-020636_squashfs
I: mounting ./psu-20200614-020636.squashfs on psu-20200614-020636_squashfs
./psu-20200614-020636_squashfs:./filesystem_squashfs
./psu-20200614-020636_squashfs ./filesystem_squashfs ./psu_overlay
./psu-20200614-020636_squashfs:./filesystem_squashfs
#############################################################
 (Y)es, create a new single filesystem.squashfs.
 (N)o, do not create a new single filesystem.squashfs.
Select to create a new single filesystem.squashfs (default is N):

Y

Rimuovere la cartella ./iso-extract/live/psu-OOS\*

rm -fr ./iso-extract/live/psu-OOS*

Copiare i file kernel-related presenti nello squashfs nella cartella ./iso-extract/live

Per fare questo lanciare nuovamente ./remaster-squashfs-editor scegliendo l’opzione (C)hroot

config-4.19.0-16-amd64
config-5.10.0-0.bpo.3-amd64
initrd.img-4.19.0-16-amd64
initrd.img-5.10.0-0.bpo.3-amd64
System.map-4.19.0-16-amd64
System.map-5.10.0-0.bpo.3-amd64
vmlinuz-4.19.0-16-amd64
vmlinuz-5.10.0-0.bpo.3-amd64

Si esca dall’ambiente chroot senza apportare modifiche

Modificare i file per personalizzare il menu di boot a piacimento:

isolinux/menu.cfg
boot/grub/grub.cfg

E” arrivato il momento di generare la nuova ISO.

Verificare che il comando xorriso nello script remaster-compose abbia i seguenti parametri:

xorriso -as mkisofs -r -D -V "${ISOTargetTitle}" -cache-inodes -J -l -iso-level 3 -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -c isolinux/boot.cat  -b isolinux/isolinux.bin  -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot  -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat  -o "${BASEDIR}/${BUILDDATE}-${ISOTargetName}.iso" .

Terminare poi con il comando ./remaster-compose per generare il file .iso

./remaster-compose

Al termine dello script si troverà nell’attuale cartella di lavoro la nuova immagine .iso.

Nota

Per successivi aggiornamenti e personalizzazioni, sarà sufficiente partire dall’immagine ISO creata precedentemente facendo solo le modifiche necessarie ed utilizzando i tre script di remaster-iso come indicato sopra.

ISO FUSS 11

Con FUSS 11, il tool adottato per personalizzare una immagine ISO rimane remaster-iso (https://github.com/unixabg/remaster-iso).

Creare la ISO live di FUSS

remaster-iso è disponibile come pacchetto solo a partire da Debian 11 «bullseye». Se si lavora con Debian 10 è necessario, peretanto, clonare il progetto remaster-iso da GitHub e spostarsi nella cartella creata:

git clone https://github.com/unixabg/remaster-iso.git
cd remaster-iso

Di seguito viene mostrato come personalizzare l’immagine di Debian Live amd64 Xfce reperibile da https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-11.4.0-amd64-xfce.iso con

wget https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-11.4.0-amd64-xfce.iso

Qualora servissero anche i firmware non-free, l’immagine dalla quale partire è la seguente: https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/current-live/amd64/iso-hybrid/debian-live-11.4.0-amd64-xfce+nonfree.iso ed il comando da dare per scaricarla è:

wget https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/current-live/amd64/iso-hybrid/debian-live-11.4.0-amd64-xfce+nonfree.iso

Modificare il file di configurazione remaster-iso.conf. Di seguito un esempio:

######################
## remaster settings
######################
_BASEDIR=$(pwd)
_ISOExtractPath="${_BASEDIR}/iso-extract"
_ISOLivePath="live"
_ISOMountPoint="${_BASEDIR}/iso-mount"
_ISOName=""
_ISOTargetName="fuss-11-amd64-live-lite"
_ISOTargetTitle="FUSS 11 amd64 live lite"

_VER="0.9.4"

Estrarre il file .iso

./remaster-extract -i debian-live-11.4.0-amd64-xfce.iso

Lanciare poi il comando remaster-squashfs-editor e selezionare «C» premendo INVIO:

./remaster-squashfs-editor

#################################
    remaster-squashfs-editor
    remaster-iso version 0.9.3
#################################
  (C)hroot - Chroot in to the filesystem.squashfs + psu-*.squashfs stack.
  (J)oin   - Join the partial squashfs update files to new single psu-DATE.squashfs
  (N)ew    - New master filesystem.squashfs file which joins all *.squashfs file to new single filesystem.squashfs
  E(x)it   - Exit the program with no action
Enter choice [C , J , N , X] C

Modifiare il file dei repository se necessario

nano /etc/apt/sources.list

# ##### Debian Main Repos
deb http://deb.debian.org/debian bullseye main
deb-src http://deb.debian.org/debian bullseye main

deb http://deb.debian.org/debian bullseye-updates main
deb-src http://deb.debian.org/debian bullseye-updates main

deb http://deb.debian.org/debian-security/ bullseye-security main
deb-src http://deb.debian.org/debian-security/ bullseye-security main

nano /etc/apt/sources.list.d/deb_debian_org_debian.list

# ##### Debian Backports Repo
deb http://deb.debian.org/debian bullseye-backports main
deb-src http://deb.debian.org/debian bullseye-backports main

nano /etc/apt/sources.list.d/archive_fuss_bz_it.list

# ##### FUSS Main Repo
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bullseye main
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bullseye main

Se servono anche pacchetti contrib e non-free, il file devono essere modificati come segue:

nano /etc/apt/sources.list

# ##### Debian Main Repos
deb http://deb.debian.org/debian bullseye main contrib non-free
deb-src http://deb.debian.org/debian bullseye main contrib non-free

deb http://deb.debian.org/debian bullseye-updates main contrib non-free
deb-src http://deb.debian.org/debian bullseye-updates main contrib non-free

deb http://deb.debian.org/debian-security/ bullseye-security main contrib non-free
deb-src http://deb.debian.org/debian-security/ bullseye-security main contrib non-free

nano /etc/apt/sources.list.d/deb_debian_org_debian.list

# ##### Debian Backports Repo
deb http://deb.debian.org/debian bullseye-backports main contrib non-free
deb-src http://deb.debian.org/debian bullseye-backports main contrib non-free

nano /etc/apt/sources.list.d/archive_fuss_bz_it.list

# ##### FUSS Main Repo
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bullseye main contrib non-free
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bullseye main contrib non-free

Aggiornare i pacchetti

apt update
apt install curl wget apt-transport-https dirmngr
wget -qO - https://archive.fuss.bz.it/apt.key | gpg --dearmour > /usr/share/keyrings/fuss-keyring.gpg
apt update && apt full-upgrade

Installare fuss-client

apt install fuss-client

Lanciare il comando per la configurazione di FUSS standalone (desktop)

fuss-client --iso --standalone --light [--unofficial] [--locale=LOCALE] --domain fuss.bz.it

dove

• --light mantiene l’immagine leggera senza installare i metapacchetti didattici;

• --unofficial permette di installare i firmware non-free di debian;

• --locale=LOCALE permette di scegliere la lingua di default, dove LOCALE è, a titolo d’esempio, nella forma de_DE.UTF-8.

Nello specifico:

• per la ISO FUSS ufficiale lite:

  fuss-client --iso --standalone --light --domain fuss.bz.it
  

• per la ISO FUSS ufficiale full:

  fuss-client --iso --standalone --domain fuss.bz.it
  

• per la ISO FUSS «unofficial» light:

  fuss-client --iso --standalone --light --unofficial --domain fuss.bz.it
  

• per la ISO «unofficial» full:

  fuss-client --iso --standalone --unofficial --domain fuss.bz.it
  

Se non fatto precedentemente, scaricare la chiave del repository archive.fuss.bz.it che verrà utilizzata da Calamares (https://calamares.io/) durante l’installazione:

curl https://archive.fuss.bz.it/apt.key | gpg --dearmor > /usr/share/keyrings/fuss-keyring.gpg

Modificare lo script /usr/sbin/sources-final che scriverà i repository durante l’installazione:

#!/bin/sh
#
# Writes the final sources.list files
#

CHROOT=$(mount | grep proc | grep calamares | awk '{print $3}' | sed -e "s#/proc##g")
RELEASE="bullseye"
FUSS_KEY="/usr/share/keyrings/fuss-keyring.gpg"

cat << EOF > $CHROOT/etc/apt/sources.list
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian $RELEASE main
deb-src http://deb.debian.org/debian $RELEASE main

deb http://deb.debian.org/debian $RELEASE-updates main
deb-src http://deb.debian.org/debian $RELEASE-updates main

deb http://security.debian.org/debian-security/ $RELEASE-security main
deb-src http://security.debian.org/debian-security/ $RELEASE-security main
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/deb_debian_org_debian.list
deb http://deb.debian.org/debian $RELEASE-backports main
deb-src http://deb.debian.org/debian $RELEASE-backports main
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/archive_fuss_bz_it.list
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main
EOF

if [ -f $FUSS_KEY ] ; then
    cp $FUSS_KEY $CHROOT/usr/share/keyrings/fuss-keyring.gpg
fi

exit 0

Per le immagini unofficial il file dev’essere

#!/bin/sh
#
# Writes the final sources.list files
#

CHROOT=$(mount | grep proc | grep calamares | awk '{print $3}' | sed -e "s#/proc##g")
RELEASE="bullseye"
FUSS_KEY="/usr/share/keyrings/fuss-keyring.gpg"

cat << EOF > $CHROOT/etc/apt/sources.list
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian $RELEASE main contrib non-free
deb-src http://deb.debian.org/debian $RELEASE main contrib non-free

deb http://deb.debian.org/debian $RELEASE-updates main contrib non-free
deb-src http://deb.debian.org/debian $RELEASE-updates main contrib non-free

deb http://security.debian.org/debian-security/ $RELEASE-security main contrib non-free
deb-src http://security.debian.org/debian-security/ $RELEASE-security main contrib non-free
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/deb_debian_org_debian.list
deb http://deb.debian.org/debian $RELEASE-backports main contrib non-free
deb-src http://deb.debian.org/debian $RELEASE-backports main contrib non-free
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/archive_fuss_bz_it.list
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main contrib non-free
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main contrib non-free
EOF

if [ -f $FUSS_KEY ] ; then
    cp $FUSS_KEY $CHROOT/usr/share/keyrings/fuss-keyring.gpg
fi

exit 0

Sostituire il file main.py nella cartella /usr/lib/x86_64-linux-gnu/calamares/modules/displaymanager con la versione modificata disponibile al link https://www.fuss.bz.it/utility/calamares/main.py

wget -O /usr/lib/x86_64-linux-gnu/calamares/modules/displaymanager/main.py https://www.fuss.bz.it/utility/calamares/main.py

Rimuovere i pacchetti inutilizzati e ripulire la cache pacchetti

apt-get autoremove
apt-get clean

Configurare la live

nano /etc/live/config.conf.d/fuss.conf

LIVE_HOSTNAME="fuss"
LIVE_USERNAME="user"
LIVE_USER_FULLNAME="FUSS Live user"
LIVE_LOCALES="en_US.UTF-8,it_IT.UTF-8,de_AT.UTF-8"
LIVE_TIMEZONE="Europe/Rome"
LIVE_KEYBOARD_LAYOUTS="it,de"

Cambiare l’encoding della console

nano /etc/default/console-setup

impostando

CHARMAP="UTF-8"

Cambiare l’hostname di default

nano /etc/hostname

fuss

Per prendere le impostazioni del pannello come previsto da FUSS, modificare una riga dello script /lib/live/config/1170-xfce4-panel:

nano /lib/live/config/1170-xfce4-panel

sudo -u "${LIVE_USERNAME}" cp /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml /home/"${LIVE_USERNAME}"/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml

Qualora servisse, nella cartella /lib/live/config ci sono tutti gli script richiamati dalla live per le diverse configurazioni. Come documentazione c’è la man page di live-config dov’è tutto abbastanza ben documentato.

Uscire e salvare le modifiche fatte in chroot digitando Y ed invio

root@jarvis:~# exit
Exited the chroot so time to clean up.
Restore original overlay/etc/hosts.
Restore overlay/etc/resolv.conf.
Remove overlay/root/.bash_history.
#############################################################
 (Y)es save my chroot modifications.
 (N)o do not save my chroot modifications.
Select to save your chroot modifications (default is N):

Y
Now making the updated squashfs 20200614-013407.
Parallel mksquashfs: Using 8 processors
Creating 4.0 filesystem on psu-20200614-013407.squashfs, block size 131072.

Lanciare nuovamente ./remaster-squashfs-editor e scegliere l’opzione N confermando poi con Y la creazione di filesystem.squashfs:

./remaster-squashfs-editor

#################################
    remaster-squashfs-editor
    remaster-iso version 0.9.3
#################################
  (C)hroot - Chroot in to the filesystem.squashfs + psu-*.squashfs stack.
  (J)oin   - Join the partial squashfs update files to new single psu-DATE.squashfs
  (N)ew    - New master filesystem.squashfs file which joins all *.squashfs file to new single filesystem.squashfs
  E(x)it   - Exit the program with no action
Enter choice [C , J , N , X] N
I: New option selected!
I: change directory to target live folder
I: strting mount list and points operations
I: found ./psu-20200614-020636.squashfs ... setting up mount point of psu-20200614-020636_squashfs
I: mounting ./psu-20200614-020636.squashfs on psu-20200614-020636_squashfs
./psu-20200614-020636_squashfs:./filesystem_squashfs
./psu-20200614-020636_squashfs ./filesystem_squashfs ./psu_overlay
./psu-20200614-020636_squashfs:./filesystem_squashfs
#############################################################
 (Y)es, create a new single filesystem.squashfs.
 (N)o, do not create a new single filesystem.squashfs.
Select to create a new single filesystem.squashfs (default is N):

Y

Rimuovere la cartella ./iso-extract/live/psu-OOS\*

rm -fr ./iso-extract/live/psu-OOS*

Copiare i file kernel-related presenti nello squashfs nella cartella ./iso-extract/live

Per fare questo lanciare nuovamente ./remaster-squashfs-editor scegliendo l’opzione (C)hroot

config-4.19.0-16-amd64
config-5.10.0-0.bpo.3-amd64
initrd.img-4.19.0-16-amd64
initrd.img-5.10.0-0.bpo.3-amd64
System.map-4.19.0-16-amd64
System.map-5.10.0-0.bpo.3-amd64
vmlinuz-4.19.0-16-amd64
vmlinuz-5.10.0-0.bpo.3-amd64

Si esca dall’ambiente chroot senza apportare modifiche

Si modifichi all’occorrenza l’immagine iso-extract/isolinux/splash.png.

Modificare i file per personalizzare il menu di boot a piacimento. Nelle ultime iso prodotte è stata lasciata solo l’opzione live (che include l’installer Calamares) e di rimuovere le opzioni Graphical Debian Installer, Debian Installer e Debian Installer with Speech Synthesis:

iso-extract/isolinux/menu.cfg
iso-extract/boot/grub/grub.cfg

È arrivato il momento di generare la nuova ISO lanciando il comando

./remaster-compose

Al termine dello script si troverà nell’attuale cartella di lavoro la nuova immagine .iso.

Nota

Per successivi aggiornamenti e personalizzazioni, sarà sufficiente partire dall’immagine ISO creata precedentemente facendo solo le modifiche necessarie ed utilizzando i tre script di remaster-iso come indicato sopra.

ISO FUSS 12

Con FUSS 12, il tool adottato per personalizzare una immagine ISO rimane remaster-iso (https://github.com/unixabg/remaster-iso).

Creare la ISO live di FUSS

remaster-iso è disponibile come pacchetto solo a partire da Debian 11 «bullseye». Se si lavora con Debian 10 è necessario, pertanto, clonare il progetto remaster-iso da GitHub e spostarsi nella cartella creata:

git clone https://github.com/unixabg/remaster-iso.git
cd remaster-iso

Di seguito viene mostrato come personalizzare l’immagine di Debian Live amd64 Xfce reperibile da https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-xfce.iso con

wget https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-xfce.iso

Qualora servissero anche i firmware non-free, l’immagine dalla quale partire è la seguente: https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/current-live/amd64/iso-hybrid/debian-live-11.4.0-amd64-xfce+nonfree.iso ed il comando da dare per scaricarla è:

wget https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/current-live/amd64/iso-hybrid/debian-live-11.4.0-amd64-xfce+nonfree.iso

Modificare il file di configurazione remaster-iso.conf. Di seguito un esempio:

######################
## remaster settings
######################
_BASEDIR=$(pwd)
_ISOExtractPath="${_BASEDIR}/iso-extract"
_ISOLivePath="live"
_ISOMountPoint="${_BASEDIR}/iso-mount"
_ISOName=""
_ISOTargetName="fuss-12-amd64-live-lite"
_ISOTargetTitle="FUSS 12 amd64 live lite"

_VER="0.9.4"

Estrarre il file .iso

./remaster-extract -i debian-live-12.1.0-amd64-xfce.iso

Lanciare poi il comando remaster-squashfs-editor e selezionare «C» premendo INVIO:

./remaster-squashfs-editor

#################################
    remaster-squashfs-editor
    remaster-iso version 0.9.4
#################################
  (C)hroot - Chroot in to the filesystem.squashfs + psu-*.squashfs stack.
  (J)oin   - Join the partial squashfs update files to new single psu-DATE.squashfs
  (N)ew    - New master filesystem.squashfs file which joins all *.squashfs file to new single filesystem.squashfs
  E(x)it   - Exit the program with no action
Enter choice [C , J , N , X] C

Modificare il file dei repository se necessario

nano /etc/apt/sources.list

# ##### Debian Main Repos
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian bookworm main
deb-src http://deb.debian.org/debian bookworm main

deb http://deb.debian.org/debian bookworm-updates main
deb-src http://deb.debian.org/debian bookworm-updates main

deb http://security.debian.org/debian-security/ bookworm-security main
deb-src http://security.debian.org/debian-security/ bookworm-security main

nano /etc/apt/sources.list.d/deb_debian_org_debian.list

# ##### Debian Backports Repo
deb http://httpredir.debian.org/debian bookworm-backports main

nano /etc/apt/sources.list.d/archive_fuss_bz_it.list

# ##### FUSS Main Repo
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg]  http://archive.fuss.bz.it/ bookworm main
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm main

Se servono anche pacchetti contrib e non-free, il file devono essere modificati come segue:

nano /etc/apt/sources.list

# ##### Debian Main Repos
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian bookworm main contrib non-free-firmware non-free
deb-src http://deb.debian.org/debian bookworm main contrib non-free-firmware non-free

deb http://deb.debian.org/debian bookworm-updates main contrib non-free-firmware non-free
deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free-firmware non-free

deb http://security.debian.org/debian-security/ bookworm-security main contrib non-free-firmware non-free
deb-src http://security.debian.org/debian-security/ bookworm-security main contrib non-free-firmware non-free

nano /etc/apt/sources.list.d/deb_debian_org_debian.list

# ##### Debian Backports Repo
deb http://httpredir.debian.org/debian bookworm-backports main contrib non-free-firmware non-free

nano /etc/apt/sources.list.d/archive_fuss_bz_it.list

# ##### FUSS Main Repo
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg]  http://archive.fuss.bz.it/ bookworm main contrib non-free
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm main contrib non-free

Aggiornare i pacchetti

apt update
apt install curl wget apt-transport-https dirmngr
wget -qO - https://archive.fuss.bz.it/apt.key | gpg --dearmour > /usr/share/keyrings/fuss-keyring.gpg
apt update && apt full-upgrade

Installare fuss-client

apt install fuss-client

Lanciare il comando per la configurazione di FUSS standalone (desktop)

fuss-client --iso --standalone --light [--unofficial] [--locale=LOCALE] --domain fuss.bz.it

dove

• --light mantiene l’immagine leggera senza installare i metapacchetti didattici;

• --unofficial permette di installare i firmware non-free di debian;

• --locale=LOCALE permette di scegliere la lingua di default, dove LOCALE è, a titolo d’esempio, nella forma de_DE.UTF-8.

Nello specifico:

• per la ISO FUSS ufficiale lite:

  fuss-client --iso --standalone --light --domain fuss.bz.it
  

• per la ISO FUSS ufficiale full:

  fuss-client --iso --standalone --domain fuss.bz.it
  

• per la ISO FUSS «unofficial» light:

  fuss-client --iso --standalone --light --unofficial --domain fuss.bz.it
  

• per la ISO «unofficial» full:

  fuss-client --iso --standalone --unofficial --domain fuss.bz.it
  

Se non fatto precedentemente, scaricare la chiave del repository archive.fuss.bz.it che verrà utilizzata da Calamares (https://calamares.io/) durante l’installazione:

curl https://archive.fuss.bz.it/apt.key | gpg --dearmor > /usr/share/keyrings/fuss-keyring.gpg

Nota

Se il fuss-client –standalone … dovesse fallire con l’errore:

ERROR: Ansible could not initialize the preferred locale: unsupported locale setting

riconfigurare i locales scegliendo una lingua lanciando il comando:

dpkg-reconfigure locales

Modificare lo script /usr/sbin/sources-final che scriverà i repository durante l’installazione:

#!/bin/sh
#
# Writes the final sources.list files
#

CHROOT=$(mount | grep proc | grep calamares | awk '{print $3}' | sed -e "s#/proc##g")
RELEASE="bookworm"
FUSS_KEY="/usr/share/keyrings/fuss-keyring.gpg"

cat << EOF > $CHROOT/etc/apt/sources.list
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian $RELEASE main
deb-src http://deb.debian.org/debian $RELEASE main

deb http://deb.debian.org/debian $RELEASE-updates main
deb-src http://deb.debian.org/debian $RELEASE-updates main

deb http://security.debian.org/debian-security/ $RELEASE-security main
deb-src http://security.debian.org/debian-security/ $RELEASE-security main
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/deb_debian_org_debian.list
deb http://deb.debian.org/debian $RELEASE-backports main
deb-src http://deb.debian.org/debian $RELEASE-backports main
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/archive_fuss_bz_it.list
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main
EOF

if [ -f $FUSS_KEY ] ; then
    cp $FUSS_KEY $CHROOT/usr/share/keyrings/fuss-keyring.gpg
fi

exit 0

Per le immagini unofficial il file dev’essere

#!/bin/sh
#
# Writes the final sources.list files
#

CHROOT=$(mount | grep proc | grep calamares | awk '{print $3}' | sed -e "s#/proc##g")
RELEASE="bookworm"
FUSS_KEY="/usr/share/keyrings/fuss-keyring.gpg"

cat << EOF > $CHROOT/etc/apt/sources.list
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian $RELEASE main contrib non-free-firmware non-free
deb-src http://deb.debian.org/debian $RELEASE main contrib non-free-firmware non-free

deb http://deb.debian.org/debian $RELEASE-updates main contrib non-free-firmware non-free
deb-src http://deb.debian.org/debian $RELEASE-updates main contrib non-free-firmware non-free

deb http://security.debian.org/debian-security/ $RELEASE-security main contrib non-free-firmware non-free
deb-src http://security.debian.org/debian-security/ $RELEASE-security main contrib non-free-firmware non-free
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/deb_debian_org_debian.list
deb http://deb.debian.org/debian $RELEASE-backports main contrib non-free
deb-src http://deb.debian.org/debian $RELEASE-backports main contrib non-free
EOF

cat << EOF > $CHROOT/etc/apt/sources.list.d/archive_fuss_bz_it.list
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main contrib non-free
deb-src [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ $RELEASE main contrib non-free
EOF

if [ -f $FUSS_KEY ] ; then
    cp $FUSS_KEY $CHROOT/usr/share/keyrings/fuss-keyring.gpg
fi

exit 0

Sostituire il file main.py nella cartella /usr/lib/x86_64-linux-gnu/calamares/modules/displaymanager con la versione modificata disponibile al link https://www.fuss.bz.it/utility/calamares/main.py

wget -O /usr/lib/x86_64-linux-gnu/calamares/modules/displaymanager/main.py https://www.fuss.bz.it/utility/calamares/main.py

Nota

Verificare periodicamente che il modulo main.py sia ancora compatibile con l’ultima versione di calamares. Eventualmente modificarlo.

Rimuovere i pacchetti uim, ibus e, se necessario, riconfigurare libdvd-pkg

apt remove uim ibus
dpkg-reconfigure libdvd-pkg

Rimuovere i pacchetti inutilizzati e ripulire la cache pacchetti

apt-get autoremove
apt-get clean

Configurare la live

nano /etc/live/config.conf.d/fuss.conf

LIVE_HOSTNAME="fuss"
LIVE_USERNAME="user"
LIVE_USER_FULLNAME="FUSS Live user"
LIVE_LOCALES="en_US.UTF-8,it_IT.UTF-8,de_AT.UTF-8"
LIVE_TIMEZONE="Europe/Rome"
LIVE_KEYBOARD_LAYOUTS="it,de"

Cambiare l’encoding della console

nano /etc/default/console-setup

impostando

CHARMAP="UTF-8"

Cambiare l’hostname di default

nano /etc/hostname

fuss

Per prendere le impostazioni del pannello come previsto da FUSS, modificare una riga dello script /lib/live/config/1170-xfce4-panel:

nano /lib/live/config/1170-xfce4-panel

sudo -u "${LIVE_USERNAME}" cp /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml /home/"${LIVE_USERNAME}"/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml

Qualora servisse, nella cartella /lib/live/config ci sono tutti gli script richiamati dalla live per le diverse configurazioni. Come documentazione c’è la man page di live-config dov’è tutto abbastanza ben documentato.

Per evitare che all’avvio della ISO live appaia lo sfondo artwork presente al momento della compilazione della stessa, si consiglia di modificare lo script /usr/share/fuss-artwork/rotate-background.sh, aggiungendo:

if grep -w "overlay" /etc/fstab; then
    EXPECTED_LINK="/usr/share/fuss-artwork/wallpapers/fuss-$(RELEASE)-wallpaper.svg"
fi

subito prima della riga:

test "$CURRENT_LINK" = "$EXPECTED_LINK" && exit 0

In questo modo, in modalità Live apparirà lo sfondo predefinito per la versione installata.

Terminate le modifiche fatte in chroot, uscire dall’Editor di squashfs e salvare digitando Y ed invio

root@jarvis:~# exit
Exited the chroot so time to clean up.
Restore original overlay/etc/hosts.
Restore overlay/etc/resolv.conf.
Remove overlay/root/.bash_history.
#############################################################
 (Y)es save my chroot modifications.
 (N)o do not save my chroot modifications.
Select to save your chroot modifications (default is N):

Y
Now making the updated squashfs 20230614-013407.
Parallel mksquashfs: Using 8 processors
Creating 4.0 filesystem on psu-20230614-013407.squashfs, block size 131072.

Lanciare nuovamente ./remaster-squashfs-editor e scegliere l’opzione N confermando poi con Y la creazione di filesystem.squashfs:

./remaster-squashfs-editor

#################################
    remaster-squashfs-editor
    remaster-iso version 0.9.4
#################################
  (C)hroot - Chroot in to the filesystem.squashfs + psu-*.squashfs stack.
  (J)oin   - Join the partial squashfs update files to new single psu-DATE.squashfs
  (N)ew    - New master filesystem.squashfs file which joins all *.squashfs file to new single filesystem.squashfs
  E(x)it   - Exit the program with no action
Enter choice [C , J , N , X] N
I: New option selected!
I: change directory to target live folder
I: strting mount list and points operations
I: found ./psu-20230614-020636.squashfs ... setting up mount point of psu-20230614-020636_squashfs
I: mounting ./psu-20230614-020636.squashfs on psu-20230614-020636_squashfs
./psu-20230614-020636_squashfs:./filesystem_squashfs
./psu-20230614-020636_squashfs ./filesystem_squashfs ./psu_overlay
./psu-20230614-020636_squashfs:./filesystem_squashfs
#############################################################
 (Y)es, create a new single filesystem.squashfs.
 (N)o, do not create a new single filesystem.squashfs.
Select to create a new single filesystem.squashfs (default is N):

Y

Rimuovere la cartella ./iso-extract/live/psu-OOS*

rm -fr ./iso-extract/live/psu-OOS*

Copiare i file kernel-related presenti nello squashfs nella cartella ./iso-extract/live

config-6.1.0-9-amd64
config-6.1.0-10.bpo.3-amd64
initrd.img-6.1.0-9-amd64
initrd.img-6.1.0-10-amd64
System.map-6.1.0-9-amd64
System.map-6.1.0-10-amd64
vmlinuz-6.1.0-9-amd64
vmlinuz-6.1.0-10-amd64

Per fare questo lanciare nuovamente ./remaster-squashfs-editor scegliendo l’opzione (C)hroot Aprire un altro terminale e spostarsi in iso-extract/live. Copiarvi i file da iso-extract/live/psu_overlay/boot/, dove è stata montata la cartella, eliminando eventualmente quelli con la versioni non desiderate

cp /media/iso/fuss-12-amd64-live-full/iso-extract/live/psu_overlay/boot/* .

Si esca dall’ambiente chroot senza apportare modifiche

Si modifichi all’occorrenza l’immagine iso-extract/isolinux/splash.png ed eventualmente anche iso-extract/isolinux/splash800x600.png.

Modificare i file per personalizzare il menu di boot a piacimento. Si può decidere ad esempio di mantenere solo l’opzione live (che include l’installer Calamares) e di rimuovere le opzioni Graphical DebianInstaller, Debian Installer e Debian Installer with Speech Synthesis:

iso-extract/isolinux/menu.cfg
iso-extract/boot/grub/grub.cfg

Nota

Nel caso nel menu di boot manchino alcune opzioni, come il supporto di localizzazione per avviare la live nella lingua desiderata, si possono copiare parti di codice dai file di distribuzioni precedenti.

È arrivato il momento di generare la nuova ISO lanciando il comando

./remaster-compose

Al termine dello script si troverà nell’attuale cartella di lavoro la nuova immagine .iso.

Nota

Per successivi aggiornamenti e personalizzazioni, sarà sufficiente partire dall’immagine ISO creata precedentemente facendo solo le modifiche necessarie ed utilizzando i tre script di remaster-iso come indicato sopra.

Nuove versioni di Debian

Questa procedura è la procedura per realizzare l’aggiornamento di una versione di FUSS basata su una nuova release Debian stable.

Procedura di aggiornamento

Repository software

I repository git contenenti il software custom di FUSS dovranno ospitare le nuove versione specifiche per la versione upstream.

Il workflow attuale è il seguente:

branch master:

attuale distribuzione debian stable

branch codename_distribuzione:

contiene il codice rispetto ad una specifica versione di Debian, per backporting e altre correzioni

Quando viene rilasciata una nuova Debian, è necessario quindi creare il branch relativo alla nuova oldstable, e proseguire su master per l’attuale versione stabile.

Ad esempio, per passare da stretch a buster, su tutti i repository che contengono software pubblicato nell’archivio di FUSS:

(master) $ git pull
(master) $ git checkout -b stretch
(stretch) $ git push -u origin stretch
(stretch) $ git checkout master
(master) $ # proseguire con le modifiche...

Aggiornamento, build e test pacchetti

Ogni nuovo pacchetto dovrà come minimo:

• Essere aggiornato allo standard di riferimento Debian per la versione in uso (vedi https://www.debian.org/doc/debian-policy/ ).

• Avere una versione (e relativo changelog) che riporti, come major version number, quello della distribuzione Debian di riferimento. Ad esempio un pacchetto per Debian Buster avrà come versione 10.x.x.

• Essere aggiornato rispetto alle nuove versioni delle dipendenze presenti nella nuova versione della distribuzioone.

• Dovrà essere buildato e testato su una installazione della versione Debian di riferimento.

Per le istruzioni di build e di successivo upload si veda Pacchetti e Repository.

fuss-server e fuss-client

FUSS Server e FUSS Client intervengono sui file di configurazione di numerosi pacchetti: per il loro aggiornamento è opportuno fare delle verifiche specifiche sul loro funzionamento.

• Per i file in cui vengono inserite sezioni nei file di configurazione (task lineinfile e blockinfile) che le sezioni siano ancora inserite nel posto opportuno.

• Per i file che vengono completamente sovrascritti (task copy e template) è generalmente il caso di ripartire dal file di configurazione di default della nuova versione di debian e riapplicare le modifiche necessarie (in modo da ricevere le nuove eventuali impostazioni di default).

Immagini ISO

TBD

Informazioni sullo sviluppo upstream

Date di release

Contrariamente ad altre distribuzioni, Debian non fissa date di rilascio, dando maggiore priorità alla qualità della distribuzione. Vengono però fissate le date di freeze, il che permette di stimare con approssimazione di qualche mese quando avverrà il prossimo rilascio.

La freeze, avviene ogni due anni d’inverno; le date precise sono annunciate con largo anticipo e pubblicate su https://release.debian.org/; i rilasci avvengono generalmente [1] durante le estati degli anni dispari.

[1]

Ulteriori statistiche sono presenti su https://wiki.debian.org/DebianReleases#Release_statistics Notare che la data della freeze è stata spostata in avanti di due mesi tra jessie e stretch.

A partire dalla data della freeze non vengono più effettuati cambiamenti delle versioni di pacchetti presenti nella distribuzione, ma vengono solo accettati fix mirati per bug sufficientemente importanti; questo per FUSS vuol dire che eventuali test di aggiornamento di versione saranno già corrispondenti al comportamento della versione rilasciata.

Macchine virtuali con libvirt+qemu/kvm per fuss-server e fuss-client

Per fare test di fuss-server e fuss-client è utile avere a disposizione delle macchine virtuali; specialmente se si lavora su debian stretch o successive (dove VirtualBox non è più disponibile) è comodo usare qemu/kvm tramite libvirt.

Installazione e configurazione

Installazione di libvirt

• Installare i seguenti pacchetti:

  apt install qemu libvirt-clients libvirt-daemon virtinst \
  libvirt-daemon-system virt-viewer virt-manager dnsmasq-base
  

• Aggiungere il proprio utente ai gruppi libvirt e kvm:

  adduser $UTENTE libvirt
  adduser $UTENTE kvm
  

Una volta che l’utente fa parte dei gruppi (ad esempio previo logout/ri-login) si può usare virt-manager per gestire macchine virtuali e reti tramite un’interfaccia grafica simile a quella di VirtualBox.

Volendo invece usare la riga di comando, si può proseguire con questa guida.

Configurazione della rete

fuss-server richiede la configurazione di almeno due, in alcuni casi tre, schede di rete: una con accesso ad internet e due su rete isolata.

Per creare queste interfacce di rete da riga di comando se ne deve scrivere il file di configurazione e passarlo al comando virsh net-define

Per la rete nattata, creare il file natted.xml con i seguenti contenuti, sostituendo a 8.8.8.8 l’indirizzo di un server dns opportuno:

<network>
  <name>natted</name>
  <forward mode='nat' />
  <bridge name='virbr7' stp='on' delay='0'/>
  <dns>
    <forwarder addr='8.8.8.8'/>
  </dns>
  <ip address='192.168.7.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.7.128' end='192.168.7.254'/>
    </dhcp>
  </ip>
</network>

Suggerimento

Con questa configurazione sull’host verrà configurata un’interfaccia di rete virbr7 con assegnato l’indirizzo 192.168.7.1.

Le macchine virtuali avranno invece a disposizione un dchp che assegnerà loro indirizzi nel range da 192.168.7.128 a 192.168.7.254, e le richieste DNS verranno inoltrate al server 8.8.8.8..

quindi lanciare, come root:

# virsh net-define natted.xml
# virsh net-start natted

Similmente, per le interfacce isolate si può usare quanto segue, nel file isolated.xml:

<network>
  <name>isolated</name>
  <bridge name='virbr6' stp='on' delay='0'/>
  <ip address='192.168.6.253' netmask='255.255.255.0'>
  </ip>
</network>

e nel file isolated2.xml:

<network>
  <name>isolated2</name>
  <bridge name='virbr8' stp='on' delay='0'/>
  <ip address='192.168.8.253' netmask='255.255.255.0'>
  </ip>
</network>

E come prima, sempre con utente root:

# virsh net-define isolated.xml
# virsh net-start isolated
# virsh net-define isolated2.xml
# virsh net-start isolated2

In questo modo le interfacce sono definite, ma non verranno avviate automaticamente; per farlo usare i seguenti comandi:

# virsh net-autostart natted
# virsh net-autostart isolated
# virsh net-autostart isolated2

oppure usare net-start per ciascuna interfaccia quando se ne ha bisogno.

Creazione delle macchine virtuali

Per creare la macchina che ospiterà il server, dopo aver abilitato le interfacce di rete e scaricato l”iso di fuss-server lanciare il seguente comando:

$ virt-install --connect qemu:///system --name fuss_server --memory 1024 \
  --cdrom $PATH_ISO_FUSS-SERVER --network network=natted \
  --network network=isolated --network network=isolated2 \
  --disk size=16,format=qcow2 --os-variant debian12

questo creerà una macchina virtuale che fa il boot dall’iso dell’installer e aprirà una finestra di virt-viewer per controllarla. Alla fine dell’installazione si può fare login e procedere con l”Installazione di Fuss Server

Una volta che il server è installato e configurato si può fare la stessa cosa per una (o più) macchine client:

$ virt-install --connect qemu:///system --name fuss_client --memory 1024 \
  --cdrom $PATH_ISO_FUSS-CLIENT --network network=isolated \
  --disk size=24,format=qcow2 --os-variant debian12

Gestione

Boot delle macchine

Per avviare le volte successive le macchine è necessario:

• Se l’host è stato spento, e non è stato configurato l’autoavvio delle interfacce di rete, abilitarle:

  # virsh net-start natted
  # virsh net-start isolated
  # virsh net-start isolated2
  

• Avviare la macchina di cui si ha bisogno:

  $ virsh --connect qemu:///system start fuss-server
  

• Se necessario, avviare una sessione grafica sulla macchina:

  $ virt-viewer --connect qemu:///system fuss-server
  

Snapshot

Per creare uno snapshot di una macchina:

virsh -c qemu:///system snapshot-create-as fuss-server <nome> "<descrizione>"

Per vedere l’elenco degli snapshot disponibili:

virsh -c qemu:///system snapshot-list fuss-server

Per riportare la macchina ad uno snapshot, eliminando tutte le modifiche effettuate nel frattempo:

virsh -c qemu:///system snapshot-revert fuss-server <nome>

oppure, per usare lo snapshot corrente (sempre perdendo le modifiche):

virsh -c qemu:///system snapshot-revert fuss-server --current

Configurazioni del sistema

Configurazione della rete

All’interno del fuss-server, le interfacce di rete come definite in questa pagina possono essere configurate aggiungendo a /etc/network/interfaces le seguenti righe:

allow-hotplug enp1s0
iface enp1s0 inet dhcp

allow-hotplug enp2s0
iface enp2s0 inet static
    address 192.168.6.1
    netmask 255.255.255.0

In fuss-client non è invece necessaria nessuna configurazione, dato che viene usato dhcp come da default.

Vedi anche

In caso di problemi o per approfondire l’uso da riga di comando di libvirt è molto utile la pagina su Libvirt della wiki di Arch Linux , la maggior parte della quale si applica anche a sistemi Debian o Debian-based.

Distrobox

Premessa

In passato, per provare distribuzioni, applicazioni, simulare configurazioni con Linux, si doveva ricorrere alla virtualizzazione e alle macchine virtuali. distrobox apre alla possibilità di usare qualsiasi distribuzione Linux all’interno della stessa finestra del terminale. Ciò è possibile grazie alla creazione di container Docker e Podman, inserendo al loro interno la distribuzione Linux di propria scelta. Una soluzione come distrobox semplifica enormemente l’installazione e l’esecuzione di molteplici distribuzioni Linux direttamente dal terminale. Ciascun container creato risulta strettamente integrato con l’host, consentendo la condivisione della directory home dell’utente, l’accesso alle unità di memorizzazione esterne, l’utilizzo di dispositivi USB, delle applicazioni dotate di interfaccia grafica (X11/Wayland) e dell’hardware multimediale. distrobox è un modo per integrare il software containerizzato come se fosse un’app nativa , anche se quel software appartiene a una distribuzione completamente diversa. Inoltre, permette di creare ambienti di sviluppo e di test senza richiedere i privilegi di root.

Come installare distrobox su Linux

Distrobox è ormai presente nei repository delle varie distribuzioni, permettendo di caricare direttamente il pacchetto software.

apt install distrobox

Una volta completata l’installazione di distrobox è possibile usare il comando seguente per caricare una distribuzione sotto forma di container. In questo esempio creiamo una distribuzione Debian 10:

distrobox-create --name debian10-box --image debian:10

Il nome può essere scelto in modo arbitrario e specificato dopo –name. Accanto a –image, invece, va specificato il nome della distribuzione Linux da installare. Nella sezione Containers Distros della documentazione di distrobox si trovano i nomi delle immagini utilizzabili nel comando distrobox-create.

Il comando che segue consente di accedere alla schermata del terminale corrispondente alla distribuzione Linux indicata:

distrobox-enter --name debian10-box

Per chiudere il container si può semplicemente digitare exit + Invio dall’interno oppure da un altro terminale:

distrobox-stop --name debian10-box

Installare applicazioni in distribuzioni distrobox

A questo punto siamo a tutti gli effetti nella distribuzione debian 10. Possiamo ad esempio installare nuove applicazioni. Nel caso delle distribuzioni Debian e derivate (ad esempio Ubuntu), si può installare ovviamente in questo modo:

sudo apt install omnitux

Abbiamo installato il programma di giochi Omnitux, che non è più compatibile con debian 12 ma lo è con debian10:

sudo dpkg --add-architecture i386
sudo apt install wine32

Abbiamo installato l’architettura i386, e l’emulatore wine32 per poter utilizzare vecchi software senza dover modificare il sistema principale. La cosa veramente interessante è che wine32, installato nel container, può essere utilizzato anche dal sistema principale (ad es. debian12), per lanciare applicazioni contenute o nel file system del container o nella home dell’utente (che è condivisa).

È anche possibile eseguire comandi in una specifica distribuzione containerizzata senza acquisire prima l’accesso alla shell della distribuzione specificata servendosi del comando che segue:

distrobox-enter --name debian10-box -- sudo apt update

In questo caso il comando viene lanciato da debian 12 ma viene eseguito in debian 10.

Altri comandi utilizzabili con distrobox

Nella documentazione si trova l’ elenco dei comandi supportati da distrobox. Tra i più utili c’è distrobox-export, uno strumento che consente di esportare un’applicazione dall’ambiente containerizzato e installarla sul sistema host. La sintassi è semplice. Se voglio esportare dal container all’host il programma omnitux installato prima:

distrobox-export --app omnitux

Così facendo, l’applicazione esportata dal container apparirà automaticamente nella lista dei programmi disponibili sul “sistema ospitante”. Se invece voglio lanciarlo nell’host dal terminale il comando è:

/usr/bin/distrobox-enter -n debian10-box -- omnitux

Si è scelto intenzionalmente l’esempio di Omnitux perchè richiede qualche configurazione aggiuntiva che in genere non è necessaria. Bisogna innanzitutto riconfigurare la lingua di sistema.

apt install locales

dpkg-reconfigure locales   # Aggiungere it_IT.UTF-8 e sceglierlo come default

Nel lanciatore /usr/bin/omnitux aggiungere la riga:

export LC_ALL=it_IT.UTF-8

Può essere utile anche la possibilità di clonare un container, per destinare i cloni ad altro uso o fare un backup. Lo si può fare rapidamente con Podman rilevando dapprima l’ID corrispondente (podman ps), arrestando il container (podman stop ID_container) quindi impartendo il comando seguente:

distrobox-create --name debian-10-clonato --clone debian10-box

Nell’esempio, il contenuto del container debian10-box viene automaticamente clonato nel nuovo container di nome debian-10-clonato.

Come salvare e reimportare i container

Per salvare, esportare e riusare un container già configurato esiste anche la possibilità di creare uno snapshot e di reimportarlo in un altro host (con qualche limitazione, come vedremo)

Per salvare un’immagine con podman:

podman container commit -p distrobox_name  backup_image_name  # Il nome del backup lo scegliamo noi

podman image save backup_image_name:latest | bzip2 > backup_image_name.tar.bz2

Questo creerà un archivio compresso tar.gz del contenitore scelto.

Ora lo si può trasferire su un altro host e per ripristinarlo basta eseguire:

podman image load -i  backup_image_name.tar.bz2

E creare un nuovo contenitore basato su quell’immagine:

distrobox-create --image backup_image_name:latest --name distrobox_name

Limitazioni nell’esportazione ed importazione di container

Per quello che si è potuto testare, non è al momento possibile caricare un’immagine nella home di un’utente di rete, ma solo in quelle di utenti locali. Problemi di permessi legati al montaggio delle home via nfs impediscono il caricamento del container podman. Per avere la stessa shell (ad esempio bash) dell’utente, si può avviare distrobox col comando:

distrobox-enter --name debian10-box -- bash

Per cambiare la shell in modo permanente per l’utente, si può sostituire /bin/sh con /bin/bash nel file /etc/passwd . Questo sostituzione si può effettuare anche col comando:

distrobox-enter --name debian10-box -- sudo sed -i "/my_username/s|/bin/sh|/bin/bash|" /etc/passwd

Esempio di applicazione di distrobox nel progetto Fuss

Come già accennato, il fatto di poter utilizzare una distro linux all’interno di un’altra apre la strada alla possibilità di integrare nel sistema principale applicazioni non compatibili (in quanto obsolete, o richiedenti librerie o architetture particolari) senza alterare il sistema stesso. Ad esempio, nel pacchetto fuss-distrobox per fuss 11 e fuss 12 viene scaricato via wget un container debian 10 con alcune applicazioni non più supportate. Il pacchetto crea un utente (gioco), vi scarica l’immagine debian 10, copia varie altre cartelle e modifica i permessi attraverso gli script, in modo tale che l’utente utilizza tali applicazioni senza nemmeno accorgersi dell’esistenza del container podman.

Contribuisci

Chiunque può contribuire a migliorare questa documentazione che è scritta in reStructuredText.

Supporto

Se ti serve aiuto, scrivi una mail ad info@fuss.bz.it

Licenze