L'azienda Canonical ha pubblicato una nuova versione del sistema di gestione dei container LXD 5.20, che è notevole 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'acceptazione delle modifiche in LXD. La licenza del codice aggiunto in LXD dai dipendenti di Canonical è stata cambiata da Apache 2.0 a AGPLv3, mentre il codice dei collaboratori esterni, su cui Canonical non detiene diritti di proprietà, rimane sotto Apache 2.0. Poiché Canonical non ha la possibilità di modificare la licenza dell'intero codice di LXD, il progetto ora sarà fornito con condizioni miste: parte del codice sotto AGPLv3 e parte sotto Apache 2.0. Il passaggio alla nuova licenza è spiegato dal desiderio di unificare la licenza con altri prodotti server di Canonical, che utilizzano AGPLv3.
Il codice delle vecchie versioni rimane disponibile sotto licenza Apache 2.0, ma tutte le modifiche apportate ai componenti ri-licenziati saranno pubblicate esclusivamente sotto licenza AGPLv3, il che impedirà al fork di Incus di trasferire modifiche da LXD senza convertire la propria base di codice alla licenza AGPLv3. Le licenze Apache 2.0 e AGPLv3 hanno una compatibilità unilaterale, cioè il codice sotto licenza Apache 2.0 può essere incluso nel codice sotto licenza AGPLv3, ma non viceversa. La modifica significa la cessazione totale della cooperazione tra i progetti LXD e Incus, poiché il trasferimento delle 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 delle caratteristiche della licenza AGPLv3 è l'introduzione di restrizioni aggiuntive per le applicazioni che forniscono il funzionamento dei servizi di rete. Quando si utilizzano componenti AGPL nel funzionamento dei servizi di rete, il sviluppatore è obbligato a fornire all'utente il codice sorgente di tutte le modifiche apportate a questi componenti, anche se il software alla base del servizio non è distribuito ed è utilizzato esclusivamente all'interno dell'infrastruttura per l'organizzazione del lavoro del servizio. La licenza AGPL impone anche condizioni di copyleft, cioè per includere il codice AGPL di LXD nel proprio progetto, la base di codice del proprio progetto deve essere ri-licenziata sotto licenza AGPL.
LXD fornisce strumenti per la gestione centralizzata di container e macchine virtuali distribuiti in un cluster di più nodi. serverLXD è implementato come processo in background che accetta richieste di rete tramite REST API e supporta vari backend di archiviazione (albero delle directory, ZFS, Btrfs, LVM), snapshot con istantanee di stato, migrazione live dei container in esecuzione da una macchina all'altra e strumenti per l'archiviazione delle immagini dei container. Per l'esecuzione dei container, viene utilizzato il toolkit LXC, che comprende la libreria liblxc, un insieme di utility (lxc-create, lxc-start, lxc-stop, lxc-ls, ecc.), modelli per la creazione di container e un set di binding per diversi linguaggi di programmazione. L'isolamento è realizzato mediante i meccanismi standard del kernel Linux (spazi dei nomi, cgroups, Apparmor, SELinux, Seccomp). Oltre a LXC, in LXD sono utilizzati anche componenti dei progetti CRIU e QEMU.
Tra le nuove funzionalità introdotte in LXD 5.20:
- Durante la creazione di pool di archiviazione basati su Cephfs, è stata fornita 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 dischi diversi durante l'uso della modalità security.csm.
- Nella firmware EDK2 UEFI è stata aggiunta una modalità di debug (boot.debug_edk2=true) per la diagnosi dei problemi di avvio. macchine virtualiIl log di debug viene salvato nel file $LXD_DIR/logs//edk2.log.
- Il codice di autorizzazione è stato convertito in una base modulare, consentendo il supporto per OpenFGA oltre all'autenticazione tramite certificati TLS e RBAC Canonical.
- Per compilare LXD ora è necessaria almeno la versione 1.20 del linguaggio Go.
- È stata rimossa la supporto per Shiftfs. Per il mapping degli identificativi degli utenti, è consigliato utilizzare il montaggio con idmap, supportato per Ext4, XFS, Btrfs, ZFS e Cephfs.
- È stata rimossa la supporto per firmware UEFI da 2MB (si raccomanda di utilizzare firmware da 4MB).
- Dalla base di codice del fork Incus è stata trasferita la supporto per la creazione di storage basati sulla tecnologia NVME. Per specificare il tipo di disco è stato aggiunto un nuovo parametro di configurazione «io.bus», che per impostazione predefinita è impostato su «virtio-scsi». Cambiando il valore in «nvme», l'unità nella macchina virtuale sarà visibile come NVME SSD.
- Dalla base di codice del fork Incus è stata trasferita la supporto per il collegamento e la disconnessione a caldo (hot-plug/hot-remove) di percorsi file o singole partizioni, passate dall'ambiente host. In precedenza, questo tipo di passaggio tramite il driver virtio-fs o FS 9p richiedeva l'arresto della macchina virtuale. Per superare questa limitazione, è stata utilizzata la possibilità di QEMU di collegare a caldo dispositivi PCI e montare il percorso all'interno del sistema guest tramite incus-agent.
- L'identificatore del dispositivo org.linuxcontainers.lxd è stato rinominato in com.canonical.lxd (per mantenere la compatibilità retroattiva è stata mantenuta la supporto per il vecchio identificatore).
Fonte: opennet.ru
