L'azienda Canonical ha pubblicato una nuova versione del sistema di gestione dei container LXD 5.20, che si distingue per la modifica della licenza del progetto e l'introduzione della necessità di firmare un accordo CLA per la cessione dei diritti di proprietà sul codice al momento dell'accettazione delle modifiche in LXD. La licenza del codice aggiunto a LXD dai dipendenti di Canonical è stata modificata da Apache 2.0 a AGPLv3, mentre il codice dei partecipanti esterni, per cui Canonical non detiene diritti di proprietà, rimane sotto Apache 2.0. Poiché Canonical non ha la possibilità di modificare la licenza su tutto il codice di LXD, il progetto sarà ora fornito con condizioni miste: parte del codice sarà sotto AGPLv3 e parte sotto Apache 2.0. Il passaggio alla nuova licenza è spiegato dal desiderio di uniformare la licenza con altri prodotti server di Canonical, nei quali è utilizzata AGPLv3.
Il codice delle vecchie versioni rimane disponibile sotto la licenza Apache 2.0, ma tutte le modifiche apportate ai componenti ridefiniti saranno pubblicate solo sotto la licenza AGPLv3, il che non permetterà al fork Incus di trasferire modifiche da LXD senza adeguare la propria base di codice alla licenza AGPLv3. Le licenze Apache 2.0 e AGPLv3 hanno una compatibilità unidirezionale, il che significa che il codice sotto licenza Apache 2.0 può essere incluso nel codice sotto licenza AGPLv3, ma non viceversa. Questa modifica segna la completa cessazione della cooperazione tra i progetti LXD e Incus, poiché il trasferimento di modifiche da LXD a Incus è ostacolato dalla nuova licenza e, da Incus a LXD, dalla necessità di firmare l'accordo CLA, che gli sviluppatori di Incus non intendono firmare.
Una caratteristica della licenza AGPLv3 è l'introduzione di limitazioni aggiuntive per le applicazioni che gestiscono servizi di rete. Quando si utilizzano componenti AGPL nel funzionamento dei servizi di rete, lo sviluppatore è obbligato a fornire all'utente il codice sorgente di tutte le modifiche apportate a questi componenti, anche se il software sottostante non è distribuito e viene utilizzato esclusivamente nella propria infrastruttura interna per organizzare il funzionamento del servizio. La licenza AGPL impone anche condizioni di copyleft, quindi per includere il codice AGPL da LXD nel proprio progetto, la base di codice del progetto deve essere rinominata sotto la licenza AGPL.
LXD fornisce strumenti per la gestione centralizzata di container e macchine virtuali distribuite in un cluster di più server. LXD funziona come un processo in background che accetta richieste sulla rete attraverso un'API REST e supporta vari backend di archiviazione (albero delle directory, ZFS, Btrfs, LVM), snapshot per il salvataggio dello stato, live migration di container attivi da una macchina all'altra e strumenti per l'archiviazione delle immagini dei container. Per l'esecuzione dei container viene utilizzato l'ambiente LXC, che comprende la libreria liblxc, un insieme di utilità (lxc-create, lxc-start, lxc-stop, lxc-ls, ecc.), modelli per la creazione di container e un insieme di binding per diversi linguaggi di programmazione. L'isolamento è realizzato utilizzando i meccanismi standard del kernel Linux (namespace, cgroups, Apparmor, SELinux, Seccomp). Oltre a LXC, nel LXD vengono utilizzati anche componenti dai progetti CRIU e QEMU.
Tra le nuove funzionalità aggiunte a LXD 5.20:
- Durante la creazione di pool di archiviazione basati su Cephfs, è stata introdotta la possibilità di creare metadati e dati per i pool OSD (Object Storage Daemon), utilizzando i parametri cephfs.create_missing, cephfs.meta_pool e cephfs.data_pool. Ad esempio: lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
- Nel pacchetto snap di LXD è stata aggiunta la possibilità di configurare la priorità di avvio da diversi dischi nell'ambito del firmware EDK2, utilizzando la modalità security.csm.
- Nel firmware EDK2 UEFI è stata aggiunta una modalità di debug (boot.debug_edk2=true) per diagnosticare problemi di avvio di macchine virtuali. Il log di debug viene salvato nel file $LXD_DIR/logs//edk2.log.
- Il codice di autorizzazione è stato convertito su base modulare, consentendo il supporto per OpenFGA oltre all'autenticazione tramite certificati TLS e Canonical RBAC.
- Per compilare LXD è necessaria almeno la versione 1.20 del linguaggio Go.
- Il supporto per Shiftfs è stato rimosso. Per il mapping delle identificazioni utente, è necessario utilizzare il montaggio con idmap, supportato per Ext4, XFS, Btrfs, ZFS e Cephfs.
- Il supporto per i firmware UEFI di dimensione 2MB è stato rimosso (è necessario utilizzare firmware di dimensione 4MB).
- Dal codice sorgente del fork Incus è stata trasferita la supporto per la creazione di archivi basati su tecnologia NVME. È stato aggiunto un nuovo parametro di configurazione "io.bus" per indicare il tipo di disco, che è impostato su "virtio-scsi" di default. Se il valore viene modificato in "nvme", l'unità nella macchina virtuale sarà visibile come NVME SSD.
- Dal codice sorgente del fork di Incus è stata aggiunta la supporto per il collegamento e la rimozione a caldo (hot-plug/hot-remove) di percorsi di file o partizioni singole, passate dall'ambiente host. In precedenza, questo passaggio attraverso il driver virtio-fs o il FS 9p richiedeva l'arresto della macchina virtuale. Per aggirare questa limitazione, è stata sfruttata la possibilità di QEMU di connettere a caldo dispositivi PCI e montare percorsi all'interno del sistema guest tramite incus-agent.
- L'identificatore del dispositivo org.linuxcontainers.lxd è stato rinominato in com.canonical.lxd (per mantenere la retrocompatibilità, si è preservato il supporto per il vecchio identificatore).
Fonte: opennet.ru
