Project

General

Profile

ProxmoxDebianCloudInit » History » Version 14

Simone Piccardi, 12/02/2019 03:17 PM

1 1 Simone Piccardi
h1. Debian su Proxmox con cloud-init
2
3 14 Simone Piccardi
Con la versione 5.x Proxmox ha aggiunto il supporto per la creazione e la configurazione automatica delle macchine virtuali utilizzando @cloud-init@. Vedremo come utilizzarlo per la gestione di macchine virtuali con Debian (quando non indicato diversamente le istruzioni si applicano sia a Stretch che a Buster).
4 1 Simone Piccardi
5 2 Simone Piccardi
Il primo passo è scaricare una immagine pronta per il cloud di Debian, sono disponibili delle versioni non ufficiali a partire su 
6 14 Simone Piccardi
https://cdimage.debian.org/cdimage ed in particolare per Proxmox servono quelle di OpenStack, pertanto si dovranno prendere da https://cdimage.debian.org/cdimage/openstack, selezionando quella per amd64, nel formato raw o qcow2 (quest'ultima è preferibile per le minori dimensioni), scaricandole ad esempio con:
7 1 Simone Piccardi
8
<pre>
9 14 Simone Piccardi
wget https://cdimage.debian.org/cdimage/openstack/current/debian-10.2.0-openstack-amd64.qcow2
10 1 Simone Piccardi
</pre>
11 2 Simone Piccardi
12 14 Simone Piccardi
insieme all'immagine si scarichino le relative checksum e firme con cui verificarne l'integrità:
13 2 Simone Piccardi
14
<pre>
15
wget https://cdimage.debian.org/cdimage/openstack/current/SHA512SUMS
16
wget https://cdimage.debian.org/cdimage/openstack/current/SHA512SUMS.sign
17 1 Simone Piccardi
</pre>
18 2 Simone Piccardi
19 14 Simone Piccardi
e si passi a verificare il tutto con i comandi:
20 3 Simone Piccardi
21
<pre>
22 13 Simone Piccardi
gpg --verify SHA512SUMS.sign SHA512SUMS
23 14 Simone Piccardi
sha512sum -c SHA512SUMS --ignore-missing 
24 3 Simone Piccardi
</pre>
25
26 14 Simone Piccardi
Se @gpg@ dice che è impossibile controllare la firma perché non c'è la chiave pubblica, questa deve essere importata dal keyring di Debian con qualcosa come @gpg --keyserver keyring.debian.org --recv-keys DF9B9C49EAA9298432589D76DA87E80D6294BE9B@ (dove il numero della chiave è quello riportato dal comando in caso di fallimento). Si tenga presente che comunque, a meno di non averne impostato un livello di fiducia,   @gpg@ avvertirà che non c'è nessuna sicurezza relativa al fatto che la chiave appartenga davvero al proprietario, quello che comunque si deve verificare è che il comando indichi una firma valida.
27 3 Simone Piccardi
28 14 Simone Piccardi
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:
29 3 Simone Piccardi
30
<pre>
31 14 Simone Piccardi
qm create 4242 --memory 512 --net0 virtio,bridge=vmbr0 # --net1 virtio,bridge=vmbr1 #,  etc.
32 3 Simone Piccardi
</pre>
33
34
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:
35
36
<pre>
37
root@proxmox ~ # qm importdisk 4242 debian-9.7.0-openstack-amd64.qcow2 local-lvm
38
  Using default stripesize 64.00 KiB.
39
  Logical volume "vm-4242-disk-0" created.
40
    (100.00/100%)
41
</pre>
42
43 14 Simone Piccardi
(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:
44 3 Simone Piccardi
45
 <pre>
46
root@proxmox ~ # qm set 4242 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-4242-disk-0,discard=on
47 4 Simone Piccardi
update VM 4242: -scsi0 local-lvm:vm-4242-disk-0,discard=on -scsihw virtio-scsi-pci
48 3 Simone Piccardi
</pre>
49
50
(si ometta il @,discard=on@ se lo storage utilizzato non supporta l'uso di discard). 
51
52 4 Simone Piccardi
Si potranno poi impostare le ulteriori caratteristiche della macchina virtuale per l'uso di @cloud-init@ con:
53 1 Simone Piccardi
54 4 Simone Piccardi
<pre>
55
qm set 4242 --ide2 local-lvm:cloudinit
56
qm set 4242 --boot c --bootdisk scsi0
57
qm set 4242 --serial0 socket --vga serial0
58
</pre>
59
60 14 Simone Piccardi
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@.
61 4 Simone Piccardi
62
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.
63
64
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.
65
66 6 Simone Piccardi
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.
67 4 Simone Piccardi
68 6 Simone Piccardi
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:
69 4 Simone Piccardi
 
70
<pre>
71
# If this is set, 'root' will not be able to ssh in and they
72
# will get a message to login instead as the above $user (debian)
73
disable_root: false
74
</pre>
75
76
inoltre occorrerà eliminare dall'@authorized_keys@ di root il prefisso che ne blocca l'accesso, cancellando tutta la parte:
77
78
<pre>
79
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"
80
</pre>
81
82 1 Simone Piccardi
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@.
83
84
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:
85
86
<pre>
87
userdel -r debian
88
rm /etc/sudoers.d/debian-cloud-init /etc/sudoers.d/90-cloud-init-users
89
</pre>
90
91 14 Simone Piccardi
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:
92 4 Simone Piccardi
93 8 Simone Piccardi
<pre>
94 14 Simone Piccardi
# A set of users which may be applied and/or used by various modules
95
# when a 'default' entry is found it will reference the 'default_user'
96
# from the distro configuration specified below
97
#users:
98
#   - default
99
</pre>
100
101
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:
102
103
<pre>
104 1 Simone Piccardi
# This file describes the network interfaces available on your system
105
# and how to activate them. For more information, see interfaces(5).
106
107
# The loopback network interface
108
auto lo
109
iface lo inet loopback
110 6 Simone Piccardi
111
source /etc/network/interfaces.d/*
112
</pre>
113
114 14 Simone Piccardi
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:
115 6 Simone Piccardi
116
<pre>
117 14 Simone Piccardi
apt install resolvconf
118 6 Simone Piccardi
</pre>
119
120 14 Simone Piccardi
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@). 
121 6 Simone Piccardi
122 14 Simone Piccardi
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:
123 11 Simone Piccardi
124
<pre>
125
apt clean
126
cd /var/log/
127
> syslog
128
> auth.log
129
> cloud-init.log
130
> cloud-init-output.log
131
> debug
132
> dpkg.log
133
> messages
134
> kern.log
135
> user.log
136
> daemon.log
137
</pre>
138
139
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:
140 6 Simone Piccardi
141
<pre>
142
qm template 4242
143
</pre>
144
145
A questo punto se ne potranno generare delle nuove macchine virtuali creando un clone, o dall'interfaccia web o con il comando:
146
147
<pre>
148
qm clone 4242 308 --name test
149
</pre>
150
151
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:
152
153
<pre>
154 8 Simone Piccardi
qm resize 308 scsi0 50G
155 6 Simone Piccardi
qm set 308 --memory 1024
156
</pre>
157
158
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:
159
160
<pre>
161 7 Simone Piccardi
qm set 308 --ipconfig0 ip=192.168.XX.YY/24,gw=192.168.XX.1
162 1 Simone Piccardi
</pre>
163 9 Simone Piccardi
164
si potranno inoltre installare ulteriori chiavi SSH con:
165
166
<pre>
167
qm set 308 --sshkey elencochiavissh.pub
168
</pre>
169
170 10 Simone Piccardi
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@).