{"id":38929,"date":"2019-10-31T22:26:48","date_gmt":"2019-10-31T19:26:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\/"},"modified":"2019-10-31T22:26:48","modified_gmt":"2019-10-31T19:26:48","slug":"linux-mnogolikij-kak-rabotat-na-lyubom-distributive","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","title":{"rendered":"Linux \u00e8 variegato: come lavorare su qualsiasi distribuzione","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Linux \u00e8 variegato: come lavorare su qualsiasi distribuzione\" src=\"\/wp-content\/uploads\/2019\/10\/ee1aaad566204532c974a3ce8f13b915.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCreare un'applicazione di backup che funzioni su qualsiasi distribuzione \u00e8 un compito complesso. Per garantire il funzionamento di Veeam Agent for Linux su distribuzioni da Red Hat 6 e Debian 6 fino a OpenSUSE 15.1 e Ubuntu 19.04, \u00e8 necessario affrontare una serie di problemi, soprattutto considerando che il prodotto software include un modulo del kernel.<\/p>\n<p>L'articolo \u00e8 stato redatto sulla base della presentazione alla conferenza <noindex><a rel=\"nofollow\" href=\"https:\/\/linuxpiter.com\/materials\/2636\"> LinuxPiter 2019<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nLinux non \u00e8 solo uno dei sistemi operativi pi\u00f9 popolari. Fondamentalmente, \u00e8 una piattaforma su cui \u00e8 possibile costruire qualcosa di unico, qualcosa di nostro. Grazie a questo, Linux ha molte distribuzioni, che si distinguono per il set di componenti software. Qui sorge il problema: affinch\u00e9 il prodotto software funzioni su qualsiasi distribuzione, \u00e8 necessario tener conto delle peculiarit\u00e0 di ciascuna.<\/p>\n<h2>Gestori di pacchetti: .deb vs .rpm<\/h2>\n<p>\nIniziamo con il problema evidente della distribuzione del prodotto per diverse distribuzioni.<br \/>\nIl modo pi\u00f9 tipico di distribuire prodotti software \u00e8 caricare un pacchetto su un repository, affinch\u00e9 il gestore di pacchetti integrato nel sistema possa installarlo da l\u00ec.<br \/>\nTuttavia, ci sono due formati di pacchetti popolari: <i>rpm<\/i> e <i>deb<\/i>. Significa che sar\u00e0 necessario supportare entrambi.<\/p>\n<p>Nel mondo dei pacchetti deb, il livello di compatibilit\u00e0 \u00e8 sorprendente. Lo stesso pacchetto si installa e funziona altrettanto bene sia su Debian 6 sia su Ubuntu 19.04. Gli standard del processo di creazione dei pacchetti e la loro gestione, stabiliti nelle vecchie distribuzioni di Debian, rimangono attuali anche nelle moderne Linux Mint e elementary OS. Pertanto, nel caso di Veeam Agent for Linux, \u00e8 sufficiente un pacchetto deb per ogni piattaforma hardware.<\/p>\n<p>Nel mondo dei pacchetti rpm, invece, le differenze sono grandi. In primo luogo, a causa del fatto che ci sono due distributori completamente indipendenti, Red Hat e SUSE, per i quali la compatibilit\u00e0 non \u00e8 affatto necessaria. In secondo luogo, questi distributori hanno distribuzioni con supporto tecnico e sperimentali. Tra di loro la compatibilit\u00e0 non \u00e8 necessaria. Risultano pacchetti distinti per el6, el7 ed el8. Un pacchetto separato per Fedora. Pacchetti per SLES11 e 12 e uno separato per openSUSE. Il problema principale riguarda le dipendenze e i nomi dei pacchetti. <\/p>\n<h2>Il problema delle dipendenze<\/h2>\n<p>\nPurtroppo, gli stessi pacchetti spesso si presentano con nomi diversi in diverse distribuzioni. Di seguito \u00e8 riportato un elenco incompleto delle dipendenze del pacchetto veeam.<\/p>\n<p>Per EL7:<br \/>\nPer SLES 12:<\/p>\n<ul>\n<li>libblkid<\/li>\n<li>libgcc<\/li>\n<li>libstdc++<\/li>\n<li>ncurses-libs<\/li>\n<li>fuse-libs<\/li>\n<li>file-libs<\/li>\n<li>veeamsnap = 3.0.2.1185<\/li>\n<\/ul>\n<ul>\n<li>libblkid1<\/li>\n<li>libgcc_s1<\/li>\n<li>libstdc++6<\/li>\n<li>libmagic1<\/li>\n<li>libfuse2<\/li>\n<li>veeamsnap-kmp = 3.0.2.1185<\/li>\n<\/ul>\n<p>\nDi conseguenza, l'elenco delle dipendenze si rivela unico per la distribuzione. <\/p>\n<p>Peggio ancora quando una versione aggiornata inizia a nascondersi dietro il vecchio nome del pacchetto. <\/p>\n<p><b>Esempio:<\/b><\/p>\n<p>In Fedora 24 il pacchetto \u00e8 stato aggiornato <i>ncurses<\/i> dalla versione 5 alla versione 6. Il nostro prodotto \u00e8 stato assemblato proprio con la versione 5, per garantire la compatibilit\u00e0 con le vecchie distribuzioni. Per utilizzare la vecchia versione 5 della libreria su Fedora 24, \u00e8 stato necessario utilizzare il pacchetto <i>ncurses-compat-libs<\/i>. <\/p>\n<p>Di conseguenza, per Fedora appaiono due pacchetti, con dipendenze diverse. <\/p>\n<p>Dopo diventa pi\u00f9 interessante. Dopo un altro aggiornamento della distribuzione, il pacchetto <i>ncurses-compat-libs<\/i> con la versione 5 della libreria risulta non disponibile. Per il distributore \u00e8 oneroso portare vecchie librerie in una nuova versione della distribuzione. Dopo un po' di tempo, il problema si \u00e8 ripetuto anche nelle distribuzioni SUSE.<\/p>\n<p>Di conseguenza, per alcune distribuzioni \u00e8 stato necessario rinunciare a una dipendenza esplicita da <i>ncurses-libs<\/i>, e modificare il prodotto in modo che potesse funzionare con qualsiasi versione della libreria.<\/p>\n<p>A proposito, nella versione 8 di Red Hat non c'\u00e8 pi\u00f9 il meta-pacchetto <i>python<\/i>, che faceva riferimento al buon vecchio <i>python 2.7<\/i>. C'\u00e8 <i>python2<\/i> e <i>python<\/i>3. <\/p>\n<h2>L'alternativa ai gestori di pacchetti<\/h2>\n<p>\nIl problema delle dipendenze \u00e8 vecchio e da tempo \u00e8 evidente. Basta ricordare il fenomeno della Dependency hell. <br \/>\nUnire le varie librerie e applicazioni in modo che tutte funzionino in modo stabile e non conflittuale \u2014 questo \u00e8 esattamente ci\u00f2 che cerca di risolvere qualsiasi distributore Linux.<\/p>\n<p>Diversamente, il gestore di pacchetti <b>Snappy<\/b> di Canonical. L'idea di base \u00e8: l'applicazione viene eseguita in una sandbox isolata e protetta dal sistema principale. Se l'applicazione ha bisogno di librerie, queste vengono fornite insieme all'applicazione stessa.<\/p>\n<p><b>Flatpak<\/b> permette anche di eseguire applicazioni in sandbox, utilizzando i container Linux. L'idea della sandbox \u00e8 condivisa anche da <b>AppImage<\/b>.<\/p>\n<p>Queste soluzioni permettono di creare un singolo pacchetto per tutte le distribuzioni. Nel caso di <b>Flatpak<\/b> l'installazione e l'esecuzione dell'applicazione \u00e8 possibile anche senza il consenso dell'amministratore.<\/p>\n<p>Il problema principale \u00e8 che non tutte le applicazioni possono funzionare in sandbox. Alcune hanno bisogno di un accesso diretto alla piattaforma. Non parlo nemmeno dei moduli del kernel, che dipendono strettamente dal kernel e non si adattano per niente al concetto di sandbox. <\/p>\n<p>Un altro problema \u00e8 che le distribuzioni popolari nel settore enterprise di Red Hat e SUSE non supportano ancora Snappy e Flatpak. <\/p>\n<p>A causa di ci\u00f2, Veeam Agent for Linux non \u00e8 disponibile n\u00e9 su <noindex><a rel=\"nofollow\" href=\"https:\/\/snapcraft.io\/\">snapcraft.io<\/a><\/noindex> n\u00e9 su <noindex><a rel=\"nofollow\" href=\"https:\/\/flathub.org\/home\">flathub.org<\/a><\/noindex>.<\/p>\n<p>Per concludere la questione dei gestori di pacchetti, osservo che \u00e8 possibile rinunciare del tutto ai gestori di pacchetti, combinando in un solo pacchetto i file binari e lo script per la loro installazione. <\/p>\n<p>Tale bundle consente di creare un unico pacchetto per diverse distribuzioni e piattaforme, realizzando un processo di installazione interattivo, effettuando la personalizzazione necessaria. Ho incontrato tali pacchetti per Linux solo da VMware.<\/p>\n<h2>Il problema degli aggiornamenti<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux \u00e8 variegato: come lavorare su qualsiasi distribuzione\" src=\"\/wp-content\/uploads\/2019\/10\/aa14b10a434c28541574421d97807de7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAnche se tutti i problemi di dipendenze sono risolti, il programma pu\u00f2 funzionare in modo diverso sulla stessa distribuzione. Il problema sono gli aggiornamenti.<\/p>\n<p>Ci sono 3 strategie per l'aggiornamento:<\/p>\n<ul>\n<li>La pi\u00f9 semplice \u00e8 non aggiornare mai. Hai configurato il server e ti sei dimenticato. Perch\u00e9 aggiornare se tutto funziona? I problemi iniziano al primo contatto con il supporto tecnico. Il creatore della distribuzione supporta solo la release aggiornata. <\/li>\n<li>Puoi fidarti del distributore e impostare aggiornamenti automatici. In questo caso, una chiamata al supporto tecnico \u00e8 probabile subito dopo un aggiornamento fallito.<\/li>\n<li>L'opzione di aggiornamento manuale solo dopo averlo testato su un'infrastruttura di prova \u00e8 la pi\u00f9 sicura, ma costosa e laboriosa. Non tutti possono permetterselo.<\/li>\n<\/ul>\n<p>\nPoich\u00e9 diversi utenti applicano varie strategie di aggiornamento, \u00e8 necessario supportare sia l'ultima release che tutte quelle precedenti. Questo complica sia il processo di sviluppo sia quello di test, aggiungendo mal di testa al supporto tecnico.<\/p>\n<h2>La variet\u00e0 delle piattaforme hardware<\/h2>\n<p>\nDiverse piattaforme hardware sono un problema, in gran parte specifico per il codice nativo. Al minimo, bisogna compilare i binari per ogni piattaforma supportata.<\/p>\n<p>Nel progetto Veeam Agent for Linux non riusciamo a supportare nulla di RISC.<\/p>\n<p>Non mi soffermer\u00f2 dettagliatamente su questo argomento. Indicher\u00f2 solo i principali problemi: tipi dipendenti dalla piattaforma, come <code>size_t<\/code>, allineamento delle strutture e ordine dei byte.<\/p>\n<h2>Linkaggio statico e\/o dinamico<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Linux \u00e8 variegato: come lavorare su qualsiasi distribuzione\" src=\"\/wp-content\/uploads\/2019\/10\/dc473aad4ea0818940af7eafdbc641fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nE ora la questione \"Come linkarsi alle librerie - dinamicamente o staticamente?\" \u00e8 da discutere.<\/p>\n<p>In genere, le applicazioni C\/C++ su Linux utilizzano il collegamento dinamico. Funziona perfettamente se l'applicazione \u00e8 compilata specificamente per una distribuzione particolare.<\/p>\n<p>Se l'obiettivo \u00e8 coprire diverse distribuzioni con un singolo file binario, \u00e8 necessario orientarsi verso la distribuzione pi\u00f9 vecchia supportata. Per noi, questa \u00e8 Red Hat 6. Essa include gcc 4.4, che non supporta nemmeno lo standard C++11. <noindex><a rel=\"nofollow\" href=\"https:\/\/gcc.gnu.org\/projects\/cxx-status.html\">completamente<\/a><\/noindex>.<\/p>\n<p>Compiliamo il nostro progetto usando gcc 6.3, che supporta completamente C++14. Naturalmente, in questo caso, su Red Hat 6, \u00e8 necessario portare con s\u00e9 la libreria libstdc++ e boost. \u00c8 pi\u00f9 semplice collegarli staticamente.<\/p>\n<p>Ma sfortunatamente, non tutte le librerie possono essere collegate staticamente.<\/p>\n<p>In primo luogo, le librerie di sistema, come <i>libfuse<\/i>, <i>libblkid<\/i> devono essere collegate dinamicamente per garantire la compatibilit\u00e0 con il kernel e i suoi moduli. <\/p>\n<p>In secondo luogo, ci sono delle sottigliezze con le licenze. <\/p>\n<p>La licenza GPL in linea di principio consente di collegare le librerie solo con codice open-source. MIT e BSD consentono il collegamento statico e permettono di includere le librerie nel progetto. Ma LGPL, apparentemente, non contraddice il collegamento statico, ma richiede di rendere disponibili i file necessari per il collegamento. <\/p>\n<p>In generale, l'uso del collegamento dinamico protegger\u00e0 dalla necessit\u00e0 di fornire qualcosa.<\/p>\n<h2>Compilazione delle applicazioni C\/C++<\/h2>\n<p>\nPer compilare le applicazioni C\/C++ per diverse piattaforme e distribuzioni, \u00e8 sufficiente scegliere o compilare una versione adatta di gcc e utilizzare i cross-compilatori per architetture specifiche, raccogliere l'intero set di librerie. Questo lavoro \u00e8 assolutamente realizzabile, ma piuttosto complicato. E non ci sono garanzie che il compilatore e le librerie scelti garantiranno una versione funzionante. <\/p>\n<p>Il vantaggio ovvio: l'infrastruttura si semplifica notevolmente, poich\u00e9 l'intero processo di compilazione pu\u00f2 essere eseguito su una sola macchina. Inoltre, \u00e8 sufficiente compilare un unico set di file binari per una architettura e si possono confezionare in pacchetti per diverse distribuzioni. \u00c8 proprio cos\u00ec che vengono creati i pacchetti veeam per Veeam Agent per Linux.<\/p>\n<p>In contrapposizione a questa opzione, si pu\u00f2 semplicemente preparare una farm di build, ossia diverse macchine per la compilazione. Ogni macchina sar\u00e0 responsabile della compilazione dell'applicazione e della creazione del pacchetto per una specifica distribuzione e architettura. In questo caso, la compilazione avviene con gli strumenti messi a disposizione dal distributore. Questo significa che il passo di preparazione del compilatore e la selezione delle librerie vengono a cadere. Inoltre, il processo di compilazione pu\u00f2 essere facilmente parallelizzato. <\/p>\n<p>Tuttavia, c'\u00e8 uno svantaggio in questo approccio: per ogni distribuzione all'interno della stessa architettura, sar\u00e0 necessario compilare un insieme specifico di file binari. Inoltre, un altro svantaggio \u00e8 che \u00e8 necessario gestire un certo numero di macchine, dedicando una grande quantit\u00e0 di spazio su disco e di memoria RAM. <\/p>\n<p>Cos\u00ec vengono creati i pacchetti KMOD del modulo del kernel veeamsnap per le distribuzioni Red Hat.<\/p>\n<h2>Open Build Service<\/h2>\n<p>\nI colleghi di SUSE hanno cercato di realizzare una sorta di compromesso con un servizio speciale per la compilazione delle applicazioni e la creazione dei pacchetti \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/openbuildservice.org\/\">openbuildservice<\/a><\/noindex>.<\/p>\n<p>In sostanza, \u00e8 un hypervisor che crea una macchina virtuale, installs in essa tutti i pacchetti necessari, esegue la compilazione dell'applicazione e la creazione del pacchetto in questo ambiente isolato, dopo di che la macchina virtuale viene liberata.<\/p>\n<p><img decoding=\"async\" alt=\"Linux \u00e8 variegato: come lavorare su qualsiasi distribuzione\" src=\"\/wp-content\/uploads\/2019\/10\/93d2a70c589a7186ecef85a7863e59e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl scheduler implementato in OpenBuildService determiner\u00e0 autonomamente quante macchine virtuali pu\u00f2 avviare per ottimizzare la velocit\u00e0 di compilazione dei pacchetti. Il meccanismo di firma integrato firmer\u00e0 automaticamente i pacchetti e li caricher\u00e0 nel repository integrato. Il sistema di controllo delle versioni incorporato salver\u00e0 la cronologia delle modifiche e delle compilazioni. Resta solo da aggiungere a questo sistema i propri sorgenti. Non \u00e8 nemmeno necessario sollevare un server, ma si pu\u00f2 utilizzare quello aperto.<\/p>\n<p>Qui, per\u00f2, c'\u00e8 un problema: questo combinato non si integra facilmente con l'infrastruttura esistente. Ad esempio, non abbiamo bisogno di un controllo delle versioni, abbiamo gi\u00e0 il nostro per i sorgenti. Il meccanismo di firma \u00e8 diverso da noi: viene utilizzato un server speciale. Anche il repository non \u00e8 necessario. <\/p>\n<p>Inoltre, il supporto per altre distribuzioni \u2014 ad esempio, Red Hat \u2014 \u00e8 piuttosto scarso, cosa comprensibile.<\/p>\n<p>Il punto di forza di questo servizio \u00e8 il supporto rapido per la nuova versione della distribuzione SUSE. Prima dell'annuncio ufficiale del rilascio, i pacchetti necessari per la compilazione vengono resi disponibili nel repository pubblico. Nella lista delle distribuzioni disponibili su OpenBuildService appare un nuovo elemento. Selezioniamo la casella e viene aggiunto al piano di compilazione. Cos\u00ec, l'aggiunta di una nuova versione della distribuzione si compie praticamente con un clic.<\/p>\n<p>Nella nostra infrastruttura, utilizzando OpenBuildService, viene assemblata tutta la variet\u00e0 dei pacchetti KMP del modulo del kernel veeamsnap per le distribuzioni SUSE.<\/p>\n<p>Ora vorrei soffermarmi sulle questioni specifiche dei moduli del kernel.<\/p>\n<h2>kernel ABI<\/h2>\n<p>\nStoricamente, i moduli del kernel Linux sono stati distribuiti come codice sorgente. Il fatto \u00e8 che i creatori del kernel non si caricano dell'onere di mantenere un'API stabile per i moduli del kernel, tanto meno a livello binario, noto come kABI.<\/p>\n<p>Per compilare un modulo per il kernel vanilla, sono necessari gli header di quel kernel specifico, e funzioner\u00e0 solo su quel kernel. <\/p>\n<p>DKMS consente di automatizzare il processo di compilazione dei moduli quando il kernel viene aggiornato. Di conseguenza, gli utenti del repository Debian (e dei suoi numerosi parenti) utilizzano i moduli del kernel o dal repository del distributore, o assemblati dai sorgenti tramite DKMS.<\/p>\n<p>Tuttavia, tale situazione non soddisfa particolarmente il segmento Enterprise. I distributori di codice proprietario vogliono distribuire il prodotto sotto forma di binari assemblati. <\/p>\n<p>Gli amministratori non vogliono mantenere strumenti di sviluppo sui server di produzione per motivi di sicurezza. I distributori di Enterprise Linux \u2014 come Red Hat e SUSE \u2014 hanno deciso di supportare un kABI stabile per i propri utenti. Di conseguenza, sono stati introdotti pacchetti KMOD per Red Hat e pacchetti KMP per SUSE.<\/p>\n<p>L'essenza di tale soluzione \u00e8 piuttosto semplice. Per una specifica versione della distribuzione, l'API del kernel viene congelata. Il distributore dichiara che utilizza un determinato kernel, ad esempio, 3.10, e apporta solo correzioni e miglioramenti che non influiscono in alcun modo sulle interfacce del kernel, e i moduli compilati per il primo kernel possono essere utilizzati per tutti i successivi senza ricompilazione.<\/p>\n<p>Red Hat dichiara la compatibilit\u00e0 kABI per la distribuzione per tutto il ciclo di vita. Ci\u00f2 significa che un modulo compilato per RHEL 6.0 (rilascio di novembre 2010) dovrebbe funzionare anche sulla versione 6.10 (rilascio di giugno 2018). E sono quasi 8 anni. Naturalmente, questo \u00e8 un compito piuttosto complesso. <br \/>\nAbbiamo registrato alcuni casi in cui, a causa di problemi di compatibilit\u00e0 kABI, il modulo veeamsnap smetteva di funzionare. <\/p>\n<p>Dopo che il modulo veeamsnap, compilato per RHEL 7.0, si \u00e8 rivelato incompatibile con il kernel di RHEL 7.5, ma si caricava e causava inevitabilmente il crash del server, abbiamo abbandonato l'uso della compatibilit\u00e0 kABI per RHEL 7 del tutto. <\/p>\n<p>Attualmente, il pacchetto KMOD per RHEL 7 contiene una build per ogni versione di rilascio e uno script che garantisce il caricamento del modulo.<\/p>\n<p>SUSE si \u00e8 avvicinata al compito della compatibilit\u00e0 kABI con maggiore cautela. Garantisce la compatibilit\u00e0 kABI solo all'interno di un singolo service pack. <\/p>\n<p>Ad esempio, il rilascio di SLES 12 \u00e8 avvenuto a settembre 2014. SLES 12 SP1 \u00e8 uscito gi\u00e0 a dicembre 2015, quindi \u00e8 passato poco pi\u00f9 di un anno. Nonostante entrambi i rilasci utilizzino il kernel 3.12, sono incompatibili con kABI. \u00c8 evidente che mantenere la compatibilit\u00e0 kABI per solo un anno \u00e8 notevolmente pi\u00f9 semplice. Un ciclo annuale di aggiornamento del modulo del kernel non dovrebbe causare problemi agli sviluppatori di moduli. <\/p>\n<p>Di conseguenza, a causa di questa politica di SUSE, non abbiamo registrato alcun problema di compatibilit\u00e0 kABI con il nostro modulo veeamsnap. Tuttavia, il numero di pacchetti per SUSE \u00e8 quasi un ordine di grandezza maggiore.<\/p>\n<h2>Patch e backport<\/h2>\n<p>\nNonostante i distributori cerchino di garantire la compatibilit\u00e0 kABI e la stabilit\u00e0 del kernel, cercano anche di migliorare le prestazioni e risolvere i difetti di questo kernel stabile. <\/p>\n<p>Inoltre, oltre al proprio \u00ablavoro sui bug\u00bb, gli sviluppatori del kernel enterprise linux monitorano le modifiche al kernel vanilla e le trasferiscono nel loro \u00abstabile\u00bb.<\/p>\n<p>A volte questo porta a nuovi <noindex><a rel=\"nofollow\" href=\"https:\/\/access.redhat.com\/solutions\/3658111\">errori<\/a><\/noindex>.<\/p>\n<p>Nell'ultimo rilascio di Red Hat 6, in uno dei minori aggiornamenti, \u00e8 stato commesso un errore. Questo portava il modulo veeamsnap a far crashare inevitabilmente il sistema quando si liberava uno snapshot. Confrontando i sorgenti del kernel prima e dopo l'aggiornamento, abbiamo scoperto che la causa era un backport. Un fix analogo \u00e8 stato effettuato nel kernel vanilla versione 4.19. Solo che nel kernel vanilla questo fix funzionava correttamente, mentre nel trasferirlo nel \u00abstabile\u00bb 2.6.32 \u00e8 emerso un problema di spin-locking.<\/p>\n<p>Certo, gli errori si verificano in tutti e sempre, ma ne valeva la pena trascinare il codice da 4.19 a 2.6.32, a rischio della stabilit\u00e0?.. Non ne sono sicuro\u2026<\/p>\n<p>La cosa peggiore \u00e8 quando il marketing si unisce al tira e molla tra \"stabilit\u00e0\"  \"modernizzazione\". Il dipartimento marketing ha bisogno che il core del nuovo distributivo sia stabile da un lato, ma allo stesso tempo migliori in termini di prestazioni e abbia nuove funzionalit\u00e0. Questo porta a compromessi strani. <\/p>\n<p>Quando ho provato a compilare un modulo sul kernel 4.4 di SLES 12 SP3, ho scoperto con sorpresa che conteneva funzionalit\u00e0 del vanilla 4.8. A mio avviso, l'implementazione dell'I\/O a blocchi del kernel 4.4 di SLES 12 SP3 assomiglia di pi\u00f9 al kernel 4.8 che alla precedente versione stabile del 4.4 di SLES12 SP2. Non mi sento di giudicare quale fosse la percentuale di codice trasferito dal kernel 4.8 al 4.4 di SLES per SP3, ma non riesco a definire il kernel come lo stesso stabile 4.4. <\/p>\n<p>La cosa pi\u00f9 sgradevole \u00e8 che, quando scrivi un modulo che deve funzionare bene su diversi kernel, non puoi pi\u00f9 fare affidamento sulla versione del kernel. Devi anche considerare la distribuzione. \u00c8 un bene che a volte puoi fare affidamento su un define, che appare insieme a nuove funzionalit\u00e0, ma questa possibilit\u00e0 non si presenta sempre. <\/p>\n<p>Di conseguenza, il codice si riempie di strane direttive di compilazione condizionale.<\/p>\n<p>Ci sono anche patch che cambiano l'API del kernel documentata. <br \/>\nHo trovato distribuzione <noindex><a rel=\"nofollow\" href=\"https:\/\/neon.kde.org\/\">KDE neon<\/a><\/noindex> 5.16 e sono rimasto molto sorpreso di vedere che la chiamata lookup_bdev in questa versione del kernel aveva cambiato l'elenco dei parametri di ingresso.<\/p>\n<p>Per compilarsi, ho dovuto aggiungere a makefile uno script che verifica se il parametro mask \u00e8 presente nella funzione lookup_bdev.<\/p>\n<h2>Firma dei moduli del kernel<\/h2>\n<p>\nMa torniamo alla questione della distribuzione dei pacchetti.<\/p>\n<p>Uno dei vantaggi dello stabile kABI \u00e8 che i moduli del kernel come file binari possono essere firmati. In questo caso, lo sviluppatore pu\u00f2 essere certo che il modulo non \u00e8 stato danneggiato accidentalmente o modificato intenzionalmente. \u00c8 possibile verificarlo con il comando modinfo. <\/p>\n<p>Le distribuzioni Red Hat e SUSE consentono di verificare la firma del modulo e caricarlo solo se il certificato corrispondente \u00e8 registrato nel sistema. Il certificato \u00e8 una chiave pubblica con cui viene firmato il modulo. Noi lo distribuiamo come un pacchetto separato.<\/p>\n<p>Il problema qui \u00e8 che i certificati possono essere incorporati nel firmware (utilizzati dai distributori) oppure devono essere scritti nella memoria non volatile EFI tramite un'utilit\u00e0 <i>mokutil<\/i>. L'utilit\u00e0 <i>mokutil<\/i> richiede di riavviare il sistema al momento dell'installazione del certificato e, anche prima del caricamento del kernel del sistema operativo, chiede all'amministratore di autorizzare il caricamento del nuovo certificato. <\/p>\n<p>Pertanto, aggiungere un certificato richiede l'accesso fisico dell'amministratore al sistema. Se la macchina si trova in qualche luogo nel cloud o semplicemente in un server remoto e l'accesso \u00e8 disponibile solo attraverso la rete (ad esempio, tramite ssh), non sar\u00e0 possibile aggiungere il certificato. <\/p>\n<h2>EFI su macchine virtuali<\/h2>\n<p>\nNonostante EFI sia supportato da tempo da quasi tutti i produttori di schede madri, durante l'installazione del sistema l'amministratore potrebbe non considerare la necessit\u00e0 di EFI, e potrebbe essere disattivato. <\/p>\n<p>Non tutti i hypervisor supportano EFI. VMWare vSphere supporta EFI a partire dalla versione 5. <br \/>\nMicrosoft Hyper-V ha anch'esso ottenuto supporto per EFI a partire da Hyper-V per Windows Server 2012R2. <\/p>\n<p>Tuttavia, nella configurazione predefinita questa funzionalit\u00e0 per le macchine Linux \u00e8 disabilitata, il che significa che non \u00e8 possibile installare il certificato. <\/p>\n<p>In vSphere 6.5, l'opzione <b>Secure Boot<\/b> pu\u00f2 essere impostata solo nella vecchia versione dell'interfaccia web, che funziona tramite Flash. L'interfaccia web basata su HTML-5 \u00e8 ancora molto indietro.<\/p>\n<h2>Distribuzioni sperimentali<\/h2>\n<p>\nInfine, esaminiamo la questione delle distribuzioni sperimentali e delle distribuzioni senza supporto ufficiale. Da un lato, \u00e8 improbabile che tali distribuzioni vengano trovate su server di organizzazioni serie. Non c'\u00e8 supporto ufficiale per tali distribuzioni. Pertanto, non \u00e8 possibile fornire supporto tecnico per il prodotto su una tale distribuzione. <\/p>\n<p>Tuttavia, tali distribuzioni diventano una piattaforma comoda per provare nuove soluzioni sperimentali. Ad esempio, Fedora, OpenSUSE Tumbleweed o le versioni instabili di Debian. Sono abbastanza stabili. Contengono sempre nuove versioni del software e un nuovo kernel. Dopo un anno, questa funzionalit\u00e0 sperimentale potrebbe apparire nella versione aggiornata di RHEL, SLES o Ubuntu. <\/p>\n<p>Quindi, se qualcosa non funziona su una distribuzione sperimentale, \u00e8 un motivo per analizzare il problema e risolverlo. Bisogna essere pronti al fatto che questa funzionalit\u00e0 apparir\u00e0 presto sui server di produzione degli utenti.<\/p>\n<p>L'attuale lista ufficiale dei sistemi operativi supportati per la versione 3.0 pu\u00f2 essere esaminata. <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/agentforlinux\/userguide\/system_requirements.html?ver=30\">qui<\/a><\/noindex>Ma l'elenco reale dei sistemi operativi su cui il nostro prodotto pu\u00f2 funzionare \u00e8 molto pi\u00f9 ampio.<\/p>\n<p>Personalmente, sono stato interessato all'esperimento con il sistema operativo \"Elbrus\". Dopo aver aggiornato il pacchetto veeam, il nostro prodotto \u00e8 stato installato e ha funzionato. Ho scritto di questo esperimento su Habr in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/447960\/\">abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer.<\/a><\/noindex>. <\/p>\n<p>La supporto per i nuovi sistemi operativi continua. Aspettiamo l'uscita della versione 4.0. A breve dovrebbe arrivare la beta, quindi seguite il <noindex><a rel=\"nofollow\" href=\"https:\/\/www.veeam.com\/whats-new-linux-agent.html\">whats-new<\/a><\/noindex>!<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/471226\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0449\u0435\u0435 \u043d\u0430 \u043b\u044e\u0431\u043e\u043c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0435 \u2014 \u0437\u0430\u0434\u0430\u0447\u043a\u0430 \u043d\u0435\u043f\u0440\u043e\u0441\u0442\u0430\u044f. \u0427\u0442\u043e\u0431\u044b \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0443 Veeam Agent for Linux \u043d\u0430 \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0430\u0445 \u043e\u0442 Red Hat 6 \u0438 Debian 6, \u0434\u043e OpenSUSE 15.1 \u0438 Ubuntu 19.04 \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0440\u0435\u0448\u0430\u0442\u044c \u0441\u043f\u0435\u043a\u0442\u0440 \u043f\u0440\u043e\u0431\u043b\u0435\u043c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u0435\u0441\u043b\u0438 \u0443\u0447\u0435\u0441\u0442\u044c, \u0447\u0442\u043e \u0432 \u0441\u043e\u0441\u0442\u0430\u0432 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 \u0432\u0445\u043e\u0434\u0438\u0442 \u043c\u043e\u0434\u0443\u043b\u044c \u044f\u0434\u0440\u0430. \u0421\u0442\u0430\u0442\u044c\u044f \u0441\u043e\u0437\u0434\u0430\u043d\u0430 \u043f\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430\u043c \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29206,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38929","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Linux \u043c\u043d\u043e\u0433\u043e\u043b\u0438\u043a\u0438\u0439: \u043a\u0430\u043a \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430 \u043b\u044e\u0431\u043e\u043c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Linux poliedrico: come lavorare su qualsiasi distribuzione | ProHoster","description":"Crea un'app per il backup.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Linux \u043c\u043d\u043e\u0433\u043e\u043b\u0438\u043a\u0438\u0439: \u043a\u0430\u043a \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430 \u043b\u044e\u0431\u043e\u043c \u0434\u0438\u0441\u0442\u0440\u0438\u0431\u0443\u0442\u0438\u0432\u0435 | ProHoster","og:description":"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/linux-mnogolikij-kak-rabotat-na-lyubom-distributive","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:26:48+00:00","article:modified_time":"2019-10-31T19:26:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38929","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:00:26","updated":"2026-01-23 23:59:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38929","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=38929"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38929\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/29206"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=38929"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=38929"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=38929"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}