ProHoster > Blog > Lajmet e internetit > Canonical e kaloi projektin LXD në licencën AGPLv3

Canonical e kaloi projektin LXD në licencën AGPLv3

Kompania Canonical publikoi versionin e ri të sistemit të menaxhimit të kontejnerëve LXD 5.20, e cila shquhet për ndryshimin e licencës së projektit dhe përpara se të nënshkruhet marrëveshja CLA për transferimin e të drejtave të pronësisë mbi kodin kur pranojnë ndryshime në LXD. Licenca për kodin e shtuar në LXD nga punëmarrësit e Canonical është ndryshuar nga Apache 2.0 në AGPLv3, ndërsa kodi i kontribuesve të tjerë, mbi të cilin Canonical nuk ka të drejta pronësore, mbetet nën Apache 2.0. Duke qenë se Canonical nuk ka mundësi të ndryshojë licencën për të gjithë kodin LXD, projekti tani do të ofrohet me kushte të përziera - një pjesë e kodit nën AGPLv3 dhe një pjesë nën Apache 2.0. Kalimi në licencën e re shpjegohet me dëshirën për të unifikuar licencën me produktet e tjera serverike të Canonical, të cilat përdorin AGPLv3.

Kodi i versioneve të vjetra, ashtu siç ishte, mbetet i disponueshëm nën licencën Apache 2.0, por të gjitha ndryshimet në komponentët e ripërcaktuar do të publikohet vetëm nën licencën AGPLv3, e cila nuk do t'i lejojë forkut Incus të transferojë ndryshime nga LXD pa e çuar bazën e tij të kodit në licencën AGPLv3. Licencat Apache 2.0 dhe AGPLv3 kanë një përputhshmëri njëanshme, e cila rezulton në faktin se kodi nën licencën Apache 2.0 mund të përfshihet në kodin nën licencën AGPLv3, por jo anasjelltas. Ndryshimi do të thotë një ndërprerje të plotë të bashkëpunimit midis projekteve LXD dhe Incus, pasi transferimi i ndryshimeve nga LXD në Incus pengohet nga licenca e re, dhe nga Incus në LXD kërkesa për nënshkrimin e marrëveshjes CLA, të cilën zhvilluesit e Incus nuk kanë ndërmend ta nënshkruajnë.

Karakteristika e licencës AGPLv3 është se sjell kufizime shtesë për aplikacionet që sigurojnë funksionimin e shërbimeve rrjet. Kur përdoren komponentë AGPL në funksionimin e shërbimeve rrjet, zhvilluesi është i detyruar të ofrojë përdoruesit kodin burimor të të gjitha ndryshimeve të bëra në këto komponentë, edhe nëse softueri që është baza e shërbimit nuk shpërndahen dhe përdoret vetëm në infrastrukturën e brendshme për organizimin e funksionimit të shërbimit. Licenca AGPL gjithashtu vendos kushte copyleft, domethënë, për të përfshirë kodin AGPL nga LXD në projektin tuaj, baza e kodit të projektit tuaj duhet të ri-licencohet nën licencën AGPL.

LXD ofron mjete për menaxhimin qendror të kontejnerëve dhe makinave virtuale, të implementuara në një klaster të disa serverësh. LXD implementohet si një proces sfondor që pranon kërkesa përmes rrjetit nëpërmjet REST API dhe mbështet disa backend të ruajtjes (strukturë drejtorish, ZFS, Btrfs, LVM), snapshot-e me prerje të gjendjes, migrimin e drejtpërdrejtë të kontejnerëve në punë nga një makinë në tjetrën dhe mjete për ruajtjen e imazheve të kontejnerëve. Si runtime për ekzekutimin e kontejnerëve përdoret mjeti LXC, i cili përfshin bibliotekën liblxc, një grup utilitarësh (lxc-create, lxc-start, lxc-stop, lxc-ls etj.), modele për ndërtimin e kontejnerëve dhe një grup lidhjesh për gjuhë të ndryshme programimi. Izolimi realizohet përmes mekanizmave standarde të kernelit Linux (hapësira e emrave, cgroups, Apparmor, SELinux, Seccomp). Përveç LXC, në LXD përdoren gjithashtu komponentët nga projektet CRIU dhe QEMU.

Ndër mundësitë e reja që u shtuan në LXD 5.20:

  • GjatĂ« krijimit tĂ« grupeve tĂ« ruajtjes nĂ« bazĂ« tĂ« Cephfs, u ofrua mundĂ«sia pĂ«r tĂ« krijuar metadata dhe tĂ« dhĂ«na pĂ«r grupet OSD (Object Storage Daemon), duke pĂ«rdorur parametrat cephfs.create_missing, cephfs.meta_pool dhe cephfs.data_pool. PĂ«r shembull: lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
  • NĂ« paketĂ«n snap tĂ« LXD, nĂ« firmen EDK2 u shtua mundĂ«sia pĂ«r tĂ« konfiguruar prioritetin e boot-it nga disqe tĂ« ndryshme kur pĂ«rdoret moda security.csm.
  • NĂ« firmen EDK2 UEFI u shtua njĂ« mod i depurimit (boot.debug_edk2=true) pĂ«r diagnostikimin e problemeve gjatĂ« boot-it makinat virtuale. Log-u i depurimit ruhet nĂ« skedarin $LXD_DIR/logs//edk2.log.
  • Kodi i autorizimit Ă«shtĂ« transferuar nĂ« njĂ« bazĂ« modulare, duke mundĂ«suar mbĂ«shtetje pĂ«r OpenFGA pĂ«rveç autorizimit me certifikata TLS dhe Canonical RBAC.
  • PĂ«r kompaktimin e LXD tani kĂ«rkohet tĂ« paktĂ«n versioni 1.20 i gjuhĂ«s Go.
  • MbĂ«shtetja pĂ«r Shiftfs Ă«shtĂ« hequr. PĂ«r mapimin e identifikatorĂ«ve tĂ« pĂ«rdoruesve duhet tĂ« pĂ«rdoret montimi me idmap, qĂ« mbĂ«shtetet pĂ«r Ext4, XFS, Btrfs, ZFS dhe Cephfs.
  • MbĂ«shtetja pĂ«r firmen UEFI, me pĂ«rmasĂ« 2MB Ă«shtĂ« hequr (duhet tĂ« pĂ«rdoren firma me pĂ«rmasĂ« 4MB).
  • Nga kodi i fork-ut Incus Ă«shtĂ« transferuar mbĂ«shtetje pĂ«r krijimin e depozitave qĂ« pĂ«rdorin teknologjinĂ« NVMe. PĂ«r tĂ« specifikuar llojin e diskut Ă«shtĂ« shtuar njĂ« parametĂ«r i ri konfigurimi "io.bus", i cili Ă«shtĂ« vendosur nĂ« vlerĂ«n "virtio-scsi" si parazgjedhje. Kur ndryshohet vlera nĂ« "nvme", disku nĂ« makinĂ« virtuale do tĂ« duket si NVMe SSD.
  • Nga kodi i fork-ut Incus Ă«shtĂ« transferuar mbĂ«shtetje pĂ«r lidhjen dhe çlidhjen e nxehtĂ« (hot-plug/hot-remove) tĂ« rrugĂ«ve tĂ« skedarĂ«ve ose tĂ« pjesĂ«ve tĂ« veçanta, tĂ« cilat kalojnĂ« nga mjedisi i host-it. MĂ« parĂ«, ky kalim pĂ«rmes drejtuesit virtio-fs ose FS 9p kĂ«rkonte ndalimin e makinĂ«s virtuale. PĂ«r tĂ« shmangur kĂ«tĂ« kufizim, Ă«shtĂ« pĂ«rdorur aftĂ«sia e QEMU pĂ«r lidhjen e nxehtĂ« tĂ« pajisjeve PCI dhe montimin e rrugĂ«s brenda sistemit mysafir pĂ«rmes incus-agent.
  • Identifikuesi i pajisjes org.linuxcontainers.lxd Ă«shtĂ« ribĂ«rĂ« nĂ« com.canonical.lxd (pĂ«r tĂ« ruajtur pĂ«rputhshmĂ«rinĂ« e prapme, mbĂ«shtetja pĂ«r identifikuesin e vjetĂ«r Ă«shtĂ« ruajtur).

Burimi: opennet.ru

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster