Debian su Proxmox con cloud-init¶

Proxmox VE è una potente piattaforma di virtualizzazione che consente di sostituire senza problemi, e senza costi di licenza, VmWare, supportando configurazioni avanzate, come clustering, HA, iperconvergenza, e molto altro. Ha inoltre il vantaggio di poter utilizzare sia le classiche macchine virtuali, su cui installare qualunque sistema operativo, che il nuovo approccio più veloce ed efficiente, dei container Linux.

Dalla versione 5.x Proxmox ha aggiunto il supporto per la creazione e la configurazione automatica delle macchine virtuali utilizzando cloud-init che consente di gestire direttamente dalla piattaforma le caratteristiche delle stesse (come indirizzi di rete, accessi SSH, ecc.). Vedremo come è possibile utilizzarlo per automatizzare la gestione di macchine virtuali installate con Debian, e come creare una immagine di sistema operativo pronta all'uso.

Uso di una immagine predisposta¶

Una possibile scelta per l'uso da parte di Proxmox, è quella di scaricare una immagine pronta per il cloud di Debian. Sono disponibili infatti delle versioni non ufficiali a partire scaricabili a partire da https://cloud.debian.org/images/cloud/; in particolare per Proxmox servono quelle denominate genericloud. Dato che le immagini non sono ufficiali, sono generati periodicamente, e di dovranno cercare nella opportuna sottodirectory, ad esempio quelle per Debian 12 Bookworm si dovranno scaricare dalla opportun sottodirectory scegliendo in genere quella generata per ultima, in sostanza da https://cloud.debian.org/images/cloud/bookworm/latest.

Per l'uso da parte di Proxmox occorrerà selezionare quella per amd64; si può prendere sia quella nel formato raw che nel formato qcow2, ma quest'ultima è preferibile per le minori dimensioni ed anche perché, se usata direttamente, è già pronta per le funzionalità avanzate di gestione da parte di Proxmox, come gli snapshot. Pertanto la si potrà scaricare con:

wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-genericcloud-arm64.qcow2

insieme all'immagine si scarichi il file con le relative checksum:

wget https://cloud.debian.org/images/cloud/bookworm/latest/SHA512SUMS

e si passi a verificare il tutto con il comando:

sha512sum -c SHA512SUMS --ignore-missing 

Come primo passo occorre creare una macchina virtuale da cui si genererà il template, ne vanno impostate anzitutto memoria e tipo di rete, facendo riferimento ad una (o più) delle interfacce di bridge disponibili (a seconda di dove la si vuole creare di default, il bridge potrà comunque essere cambiato in seguito, e se ne possono indicare più di uno se servono più interfacce), questo si fa, utilizzando un VMID non allocato, con:

qm create 4242 --memory 1024 --net0 virtio,bridge=vmbr0 # --net1 virtio,bridge=vmbr1 #,  etc.

poi si potrà ottenere il disco della nostra importando nello storage l'immagine scaricata, in questo caso se si sta usando LVM come backend per i dischi associato allo storage local-lvm (come avviene in una installazione di default) lo si potrà fare eseguendo:

root@proxmox ~ # qm importdisk 4242 debian-12-genericcloud-arm64.qcow2 local-lvm
importing disk 'debian-12-genericcloud-arm64.qcow2' to VM 4242 ...
  Logical volume "vm-4242-disk-0" created.
transferred 0.0 B of 2.0 GiB (0.00%)
transferred 20.5 MiB of 2.0 GiB (1.00%)
...
transferred 2.0 GiB of 2.0 GiB (100.00%)
Successfully imported disk as 'unused0:local-lvm:vm-4242-disk-0'

(si usi al posto di local-lvm un eventuale altro tipo di storage), questo creerà l'immagine del disco con lo stesso schema di denominazione usato nella creazione delle macchine virtuali dall'interfaccia web (vm-4242-disk-0), convertendo il contenuto del file scaricato (si possono convertire tutti i formati supportati da qemu-img, primi fa tutti .raw e .qcow2), per poter usare il disco nella macchina virtuale precedentemente creata occorrerà poi collegarcelo, con il comando:

root@proxmox ~ # qm set 4242 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-4242-disk-0,discard=on
update VM 4242: -scsi0 local-lvm:vm-4242-disk-0,discard=on -scsihw virtio-scsi-pci

(si ometta il ,discard=on se lo storage utilizzato non supporta l'uso di discard).

Si potranno poi impostare le ulteriori caratteristiche della macchina virtuale per l'uso di cloud-init con:

qm set 4242 --ide2 local-lvm:cloudinit
qm set 4242 --boot c --bootdisk scsi0
qm set 4242 --serial0 socket --vga serial0

che predispone l'avvio dall'immagine CD usata da cloud-init per passare le configurazioni alla macchina, forza l'uso dello stesso e del disco appena collegato per l'avvio e riporta la console via seriale (dato che questa è la configurazione adottate nelle immagini preparate per OpenStack come quella che abbiamo usato). Si può anche assegnare un nome alla macchina con qm set 4242 --name templimg, questo può essere impostato anche in sede di creazione aggiungendo a qm create l'opzione --name templimg.

A questo punto dall'interfaccia web si potrà utilizzare la sezione Cloud-Init relativa alla macchina, e caricare una chiave SSH per l'accesso (Cloud-Init->SSH-Public-Key->Edit->Load SSH Key File). Se poi, come nel nostro caso, si vogliono fare delle modifiche all'immagine prima di trasformarla in template, le si dovrà assegnare un IP e farla partire, l'immagine fornita da Debian infatti non consente un accesso dalla console (tutti gli utenti sono bloccati senza password) per cui la console può essere utilizzata solo per accertarsi di quando il processo di boot è finito e si può provare a collegarsi con SSH.

L'unico possibile accesso alla macchina infatti è via SSH con autenticazione a chiavi, usando la chiave corrispondente a quella che si è caricata come descritto in precedenza. Inoltre l'accesso a root è bloccato (la chiave viene riconosciuta, ma usata per stampare il messaggio di collegarsi con utente debian) e l'unico utente disponibile è debian (anche se questo può essere cambiato nella sezione Cloud-Init relativa alla macchina). Si potrà pertanto entrare sulla macchina con ssh debian@ID.DE.LA.MACCHINA e poi eseguire sudo -s per ottenere una shell di root.

Dato che questa politica prevede un inutile passaggio attraverso un utente intermedio che ha comunque accesso illimitato via sudo, non dà di per sé nessuna garanzia di sicurezza maggiore rispetto ad un accesso diretto a root, al prezzo di complicare le cose per fare operazioni remote (ad esempio degli scp) qualora questi debbano essere effettuati coi privilegi di amministratore sulla macchina stessa. Pertanto si provvederà a ripristinare una configurazione che consenta l'accesso a root con autenticazione a chiavi, eliminando l'utente superfluo.

Per far questo una volta collegati e ottenuta la shell di root il primo passo sarà quello modificare la configurazione di cloud-init in /etc/cloud/cloud.cfg, modificando la riga con disable_root da true a false (il file è in formato YML) in modo che questo diventi:

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

inoltre occorrerà eliminare dall'authorized_keys di root il prefisso che ne blocca l'accesso, cancellando tutta la parte:

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"debian\" rather than the user \"root\".';echo;sleep 10" 

lasciando solo i dati della chiave a partire da ssh-rsa; si verifichi poi il funzionamento della modifica eseguendo un accesso diretto collegandosi con ssh root@ID.DE.LA.MACCHINA.

Una volta che ci si sia ricollegati con successo usando direttamente root, si potrà cancellare l'utente debian usato per l'accesso e la relativa configurazione in /etc/sudoers.d/ con:

userdel -r debian
rm /etc/sudoers.d/debian-cloud-init /etc/sudoers.d/90-cloud-init-users

Su Buster inoltre, per evitare che venga ricreato ad ogni riavvio, occorre anche disabilitarne l'uso nella configurazione di cloud-init in /etc/cloud/cloud.cfg commentando le ultime due delle righe seguenti:

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

Infine l'immagine scaricata contiene un file /etc/network/interfaces che cerca di effettuare una configurazione in DHCP di eth0 ed eventuali altre interfacce, che deve andare in timeout prima che venga utilizzata la configurazione creata via cloud-init in /etc/network/interfaces.d/50-cloud-init.cfg. Inoltre la lettura della configurazione aggiuntiva viene fatta prima delle ulteriori configurazioni, con il risultato che queste (in particolare quella per lo) sovrascrivono quanto in essa contenuto (nel caso l'impostazione dei server DNS con resolvconf). Per questo occorre modificarne il contenuto in modo che il file contenga soltanto:

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

# The loopback network interface
auto lo
iface lo inet loopback

source /etc/network/interfaces.d/*

inoltre dato che il contenuto generato in /etc/network/interfaces.d/50-cloud-init.cfg imposta i DNS con la direttiva dns-nameservers, perché abbia effetto deve essere installato resolvconf, che invece non è presente e deve essere inserito nell'immagine con:

apt install resolvconf

Si tenga conto che per poterlo installare la rete deve essere accessibile quindi la macchina deve essere stata configurate correttamente per avere un gateway di uscita, ed inoltre, avendo l'immagine come default per il DNS (che viene mantenuto, a meno di non avere un DHCP sulla rete che configura le interfacce) 120.0.0.1 in resolv.conf, senza che il relativo servizio sia disponibile, si dovrà impostare un server DNS valido manualmente in /etc/resolv.conf (ad esempio con echo nameserver 1.1.1.1 > /etc/resolv.conf).

A questo punto si potranno effettuare eventuali altre ulteriori personalizzazioni della macchina che poi trasformeremo in template, come l'installazione di pacchetti aggiuntivi, creazione di utenti (questi potrebbero comunque essere gestiti anche tramite cloud-init), cambi di configurazione. Completate le personalizzazioni si ricordi di eliminare ogni rimasuglio, pulire la cache di APT, svuotare i file di log, ecc. Un possibile esempio di operazioni di pulizia potrebbero essere le seguenti:

apt clean
cd /var/log/
> syslog
> auth.log
> cloud-init.log
> cloud-init-output.log
> debug
> dpkg.log
> messages
> kern.log
> user.log
> daemon.log

Infine si fermi la macchina virtuale. Una volta tolta la configurazione della rete aggiunta per poterla personalizzare, la si potrà trasformare in template dall'interfaccia web o con il comando:

qm template 4242

A questo punto se ne potranno generare delle nuove macchine virtuali creando un clone, o dall'interfaccia web o con il comando:

qm clone 4242 308 --name test

da riconfigurare a piacere per l'uso delle risorse sia via web (reimpostando RAM e dimensione del disco dalla sezione Hardware) che da linea di comando con qualcosa del tipo:

qm resize 308 scsi0 50G
qm set 308 --memory 1024

e poi impostandone le caratteristiche pilotate da cloud-init, sia via web (dalla sezione Cloud-Init) che da riga di comando con qualcosa del tipo:

qm set 308 --ipconfig0 ip=192.168.XX.YY/24,gw=192.168.XX.1

si potranno inoltre installare ulteriori chiavi SSH con:

qm set 308 --sshkey elencochiavissh.pub

dove elencochiavissh.pub è un file contenente un elenco di chiavi pubbliche (una per riga) che verranno abilitate per la macchina in questione (lo si può generare da un elenco di file di chiavi con qualcosa tipo cat *.pub > elencochiavissh.pub).