Cubic

Cubic è un acronimo e sta per Custom Ubuntu ISO Creator. Questo software però funziona anche su Debian e riesce a rielaborare anche le ISO prodotte con eggs, per cui diventa interessante per consentire una post-produzione di una immagine creata con eggs.

Cubic ha una propria storia ed un diverso approccio alla riproduzione, non rende diciamo così l’intero sistema riproduttivo ma si limita a partire dalla iso preeesistente per andare spacchettarla e ricostituirla. Vengono qua creati due archivi il primo denominato root che in sostanza è l’equivalente di filesystem.squashfs di eggs (il sistema chrooted che andiamo a riconfigurare) e l’altro, denominato disk che non è altro che l’equivalente della cartella denominata ISO in /home/eggs che, una volta compressa sarà il nostro systema live.

/home/eggs/ovarium/filesystem.squashfs -> custom-root
/home/eggs/ovarium/iso -> custom-disk

Essendo l’autore di eggs, mi si permetta di fare rifermento ai nomi di eggs, per semplicità, anche se poi si tratta sostenazialmente della stessa architettura.

Installazione di eggs #

Installiamo eggs semplicemente aggiungendo la repository di eggs alle nostre repository apt. Basterà copiare ed incollare le due seguenti righe:

curl -SsL https://pieroproietti.github.io/penguins-eggs-ppa/debian/KEY.gpg | sudo apt-key add -
sudo curl -s --compressed -o /etc/apt/sources.list.d/penguins-eggs-ppa.list "https://pieroproietti.github.io/penguins-eggs-ppa/debian/penguins-eggs-ppa.list"

A questo punto possiamo aggiornare il sistema, ed andremo ad eseguire l’installazione.

sudo apt update

sudo apt install eggs

sudo eggs config

sudo eggs calamares --install

sudo eggs dad -d

eggs info

Creazione di un iso con eggs #

eggs produce --fast

Abbiamo creato una immagine ISO in /home/eggs che possiamo utilizzare per l’avvio di un nuovo sistema oppure per una ulteriore rielaborazione con cubic.

Installazione di cubic #

L’installazione di cubic è molto semplice, si riduce ad aggiungere la repo nelle nostre sorgenti apt. Per prima cosa installeremo il pacchetto software-properties-common per avere disponibile il comando: apt-add-repository

sudo apt-get install software-properties-common

A questo punto andiamo ad installare cubic-wizard
sudo apt-add-repository ppa:cubic-wizard/release

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 6494C6D6997C215E

Per risolvere eventuali problemi con chiavi non trovate, ho semplicemente editato il file

/etc/apt/source.list.d/cubic-wizard-ubuntu-release-impish.list

aggiungo [trusted=yes] alla riga di apt

deb [trusted=yes] http://ppa.launchpad.net/cubic-wizard/release/ubuntu impish main

A questo punto, sudo apt update ed sudo apt install cubic e ci troviamo cubic installato.

Rielaborazione della immagine creata con eggs #

Andiamo a create una cartella denominata “custom”, ed esempio:

mkdir custom

Bene, adesso avviamo cubic, basterà digitare cubic al prompt del terminale.

cubic-custom

A qusto punto andiamo a selezionare la iso precedentemente creata con eggs /home/eggs/egg-of-debian-bullseye-xfce-amd64_2021-09-10_1214.iso

cubic-select-iso

In questa finestra potremo aggiungere o rimuovere o aggiornare i programmai.

cubic-customize

Terminata questa operazione, ci verrà proposto di selezionare quali programmi rimuovere per l’opzione minimun.

cubic-minimun

NixOS

La storia di NixOS è abbastanza lunga, pure se al momento per me completamente ignota. Come presentazione lascio dei link presi da widipedia.

Nel 2003, Eelco Dolstra ha iniziato NixOS come un progetto di ricerca. Nel 2015, è stata fondata Stichting NixOS con lo scopo di supportare progetti come NixOS che implementano il modello di distribuzione puramente funzionale.

Andremo a farci una semplice - per quanto possibile - passeggiata cercando di installare NixOS in una macchina virtuale e configurarla per i nostri scopi, nel nostro caso una macchina per sviluppare con nodejs.

Installatione #

Potete scaricare NixOS in più modalita dalla pagina NixOS Download page. Sceglieremo la ISO della versione minima - corrispondente alle nostre naked - per poter customizzare la stessa secondo le nostre esigenze.

Effettuare il boot dalla iso nixos-minimal, se si desidera la lingua italiana: sudo loadkeys it. Se i caratteri sono troppo piccoli, potete lanciare il comando: setfont ter-v32n, se desiderate è possibile connettervi alla VM con ssh. Creare una password per l’utente nixos che di default non è presente, rilevate l’indirizzo con ip a e quindi da terminale, sulla macchina ospite, connettevi digitando: ssh nixos@192.168.61.100

A questo punto siamo pronti all’installazione ed abbiamo disponibile la possibilità di effettuare dei cut and past dei vari comandi di seguito riportati.

Partizionamento dei dischi per BIOS standard #

La prima cosa da fare è partizionare il disco, nixos non prevede un installer grafico.

1
2
3
parted /dev/sda -- mklabel msdos
parted /dev/sda -- mkpart primary 1MiB -8GiB
parted /dev/sda -- mkpart primary linux-swap -8GiB 100%

Formattazione per BIOS standard #

1
2
mkfs.ext4 -L nixos /dev/sda1
mkswap -L swap /dev/sda2

Installazione #

1
2
mount /dev/disk/by-label/nixos /mnt
swapon /dev/sda2

Creazione configurazione #

1
nixos-generate-config --root /mnt

Adattamento e customizzazione #

A questo punto andiamo a modificare la configurazione per stabilire servizi, programmi etc di cui vogliamo disporre. I commenti nel codice ci indicano la strada, ma volendo potete anche abbreviarla copiando la configurazione posta a fine articolo e salvarla configuration.nix in /mnt.

nano /mnt/etc/nixos/configuration.nix

Dovete impostare l’opzione boot.loader.grub.device per specificare in quale disco risiede il grub boot loader altrimenti NixOS non può avviarsi. Esempio: boot.loader.grub.device=/dev/sda

Installazione #

1
nixos-install

Alla fine dell’installazione verrà immessa la password di root.

All’avvio non spaventatevi se il vostro utente non entra, bisognerà creare la password dello stesso. Basta aprire un terminale di root e digitare: sudo password artisan per creare la password.

Visual studio code #

Installiamo visual studio code, dobbiamo in primo luogo abilitare i programi non free.

1
2
export NIXPKGS_ALLOW_UNFREE=1
nix-env -iA nixos.vscode

Nodejs #

Installiamo nodejs.

1
nix-env -iA nixos.nodejs

Proviamo l’ebbrezza di smanettare su eggs #

A questo punto scarichiamo eggs dalla repository con git e quindi anchiamo a provare a compilarlo.

1
2
3
git clone https://github.com/pieroproietti/penguins-eggs
cd penguins-eggs
./init

NB eggs, prima di installare i pacchetto npm, necessita che siano installati pure perrisbrewery e oclif.dev che vendono prelevati sempre dalle mie repo con il comando custom ./init.

Va tutto bene, però l’installarione dei pacchetti npm viene interrotta e genera errore in quanto mancano i pacchetti per la compilazione, le cosidette - in termini Debian - build-essential.

Qua la faccenda è complessa, risolveremo in una prossima puntata, ma in ogni modo, brevemente ci siamo costruiti una nostra stazione di lavoro di cui, in buona sostanza, tutto quel che ci serve è raccolto nel file di descrizione.

Conclusioni #

NixOS è interessante, perchè in ultima analisi permette un approccio semplice alla costruzione di una macchina di lavoro, è come dire nato per essere customizzato ed molto affidabile.

Mi piacerebbe però - se fosse possibile - miscelare i due sistemi Debian e NixOS, per non dover disimpare ed apprendere di nuovo.

La cosa - per adesso - non sò se sia fattibile.

Da quello che mi risulta è possibile installare facilmente nix in un sistema Debian o altre distribuzioni e, per quello che ho capito, non è un problema la coesistenza dei due package manager apt e nix un po’ come succede con flatpack. Tuttavia ignoro sino a che punto si possa spingere nella coesistenza degli stessi. In soldoni se, partendo da una Debian minimale, sul quale si installata nix sia poi possibile aggiungere nixos e far convivere i due sistemi. Per essere ancora più chiari, se partendo da una ristretta repository Debian dal quale installare i pacchetti deb indispensabili, sia poi possibile attingere ed installare tutto il resto via nix-env -iA nixos.xfce4 etc.

Ai poster l'ardua sentenza, mi sento di poter dire che il sistema è figo, pure se richiede l’ennesimo cambiamento di paradigma, memorizzazione di nuovi termini, comendi e sintassi, etc. Nulla in contrario in linea di massima, ma è evidente che anche in questo caso le “limitate” umane capacità meritino di essere prese in considerazione. Questo tuttavia non è un problema per un giovane che sta iniziando ma può esserlo per uno sviluppatore di una certa età come il sottoscritto e, forse è anche all’origine della scarsa diffusione di NixOS stesso, che in effetti è veramente una perla in termini di possibilità di modificare, tornare indietro, consolidare il lavoro fatto, etc.

/images/nixos-xfce-code

Esempio di configurazione #

Questo è un esempio della configurazione utilizzata, potete fare un cut e copy e sostituirlo al file /mnt/etc/nixos/configuration.nix creato con il comando nixos-generate-config –root /mnt per il vostro esperimento.

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
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
# Edit this configuration file to define what should be installed on
# your system. Help is available in the configuration.nix(5) man page
# and in the NixOS manual (accessible by running ‘nixos-help’).

{ config, pkgs, ... }:

{
imports =
[ # Include the results of the hardware scan.
./hardware-configuration.nix
];

# Use the GRUB 2 boot loader.
boot.loader.grub.enable = true;
boot.loader.grub.version = 2;
# boot.loader.grub.efiSupport = true;
# boot.loader.grub.efiInstallAsRemovable = true;
# boot.loader.efi.efiSysMountPoint = "/boot/efi";
# Define on which hard drive you want to install Grub.
boot.loader.grub.device = "/dev/sda"; # or "nodev" for efi only

networking.hostName = "nixos"; # Define your hostname.
# networking.wireless.enable = true; # Enables wireless support via wpa_supplicant.

# Set your time zone.
time.timeZone = "Europe/Rome";

# The global useDHCP flag is deprecated, therefore explicitly set to false here.
# Per-interface useDHCP will be mandatory in the future, so this generated config
# replicates the default behaviour.
networking.useDHCP = false;
networking.interfaces.ens18.useDHCP = true;

# Configure network proxy if necessary
# networking.proxy.default = "http://user:password@proxy:port/";
# networking.proxy.noProxy = "127.0.0.1,localhost,internal.domain";

# Select internationalisation properties.
i18n.defaultLocale = "it_IT.UTF-8";
console = {
font = "Lat2-Terminus16";
keyMap = "it";
};

# Enable the X11 windowing system.
services.xserver = {
enable = true;
desktopManager = {
xterm.enable = false;
xfce.enable = true;
};
displayManager.defaultSession = "xfce";
};


# Configure keymap in X11
services.xserver.layout = "it";
services.xserver.xkbOptions = "eurosign:e";

# Enable CUPS to print documents.
# services.printing.enable = true;

# Enable sound.
# sound.enable = true;
# hardware.pulseaudio.enable = true;

# Enable touchpad support (enabled default in most desktopManager).
# services.xserver.libinput.enable = true;

# Define a user account. Don't forget to set a password with ‘passwd’.
users.users.artisan = {
isNormalUser = true;
extraGroups = [ "wheel" ]; # Enable ‘sudo’ for the user.
};

# List packages installed in system profile. To search, run:
# $ nix search wget
environment.systemPackages = with pkgs; [
nano # Do not forget to add an editor to edit configuration.nix! The Nano editor is also installed by default.
wget
firefox
git
];

# Some programs need SUID wrappers, can be configured further or are
# started in user sessions.
# programs.mtr.enable = true;
# programs.gnupg.agent = {
# enable = true;
# enableSSHSupport = true;
# };

# List services that you want to enable:

# spice-vdagent
services.spice-vdagentd.enable = true;

# Enable the OpenSSH daemon.
services.openssh.enable = true;

# Open ports in the firewall.
# networking.firewall.allowedTCPPorts = [ ... ];
# networking.firewall.allowedUDPPorts = [ ... ];
# Or disable the firewall altogether.
# networking.firewall.enable = false;

# This value determines the NixOS release from which the default
# settings for stateful data, like file locations and database versions
# on your system were taken. It‘s perfectly fine and recommended to leave
# this value at the release version of the first install of this system.
# Before changing this value read the documentation for this option
# (e.g. man configuration.nix or on https://nixos.org/nixos/options.html).
system.stateVersion = "21.05"; # Did you read the comment?

}

eggs una utility per creare la propria distribuzione Linux

Se hai sempre desiderato di creare e mantenere una tua distribuzione Linux personalizzata, forse è il momento di provare a realizzarlo con questa simpatica utility.

Lo strumento permette in maniera immediata la creazione di una versione live del proprio sistema installabile con l’ottimo installer di sistema grafico calamares. Questo facilità anche il compito di installare la propria distro in dual boot,

E’ possibile con eggs creare la live a partire praticamente da tutto il panorama delle distribuzioni della famiglia Debian e quindi comprende pure Ubuntu, Devuan e tutte le derivate come Linux Mint, KDE neon, deepin linux, MX Linux etc.

Tutto quello che devi fare è installare la tua distribuzione preferita, che sarà la base del remaster e quindi installare Penguin’s eggs.

Esiste anche la possibilità di utilizzare delle installazioni senza interfaccia grafica, ma comunque già “riproduttive” ed installabili con l’ottimo installer interno denominato krill. Questo installer, pur essendo a linea di comando, presenta una interfaccia simile al più noto e raffinato calamares e si basa sulla sua stessa configurazione automaticamente generata da eggs.

Partire da una versione base come può essere ad esempio una net-install di Debian presenta il vantaggio che tutto il software che andremo ad installare è stato scelto da noi stessi ed eviteremo più facilmente le ridondanze che si possono verificarsi partendo da una installazione ad esempio xfce ed andando mano, mano a rimuovere i pacchetti che non ci interessano, per passare a gnome, cinnamon, KDE, LXQT o altro.

Su sourcefoge sono presenti delle ISO già preimpostate con eggs ed immediatamente installabili e riproduttive denominate naked. Naturalemte sono versioni molto leggere - meno di 500 MB - e velocemente rimasterizzabili, adatte - per così dire - alla “riproduzione”.

Potete partire da una di queste o da una installazione pulita o persino dal vostro stesso sistema. eggs creerà comunque una immagine ISO live pulita, con un nuovo utente denominato live e SENZA alcun account utente e dato dell’utente preesistente.

Naturalmente, poichè l’utente creato è nuovo, prenderà le sue impostazioni dal catalogo standard /etc/skel, per questo può essere utile il comando sudo eggs tools:skel che permette di prendere la configurazione di un utente e salvarla come default per i prossimi utenti creati.

E’ comunque possibile includere anche i precedenti account ed i propri dati nella ISO, questi non saranno però disponibili sulla ISO ma soltanto ua volta che il sistema viene installato.

Questa è stata una precisa scelta di progetto per evitare la pubblicazione di dati utente sensibili.

L’opzione –backup permette difatti di creare una ISO normale senza alcun account originario e dato sensibile, ma all’interno della immagine live, viene creato un volume luks2 criptato che contiene sia gli account salvati che i dati utente.

Utilizzando l’installer krlll, questo volume verrà automaticamente rilevato, verrà richiesta la passprhase di creazione ed i dati verrano importati all’interno del nuovo sistema installato.

Installazione di eggs #

L’installazione di eggs è analoga a quella di altri programmi, eggs dispone di una propria ppa che può essere aggiunta alle repository del sistema ed una volta aggiornate le stesse il pacchetto eggs è disponibile per l’installazione Debian standard.

Basta copiare le seguenti due righe ed incollarle in una finestra di terminale:

1
2
url -SsL https://pieroproietti.github.io/penguins-eggs-ppa/debian/KEY.gpg | sudo apt-key add -
sudo curl -s --compressed -o /etc/apt/sources.list.d/penguins-eggs-ppa.list "https://pieroproietti.github.io/penguins-eggs-ppa/debian/penguins-eggs-ppa.list"

A questo punto utilizzare i soliti comandi sudo apt update ed sudo apt install eggs o utilizzare un package manager grafico.

Creazione della prima ISO #

In effetti eggs andrebbe configurato ed adattato al proprio sistema, scegliendo con cura il nome utente da dare all’utante del livecd, la sua password, la password di root del livecd etc.

Essendo però l’operazione tediosa ho deciso per un approccio più semplice, ci facciamo auitare da papà - un tipo che bada al sodo - e va dritto allo scopo.

Daremo questi due comandi, che sono comunque illustrati in dettaglio sia nella Users’ guide che nella pagina man, ma andiamo con ordine:

1
sudo eggs config

Eventualmente accettiamo l’installazione di calamares che ci verrà richiesta solo nel caso siamo in un sistema capace di grafica, quindi:

1
sudo eggs dad -d

Che è un po’ come dire: papà carica tutti i default, intesta questo tuo figlio e fai partire la produzione dell’uovo.

dad, senza battere ciclio ci risponde se siamo sicuri ed avvia la produzione della ISO compressa in modalità veloce, per risparmiare tempo. Va sempre di fretta!

A fine operazione, ci verrà indicato il nome della ISO, la directory o nido nella quale è presente, l’utente e la password impostata.

Basterà un semplice scp per esportare la iso da qualche parte ed utilizzarla quindi per avviare una altra macchina virtuale o fisica.

E la mamma? #

Eggià - come in ogni buona metafora - papà non poteva certo essere lasciato solo. E’ stato comodo però e ci tornerà utile anche in seguito per creare delle immagini senza fronzoli, ma se da pargoli vogliamo veramente capire come va il mondo, allora oltre a papà ci converrà seguire la mamma che ci prenderà per mano per prendere confidenza con l’User’s guide, la pagina di man e tutti i comandi disponibili.

Con la mamma occorre essere gentili e quindi, MAI utilizzare sudo semplicemente si immusonisce e rifiuta di eseguire il compito.

1
eggs mom

mom

Come vedete, sono presenti i principali comandi di eggs, dal config iniziale agli altri in ordine alfabetico, quindi la documantation , i comandi export, i tools e l’opzione di uscita.

Andiamo per prima cosa a vedere la documentation, in fondo la configurazione e la produzione della ISO già l’ha fatta papà - pure se in via provvisoria e: “tua madre… s’adatta”!

Nella documentazione troviamo book e book translated che non fanno altro che avviare il browser di default sulla pagina internet che contiene l’user’s guide - il primo - e su Google translator che la traduce sull’altro.

Allo stesso modo è presente manual che ci porta alla pagina man di eggs, in formato html per maggiore comodità e che risiede sul sistema, non necessita quindi di connettività internet.

Questo può essere utile in alcuni casi.

Ma potremmo anche trovarci in un ambiente esclusivamente CLI e la mamma non abbandonerà mai il suo figliolo, almeno no fino a che non cresca, gli siano spuntate le alette e non se lo sia per così dire goduto. Ed ecco allora che ci viene proposto man, ovvera la visualizzazione in formato man della pagina di eggs.

Naturalmente, una volta imparato il metodo, non è indispensabile ricorrere alla mamma per digitare man eggs, ma all’inizio può aiutare.

Una volta ottenuta la nostra visualizzazione basterà chiudere la finestra del browser o uscire da man per tornare al menu principale di mom ed iniziare ad esplorare le altre possibilità.

Scegliamo a questo punto il menu info che equivale in analogia a digitare da terminale: eggs info.

Ci verrà presentata una schermata graphic-like che rappresenta la configurazione attuale di eggs.

info

Anche qua, basterà il tocco di un tasto per chiudere e continuare sul menu principale di mom.

Chiedere a mom di uccidere il figlio, opzione del menu kill potrebbe sembrare spaventoso, ma ormai siamo abituati a tutto e l’idea di uccidere un processo o cancellare un file e non ci fa più di tanto effetto. Ed in ogni caso c’è chi lo fa e pure di peggio purtroppo.

kill rimuoverà completamente il nido ed il suo contenuto. Ancora, possiamo chiamare kill in maniera diretta e lo faremo quando lo conosceremo meglio con sudo eggs kill.

Potremmo continuare, essere ligi all’ordine ed alla tradizione ed affrontare man mano le varie opzione che mom ci propone e ci sono tutte.

Vedremo come esempio il menu produce quello più importante, perchè in fondo questo è il nostro scopo: riprodurre il nostro sistema.

mom-produce

Vediamo che mom ci illustrerà le opzioni di produce, cercando di insegnarcele con il suo commento. Però il suo compito si sta esaurendo, dopo le prime prove saremo in grado, viaggiare più speditamente da soli utilizzando i vari comandi e la funziona di autocomplete degli stessi.

La funzione di autocomplete in eggs #

Così se andiamo a battere nel terminale direttamente: sudo eggs produce seguita da e, quindi, premendo due volte il tasto [TAB], ci vedremo comparire a video le opzioni disponibili e che possiamo impostare

1
2
3
4
artisan@fabrica:~/penguins-blog$ eggs produce --
--addons --fast --normal --script --yolk
--backup --help --prefix --theme
--basename --max --release --verbose

L’autocomplete è dinamico ed è presente per tutti i comandi ed i flag di eggs. Così se digitiamo eggs [TAB][TAB] ci appare la lista dei comandi

1
2
3
4
5
6
artisan@fabrica:~/penguins-blog$ eggs 
adapt export:deb install tools:clean update
autocomplete export:docs kill tools:locales
calamares export:iso mom tools:skel
config help produce tools:stat
dad info remove tools:yolk

e, per ogni comando, inserendo i due trattini, la lista dei flag. Ad esempio:

1
2
artisan@fabrica:~/penguins-blog$ eggs calamares --
--final --help --install --remove --theme --verbose

oppure:

1
2
artisan@fabrica:~/penguins-blog$ eggs install --
--cli --help --mx --verbose

e così via.

Potete sperimentare liberamente in maniera interattiva, naturalmente la lettura del manuale vi aiuterà non poco, ma tutta questa introduzione, spero, vi abbia messo sulla buona strada per l’apprendimento.

Riporto il link alla Penguin’s eggs user’s guide e vi auguro una buona lettura.

Personal Package Archives PPA

Today on the advice of the excellent Yannis I’ve created a PPA repository for eggs.

You just need to add it to your current sources to have eggs available simply through apt, gdebi, synaptic, etc.

Copy and past to add this penguins-eggs-ppa to your sources lists

1
2
curl -SsL https://pieroproietti.github.io/penguins-eggs-ppa/debian/KEY.gpg | sudo apt-key add -
sudo curl -s --compressed -o /etc/apt/sources.list.d/penguins-eggs-ppa.list "https://pieroproietti.github.io/penguins-eggs-ppa/debian/penguins-eggs-ppa.list"

then

1
2
sudo apt update
sudo apt install eggs

penguins-eggs-pps

link

MX21 adventures

Few days ago, MX-Linux annunced his new beta release MX21. based on Debian.

I decided to get a look to MX, a great platform and always intesting. They have his way to remaster and install the system included in the distro: mx-snapshot and mx-installer.

Both are really nice and is a joy to work with them.

The only problem was the fact that I am the parent of a relative of mx-snapshot, a cousin or maybe even a brother, since both eggs and mx-snapshot started from refracta-snapshot each one trying then his own way

The operations I tried #

I first tried to install mx21 with krill, and succeeded, then I remastered mx21 with eggs and installed it with calamares. Again with success.

Both went well, perhaps with minor issues that you can fix later, but the system was installed in both cases.

At this point I decided to try mx-installer and made some slight adjustments to eggs to accommodate it. To get it working I made same modification in install.ts too and add a flag –mx. Then the follow changement:

1
2
3
4
5
6
7
8
9
10
11
12
if (Pacman.packageIsInstalled('mx-installer') && Pacman.guiEnabled() && flags.mx) {
if (!fs.existsSync('/live/')) {
execSync('mkdir /live/ ')
}
if (!fs.existsSync('/live/aufs')) {
execSync('ln -s /lib/live/mount/rootfs/filesystem.squashfs/ /live/aufs')
}
if (!fs.existsSync('/live/linux')) {
execSync('ln -s /lib/live/mount/rootfs/filesystem.squashfs/ /live/linux')
}
execSync('minstall')
...

Well, again - with minor problems - it work from the MX21 remastered iso.

Here You can find the resulting iso: egg-of-mx-bullseye-xfce.

To use mx-installer just open terminal and type: sudo eggs install --mx. You can install it with krill and calamares too.

Moment, where can lead this tests? #

Of course all this operations are - at last - unusefull, mx can be remastered just fine with his tool: mx-snapshot and install perfectly with his mx-installer. So, where can lead this tests again?

Using mx-installer on a common Debian bullseye #

I choose a light iso Debian bullseye with xfce and no other to try to use mx-installer out from mx-linux.

Before I had install it, so I added mx.list from MX21-beta to my the current repos and change them to trust it

1
deb [trust=yes] http://it.mxrepo.com/mx/repo/ bullseye main non-free

After that I installed mx-installer and smartmontools.

1
sudo mx-installer smartmontools

PS: without smartmontools mx-installer seen to not work.

Results #

end

My debian was correctly installed, with the following errors:

  • get configuration errot (quite normal);
  • not ask for user and so not create it;
  • I have no way to remove link to installer when installation end.

Well, we must to study more!

Here You can fine this experiment egg-of-debian-bullseye-xfce-amd64.

_

Dimostrazione eggs

In questo breve video viene presentato eggs

  • installazione di una distro naked
  • installazione di xfce4 sul sistema installato
  • rimasterizzazione del nuovo sistema e sua re-installazione con krill
  • aggiunta dell’installar grafico calamares e rimasterizzione;
  • installazione della nuova iso con calamares
  • saluti finali

luks-krill

Cercando di capire come far funzinare krill con luks, vediamo come viene impostato luks per l’installazione fullencrypted su una VM con /dev/sda di 32 GB con Ubuntu.

BIOS STANDARD #

luks-standard
gpt

fstab #

1
2
3
4
5
6
7
8
9
10
11
12
13
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/vgkubuntu-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda3 during installation
UUID=6ed10a98-b94a-4ad9-9a4a-59d17511170d /boot ext4 defaults 0 2
# /boot/efi was on /dev/sda2 during installation
UUID=CDA5-A018 /boot/efi vfat umask=0077 0 1
/dev/mapper/vgkubuntu-swap_1 none swap sw 0 0

Si usa LVM i dischi sono sia in /dev/vgname/root, /dev/vgname/swap_1 che su /dev/mapper/vgname-root, /dev/mapper/vgname-swap_1

1
2
3
4
5
6
7
8
9
10
artisan@kde:~$ sudo pvscan 
PV /dev/mapper/sda4_crypt VG vgkubuntu lvm2 [30,76 GiB / 32,00 MiB free]
Total: 1 [30,76 GiB] / in use: 1 [30,76 GiB] / in no VG: 0 [0 ]

artisan@kde:~$ sudo vgscan
Found volume group "vgkubuntu" using metadata type lvm2

artisan@kde:~$ sudo lvscan
ACTIVE '/dev/vgkubuntu/root' [<29,78 GiB] inherit
ACTIVE '/dev/vgkubuntu/swap_1' [976,00 MiB] inherit

Quello che non capisco è come vengono creati.

/dev/sda (omterp disco) #

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A7049CC0-4048-4722-96CE-79D917814679

Dispositivo Start Fine Settori Size Tipo
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 1054719 1050624 513M EFI System
/dev/sda3 1054720 2553855 1499136 732M Linux filesystem
/dev/sda4 2553856 67106815 64552960 30,8G Linux filesystem

dev/sda1 #

1
2
3
4
Disk /dev/sda1: 1 MiB, 1048576 bytes, 2048 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

dev/sda2 #

1
2
3
4
5
6
Disk /dev/sda2: 513 MiB, 537919488 bytes, 1050624 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

dev/sda3 #

1
2
3
4
Disk /dev/sda3: 732 MiB, 767557632 bytes, 1499136 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

dev/sda4 #

1
2
3
4
5
Disk /dev/sda4: 30,78 GiB, 33051115520 bytes, 64552960 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

mount bios-standard #

1
2
3
4
/dev/mapper/vgkubuntu-root on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sda3 on /boot type ext4 (rw,relatime)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

UEFI #

uefi

gpt

1
2
3
4
5
6
7
8
9
10
11
12
Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3CE9FDC3-8217-4A4B-A31F-8A8C39E37B80

Dispositivo Start Fine Settori Size Tipo
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 2549759 1499136 732M Linux filesystem
/dev/sda3 2549760 67106815 64557056 30,8G Linux filesystem

dev/sda1 #

1
2
3
4
5
6
7
Disk /dev/sda1: 512 MiB, 536870912 bytes, 1048576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

dev/sda2 #

1
2
3
4
5
Disk /dev/sda2: 732 MiB, 767557632 bytes, 1499136 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

dev/sda3 #

1
2
3
4
5
Disk /dev/sda3: 30,78 GiB, 33053212672 bytes, 64557056 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

mount uefi #

1
2
3
/dev/mapper/vgkubuntu-root on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sda2 on /boot type ext4 (rw,relatime)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

luks-size

Determinazione della grandezza del volume luks-users-data #

A questo punto manca ancora la pre-determinazione della grandezza del volume luks-users-data che sarà determinata:

Qui sono riportate le specifiche del formato Luks2

  • Binary Header size 4M
  • tipo di formattazione ext2. Per ext4 aggiungere 128MB per journal
  • dati da copiare

Per determinare lo spazio ho così proceduto;

  • determino lo spazio delle home degli utenti
  • aggiungo 4MB per l’header
  • se la grandezza è inferiore a 32MB imposto la grandezza a 32MB
  • aumento lo spazio del 10%

Ha funzionato per dimensioni da pochi byte sino a 2GB. Probabilmente il 10% può essere ridotto a 5% per dimensioni superiori a 1GB, mentre occorrerà aumentarlo almeno al 15% per dimensioni inferiori a 512MB.

issue #

Puoi segnalare problemi o malfunzionamenti issue

You can report problems or malfunctions issue

share #

If you like eggs, please rate this project on sourgeforce and githut and help to spread it’s diffusion.

to be continued #

pacchetti

Eggs viene rilasciato sia come pacchetto npm - versione originale - sia come pacchetto Debian di più semplice utilizzazione.

Sia per l’uno che per l’altro caso, per il funzionamento di eggs occorre caricare i pacchetti deb che effettivamente “svolgono” il lavoro. Tale compito per i pacchetti di eggs npm, veniva svolto dalla classe pacman, mentre nelle versioni di eggs pacchetizzate come pacchetto Debian le dipendenze sono poste in /DEBIAN/control.

I pacchetti che svolgono il lavoro “sporco” #

I pacchetti Debian necessari ad eggs per svolgere il suo lavoro, anzi, sono questi pacchetti che essenzialmente svolgono il compito.

Tali pacchetti possono essere di differente tipologia, variando a seconda dell’architettura e della versione di Linux che stiamo utilizzando per la riproduzione.

Andiamo a vedere le problematiche che ne risultano.

pacchetti indipendenti e che possono essere rimossi #

In questa lista ci sono pacchetti che in casi normali - non vengono utilizzati da altri progammi, ma solo da eggs e, che quindi possono essere correttamente rimos

  • squashfs-tools
  • xorriso
  • live-boot
  • live-boot-initramfs-tools
  • dpkg-dev
  • syslinux-common
  • isolinux

pacchetti di cui non è prevedibile l’uso da altri programmi o quasi sicuramente usati #

Pacchetti che possono essere presenti anche senza eggs e di cui è difficile individuare la rimozione o meno.

  • cryptsetup
  • dosfstools
  • net-tools
  • parted
  • rsync
  • whois

Pacchetti che dipendono dall’architettura #

Attualmente eggs supporta i386, amd64, arm64 ed armel.

Vi sono delle differenze su quali pacchetti è necessario e possibile installare

  • syslinux per amd64, i386
  • syslinux-efi per arm64, armel

Pacchetti che dipendono dalla distribuzione/versione di Linux da rimasterizzare #

  • live-config

Pacchetti che dipendono sia dalla distribuzione/versione di Linux da rimasterizzare che dal tipo di init (systemd/sysvinit) #

  • live-config-systemd
  • open-infrastructure-system-config in Ubuntu bionic
  • live-config-sysvinit

Ovviamente gestire il tutto richiede una certa complessità e ci sono stati casi in cui alcune versioni di eggs non sono state compatibili con tutte le versioni di sistema operativo installato.

Come ho proceduto sinora #

Sino alla creazione dei pacchetti deb realizzati sulla spinta di UfficioZero ed altri, tutti i pacchetti venivano caricati da eggs attraverso il comando:

sudo eggs prerequisites

Da allora però parecchia acqua è passata sotto i ponti e, sostanzialmente credo di non sbagliare se nella totalità dei casi eggs venga installato come pacchetto deb.

I pacchetti .deb di eggs #

La creazione del pacchetto deb di eggs è basata su oclif-dev e produce un pacchetto deb SENZA dipendenze e script di pre e post installazione.

L’unica differenziazione presente è, quindi, esclusivamente l’architettura: i386, amd64, arm74 o armel.

Perrisbrewery e l’introduzione di script e dipendenze #

Queste dipendenze e gli script sono però importanti per garantire l’aggiornamento e la rimozione del pacchetto e sono stato costretto ad inserirli, da qua è nato il progetto compagno di eggs perrisbrewery.

Perrisbrewery è, come dire, un assistente che non fa altro che prendere il pacchetto debian originato da oclif e variabile unicamente dalla architettura ed andare ad inserire le dipendenze e gli script necessari.

Sinora ho cercato di limitare le tipologie di pacchetto, evitando di specificare la versione, in quanto questo - sia per me che per chi ha introdotto eggs nelle proprie repositories - può generare molto lavoro.

D’altra parte però la versione del sistema operativo su cui eggs sta girando, non essendo conosciuta nel momento della compilazione, deve essere valutata al runtime e, richiedere, l’analisi e l’installazione dei pacchetti specifici per la distribuzione/versione in uso.

Tre possibili alternative #

Abbiamo, quindi, tre possibili strade:

  • rilasciare eggs esclusivamente come pacchetto non, era l’idea originale, ma comporta disporre di nodejs pre-installato e l’impossibilità della corretta rimozione di eggs e dei prerequisiti;
  • creare pacchetti .deb distinti ma solo per architettura, Comporta una ulteriore configurazione al runtime, necessaria per stabilire se i pacchetti dipendenti dalla versione o dal tipo di init (systemd/sysvinit) siano presenti o meno;
  • creare pacchetti distinti sia per architettura che per distribuzione/versione;

Considerata la comodità della pacchettizazione per l’utente finale, la possibilità di specificare direttamente nel pacchetto le dipendenze e gli script, la soluzione occorrente è l’ultima e cioè creare pacchetti distinti sia per architettura che per distribuzione/versione.

La birreria va espansa mentre il pacman va ridotto #

Attualmente, poichè sinora ho scelto la soluzione ibrida, abbiamo due punti dove vengono decise le dipendenze da installare: perrisbrewery e pacman.

Lo svantaggio della installazione delle dipendenze con pacman è che quest’ultimo, i pacchetti richiesti da eggs non vengono registrate come dipendenze e, quindi, non è possibile rimuoverle in sicurezza. Forse questo potrebbe essere evitabile con qualche hatch.

Inoltre, avere due decisori per le dipendenze genera una inutile duplicazione di codice, da aggiornare ad ogni modifica dell’uno o dell’altro. In una parola, questo approccio è scomodo.

Dovremmo quindi pensare ad ampliare perrisbrewery che riceve attualmente in ingresso i pacchetti .deb di oclif ed introduce dipendenze e script.

perrisbrewery dovrebbe prevedere, quindi, in uscita per ogni architettura le versioni possibili e, generare, di conseguenta un pacchetto per ogni versione di distribuzione.

Immaginiamo, per il momento di continuare con l’uso di sourceforge per distribuire eggs. Attualmente tutti i pacchetti risiedono in due cartelle:

1
2
https://sourceforge.net/projects/penguins-eggs/files/packages-deb/
https://sourceforge.net/projects/penguins-eggs/files/packages-deb/old

Naturalmente, per includere la versione lo schema dovrebbe cambiare ed avremmo:

1
2
3
4
5
6
7
https://sourceforge.net/projects/penguins-eggs/files/packages-deb/jessie
https://sourceforge.net/projects/penguins-eggs/files/packages-deb/stretch
https://sourceforge.net/projects/penguins-eggs/files/packages-deb/buster
https://sourceforge.net/projects/penguinsq-eggs/files/packages-deb/bullseye
https://sourceforge.net/projects/penguins-eggs/files/packages-deb/bionic
https://sourceforge.net/projects/penguins-eggs/files/packages-deb/focal
https://sourceforge.net/projects/penguins-eggs/files/packages-deb/groovy

Per semplicità non ho riportato la directory old che pure dovrebbe essere inclusa per ogni versione.

Modifiche necessarie in perrisbrewery #

In perrisbrewery, andrebbe quindi previsto che per ogni architettura si creino i pacchetti per tutte le varie versioni;

  • jessie, strecth, buster, bullseye, beowulf, bionic, focal, hirsute

La fabbrica di birra necessiterebbe di ulteriori punti vendita #

Non disponendo di risorse adeguate a gestire un repository ho gestito il rilascio utilizzando un server che se interrogato, risponde con le versioni disponibili e rilascia un indirizzo da dove scaricarle, nel nostro caso sourceforge.

Questo servizio è denominato basket, da cestino per le uova.

L’interrogazione avviene tramite usa una url specifica:

https://penguins-eggs.net/versions/all/' + Utils.eggsArch() + ‘/

Ad esempio con https://penguins-eggs.net/versions/all/i386/

si otterranno tutte le versioni disponibili per questa architettura

mentre con https://penguins-eggs.net/versions/7.8.50/i386/

verrà richiesta la versione 7.8.50 per arch i386,

Naturalmente dovrà essere previsto un ulteriore livello per gestire la versione:

1
https://penguins-eggs.net/versions/7.8.50/i386/buster/

In questo modo verrà ricevuto dal client eggs l’indirizzo da cui scaricare l’aggiornamento per l’architettura e la versione installata.

inserimento di nuove versioni di eggs #

Adesso, l’inserimento viene effettato tramite una chiamata alla url

https://localhost:4000/add/package-version/distro-arch/description

ovviamente dovrà essere possibile

https://localhost:4000/add/package-version/arch/distro-version/description

e, poichè chiamarlo a mano sarebbe lungo - si passa da quattro versioni differenti ad una ventina - fare in modo che venga automatizzato l’inserimento.

Stiamo come stiamo che stiamo bene #

Ragionando sul problema, m’è venuto un dubbio: ma se rimanessimo così? Quali sarebbero i problemi?

Essenzialmente avremo: pacchetti comuni e dipendenti da architttura SEMPRE rimuovibili.

Tutti questi pacchetti sono comuni, non dipendono ne’ da architettura e neppure dalla versione e possono quindi essere previsti con la suddivisione attuale.
Per essi avremmo la possibilità di rimozione perchè accettati come dipendenze di eggs.

  • squashfs-tools
  • xorriso
  • live-boot
  • live-boot-initramfs-tools
  • dpkg-dev
  • syslinux-common
  • isolinux
  • cryptsetup
  • dosfstools
  • net-tools
  • parted
  • rsync
  • whois

Pacchetti che dipendono dall’architettura #

Anche questi pacchetti, pur non essendo comuni, essendo prevista una suddivizione per architettura finiscono nele dipendenze, come tali possono essere facilmente rimossi se rimangono orfani.

  • syslinux per amd64, i386
  • syslinux-efi per arm64, armel

Pacchetti che dipendono dalla versione #

Il problema esiste solo per questi pacchetti che, alla fine non sono poi molti e non da luogo ad incertezze.

  • live-config (OK Debian/Devuan ma non Ubuntu bionic)
  • live-config-systemd (OK Debian/Devuan ma non Ubuntu bionic)
  • open-infrastructure-system-config Ubuntu bionic
  • live-config-sysvinit

Ci restano solo i pacchetti dipendenti da versione ed init #

Solo i pacchetti derivanti dalla versione o dallinit andrebbero valutati. Alla fine si tratta di solo questi pacchetti che, dipendento più o meno da live-config, potremmo anche scegliere di rimuovere brutalmente senza timore di danni:

  • live-config
  • live-config-systemd
  • live-config-sysvinit
  • open-infrastructure-system-config in Ubuntu bionic

pacman e perrisbrewery #

Rimane come è, salvo NON distinguere rimovibili e non rimovibili, in quanto essendo i pacchetti inclusi nelle dipendenze sono sempre rimovibili in automatico tramite apt.

Potrebbe però essere definito un file lib/dependecies.ts che esporti le nostre dipendenze e che venga utilizzato sia da config, pacman che in perrisbrewery e che contenga:

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
62
63
64
65
66
67
68
69
70
71
72
73
74
75
/**
* depCommon
* depArch
* depVersion
* depInit
*/

export const depCommon = [
'squashfs-tools',
'xorriso',
'live-boot',
'live-boot-initramfs-tools',
'dpkg-dev',
'syslinux-common',
'isolinux',
'cryptsetup',
'dosfstools',
'net-tools',
'parted',
'rsync',
'whois'
]

/**
* Dependencies for arch
*/
export const depArch = [
{
package: 'syslinux',
arch: ['amd64', 'i386']
},
{
package: 'syslinux-efi',
arch: ['arm64', 'armel']
}
]

/**
* dependencies for versions
*/
export const depVersions = [
{
package: 'live-config',
versions: ['jessie', 'stretch', 'buster', 'bullseye', 'beowulf', 'focal', 'groovy', 'hirsute']
},
{
package: 'live-config-systemd',
versions: ['jessie', 'stretch', 'buster', 'bullseye', 'focal', 'groovy', 'hirsute']
},
{
package: 'live-config-sysvinit',
versions: ['beowulf']
},
{
package: 'open-infrastructure-system-config',
versions: ['bionic']
}
]

/**
* dependecies for init
*
* We need for buster derivate with sysvinit MX-LINUX and probably others
*
*/
export const depInit = [
{
package: 'live-config-systemd',
init: 'systemd'
},
{
package: 'live-config-sysvinit',
init: 'sysvinit'
}
]

implementazione #

Con la versione 8.0.27 ho provveduto a realizzare l’opzione ibrida, ovvero rimanere con una distinzione dei pacchetti deb solo a livello di architettura ed utilizzando pacman - a runtime - per caricare gli ulteriori pacchetti necessari dipendenti dalla versione e/o dall’init.

Il codice risulta più compatto, la complassità si riduce soprattutto per la presenza del lib/dependencies.ts che è condivisa tra il comando config, la classe produce ed il pacchetto perrisbrewery.

Mi era rimasto il dubbio: eliminare il comando config.

Tale comando, pur essendo chiamato config comprende anche la chiamata a pacman per l’installazione dei pacchetti che dipendono dalla versione o dall’init. Alla fine, quindi, è già automatizzato. eggs config, inoltre, viene chiamato pure all’interno di post installazione - ma non può, in questa fase - installare pacchetti, per cui si limita ad emettere dei suggerimenti.

Quindi, alla fine ho deciso di rilasciare questa nuova version così com’è, in fondo sarà più semplice anche per gli utenti, che non si ritroverranno di fronte ad una pletora di pacchetti che, sostanzialmrnte, differiscono solo per le dipendenze.

Il comando config. viene automaticamente eseguito da produce per controllare se manca qualcosa ed in questa sede giò è autolatizzato

test #

Non ho fatto moltissimi test, mi sono limitato a buster e bulldeye naked ed a linuxmint i386, ma dovrebbe essere ok anche per altre distro.

issue #

Puoi segnalare problemi o malfunzionamenti issue

You can report problems or malfunctions issue

share #

If you like eggs, please rate this project on sourgeforce and githut and help to spread it’s diffusion.

Good luks eggs!

Per molto tempo, sino a qualche settimana fa, non ho aggiunto una opzione di backup ad eggs per un preciso motivo: non volevo che inavvertitamente un utente potesse mettere a rischio i suoi dati.

Tuttavia la possibilità di effettuare il backup delle aree utente mi è stata richiesta anche nel campo del backup/spostamento di server e, quindi, è stata aggiunta.

Sempre, attraverso lo stesso canale, mi è stata richiesta la possibilità di cryptare con LUKS le iso create ed eventualmente l’installazione stessa.

In effetti, mai avevo considerato il rischio insito in un laptop dimenticato presso un cliente, una sala riunioni, etc. Oppure la semplice chiavetta USB smarrita, magari creata con l’optione backup e che, quindi, contiene oltre al sistema operativo stesso la nostra home utente, con dati che possono essere più o meno riservati.

Huston: we have a problem! #

C’è un problema serio, quindi, proprio come in Apollo 13: garantire o limitare la possibilità di accesso ai nostri dati nel caso un terzo abbia accesso al dispositivo: notebook, chiavetta USB, DVD, etc.

LUKS #

Linux Unified Key Setup, abbreviato LUKS, è un metodo di cifratura dei dischi rigidi. Le sue specifiche sono state scritte da Clemens Fruhwirth nel 2004 ed è stato originariamente pensato per Linux.

Con LUKS è possibe criptare l’intero filesystem o una parte di esso.

In questo primo momento, ho pensato a “mettere una pezza” solo ad una parte del problema e, cioè garantire che un backup di un nostro server che - necessariamente finisca in rete, non foss’altro che per la sua installazione - esponga direttamente i nostri dati utente.

Per fare questo sono state necessarie alcune modifiche ad eggs, in particolare è stato aggiunto un ulteriore livello nella creazione della iso e cioè:

  • preparare un volume luks, formattarlo e montarlo;
  • copiare sul nostro volume criptato i dati degli account degli utenti e le loro home directory;
  • smontare il volume criptato e chiuderlo;
  • spostare il volume criptato nella cartella live della iso di destinazione

Quindi avremo una live che si avvia normalmente, eventualmente con l’autologin ed il solo utente live, ma che contiene al proprio interno sia gli accout degli utenti che i dati degli stessi.

In sede di installazione avviene il processo opposto - al momento solo per l’installer krill - ma sto pensando di aggiungere un modulo per calamares - dopo la fase di unpacking del file system, nel caso venga rilevato il volume criptato, si procede al restore dei dati:

  • si apre il volume criptato e viene richiesta la passphrase immessa;
  • si monta il volume ed i dati in esso contenuti vengono copiati nel sistema in installazione;
  • a questo punto non resta che smontare il volume criptato e proseguire come nel caso normale.

Naturalmente tutte queste fasi sono automatizzate, l’unica cosa da fare è digitare la passphrase e ricordarla poichè non sarà possibile recuperarla.

A fine dell’installazine il nostro “uovo” sarà diventato un pulcino esattamente come il padre.

Forse sarebbe più corretto parlare di clonazione, in stile pecora Dolly, più che di backup ma questo è un altro discorso.

I vantaggi di questo approccio #

I dati utente non vengono mai esposti direttamene e la password non viene mai registrata e passa in rete solo al momento dell’installazione.

Questo risolve il problema per le nostre iso che - anche solo per l’installazione - in rete ci dovranno comunque finire.

Per quanto concerne, invece, l’installazione del sistema direttamente su di un file system cifrato - che risolverebbe il problema dello smarrimento di un notebook - è essenzialmente un caratteristica dell’installazione stessa e, se ci sarà interesse, potrà essere aggiunta in future versioni di krill.

Considerazioni #

Questo è un progetto originale, nato inizialmente da necessità personali e dalla voglia di mettersi in gioco o, comunque, di rimanerci una volta abbandonata l’attività professionale per raggiunti limiti di età.

Indubbiamente mi sta dando molte soddisfazioni e, grazie ad esso, oltre a non aver assunto l’aspetto arruginito di un binario morto sul quale non passano più i tram, ho appreso diverse tecniche che non conoscevo precedentemente. Tuttavia, lo scrivere e mantenere un programma come eggs è piuttosto impegnativo sia in termini di tempo - sostanzialmente non meno di otto ore a giorno, spesso sabato e domenica compresi - sia dal punto di vista tecnico - occorre rimanere aggiornati e cercare di cogliere e comprendere quanto di nuovo esce a riguardo, infine, c’è anche un aspetto economico: necessità di avere almeno un server virtuale in uso sia per il blog per la diffusione delle versioni, oltre naturalmente ad avere bisogno di adeguato hardware dove creare. testare, etc. Attualmente utilizzo una stazione di lavoro basata su Debian buster con l’addizione di Proxmox VE e l’aggiunta di una interfaccia grafica, la macchina ha ormai cinque anni e, come dire, missile non lo è più!

Inotre, per poter testare le versioni per arm, ci sarebbe bisogno pure di hardwre fisico. Adesso le varie prove adesso vengono effettuate sempre su Proxmox VE emulando con qemu l’architettura arm64 e, naturalmente, faccenda lenta è.

Sinora - e sono appunto quattro, cinque anni - ho portato avanti lo sviluppo sostanzialmente da solo, però eggs nel frattempo è cresciuto ed diventato uno strumento maturo, utilizzato sia in ambienti professionali UfficioZero, scolastici guadalinex e minino-TDE o sviluppate da appassionati TeLOS. Alcune distro/remix realizzate con eggs sono presenti o comunque sottoposte anche su distrowatch (UfficioZero e TeLOS) e, comunque vengono scaricate in ogni parte del mondo.

eggs in sostanza può essere interessante per il lavoro di molti: da chi desidera realizzare una propria remix, a chi vuole un modo per installare la propria faticosamente creata ed, infine, per salvare, spostare o clonare le proprie infrastrutture informatiche, traferendole magari da hardware fisico a virtuale, da locali a remote e viceversa.

Inoltre - ed è un particolare di non poco conto - eggs è estremamente versatile a riguardo delle architetture sulle quali può girare. Difatti, essendo scritto in javascript utilizzando nodejs, è possibile rilasciarlo ed è attualmente rilasciato per quattro differenti architetture: amd64, i386, arm64 ed armel. Altre possono essere aggiunte in futuro a seconda degli sviluppi dell’IT ed in particolare dell’uscita di nuovi processori, penso soprattutto all’architettura RISC-V dalla quale spero e mi aspetto sorprese.

good-luks-eggs

Sarei quindi felice di trovare persone interessate, disponibili per delle collaborazioni, a delle sponsorizzazioni del progetto. Anche eventualmente a finanziare delle nuove features di cui si potrebbe aver bisogno e migliorare, quindi, il progetto stesso.

D’altra parte il progetto è grande. comprende la grande famiglia di Debian/Devuan/Ubunte e derivate, e potrebbe essere anche esteso portandolo magari su distribuzioni diverse come Funtoo o Arch, etc.

Ma per tutto questo c’è bisogno di un aiuto.

Grazie per l’attenzione

Piero Proietti