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.

backup users revisited

E’ da qualche tempo che sto pensando di rendere eggs utile per effettuare backup,

In effetti non sarebbe troppo difficile, eggs non effettua il salvataggio dei dati utente, per una decisione di progetto: impedire che dati privati vengano esposti in pubblico.

Pur tuttavia, un collega indiano, qualche tempo fa mi propose di utilizzare eggs per spostare delle macchine server da una serverfarm ad un’altra, in particolare dalla sede a Kerala a quella in Germania e viceversa.

Naturalmente i dati non dovrebbero essere esposti su internet, trattandosi anche di dati privati.

Immaginai che eggs, una volta finito il lavoro necessario alla costruzione di una iso, controllasse la dimensione dei dati da salvare dalle rispettive home degli utenti e server, quindi costruisse un volume LUKS di adeguate dimensioni, e ci copiasse questi dati. Infine copiasse nella iso il volume luks stesso.

In effetti già da qualche tempo, eggs ha questa “capacità”. La procedura però - poco testata - aveva dei problemi che, finalmente, sto cercando di risolvere: in primo luogo la stima dei dati, tra blocchi e dimensioni risultava a volte errata e, quindi, il backup veniva interrotto; inoltre, il backup avveniva solo sotto la directory /home, limitando quindi la possibilità di salvare dati dei server.

Immaginando unaa soluzione, abbiamo due casistiche differenti: creare una iso del nostro server con una configurazione di base e che, quindi contiene necessariamente anche le home dei servizi, ed un’altra nella quale abbiamo un server con dati reali e quindi privati, nella quale quindi, gli stessi devono essere presenti in modalità criptata.

Nel primo caso, server con una configurazione di base, creaimo la iso direttamente: nessun backup è necessario, in quanto i dati delle home dei servers vengono comunque copiati nella iso.

Per il secondo caso - backup - invece, dobbiamo:

Prima fase: analisi ed esclusione dei dati privati #

  • analizziamo /etc/password allo scopo di rilevare le varie home significative. C’è anche un nuovo comando in eggs che permette di farsi subito un’idea: eggs analyze
  • creiamo una lista di esclusione aggiuntive per le home degli utenti e servizi rilevati.

Seconda fase: creazione del filesystem.squashfs #

Procediamo normalmente per la creazione del filesystem.squashfs compresso, naturalmente utilizzeremo se del caso le nuove esclusioni per i dati privati.

Terza fase: backup dei dati #

  • dopo la costrunzione del filesystem.squash si torna ad analizzare /etc/passwd e decidere le dimensioni necessarie:
  • preparazione di un un file per il volume luks-eggs-backup
  • creazione e montaggio del volume luks-eggs-backup e copia delle home sia dei server che degli utenti nella cartella demoninata: ROOT del volume stesso;
  • salvataggio dei file: /etc/passwd, /etc/shadow ed /etc/groups nella root del volume luks;
  • chiusura e smontaggio del volume luks e copia del file risultante nella iso

A questo punto ho aggiunto un ulteriore comando ad eggs: eggs syncfrom.

Questo comando non fa altro che realizzare il processo inverso e, se chiamato da un sistema live, sostituisce nel sistema di destinazione dei file cruciali per il suo funzionamento e, cioè /etc/passwd, /etc/shadow ed /etc/groups, quindi, carica tutte le home salvate in precedenza.

Naturalmente, potrebbe essere conveniente inviare i dati da un posto ad un altro in due differenti file, ovvero, da una parte la normale iso contenente la configurazione di base e dall’altra il volume di backup.

Dovremmo, quindi, andare ad utilizzare il comando syncfrom su una macchina installata e fornire come parametro il percorso per il volume luck-eggs-backup precedentemente salvato. Naturalmente in tal caso NON potremo sostituire i file /etc/passwd, /etc/shadow ed /etc/groups, quindi la macchina accetterà soltanto i dati presenti sulle home di servizi ed utenti.

Il sistema, dovrebbe, comunque funzionare, presentare le stesse configurazioni di base ma andrebbe a sostituire le home precedenti con i nuovi dati. In teoria, questo dovrebbe fornire un aggiornamento ed allineamento con il sistema salvato.

A questo punto è nato anche un ulteriore comando: eggs syncto che, senza creare la iso del sistema, crea solamente il volume di backup.

reflections

It’s amazing how after so much effort to create a unique remastering tool, it turns out well.

I’ve just released the eggs 9.0.10 version, the first one running on Debian both in standard and UEFI BIOS mode.

Well, just after publishing it, I restored a VM with manjaro xfce - the last version - give the folloging commands:

  • sudo pamac upgrade
  • sudo pamac install base-devel
  • git clone https://github.com/pieroproietti/penguins-eggs
  • cd penguins-eggs
  • makepkg -sri
  • sudo eggs calamares --install
  • sudo eggs config
  • sudo eggs dad -d
  • sudo eggs produce --fast

After that I exported the resulting iso in my host and put it in another VM enabled with UEFI.

That’s the results:

manjaro-uefi-booting

disperato erotico stomp

Sono due giorni che sto combattendo con UEFI. Ho sempre cordialmente odiato UEFI, purtroppo mi ci tocca convivere!

Per di più utilizzando e - non potendo fare altrimenti delle VM - vengono aggiunti anche i problemi della virtualizzazione.

In effetti, l’anno scorso dopo un duro rincorrere i codici del buon refracta-snapshot-base di fsmithred di cui potete vedere questa intervista del 2019. Refracta, in qualche modo ha fatto la Storia - visto che da questa base si sono sviluppati almeno altri tre progetti: l’installer di Devuan dello stesso autore, quello di MX-linux mx-remaster ed il mio penguins-eggs.

Leggendo, sforzandomi di capire la logica, e ritraducendo il tutto in un misto di typescript e comandi di terminale - più gestibile per i miei gusti - ero riuscito a farlo funzionare.

Non uso molto UEFI però, normalmente sulla stazione di lavoro composta da Proxmox VE sul quale ho installato una interfaccia grafica cinnamon ed i strumenti di sviluppo, le macchine nascono con BIOS standardd e l’UEFI ha rappresentato sempre - come dire - una inutile “rottura”. Così non mi sono accorto di quando era successo il “fattaccio”.

Sono andato a tentoni, cercando di ritrovare una immagine funzionante, ma ne faccio e ne cancello così tante che non c’è stato verso.

In effetti avevo anche un problema sulla virtualizzazione, o meglio qualche cambio della stessa, di cui non mi ero reso conto.

Tutti i nodi vengono al pettine #

Avendo però attualmente un collega, che sta sviluppando una distribuzione con interfaccia Android, l’esigenza di utilizzare un notebook Microsoft, ci siamo trovati di fronte al problema,

Non mi capacitavo del perchè era sempre rimasto alla versione 8.17.x di eggs. Mi riferiva di avere problemi con la versione corrente, ma non avevo compreso che il problema era proprio la sua necessità del funzionamento UEFI, a me le nuove versioni andavano, a lui no. Io d’altra parte ero impossibilitato dal compremdere, in UEFI semplicemente non mi funzionavano ne’ le versioni della serie 8.x, ne quelle della 9.x e quindi, non conoscevo quando s’era rotto il codice.

In effetti era successa una cosa diversa: l’emulazione di Proxmox andava riconfigurata, si può avviare con UEFI ma sono disabilitando il secure boot.

Ieri, preso dal panico che l’amico dovesse rinunciare alla collaborazione in ragione del fatto che non riuscivo ad assicurargli l’avvio UEFI, ho cominciato ad indagare.

Il primo passo è stato richiedere allo stesso una “ultima” iso funzionante.

Con sorpresa, l’ultima iso funzionante era proprio quella che mi aveva appena condiviso.

Quindi, una volta segnato il punto è cominciata la caccia!

Per prima cosa ho provato con una chiavetta USB e, finalmente scopro che in effetti l’immagine che mi era stata inviata funziona in UEFI dalla chiavetta USB. Era solo dall virtualizzatore che non riuscivo ad avviarla.

Una volta assicuratomi di questo e, dopo la meritata dormita notturna, fresco al risveglio ho cercato di capuire che problemi avessi su Proxmox dove la stessa immagine non veniva avviata.

Dopo una oretta di bestemmie varie, ho compreso che il problema risiedeva nella configurazione interna delle VM UEFI, ho fatto i seguenti passi:

Avvio la macchina virtuale, precedentemente configurata con BIOS: OMVF (UEFI) e la avvio premendo il tast ESC.
uefi-ovmf

e vado a selezionare il: Device manager:
uefi-device-manager

A questo punto, scelgo: secure boot configuration
uefi-secure-boot-configuration

Mi trovo la seguente schermata, nella quale come si può vedere, lo stato corrente di Secure Boot è enabled.
uefi-seture-boot-state-enabled

Non ci resta che modificare lo stato e disabilitarlo:
uefi-current-state

Adesso le nostre immagini potranno essere avviate con UEFI.

Mi resta ancora da capire, perchè le distro originali Debian/Ubuntu/etc funzionano comunque. anche con il Current Secure Boot State enable, ma questo ce lo portiamo appreso per una prossima fase. Si accettano però suggerimenti.

Inizio della comparazione del codice 8.17.x con la versione 9.0.x #

La versione 9.0.x ha subito diverse riscritture rispetto alla versione originale e, tornare indietro, è discretamente impossibile. Per cui mi sno concentrato sulle differenze tra le due versioni, comparando i file cruciali per il boot UEFI: grub.template e grub.theme.cfg con quelli dell’altra versione.

Mi sono subito accorto che, addirittura, manco li avevo aggiornati, erano ancora con i vecchi parametri che, nella versione 9.x, ho dovuto riunire in un unico paramtro kernel_paremeters per gestire meglio le varie famiglie di linux.

Il processo è durato almeno due ore buone, perchè l’unico modo che conosco per controllare grub è quello di generare una nuova iso e testarla. Ho scoperto oggi grub-emu, un emutatore di grub discretamente funzionante, ma alla fine non l’ho trovato pratico.

Sistemato, con alterne fortune il template di grub ed il codice per il suo riempimento ho notato di avere comunque errori.

La macchina si avvia, ma va in grub rescue. Però immettendo:

1
2
3
set root=(cd0)
set prefix=(cd0)/boot/grub
normal

e dando invio. Pur senza caricare il tema - nel quale ho poi scoperto altri problemi - esegue correttamente il boot in UEFI.

A domani per il definitivo bugfix ed il completamento dell’articolo.

Se qualcuno vuole darci una occhiata, questi sono i file di configurazione:

mentre il codice che compone i kernel_parameter si trova in ovary.ts, nella fuzione makeEfi() dalla linea 1335

Conclusioni #

Con la versione eggs-9.0.10 possiamo finalmente dire: la stagione di caccia è finita!

Le ragioni del non funzionamento erano molteplici:

  • problematiche di configurazione delle VM utilizzate che mi hanno impedito di rendermi conto immediatamente del problema;
  • problematiche legate alla difficoltà di creare degli splash compatibili con grub;
  • questa istruzione, in makeEfi() di ovary.ts
1
2
// make a tarred "memdisk" to embed in the grub image
await exec(`tar -cvf ${memdiskDir}/memdisk ${memdiskDir}/boot`, echo)

che si portava dietro tutto il path di memdiskDir, ed stata così modificata:

1
2
3
4
5
6
7
8
// make a tarred "memdisk" to embed in the grub image
/**
* NOTE: it's CRUCIAL to chdir before tar!!!
*/
const currentDir = process.cwd()
process.chdir(memdiskDir)
await exec(`tar -cvf memdisk boot`, echo)
process.chdir(currentDir)

Va bene, la rampa di lancio è stata approntata, si resta in attesa dell’arrivo dei missili e del conto alla rovescia.

Buon viaggio in UEFI a tutti!