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.

wardrobe accessories

Ieri ho creato un “vestitino” giusto per aggiungerlo ad una remix di Linuxmint elsie che, come noto, è di base estremamente completa.

Ho pensato a qualcosa per effettuare le modifiche che normalmente faccio e cioè:

  • aggiungere la repository di penguins-eggs-ppa;
  • aggiuntere code e nodejs per poter utilizzare la remix per sviluppare eggs.

Questa soluzione è molto comoda, di norma, anche se ho sempre preferito lasciare le varie distribuzioni così come le trovato, rimasterizzarle aveva principalmente come obiettivo quello di “provare” il funzionamento di eggs e, permettere, agli utenti una propria customizzazione, nondimeno andavo ad aggiungere almeno spice-vdagent per ridimensionare le finustre delle mia macchine virtuali e poter effetture il copia ed incolla.

basic mi evita questo, la customizzazione di base è a portata di riga di comando completamente automatizzata.

Di più, ovvio che una customizzazione di questo genere, non porta con se la conseguenza di ridenominare l’host e neppure quella di effettuare il reset del sistema a fine installazione.

E se mi organizzassi per accessori?

Mi spiego: un costume potrebbe essere composto di “materiale” proprio e di richiami ad accessori. Potremmo definire accessori dei particolari del costume, dei sottoinsiemi, ad esempio:

  • basic: repository penguins-eggs-ppa, packages: spice-vdagent, dirs/usr/share/backgrounds/penguins-wallpapers:
  • eggs-dev: repository: code, nodesource, packages: code, nodejs:
  • firmware: firmware non necessari per immagini che girano solo su VM:
  • office: libreoffice
  • A questo punto, prendendo per riferimento hen, avremmo una bella semplificazione:
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
49
50
51
52
53
54
55
56
57
58
59
60
61
# hen
---
name: hen
description: desktop xfce3, all I need to develop eggs and firmware
author: artisan
release: 0.0.3
distroId: Debian
codenameId: bullseye
releaseId: stable
applyTo: naked
sequence:
repositories:
sourcesList:
main: true
contrib: true
nonFree: true
sourcesListD:
curl -fsSL "https://keys.anydesk.com/repos/DEB-GPG-KEY" | gpg --dearmor
-o /usr/share/keyrings/anydesk-stable.gpg
- >-
echo "deb [signed-by=/usr/share/keyrings/anydesk-stable.gpg]
http://deb.anydesk.com/ all main" | tee
/etc/apt/sources.list.d/anydesk-stable.list > /dev/null
update: true
full-upgrade: true
dependencies:
- null
packages:
- adwaita-qt
- firefox-esr
- libxfce4ui-utils
- lightdm
- network-manager-gnome
- network-manager-openvpn
- network-manager-openvpn-gnome
- qt5ct
- tango-icon-theme
- thunar
- xarchiver
- xfce4-appfinder
- xfce4-panel
- xfce4-pulseaudio-plugin
- xfce4-session
- xfce4-settings
- xfce4-terminal
- xfce4-whiskermenu-plugin
- xfconf
- xfdesktop4
- xfwm4
debs: false
dirs: true
accessories:
- basic
- eggs-dev
- firmware
- office
hostname: true
customizations:
scripts:
- null
reboot: true

Il nuovo costume hen, andrebbe a prendere XFCE4 da se stesso e potrebbe aggiungere gli accessori: basic, eggs-dev. firmware ed office.

Non solo, ovviamente firmware potrebbe essere un accessorio per gwaydroid e kwaydroid e, più in generale per dove si vuole ottenere una remix installabile su hw reale.
Lo stesso varrebbe per gli altri accessori, esempio: vogliamo che con la iso di gwaydroid si prossa utilizzare per lo sviluppo di eggs? Aggiungiamo eggs-dev, ci occorre la suite office per una remix “corposa” aggoimgiamo office.

Il tutto al momento è solamente un’idea, ma scrivendolo sto già pensando a come organizzarmi.

accessories

Dove mettere gli accessori?

Un accessorio potrebbe comprendere anche grafica e, quindi, dovrebbe andare in penguins-wardrobe più che in wardrobe.d interno ad eggs. D’altra parte sarebbe comodo avere basic all’interno di eggs per eseguire una customizzazione leggera.

Gli accessori dovrebbero essere distinti dai costumi?

E’ scocciante, però penso di si, si potrebbe creare una directory all’interno del wardrobe per gli accessori. Peò un accessorio è pur sempre un costime e, quinid, in sede di ricarca dovremmo cercare prima tra i costumi e poi nel tiretto degli accessori.

Quale è la migliore soluzione? Non lo sò, al momento, ma l’idea di un settimino all’interno del guardaroba mi attizza.

wardrobe ironing

Ho pensato di utilizzare un file yaml per definire i pacchetti e le modifiche da attuare per passare da una configurazione generica, senza interfaccia grafica ne’ servizi, ad una customizzazione, anche spinta come andremo a vedere.

L’idea è nata sulla scorta della mia partecipazione al progetto di BlissOS per portare Android su Linux, parlando con Jon West che avrebbe avuto il bisogno che includessi un particolare driver sulla mia immagine iso.

Normalmente, preferendo sviluppare eggs, non mi occupo molto di firmware, tendo a preferire l’uso di macchine virtuali che mi accorciano e rendono possibile il mio lavoro di testing.

Pensando a come risolvere il problema, ed essendo passato un po’ anche su majaro, ho pensato di utilizzare un file .yaml per la gestione dei pacchetti, qualcosa di semplice da mantenere, poi di metterlo in una directory chiamata “costume” e, quindi, aggiungere tutti i costumes creati in un “wardrobe”.

Insomma ho immaginato un armadio con una serie di vestiti da indossare su una installazione naked, ovvero senza GUI.

A questo punto, per ottenere lo scopo, ho aggiunto anche una cartella dirs, nella quale vado a porre tutti i file che voglio nel sistema finale. Sostanzialmente dirs viene copiata con rsync sulla /, inoltre per dirs/etc/skel ho pensato di copiare i files anche nella home utente.

Ho previsto anche una cartella debs, dove porre i pacchetti *.deb non reperibili da repository, e qualcos’altro.

Poi mi sono messo a programmare un sistema per vestirsi (wear) in una classe denominata sarto (tailor).

tailor analizza il file index.yml e la directory del costume stesso ed esegue le operazione specificate in index.yml.

Ecco un semplice esempio di index.yml per una banale installazione lamp:

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
 costume: lamp
# tailor: artisan
---
name: lamp
description: 'LAMP: linux, apache2, mysql, php example, completely untested!'
author: artisan
release: 0.0.2
distroId: Debian
codenameId: booksworm
releaseId: unstable
applyTo: naked
sequence:
repositories:
sourcesList:
main: true
contrib: true
nonFree: true
sourcesListD:
- curl -fsSL "https://pieroproietti.github.io/penguins-eggs-ppa/KEY.gpg" | gpg --dearmor -o /usr/share/keyrings/penguins-eggs-ppa.gpg
- echo "deb [signed-by=/usr/share/keyrings/penguins-eggs-ppa.gpg] https://pieroproietti.github.io/penguins-eggs-ppa ./ " | tee /etc/apt/sources.list.d/penguins-eggs-ppa.list > /dev/null
update: true
full-upgrade: true
packages:
- apache2
- mysql-server
- php
- phpmyadmin
debs: false
dirs: false
hostname: true
customizations:
scripts:
- null
reboot: true

Dovrebbe risultare immediato,

Questo è l’esempio per una piccola installazione lamp. l’esempio più completo è quello di hen,

Fino a che questi index.yml erano abbastanza corti, me li ordinavo da solo con l’editor.

Avendo preso per il costume hen, le repository, i package ed il firmware dal progetto quirinux-os ben più fornito del mio, mi sono reso conto che ci voleva qualcosa per suddividere la sequenza ed ordinare i pacchetti all’interno delle varie tipologie, così oggi ho aggiunto un nuovo comando ironing (stirare).

Naturalmente è un lavoro in corso, praticamente sto decidendo che nomi e quali tipologie passi utilizzare. Ad esempio ho suddiviso firmwares in:

  • drivers_wifi
  • codecs
  • drivers_various
  • drivers_video_amd
  • drivers_video_nvidia
  • drivers_graphics_tablet
  • drivers_printer
  • drivers_network

prendendo spunto dal tuo script https://github.com/quirinux-so/instalar-quirinux

Mi sembra che stia funzionando abbastanza… almeno per hen - la mia stazione di sviluppo - ma anche per gwaydroid ed i due tre esempi.

Che ne pensate?

Un breve video…

https://youtu.be/R44gvjOMWLo

è nato prima l'uovo o la gallina?

Quante volte da bambini ci siamo fatti questa domanda? Da grandi, forse abbiamo trovato anche la risposta: è nato prima l’uovo.

In questo caso, non stiamo parlando di biologia ma di sviluppo di software: eggs è un sistema di rimasterizzazione che consente di creare una live a partire da un sistema installato.

Hen, invece, la femmina del pinguino, è la macchina di sviluppo utilizzata per creare eggs.

Ed anche in questo caso, è nato prima l’uovo.

penguin’s eggs wardobe.d

Ultimamente sto sviluppando un sistema di customizzazioni dove tenere traccia ed automatizzare gli svariati passi che conducono ad una customizzazione.

Ho definito come wardrobe (guardaroba) l’armadio dove vengono custoditi e costumi di scena che l’uovo/pulcino - una volta installato - può indossare.

Così, se avviamo una configurazione naked, leggerissima, solo CLI e la installiamo con sudo eggs install (conosciuto anche come krill installer) otteniamo un sistema nudo che potrà essere customizzato in ogni direzione.

Il costume è appunto la customizzazione. Una sorta di riassunto dei passi che facciamo per creare e consolidare la nostra customizzazione.

Potremmo a partire dalla versione naked passare and una lamp, installando apache2, mysql e php, oppure installare una interfaccia grafica, come xfce3, kde, gnome o altre.

Sino a quando la nostra customizzazione non sarà spinta, diciamo che aggiungeremo solo delle nuove repository e, da queste, installeremo i pacchetti, il nostro costume sarà veramente leggero. Così leggero che le versioni minime di xfce4, kde e lamp le trovate direttamente nella “valigetta” di eggs. Ovvero, fuor di metafora sono comprese in eggs stesso e potrete passare da una versione naked and una con xfce attraverso il comando:

1
sudo eggs wardrobe wear --costume xfce4

Naturalmente è possibile anche vedere il contenuto di un costume, con il comando:

1
eggs wardrobe show --costume xfce4

e la lista dei costumi contenuti all’interno di eggs stesso:

1
eggs wardrobe list

Scarichiamo un “armadio” più grande

Normalmente le nostre customizzazioni non sono solo semplici aggiunte di repositury e pacchetti, ma comprendono pure delle customizzazioni più profonde, necessitano di grafica, dischi immagine, etc.

Per questo, la nostra valigetta interna non basta, occorre un vero e proprio guardaroba: penguins-eggs-wardrobe.

Qui vedrete che ogni costume comprente una directory chiamata dirs che verrà sovrapposta alla radice del nostro sistema, andando a aggiornare/aggiungere qualsiasi file o configurazione - senza esagerare però - pur se ci troviamo all’interno di un sistema vergine e da configurare, sta tutto nelle nostre mani ed è possibile fare dei casini notevolissimi. D’altra parte, per customizzare, sovente, ci tocca andare a fondo e questa funzione è praticamente indispensabile.

Non solo il contenuto di dirs/ verrà copiato in /, ma il contenuto di /dirs/etc/skel verrà copiato come configurazione nella home dell’utente corrente, trascinandosi quindi tutte le nuove impostazioni.

Ci sono casi in cui occorre anche portarsi dietro altro, un caso di questi sono i costumi gwaydroid e kwaydroid, in questo caso, all’interno sono presenti anche alcuni script per l’installazione dell’immagine Lineage-17.1 o da host nella nostra rete locale o liberamente scaricabile da sourceforge.

bene, la nostra “gallina” è un costume!

hen la stazione di lavoro dalla quale “trasmetto” e sulla quale sviluppo eggs, è un costume!

Per installare il mio stesso sistema di sviluppo - icone e sfondi compresi - vi basta scaricare una versione naked di Debian, potete scegliere tra la stabile: bullseye e la unstable (bookworm), installare con il comando: sudo eggs install.

L’installazione è veramente semplice, utilizzando una TUI (Terminal User Interfaces) che sostanzialmente ricalca il funzionamento dell’installer calamares. Da questo nasce anche il nome dell’installer stesso che, viene denominato “krill”.

Una volta riavviata la macchina, potete scaricare penguins-wardrobe con il comando: git clone https://github.com/pieroproietti/penguins-wardrobe e divertirvi ad assistere a diverse vestizioni del pinguino.

Con il comando eggs wardrobe list –wardrobe penguins-wardrobe potrete scoprire quali sono i vestiti disponibili, al momento tre: gwaydroid, kwaydroid ed hen.

Ecco il comando per vestire il vostro pinguino come chioccia:

1
2
git clone https://github.com/pieroproietti/penguins-wardrobe
sudo eggs wardrobe wear --wardrobe penguins-wardrobe --costume hen

dressing he

ed attendere la fine della vestizione:

dressing hen installing packages

Eccoci qua, si è proprio il nostro sistema iniziale completamente trasformato nella stazione di lavoro per sviluppare eggs!

dressing hen enjoy

penguin's wardrobe

First of all, if we don’t have git, install git.
apt install git

After clone the wardrobe. The internal wardrobe of eggs, cannot include too much things.

Let’s go to clone:

1
git clone https://github.com/pieroproietti/penguins-wardrobe

After that we can see what costumes are included inside, for now just waydroid:

1
eggs wardrobe list --wardrobe ./penguins-wardrobe

Well, let’s go to wear this new dress!

1
sudo eggs wardrobe wear --wardrobe ./penguins-wardrobe --costume waydroid

result in…
dressing waydroid

costumes and wardrobes

This is a costume, a simple way to code our customizations starting from a naked system to a minimun KDE installation.

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
# recipe: kde
# author: artisan
---
name: kde
description: minimal KDE installation
author: artisan
release: 0.0.3
distroId: Debian
codenameId: booksworm
releaseId: sid
applyTo: naked
sequence:
repositories:
sourcesList:
main: true
contrib: true
nonFree: false
sourcesListD:
- curl -fsSL "https://pieroproietti.github.io/penguins-eggs-ppa/KEY.gpg" | gpg --dearmor -o /usr/share/keyrings/penguins-eggs-ppa.gpg
- echo "deb [signed-by=/usr/share/keyrings/penguins-eggs-ppa.gpg] https://pieroproietti.github.io/penguins-eggs-ppa ./ " | tee /etc/apt/sources.list.d/penguins-eggs-ppa.list > /dev/null
update: true
full-upgrade: true
packages:
- kde-plasma-desktop
- plasma-nm
- ark
- kate
- kcalc
- kde-spectacle
- firefox-esr
- okular
debs: false
dirs: false
hostname: true

customizations:
scripts:
- null

reboot: true
...

eggs come with a new command: wardrobe.

You can prepare your costumes to dress your penguins, costumes are simple and automatic configuration. A costume consists just on a dir named after the costume and an file index.yml, as you can note, we have large spaces for others future addictions: debs, icons, themes and so on.

Inside wardrobe.d you will find same simple examples: xfce4 and KDE costumes.

Logic of costumes

penguin-sailor

Logic for costumes is enought simple, we have a directory named after the costume and an index.yml.

In index.yml, we have:

sequence

Here we define the sequence of that we will do. Example:

1
2
3
4
5
6
7
8
#
# We start here, step by step
#
sequence:
repositories:
sourcesList:
main: true
(...)

repository

Here we define that will do with repositories, usually four tasks, the first sourcesList it’s to check that component must be present in /etc/apt/sources.list: main, contrib, non-free. The second sourcesListD, commands to adds other repositories to ```/etc/source.list.d’’’. The third task is mandatory update, the forth can be optional full-upgrade. Example:

1
2
3
4
5
6
7
8
#
# steps for repositories
#
repositories:
- sourcesList
- sourcesListD
- update
- full-upgrade

In the upper example I excluded step sourceListD, becouse actually I have same problems with my pubblic key.

sourcesList

Here we define, that components we need. Example:

1
2
3
4
5
6
7
#
# components to be added to /etc/apt/sources.list
#
sourcesList:
main: true
contrib: true
nonFree: false

sourcesListD

Here we define commands to add other repositories to /etc/apt/sources.list.d
example:

1
2
3
4
5
6
#
# add entries on /etc/apt/sources.list.d
#
sourcesListD:
- curl -fsSL "https://pieroproietti.github.io/penguins-eggs-ppa/KEY.gpg" | gpg --dearmor -o /usr/share/keyrings/penguins-eggs-ppa.gpg
- echo "deb [signed-by=/usr/share/keyrings/penguins-eggs-ppa.gpg] https://pieroproietti.github.io/penguins-eggs-ppa ./ " | tee /etc/apt/sources.list.d/penguins-eggs-ppa.list > /dev/null

packages

As the name, here we define packages we need will be installed:

1
2
3
4
5
6
#
# packages to be installed
#
packages:
- kde-plasma-desktop
- plasma-nm

debs

We define here a place, inside our recipe, containg all the custom debs we need. In this case the directory is named debs. You can choose others name, but I think can be better to name it in accord to the scope.

1
2
3
4
#
# local dir with deb files to be installed
#
debs: false

accessories

We define others packages we want to let to the user to install or not. Like accessories to our costume.

1
2
3
4
5
6
7
8
9
10
#
# accessories for your dress
#
accessiories:
- ark
- kate
- kcalc
- kde-spectacle
- firefox-esr
- okular
1
2
hostname: true
reboot: true

your wardrobe

It’s possible to create your own local wardrobe, and create personal costumes. In your costumes on your local wardrobe, you can add a place for debs, for your custom special debs you need.

Considerations

penguin-grill

Costumes are not limited to the interfaces: Desktop Enviroment and so on. It’s possible to create a dress on a system to be server for xampp or others configurations. Again, you can make an xfce4 installation specialized for eggs developer and name it hen, You will add: xfce4, nodejs-16.x, git and code. Of course, you can dress your image with the specific firmware too, and so on.

This let me to create, simple and light naked system, and the entire work of customization can go on the side of passionate system integrators.

Suggestions are welcome

penguin-pirate

It’s a new feathure, so - as usual - you can find problems, lacks and so on.

Suggestions and ideas are welcome: together we can see how your ideas can fit inside.

Feel free to open an issue on github - preferred - or to email me at: piero.proietti@gmail.com

Credits

I want to thanks Jon West from waydroid, from his needs and our discussion come this idea, and pixabay.com, from where I still some fantastic free images!

eggs wardrobe list

eggs wardrobe wear --costume waydroid

access to a VM from egg-of-debian-bullseyes-pve

egg-of-debian-bullseye-pve

Possiamo utilizzare la nostra immagine iso in molteplici situazioni:

  • sperimentare le possibilità della nostra iso creando all’interno di una installazione di Proxmox VE una VM abilitata per la virtualizzazione nested;
  • utilizzare egg-of-debian-bullseye-pve per avviare un server Proxmox e montare una VM dello stesso.
  • installazione Proxmox VE completa di Workstation;

Primi passi

Per sperimentare, la possibilità più semplice è quella di creare una VM con processore host, allo scopo di permettere la virtualizzazione nested.

Andiamo quindi a creare la nostra macchina, non servirà neppure un volume di installazione, in quanto utilizzeremo la VM solo in modalità live.

Creazione di real-storage

Una volta avviata la nostra live con proxmox, dovremo naturalmente create uno storage reale, dove avremo i dischi e le iso delle nostre macchine virtuali.

Per simulare la presenza di uno storage sulla nostra live, andremo a montare con sshfs lo storage della installazione ospitante, normalmente presente in ‘’’/var/lib/vz```

1
2
mkdir /real-storage
sshfs root@192.168.61.2:/var/lib/vz /real-storage

Vediamo cosa contiene il nostro storage:

1
dump  images  private  snippets  template

Non ci resta che montare questo real-storage sulla nostra live, attraverso l’interfaccia di Proxmox-VE.

Selezioniamo data center, quindi “Storage” e clicchiamo su Add. Andremo ad aggiungere lo storage come directory.

add-real-storage

Abbiamo visto che il nostro “real storage” contiene dump images private snippets template per cui nel nostro storage configuriamo:

Disk Imange, ISO image, tralasciando il resto.

add-real-storage

Queste sono le nostre immagini delle VM dell’ospite
add-real-storage

E quest’altre le varie immagini iso presenti sull’host
add-real-storage

Creare una VM sulla live utilizzando lo storage-real

A questo punto non ci resta che copiare la configurazione della macchina che ci interessa, dall’installazione reale alla nostra home:

1
scp root@192.168.61.2:/etc/pve/qemu-server/300.conf .

ed otterremo il seguente file di configurazione:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 2
efidisk0: local:300/vm-300-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: local:iso/archlinux-2022.02.01-x86_64.iso,media=cdrom
memory: 8192
meta: creation-qemu=6.1.1,ctime=1644734076
name: kisslinux
net0: virtio=96:2F:E5:8A:35:3D,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: local:300/vm-300-disk-1.qcow2,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=81f92f87-08cd-4e1b-bc0a-bc4f16d2f409
sockets: 2
vga: qxl
vmgenid: fa898e0a-1d56-4e1c-bbda-1aa489d5dae4

andiamo a sostituire, allo storage local lo storage real-storage, come nell’esempio seguente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 2
efidisk0: real-storage:300/vm-300-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: real-storage:iso/archlinux-2022.02.01-x86_64.iso,media=cdrom
memory: 8192
meta: creation-qemu=6.1.1,ctime=1644734076
name: kisslinux
net0: virtio=96:2F:E5:8A:35:3D,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: real-storage:300/vm-300-disk-1.qcow2,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=81f92f87-08cd-4e1b-bc0a-bc4f16d2f409
sockets: 2
vga: qxl
vmgenid: fa898e0a-1d56-4e1c-bbda-1aa489d5dae4

Copiamo la configurazione su /etc/pve/qemu-server ed opla, la nostra macchina è apparsa.

Per renderla avviabile, dal momento che non abbiamo ancora creato un bridge per la rete, per semplicità rimuoveremo la stessa.

La nostra immagine sta facendo girare una VM del sistema ospitante!
proxmox-ve-lite-running-kisslinux

A che serve? Ancora non lo sò, ma è davvero carino e potente.

Per chi volesse sperimentare sull’argomento, è a disposizione una egg-of-debian-bullseye-pve con la quale è stato eseguito l’esperimento ed, aventualmente, sono disponibili anche immagini di VM.