eggs and cuckoos

eggs-and-cuckoos

Nella foto di David Viani, vediamo un codirosso (a destra) che nutre un “piccolo” cuculo (a sinistra), decisamente più grande del genitore adottivo.

Premessa #

Uno dei motivi per crearsi una propria versione di Linux può essere quello di utilizzarlo su numerose postazioni, all’interno di un Ente, di una azienda o di una scuola.

Sicuramente il metodo migliore per effettuare un gran numero di installazioni è quello di utilizzare un server PXE che avvii le macchine della rete e consenta una installazione più veloce del DVD o della chiavetta.

D’altra parte, La configurazione di un server PXE richiede tempo ed esperienza e non è sempre disponibile, l’immagine iso del sistema da installare si.

Ecco, in eggs abbiamo aggiunto un server PXE autoconfigurante che vi permette tranquillamente di installare contemporaneamente più macchine semplicemebte avviandole dalla rete.

Avvio del server PXE #

Tutto quello che c’è da fare è avviare una live della distribuzione rimasterizzata con eggs, aprire una finestra di terminale ed avviare il comando: sudo eggs cuckoo. A questo punto la macchina si comporterà da server di boot per la nostra rete locale e noi potremo avviare altri computer utilizzando la rete locale stessa.

eggs-and-cuckoos

Avvio delle macchine da installare #

Bisognerà entrare necessariamente nella configurazione BIOS del sistema ed abilitare il boot dalla scheda di rete, nomarlmente dovrete abilitare PXE sulla scheda di rete e controllare le priorità di avvio.

A questo punto, avviate la vostra macchina selezionando il boot da rete:

eggs-and-cuckoos

Selezionando la prima opzione, verrà caricato il sistema operativo contenuto nella immagine, nel nostro caso una versione di MX Linux21.x rimasterizzata con eggs.

eggs-and-cuckoos

Non resta altro che effettuare l’installazione potremo scegliere sia calamares

eggs-and-cuckoos

che l’installazione con krill: sudo eggs install --unattended

eggs-and-cuckoos

Per l’installazione unattended sono disponibili alcuni flag:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
ommand-line system installer - the egg became a penguin!

USAGE
$ eggs install [-u] [-i] [-r] [-d <value>] [-S] [-s] [-n] [-k] [-p]
[-h] [-v]

FLAGS
-S, --suspend Swap suspend: RAM x 2
-d, --domain=<value> Domain name, defult: .local
-h, --help Show CLI help.
-i, --ip hostname as ip, eg: ip-192-168-1-33
-k, --crypted Crypted CLI installation
-n, --none Swap none: 256M
-p, --pve Proxmox VE install
-r, --random Add random to hostname, eg: colibri-ay412dt
-s, --small Swap small: RAM
-u, --unattended Unattended installation
-v, --verbose Verbose

DESCRIPTION
command-line system installer - the egg became a penguin!

EXAMPLES
$ eggs install
Install the system using krill installer

che consentono facilmente installazioni multiple.

Commenti: Facebook group. Telegram, Github issue

eggs 9.3.x manual

The move to eggs 9.3.x was mainly characterized by the introduction and improvement of the cuckoo command to get a PXE server directly from our live. While previously I used dnsmasq to get services proxy-dhcpd and dhcpd, actually thanks to FOGProject/node-dhcproxy we use just node and only a proxy-dhcpd service.

Having found that due to a grub problem, the field next from the dhcp offer of the proxy-dhcpd server was not read, we switched to using the more versatile ipxe as a network bootloader.

So it is no longer necessary to have an option for a real dhcpd service in the cuckoo command and we do not risk overlapping the network dhcpd.

Another novelty is the introduction of the command: eggs tools ppa which adds or removes the penguins-eggs-ppa repository to our apt sources list. Example:

1
sudo eggs tools ppa --add

Original edition of the eggs manual is released in Italian, of course other languages can be accessed using machine translation.

eggs-linuxfs-installed-via-pxe

Community choice badge

With some surprise eggs received the badge for 10,000 downloads!

Hi Piero Proietti,

Congratulations! Penguin’s eggs has just been recognized with a Community Choice award by SourceForge. This honor is awarded only to select projects that have reached significant milestones in terms of downloads and user engagement from the SourceForge community.

This is a big achievement, as your project has qualified for this award out of over 500,000 open source projects on SourceForge. SourceForge sees nearly 30 million users per month looking for, and developing, open source software. This award badge will now appear on your project page, and the award assets can be found in your project admin section.

To recognize Penguin’s eggs’s achievement, we’ve awarded you with the Community Choice award, which you can see below:

Le specie presenti

Continuando la nostra metafora abbiamo ormai quattro specie presenti:

  • duck
  • colibri
  • owl
  • eagle

Tutte le specie sono ottenibili da differenti distribuzioni Linux: Debian, Devuan ed Ubuntu. Inoltre, ad esempio per Debian è possibile ottenere un colibri sia da una versione bullseye che dalla versione bookworm, in Ubuntu sia da focal che da jammy e così via.

Si fa presto, quindi ad avere una grande quantità di specie.

L’importanza del wardrobe e della scelta dei costumi #

Avere le nostre specie sia in formato iso live installabili con calamares che in formato script ci permette di poterle diversificare ulteriormene o prenderne spunto per aggiungere altre configurazioni.

Ad esempio, con queste specie ho esplorato abbastanza il mondo cinnamon ed xfce4, trascurando però gli altri: KDE, gnome3, mate, LXQT, etc.

D’altra parte, mentre tutto sommato mi è stato possibile scrivere un software per la rimasterizzazione comune a più versioni o, almeno ho acquisito le necessarie esperienze, lo stesso non può dirsi per tutte le differenti customizzazioni possibili: kde, gnome, cinnamon, xfce, per il desktop manager, X11 e wayland per il compositore, grafica, office, giochi, lato serve e quant’altro.

Diciamo quindi che ho esplorato le possibilità nei rami che conosco e sono abbastanza sicuro che colibri - che ha lo scopo di sviluppare eggs - sia perfettamente funzionale, mentre per duck ed owl rispettivamente per un uso generico e per la grafica, pur avendo adottanto delle selezioni di software ragionevoli, beh dovrei essere un utilizzatore generico o un grafico per poter rispondere in maniera affermativa.

D’altra parte, poter accedere e modificare deile customizzazioni esistenti in luogo di dover completamente reinventare la ruota ha comunque i suoi vantaggi: in primo luogo abbamo già qualcosa funzionante e degli esempi che possiamo seguire e/o modificare, inoltre abbiamo un percorso che ci permette di “cucire” costumi diversi utilizzando quelli che più si adattano alle nostre necessità, che possono essere le più svariate.

Sarebbe carino realizzare una specie “giocosa”, altri gradirebbero una interfaccia KDE magari configurata con un aspetto simile a mac e via dicendo.

Quello che posso ed ho potuto fare è fornire uno strumento per facilitare questo, una sorta di “remastering on rail”, per il resto mi manca sia il tempo che la pazienza che creare ulteriori specie.

Questo può essere quindi il vostro compito, oltre che riportare le eventiali difficoltà d’uso, i bug e via dicendo.

Eggs è rimasto uno strumento a riga di comando per uno scopo preciso, permettere la creazione o la ‘ri-creazione’ di sistemi CLI ovvero senza interfaccia grafica.

Sinora ho trascurato molto la sezione server, anche perchè non essendo più al lavoro non ne ho una vera necessità. Vero poi che attuamelmente esistono tante customizzazioni installabili semplicemente con docker, ma d’altra parte anche configurarsi in toto il proprio server, non necessariamente virtuale potrebbe avere i suoi vantaggi.

Anche qua però vale lo stesso discorso: è possibile fare di tutto dalla macchina per sviluppare sulla blockchain, al semplice server samba, ad una installazione XAMPP, etc ma - il motore di questo - è la necessità.

Quindi e vorrei concludere, eggs rende possibile la rimasterizzazione di ben tre diverse tipologie di distribuzione Linux e comprende uno scripting per creare, conservare e consolidare le proprie customizzazioni.

Come dimostrato per manjaro eggs può essere esteso anche su altre distribuzioni non necessariamente di derivazione Debian e difatti, tempo fa con la collaborazione di Stefano Capitali, lo abbiamo portato eggs su manjaro.

In aggiunta, resta tutta da esplorare la possibilità di utilizzare eggs su architettura ARM: sia armel che arm64, mentre - mio malgrado - non possiamo sperare in future versioni per i386 visto che node dalla versione 10 in poi non supporta più tale architettura.

Che dire?

Esplorate nelle aree di vostra pertinenza, quelle che conoscete meglio ad esempio molti customizzatori amano Mate, altri sono appassionati di ingegneria, che di grafica, di fotografia, etc.

Teniamoci in contatto.

Mi farebbe molto piacere assistere alla nascita di ulteriori costumizzazioni, sia lato server che lato desktop e d’altra parte avere una ragionevole comunità di utenti sarebbe sia un grosso stimolo che un importante canale di suggerimenti e feedback, non trascurando naturalmente l’amicizia.

Buon viaggio dal parco degli uccelli!

presentazione wardrobe

Dicono che a volte un video è meglio di mille parole.

Pur ritenendomi migliore nelle parole che nei video, nondimeno provo ad illustrarvi come creare una vostra live originale con eggs e come vestire una versione naked.

Non sono un esperto del multimedia, ho una voce bassa - ma proprio bassa - però forse seguire il video può darvi una idea sia della versatibilità di eggs sia della potenza del wardrobe e dei costumi per creare delle versioni custom di Linux.

01 presentazione wardrobe #

Mentre eggs produce ci permette di rimasterizzare il nostro sistema, wardrobe ci permette di definire la nostra customizzazione.

Customizzare un sistema può essere da banale ad estremante complesso, in ogni caso è qualcosa che viene effettuato spesso per tentativi ed errori e ripercorrendo le esperienze precedenti.

Wardrobe, permette di riutilizzare le nostre configurazioni e riutilizzarle per definire nuovi costumi, in qualche modo ci permette di consolidare la nostra esperienza, consolidarla e condividerla.

Il concetto di costume è quello di una customizzazione, si parte da un sistema senza alcuna interfaccia e - senza alcuno scopo - se non la capacità di autoriprodursi e lo si veste per le proprie esigenze: un desktop da lavoro, un server per il multimedia e via dicendo.

Non solo, mentre intendiamo per costume la vestizione finale risultante, ad esempio colibri potrebbe essere definito un sistema di sviluppo, owl un sistema specializzato per la grafica e via dicendo, all’interno del costume potremmo utilizzare sei sotto-costumi denominati accessories per le più svariate necessità. Ad esempio l’accessorio eggs-dev che installa visual studio code, nodejs viene utilizzato da più costumi, lo stesso può dirsi per i firmwares etc.

Il risultato della definizione di un costume è una cartella in costumes denominata nel nostro esempio colibri, all’interno della quale è presente un file index.yml che definisce il costume stesso e richiama gli eventuali accessori.

Nel video vedrete il risultato finale della nostra configurazione, la possibilità di passare da un sistema naked ad uno configurato secondo le nostre esigenze

02 Installazione di calamares, configurazione e creazione dell’immagine live #

Una volta che il nostro sistema è installato, dovremo installare calamares che verrà configurato per l’installazione della nostra immagine live che andremo a costruire con eggs produce.

L’immagine una volta creata dovrà essere esportata e messa su una chiavetta USB per essere utilizzata per avviare un altro sistema con la nostra live.

03 Installazione della nostra live su un nuovo sistema #

A questo punto non ci resta che vedere il risultato finale della nostra configurazione, ovvero un sistema creato da noi stessi, per le nostre necessità creato con cura professionale.

flatpak

Aggiungere flatpak a colibri è stato semplice, in fondo sono solo due pacchetti. Ho creato al volo un accessorio e l’ho aggiunto al wardrobe.

Più difficile, forse è comprendere un nuovo paradigma che è sorto: non stiamo più lavorando per le uova ma per i pulcini.

colibri, in effetti, nato per le mie personalissime esigenze, con l’aggiunta del market flatpak in effetti è pronto a tutto, a distanza di un click per aggiungere un gioco per il bimbo, un click per editare i nostri documenti, un esempio di come installare nuovi software per convincere un utente restio a passare a Linux.

colibri, non è una distribuzione, alla fine è giusto un costume da apporre a Debian/Devuan/Ubuntu e non è manco il solo.

La grossa forza di Android: il market - nella specie quello disponibile con flatpak - è a portata di mano, la possibilità di personalizzazione di wardrobe è immensa, quella di creare una propria iso installabile con eggs ed installarla con calamares, krll e magari un domani con os-installer o live-installer di Linux Mint anche.

Aiuto! Non riesco più a distinguere l’uovo dalla gallina…

colibri-fastpak

ubuntu 22.04 e wardrobe

Da qualche giorno è uscito Ubuntu 22.04 l’ultima release LTS di Ubuntu.

Ho provato a testare la compatibilità con eggs e con la nuova funzionalità warbrobe.

Mentre per quanto riguarda eggs non vi è molto da segnalare, eggs semplicemente funziona e riproduce correttamente la nuova release, qualche problema insiste invece sul funzionamente del wardrobe.

funzioni di rimasterizzazione (eggs) #

Ho provato a rimasterizzare Ubuntu 22.04 nella varie versioni: gnome, xfce, kde ed lxqt (Ubuntu, Xubuntu, Kubuntu e Lubuntu), eggs ha correttamente ricreato le rispettive iso senza sorprese.

funzioni di masterizzazione (wardrobe) #

Il problema in questo caso, non è tanto il funzionamento di wardrobe, ma la mancanza di un procedura chiara per ottenere una iso di Ubuntu 22.04 esclusivamente CLI e minima, per intenderci di una corrispondente netinstall di Debian/Devuan.

Ho provato sia a partire dalla versione server selezionando l’installazione minima che quella con maggiori configurazioni, il risultato non è stato soddisfacente. L’insieme dell’ISO supera il GB ed inoltre vi sono problemi per l’avvio della rete. Praticamente al momento del boot da live, il sistema attende il timeout per la configurazione della rete, facendoci aspettare grosso modo due minuti prima che si verifichi.

Per cercare di ovviare, ho provato a “spogliare” una installazione Xubuntu minima, rimuovendo XFCE, Xorg, lightdm, etc.

Purtroppo anche in questo caso si verifica lo stesso inconveniente e restano comunque dei pacchetti spuri.

Creazione di colibri, owl e duck da wardrobe #

Per ovviare al problema, approfittando del fatto che Ubuntu permette una installazione minimale della distro sia pure con interfaccia grafica, ho utilizzato l’installazione minima di Xubuntu basata su XFCE per ri-creare colibrì ed owl.

Per owl ho inoltre rinunciato al kernel liquorix, in quanto non è presente una repository per ubuntu jammy.

Inoltre, non ho installato hardware, facendo conto sulla installazione standard di Ubuntu che già lo comprende.

Per quanto riguarda duck ho proceduto nel medesimo modo, rimuovendo alla fine la sessione di XFCE e le sue dipendenze.

Conclusioni #

C’è poco da dire alla fine, con wardrobe, è possibile creare in maniera agevole una customizzazione riusabile anche in altri contesti.

Delle quattro versioni realizzate per Debian: colibrì,duck, eagle ed owl siamo riusciti a farle girare anche in Devuan/Ubuntu con poche o nulle modifiche.

Questo secondo me è una gran cosa, perchè ci permette di automatizzare parzialmente il nostro lavoro di customizzazione.

D’altra parte - e non può essere che così - integrare sistemi diversi ed aggiungere nuove feathure è normalmente un mestiere difficile che richiede buona conoscenza tecnica e, spesso, numerosi tentativi per realizzare una release che ci soddisfi.

Anche per questo, non vorrei rimanere solo su questa strada, ormai le customizzazioni nelle quali sono esperto funzionano egregiamente, manca di espandersi verso altri lidi: server, altri desktop, etc.

C’è bisogno quindi di condividere informazioni ed esperienze e per questo vi invito a collaborare al progetto.

Wardrobe, rende la customizzazione replicabile e concentra nel “costume” i passi fatti per realizzarla, consolidando la nostra esperienza e facilitandoci uno scambio di informazioni.

Perchè non approfittarne?

colibri
duck
owl

Nota: potete trovare le iso con i “costumi”

  • colibrì (sviluppo)
  • duck (general)
  • eagle (virtualizzazione)
  • own (grafica, multimedia)

create con Debian bullseye, Devuan Chimaera ed Ubuntu 20.04 jammy nei rispettivi link:

Oppure potere ricrearle a partire dalle rispettive versioni naked.

wardrobe: colibri, duck, eagle and owl

Dopo qualche settimana di esperienza dalla creazione di un sistema di scripting per creare - a partire da versione naked - delle customizzazioni complete, sono lieto di annunciare che tutte le mie attuali customizzazioni sono stare ri-create e vengono ad essere gestite con eggs wardrobe.

Perchè wardrobe è importante? #

Pensate solo alla semplicità con la quale posso permettermi di gestire la presenza o meno di firmware, condividere degli accessori, ritrovare in dettaglio le varie configurazioni, etc.

Il processo di una customizzazione di una sistema è una operazione relatimente complessa, se precedentemente avevamo a disposizione un sistema di rimasterizzazione, a partire da remastersys, passando per systemback sino ad eggs, non mi è mai capitato di imbattermi in un sistema di masterizzazione, ovvero costruire una customizzazione partendo da una base minima.

wardrobe è basato su yaml e consiste essenzialmente nela definizione di costume che saranno “indossati” dal sistema in progetto attraverso una sequence di operazioni che - del resto - conosciamo benissimo:

  • aggiungere o modificare repository
  • aggiungere o rimuovere pacchetti, inclusi nuovi kernel
  • aggiungere pacchetti python
  • customizzazione

Ogni volta che creaiamo una nuova customizzazione ci scontriamo con due generi di problemi:

  • rimuovere tutto quello che non interessa
  • ricordare e manutenere le operazioni fatte.

Il primo probleam può essere risolto, tutto sommato abbastanza semplicemente, partendo da una installazione minima - senza interfaccia grafica - che io denomino naked.

Il secondo problema, viene affrontato con la definizioni dei costume.

costume #

Un costume è essenzialmente costituito da una directory denominata come il costume ed in file index.yml.

La seguente è una definizione di un costume.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# esempio
---
name: esempio
author: artisan
description: questo è un esempio di costume
release: "0.0.1"
distributions:
- bullseye
sequence:
repositories:
sources_list:
- main
- contrib
- non-free

sources_list_d:
- null

update: true
upgrade: true

preinst:
- null

packages:
- cinnamon
- firefox

packages_no_install_recommends:
- null

debs: false

packages_python:
- null

accessories:
- grafica

customize:
dirs: true

hostname: true

scripts:
- desktop_links_set

reboot: true

Si noti che ho volutamente incluso tutti i possibili item, includendo alcuni che non sono valorizzati e che quindi per semplicità sarebbe stato corretto omettere: sources_list_d, packages_no_install_recommends, etc.

costume #

Andiamo ad analizzare il nostro esempio, passo per passo:

Instestazione #

1
2
# esempio
---

Qui c’è poco da dire, si tratta di informazioni per aiutare noi poveri umani a capire di cosa si tratta, sino a — possiamo scriverci quello che ci pare.

Generalità #

1
2
3
4
name: esempio
author: artisan
description: questo è un esempio di costume
release: "0.0.1"

Anche qui poco da dire, queste sono le informazioni generali che verranno riportate dal comando eggs wardrobe list per una semplice visione d’insieme.

distributions #

Riporta una lista dei codename delle distribuzioni compatibili con il costume. Esempio: bullseye, bookworm ma anche focal, jammy, chimaera, etc.

Naturalmente il nostro costume può essere indossato dal sistema solo se il suo codename lsb_release -sc è compreso nella lista distributions.

sequence #

La sequence, individuata per essere il più possibile atomica e coerente, è naturalmente la parte centrale del costume.

Consiste in una sezione repositories ed item per l’installazione dei pacchetti o dalle repository o dalla apposita cartella debs inclusa - se utilizzata - nel costume.

Andiamo a vedere la sequence in dettaglio.

repositories #

Come sappiamo le repositories vengono normalmente definite nel file /etc/apt/sources.list ed all’interno della directory /etc/apt/sources.list.d

Qua la suddivisione è la medesima.

sources.list #

In questa sezione vengono specificati semplicemente i componenti da utilizzare:

  • main
  • contrib
  • non-free

Ovviamente i componenti specificati dovranno essere presenti nel nostro file /etc/apt/sources.list. Tuttavia verrà emesso solo un avviso, questa configurazione non è bloccante, poichè - nello specifico linuxmint - non utilizzano il file /etc/apt/sources.list preferendo una diverso configurazione.

sources.list.d #

Quante volte vi sarà capitato di fare il taglia ed incolla per aggiungere repository ad un sistema? Beh, qui semplicemente andiamo ad aggiungere i medesimi comandi all’interno del costume.

Ad esempio, per aggiungere le repository per nodejs e visual studio code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
sources_list_d:
- rm -f /usr/share/keyrings/packages.microsoft.gpg
- >-
curl -fsSL "https://packages.microsoft.com/keys/microsoft.asc" | gpg
--dearmor -o /usr/share/keyrings/packages.microsoft.gpg
- >-
echo "deb [signed-by=/usr/share/keyrings/packages.microsoft.gpg
arch=amd64] http://packages.microsoft.com/repos/code stable main" | tee
/etc/apt/sources.list.d/vscode.list > /dev/null

- rm -f /usr/share/keyrings/nodesource.gpg
- >-
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource.gpg.key | gpg
--dearmor -o /usr/share/keyrings/nodesource.gpg > /dev/null
- >-
echo "deb [signed-by=/usr/share/keyrings/nodesource.gpg]
https://deb.nodesource.com/node_16.x `lsb_release -cs` main" | tee
/etc/apt/sources.list.d/nodesource.list > /dev/null

Notate che alcune linee cominciano con il simbolo - >-, questa è una specifica di yaml che permette semplicemnte di scrivere su più righe.

Si noti pure che la prima operazione è una rimozione del file signed-by, questo è utile per non avere interruzioni del processo se lo stesso file è già stato scaricato.

Anche qua, rivolgendomi ad integratori di sistema vi è ben poco da aggiungere, cercato su google i comandi per la repository interessata dalla quale dovete scaricare i pacchetti ed aggiungeteli all’interno di sources_list_d.

update #

Naturalmente prima di poter scaricare i pacchetti dalle repository aggiunte va eseguito un apt updatem per cui normalmente l’item update è configurato normalmente a true.

upgrade #

Qua vi è maggiore libertà, se upgrade è true prima dell’installazione dei pacchetti verrà fatto un aggiornamente generale: apt full-upgrade,

preinst #

Succede che prima di installare un pacchetto, vi sia bisogno di configurazioni particolaru. Un caso specifico è l’installazione di proxmox-ve che richiede nella configurazione dell’host di valorizzare l’indirizzo ip dello stesso,

preinst viene utilizzato per questo scopo.

packages #

Qui viene riportata la lista dei pacchetti da installare, nel nostro caso: cinnamon e firefox-esr. Notate che in packages l’installazione avverrà sia per i pacchetti stessi che per i pacchetti specificati come recommanded all’interno dei pacchetti richiesti, per cui cinnamon si porterà dietro tutto il necessario: xorg-server, lightdm, etc

packages_no_install_recommends #

Vi sono casi in cui non conviene scaricare i pacchetti raccomandati, packages_no_install_recommends viene utilizzato per questo scopo.

debs #

Specificando debs: true ed aggiungendo all’interno del costume una cartella debs è possibile installare pacchetti custom non presenti in una repository specifica.

packages_python #

Possiamo anche installare pacchetty python con pip, basterà aggiungere i pacchetti pyhon a questa lista.

accessories #

Come detto in precedenza, la sequence è il pù possibile atomica e cioè indivisibile, non di meno è possibile suddividere il nostro lavoro di vestizione in più parti, ad esempio: interfaccia grafica, ufficio, multimedia, firmware, etc.

Questi costumi, non sono completi di norma, ma sono considerati accessori del costume principale e possono essere interni - contenuti all’interno del costume stesso come sottodirectory oppure nella cartella accessories all’interno del wardrobe,

Naturalmente questo ci facilita notevolmente il lavoro e permette di utilizzare gli stessi accessori su costumi diversi. Di norma - ma sto sperimentando anche io - conviene partire inizialmente con accessori interni poi - quando il lavoro è consolidato - sarà sufficiente transitare l’accessorio nel cassetto del wardrobe per poterlo utilizzarlo su altri costume.

customize #

customize si compone al momento di dirs ed hostname - variabili booleane - e scripts di customizzazione.

dirs #

E’ possibile inserire all’interno del costume una directory dirs contentente tutte le nostre modifiche al file system del sistema.

La cartella verrò copiata ricorsivamente nella root del sistema e porterà con sè la nostra customizzazione, Normalmente vengono utilizzate dirs/etc/skel e dirs/usr/share/backgrounds per la configurazione iniziale dell’utente e degli sfondi.

hostname #

Se hostname è impostato a true il sistema verrà ridenominato con il nome del costume. Ad esempio: colibri

scripts #

Gli scripts vengono chiamati come specificato dalla lista e vengono passati i parametri $1 e $2 come nome dell’utente chiamante e path per il desktop, tradotto secondo lo schema xdg.

reboot #

In caso di costume questo campo è sempre true e comporterà il reboot alla fine della sequenza e della customizzazione. Nel caso di accessorio questo campo non è specificato o sarà specificato come false.

1
2
3
4
5
dirs: true
hostname: true

scripts:
- desktop_links_set

ISO create con wardrobe #

Potete trovare le mie customizzazioni sotto ISOs/Debian/bullseys sulla pagina del progetto penguins-eggs.