{"id":1149,"date":"2013-06-06T23:01:55","date_gmt":"2013-06-06T21:01:55","guid":{"rendered":"http:\/\/blog.mageia.org\/it\/?p=1149"},"modified":"2013-07-22T23:26:28","modified_gmt":"2013-07-22T21:26:28","slug":"loro-fanno-mageia-il-team-degli-amministratori-di-sistema-installazione-e-configurazione-di-software-sui-server-mageia","status":"publish","type":"post","link":"https:\/\/blog.mageia.org\/it\/2013\/06\/06\/loro-fanno-mageia-il-team-degli-amministratori-di-sistema-installazione-e-configurazione-di-software-sui-server-mageia\/","title":{"rendered":"Loro fanno Mageia \u2013 il team degli amministratori di sistema: installazione e configurazione di software sui server mageia"},"content":{"rendered":"<p>(<em>traduzione realizzata da kyuzo<\/em>)<\/p>\n<p>Nel progetto Mageia il team degli amministratori di sistema (<em>n.d.t. detto sysadmin<\/em>) \u00e8 responsabile della configurazione e della manutenzione di tutta la struttura mageia cos\u00ec come degli utenti e dei contributori. Per aiutare le persone a comprendere di cosa si occupa questo team e per condividere qualche idea con altri amministratori di sistema, pubblicheremo una serie di post per spiegare cosa facciamo.<\/p>\n<p>I nostri principali compiti sono:<\/p>\n<ul>\n<li>Installazione dei server nei datacenter<\/li>\n<li>Installazione e configurazione di software vari sui server Mageia<\/li>\n<li>Compiti vari da amministratore, come aggiornamenti dei permessi per gli utenti, rimozione pacchetti, trasferimento pacchetti tra i vari repository, etc.<\/li>\n<li>Sviluppo e manutenzione di strumenti vari, come per esempio i componenti del sistema di compilazione dei pacchetti (n.d.t. <em>dall&#8217;inglese package build system<\/em>)<\/li>\n<\/ul>\n<p>Questo primo post tratter\u00e0 delle procedure usate per l\u2019installazione e la configurazione di software sui server Mageia, delle ragioni per cui facciamo questo, e dei motivi per cui potreste voler utilizzare procedure simili quando gestite i vostri propri server.<\/p>\n<p>Una sintesi del processo utilizzato per configurare il software su server Mageia potrebbe essere:<\/p>\n<ul>\n<li>Tutto il software \u00e8 installato usando pacchetti<\/li>\n<li>Tutti i pacchetti sono costruiti utilizzando il build system (<em>n.d.t. sistema di compilazione<\/em>)<\/li>\n<li>Tutti i pacchetti sono installati e configurati con puppet<\/li>\n<\/ul>\n<p>La ragione di ci\u00f2 pu\u00f2 gi\u00e0 essere chiara per la maggior parte dei packager Mageia. Questo post vuole spiegarne i motivi a chi invece non lo \u00e8.<\/p>\n<h2>Compilazione ed installazione del software<\/h2>\n<p>Uno dei compiti pi\u00f9 comuni dell\u2019amministratore di sistema \u00e8 l\u2019installazione o l\u2019aggiornamento del software. Quando \u00e8 la tua distro Linux a fornire i pacchetti per il software che ti occorre, \u00e8 semplice; il pacchetto pu\u00f2 essere installato utilizzando il gestore dei pacchetti.<\/p>\n<p>Tuttavia, in molti casi il software in questione non sar\u00e0 disponibile nella distro che stai usando, oppure non lo sar\u00e0 nella versione di cui hai bisogno.<\/p>\n<h3>Compilare il pacchetto manualmente<\/h3>\n<p>Molti pensano che la soluzione pi\u00f9 semplice sia quella di scaricare il codice sorgente del software, seguire le istruzione per la compilazione e utilizzare gli script di installazione o il Makefile presenti. A seguire questa strada per\u00f2, possono sorgere parecchi problemi:<\/p>\n<ul>\n<li><strong>Installare le dipendenze necessarie per la compilazione<\/strong> :<br \/>\nAvrete bisogno di tutte le dipendenze necessarie per la compilazione installate nel vostro sistema. Nella maggior parte dei casi vorrete compilare il software in un server dedicato a questo compito, e poi copiarne i binari ottenuti sulle vostre macchine.<\/li>\n<li><strong>Gestire le dipendenze<\/strong> :<br \/>\nSe state utilizzando archivi tarball o un server NFS per distribuire i binari del vostro software alle macchine che ne faranno uso, dovrete trovare ed installare tutte le dipendenze necessarie perch\u00e8 il software funzioni su ogni macchina. Inoltre vorrete creare una lista delle dipendenze da salvare da qualche parte, cos\u00ec da ricordarvi cosa deve essere installato quando deciderete di utilizzare quel software su una nuova macchina.<\/li>\n<li><strong>Aggiornare il software<\/strong> :<br \/>\nQuando compilate un software, spesso avrete bisogno di impostare opzioni specifiche in uno script configure o in un file di configurazione. Alcuni software possono essere difficili da compilare e possono richiedere complesse operazioni o configurazioni per poterli compilare. Quando aggiornate un software ad una nuova versione, probabilmente vorrete mantenere la stessa configurazione di compilazione, per evitare di introdurre cambiamenti non necessari col solo rischio di bloccare il sistema. Tutto ci\u00f2 non \u00e8 facile da ricordare, e a meno che non sia un esercizio quotidiano, probabilmente prima o poi lo dimenticherete. Cos\u00ec vorrete conservare le configurazioni personali in un file, cos\u00ec da essere in grado di usarle successivamente, quando avrete bisogno di nuovo di aggiornare il software.<\/li>\n<li><strong>Patchare il software<\/strong> :<br \/>\nCerte volte il software necessiter\u00e0 solo di piccole modifiche per poterlo compilare, o per poterlo eseguire o, ancora, vorrete aggiungere ulteriori funzionalit\u00e0. Potrete applicare tali modifiche prima di iniziare il processo di compilazione. Ma questi cambiamenti andranno perduti una volta che utilizzerete i sorgenti da un tarball che aggiorna il software.Per essere in grado di applicare le stesse modifiche alle nuove versioni del software, dovrete salvare questi cambiamenti in qualche sorta di patch.<\/li>\n<li><strong>Conservare un changelog (archivio delle modifiche)<\/strong> :<br \/>\nE\u2019 facile dimenticare perch\u00e8 avete voluto fare determinati cambiamenti, o perch\u00e9 abbiate voluto aggiornare un particolare modulo del software. Specialmente se non lavorate da soli ma fate parte di un team, sar\u00e0 necessario conservare un archivio delle modifiche effettuate sul software che avete compilato ed installato.<\/li>\n<li><strong>Sapere che versione del software avete installato, disinstallare o aggiornare il software<\/strong> :<br \/>\nSapere che versione del software \u00e8 attualmente installata \u00e8 molto utile. E&#8217; altrettanto utile essere in grado di disinstallare quel software, o installarne una versione differente per testarlo, o per ricercarne eventuali bug, o ritornare ad una versione precedente se si riscontra qualche problema. Se usate le procedure di installazione standard, gran parte del software installer\u00e0 files in un mucchio di posti diversi del sistema. Sapere quali file sono installati dove, e qual \u00e8 la versione attualmente in uso, \u00e8 difficile se non impossibile. Quando installate una nuova versione del software, gli script di installazione faranno si che i vecchi file vengano sovrascritti, senza per\u00f2 che i file obsoleti vengano rimossi, creando cos\u00ec confusione o problemi. Alcuni cercano di evitare questi problemi installando ciascun software in una cartella differente, includendo il numero della versione nel nome della directory stessa. Questo per\u00f2 pu\u00f2 creare problemi ulteriori: gran parte del software non \u00e8 concepito per essere installato in questo modo e sar\u00e0 quindi necessario utilizzare qualche trucco affinch\u00e9 funzionino. Inoltre pu\u00f2 essere che la particolare versione che intendete usare abbisogni di una complessa rivisitazione dei link simbolici o delle variabili d\u2019ambiente. E questo pu\u00f2 diventare ancora pi\u00f9 complicato quando installiamo dei software che hanno reciproche dipendenze. La miglior soluzione per evitare questo genere di problemi e di utilizzare strumenti specifici che tengano traccia di QUALI file sino installati DOVE, e in QUALE versione.<\/li>\n<\/ul>\n<h3>Usare i pacchetti<\/h3>\n<p>Per risolvere i problemi di cui sopra, potreste voler utilizzare strumenti specifici. Anzi, potreste voler iniziare a scrivere il vostro script personale od il vostro programma personale per gestire questo tipo di cose. In realt\u00e0 \u00e8 molto meglio utilizzare quanto \u00e8 gi\u00e0 esistente e disponibile. Gli strumenti migliori per risolvere questi problemi sono i Package Managers (Gestori di Pacchetti).<\/p>\n<p>Se non avete mai creato dei pacchetti prima, \u00e8 necessario spendere un po &#8216;di tempo per imparare a farlo. Tuttavia la fatica far\u00e0 risparmiare un sacco di tempo dopo. L&#8217;utilizzo di pacchetti per costruire e installare il software ha un mucchio di vantaggi:<\/p>\n<ul>\n<li><strong>Installazione dipendenze di compilazione<\/strong>:<br \/>\nI pacchetti vi permetteranno di compilare il vostro software su una macchina specifica, producendo pacchetti che saranno poi installati sulla macchina prescelta senza obbligarvi ad installarci sopra nessuna delle dipendenze necessarie alla compilazione. Il sorgente dei pacchetti vi permettr\u00e0 inoltre di specificare la lista delle dipendenze di compilazione, cos\u00ec che possano essere installate automaticamente sulla vostra macchina per la compilazione per poi essere successivamente rimosse.<\/li>\n<li><strong>Gestire le dipendenze automaticamente<\/strong>:<br \/>\nTener traccia delle dipendenze richiede molto tempo e non \u00e8 sempre facile. Fortunatamente la maggior parte dei sistemi di compilazione analizzer\u00e0 i file inclusi nel pacchetto per determinarne le dipendenze. Le librerie perl, python, ruby, PHP, C\/C++ vengono normalmente individuate in automatico durante la compilazione. Le dipendenze che non possono essere rilevate in automatico \u00e8 possono invece essere esplicitate nel pacchetto. Tutte queste dipendenze potranno quindi essere installate automaticamente dal gestore dei pacchetti durante l\u2019installazione del software.<\/li>\n<li><strong>Aggiornare il software<\/strong> :<br \/>\nI pacchetti sorgente contengono le istruzioni di compilazione. Il processo di compilazione pu\u00f2 cambiare un po\u2019 a volte, ma nella maggior parte dei casi sar\u00e0 lo stesso per tutte le versioni del software. In questo caso aggiornare un pacchetto ad una versione pi\u00f9 nuova sar\u00e0 semplice come aggiornare il numero di versione del pacchetto sorgente e far partire il processo di compilazione dello stesso. Ricompilare il vostro software con qualche opzione differente pu\u00f2 essere comunque fatto piuttosto facilmente.<\/li>\n<li><strong>Patchare il software<\/strong> :<br \/>\nI pacchetti sorgente vi permettono di includere correzioni che saranno applicate durante la compilazione del software. Quando si aggiorna il software ad una versione pi\u00f9 recente, possono essere applicati i medesimi cambiamenti.<\/li>\n<li><strong>Conservare un changelog<\/strong> <strong>(archivio delle modifiche) <\/strong>:<br \/>\nI pacchetti contengono un file di changelog che potete utilizzare per spiegare le ragioni delle modifiche apportate, cos\u00ec che voi stessi o i membri del vostro team possiate sapere il perch\u00e8 delle modifiche effettuate, per esempio, 6 mesi f\u00e0. Se utilizzate uno strumento di controllo del sorgente come git o subversion per gestire i vostri pacchetti sorgente (il che \u00e8 raccomandato) potete usare i commit log come changelog.<\/li>\n<li><strong>Sapere che versione del software avete installato, disinstallare o aggiornare il software<\/strong> :<br \/>\nI pacchetti vi permettono di tracciare la versione del software installata sul vostro sistema. Cos\u00ec come vi permettono una facile installazione, disinstallazione o aggiornamento del software, o di scoprire che pacchetto fornisce un determinato file.<\/li>\n<\/ul>\n<h2>Creazione di pacchetti in un ambiente pulito e la distribuzione dei pacchetti<\/h2>\n<h3>Perch\u00e9 \u00e8 necessario utilizzare un sistema di compilazione<\/h3>\n<p>Il gestore di pacchetti \u00e8 uno strumento molto efficiente per gestire la compilazione e l&#8217;installazione di software. Tuttavia questo non \u00e8 sufficiente. Il gestore di pacchetti compiler\u00e0 il software utilizzando gli strumenti e le librerie disponibili sul sistema attuale, dopo aver installato le dipendenze di compilazione previste.<\/p>\n<p>Possono sorgere per\u00f2, alcuni problemi :<\/p>\n<ul>\n<li><strong>Supporto per pi\u00f9 distribuzioni<\/strong> :<br \/>\nA volte l&#8217;infrastruttura utilizzer\u00e0 distro diverse, o diverse versioni di una stessa distro. Un pacchetto costruito su una distro non funzioner\u00e0 necessariamente su un altra, perch\u00e9 la versione di alcuni componenti pu\u00f2 essere diversa o incompatibile. Per evitare questo tipo di problemi, i pacchetti dovrebbero essere compilati utilizzando la stessa distribuzione per cui verranno utilizzati.<\/li>\n<li><strong>Ambiente di compilazione \u201cpulito\u201d<\/strong> :<br \/>\nI pacchetti sorgente includono un elenco di dipendenze per la compilazione che devono essere installate per creare il pacchetto. Tuttavia quando si costruisce il pacchetto sulla propria macchina o su un server di compilazione specifico, di solito ci sono altri pacchetti che sono gi\u00e0 installati e che potenzialmente possono essere utilizzati durante la compilazione di un pacchetto E &#8216;quindi molto facile dimenticare che si \u00e8 installato qualche pacchetto, dimenticare di includere nel pacchetto dipendenze di compilazione e non accorgersi del problema, perch\u00e9 per voi la compilazione funziona. Il sistema potrebbe anche avere una configurazione personalizzata o aggiornamenti che avete dimenticato di aver installato, che possono potenzialmente influenzare il processo di compilazione. Il problema non sar\u00e0 notato fino a quando qualcuno non avr\u00e0 bisogno di ricompilare il pacchetto su un altro sistema. Se volete aumentare le probabilit\u00e0 di essere in grado di riprodurre il processo di ricompilazione di un pacchetto in futuro, \u00e8 necessario utilizzare un ambiente \u201cpulito\u201d per la creazione di pacchetti. Di solito questo viene fatto con la creazione, per ogni compilazione, di un ambiente chroot minimale per la distribuzione selezionata.<\/li>\n<\/ul>\n<p>Una volta che il pacchetto \u00e8 stato compilato, sar\u00e0 necessario copiarlo sulle macchine dove intendete installarlo. Le distro di solito forniscono gli strumenti per gestire questa operazione (apt-get su Debian, urpmi su Mageia, yum su Fedora, ecc). Questi strumenti scaricheranno e installeranno un pacchetto e le sue dipendenze da un server che mette a disposizione un repository di pacchetti. Per poter utilizzare questi strumenti, \u00e8 necessario impostare un repository di pacchetti, che \u00e8 una directory contenente tutti i pacchetti disponibili e alcuni metadati.<\/p>\n<p>Tutto questo pu\u00f2 essere gestito manualmente, ma \u00e8 molto meglio creare un sistema per la compilazione dei pacchetti che gestir\u00e0 tutto questo per voi automaticamente. Utilizzare un sistema per la compilazione dei pacchetti ha molti vantaggi :<\/p>\n<ul>\n<li><strong>E\u2019 meno soggetto ad errori<\/strong> :<br \/>\nCompilare pacchetti in un ambiente chroot, copiare i file risultanti nel repository corretto e rigenerare i metadata dei repository non \u00e8 molto difficoltoso, ma porta via parecchio tempo e se fatto manualmente pu\u00f2 causare errori. Usare un sistema per la generazione automatica dei pacchetti vi far\u00e0 risparmiare tempo ed errori.<\/li>\n<li><strong>E\u2019 pi\u00f9 facile<\/strong> :<br \/>\nSe \u00e8 vero che compilare ed installare pacchetti nel repository \u00e8 un compito gravoso e soggetto ad errori, voi o gli altri membri del vostro team cercherete di evitarlo o quanto meno di farlo adottando altre soluzioni.<\/li>\n<li><strong>Strumenti di controllo di revisione e tracciabilit\u00e0<\/strong> :<br \/>\nUsare git o subversion come strumenti di controllo della revisione per gestire i cambiamenti nei pacchetti sorgente \u00e8 caldamente raccomandato. Un SCM collegato al sistema di compilazione far\u00e0 s\u00ec che qualsiasi pacchetto disponibile nel repository sar\u00e0 disponibile anche nel repository di controllo del codice sorgente, permettendo la tracciabilit\u00e0 dei vostri pacchetti.<\/li>\n<li><strong>Fare rispettare le politiche di compilazione<\/strong> :<br \/>\nAlcuni strumenti sono a disposizione per far rispettare alcune politiche di compilazione (rpmlint per rpm, lintian per deb). Avere politiche di compilazione \u00e8 utile per avere pacchetti coerenti. Il packaging build system pu\u00f2 essere configurato per eseguire automaticamente alcuni test di verifica e per rifiutare il caricamento di pacchetti non conformi con la stessa.<\/li>\n<li><strong>Monitoraggio<\/strong> :<br \/>\nIl sistema di compilazione consente il monitoraggio delle compilazioni pi\u00f9 recenti. Una interfaccia web offre una rassegna delle pi\u00f9 recenti compilazioni, i log di compilazione. Una mailing list pu\u00f2 essere utilizzata per ricevere le notifiche di compilazione. Quando si lavora con un team questo consente a tutti i membri del team di seguire le ultime modifiche.<\/li>\n<li><strong>Automazione<\/strong> :<br \/>\nAlcuni pacchetti specifici possono richiedere ulteriori elaborazioni da svolgere quando vengono aggiornati. L&#8217;invio di una e-mail, l&#8217;estrazione di alcuni file per aggiornare un sito web o altri compiti possono essere inseriti in uno script in modo che siano eseguiti automaticamente quando il pacchetto viene aggiornato. Questo \u00e8 ci\u00f2 che viene utilizzato per estrarre i file di installazione Mageia nel mirror tree quando il pacchetto viene aggiornato.<\/li>\n<\/ul>\n<h3>Come installare un sistema di compilazione Mageia<\/h3>\n<p>Sar\u00e0 argomento di un altro post.<\/p>\n<h2>Configurare il vostro software<\/h2>\n<p>L\u2019installazione del software di solito \u00e8 solo la prima parte del lavoro che viene fatto dagli amministratori di sistema. La seconda parte \u00e8 la configurazione del software. Il pacchetto far\u00e0 la prima parte della configurazione iniziale, sebbene sar\u00e0 necessaria di solito una configurazione ulteriore.<\/p>\n<p>Ci sono vari metodi per farlo :<\/p>\n<ul>\n<li>Editare manualmente la configurazione direttamente sul server<\/li>\n<li>Non fare niente di tutto ci\u00f2, ma far si che siano strumenti di gestione di configurazione come Cfengine, Puppet or Ansible a farlo per voi.<\/li>\n<\/ul>\n<p>Quando si utilizza uno strumento di gestione della configurazione, non si aggiorna direttamente la configurazione sui server, ma si scrivono alcune regole nel repository di gestione della configurazione che verranno applicate automaticamente dal vostro strumento di gestione della configurazione. Non sar\u00e0 veloce come la modifica diretta della configurazione sul server, ma ci sono parecchi vantaggi:<\/p>\n<ul>\n<li><strong>Gestire l\u2019infrastruttura come un progetto software<\/strong> :<br \/>\nGli strumenti di configurazione consentono di gestire l&#8217;infrastruttura come qualsiasi altro normalissimo progetto per lo sviluppo di software. Possono essere utilizzati molti degli strumenti disponibili per gli sviluppatori di software: il controllo di revisione sorgente, l\u2019invio di patch, la revisione di codice, test automatici, ecc.<\/li>\n<li><strong>Lavoro di gruppo<\/strong> :<br \/>\nSe si lavora in un team, \u00e8 possibile memorizzare le regole di configurazione del server in un repository condiviso di controllo di revisione sorgente, rendendo possibile seguire e rivedere tutte le modifiche ai server fatti da tutti i membri del team.<\/li>\n<li><strong>Documentazione<\/strong> :<br \/>\nAvere un po&#8217; di documentazione su che software \u00e8 installato sui server e come \u00e8 configurato \u00e8 molto utile, soprattutto quando ci pu\u00f2 essere pi\u00f9 di una persona a lavorare su di esso. Tuttavia un problema molto comune con la documentazione \u00e8 che qualcuno la scrive inizialmente, ma nessuno la mantiene e diventa rapidamente obsoleta. E &#8216;molto facile fare un cambiamento e dimenticare di documentarlo, o dimenticare che una documentazione esiste da qualche parte e deve essere aggiornata. Ma avere una documentazione accurata \u00e8 importante e talvolta avendo documentazione superata che fornisce informazioni obsolete pu\u00f2 essere peggio di non avere alcuna documentazione. Il repository di gestione della configurazione pu\u00f2 essere utilizzato come una sorta di documentazione sulla vostra infrastruttura e, in quanto rappresenta ci\u00f2 che \u00e8 effettivamente utilizzato per configurare l&#8217;infrastruttura, \u00e8 molto pi\u00f9 probabile che sia accurata rispetto a qualsiasi altra documentazione. Nello sviluppo di software, avere codice ben commentato o codice che pu\u00f2 essere compreso senza documentazione \u00e8 in generale una soluzione migliore che avere la documentazione mantenuta separatamente e lo stesso si pu\u00f2 dire per l&#8217;amministrazione del sistema.<\/li>\n<li><strong>Ambiente per il collaudo \u00e8 riproducibilit\u00e0 <\/strong>:<br \/>\nUtilizzare uno strumento di configurazione consente di riprodurre facilmente la configurazione di un server su un altro server. Questo \u00e8 utile quando \u00e8 necessario sostituire o aggiungere un server o se avete bisogno di creare un ambiente di test.<\/li>\n<li><strong>Mantenere una configurazione corretta <\/strong>:<br \/>\nLo strumento di gestione della configurazione verr\u00e0 eseguito a intervalli regolari per verificare che la configurazione sia sempre corretta e per applicare eventuali modifiche che si rendano necessarie.<\/li>\n<li><strong>Riusabilit\u00e0<\/strong> :<br \/>\nCome nello sviluppo di software, l&#8217;utilizzo di uno strumento di gestione della configurazione consente di riutilizzare i componenti creati. Di solito \u00e8 possibile creare moduli con parametri per modificare il comportamento del modulo. A volte \u00e8 possibile trovare i moduli direttamente su internet, ma purtroppo la maggior parte di essi richiedono sostanziali modifiche per essere adattati per il nostro specifico uso. Le versioni precedenti di Puppet mancavano di importanti caratteristiche come la classe parametrizzata, per cui la creazione di componenti riutilizzabili era difficile, ma si sono fatti passi avanti.<\/li>\n<\/ul>\n<h3>Quale strumento di gestione della configurazione utilizzare?<\/h3>\n<p>Quando abbiamo iniziato l&#8217;installazione di server Mageia, all&#8217;inizio del progetto Mageia, abbiamo deciso di utilizzare <a href=\"http:\/\/puppetlabs.com\/\">puppet<\/a> dopo aver esaminato i vari strumenti disponibili. Puppet sembrava il pi\u00f9 interessante strumento di gestione della configurazione al momento. Negli ultimi anni, le cose si sono evolute molto in questo settore, ed esistono alternative a Puppet che potreste prendere in considerazione prima di decidere quale usare:<\/p>\n<ul>\n<li><a href=\"http:\/\/ansible.cc\/\">ansible<\/a><\/li>\n<li><a href=\"http:\/\/saltstack.com\/community\">salt stack<\/a><\/li>\n<\/ul>\n<h3>I moduli Puppet di Mageia<\/h3>\n<p>I moduli Puppet che usiamo per configurare i server Mageia sono disponibili su un <a href=\"http:\/\/svnweb.mageia.org\/adm\/puppet\/\">repository svn<\/a>.<\/p>\n<h2>Cosa dobbiamo migliorare<\/h2>\n<p>Il processo in corso \u00e8 buono, ma ci sono ancora alcune cose che potrebbero essere migliorate. Se volete contribuire, ma non sapete come fare, ecco alcune idee.<\/p>\n<ul>\n<li><strong>Generazione automatica dei pacchetti<\/strong> :<br \/>\nAlcuni linguaggi come Perl, Python o Ruby utilizzano il proprio sistema di confezionamento per le librerie. Molti preferiscono usare questi pacchetti piuttosto che pacchetti RPM perch\u00e9 i pacchetti della distro non sono sempre disponibili o aggiornati. Il vantaggio di questi pacchetti \u00e8 che sono fatti a monte, per cui sono immediatamente disponibili. Il problema \u00e8 che non sono solitamente molto ben integrati con il resto del sistema, richiedendo cos\u00ec l\u2019utilizzo di due diversi sistemi di pacchettizzazione, il che rende le cose pi\u00f9 complicate. In molti casi, queste persone non sono pacchettizzatori esperti, cos\u00ec che preferiscono utilizzare i pacchetti disponibili, pacchettizzati secondo le specifiche del linguaggio, perch\u00e9 pensano che compilare sia troppo complesso o perch\u00e8 non hanno il tempo per farlo. Se una conversione da quei pacchetti in RPM fosse pi\u00f9 semplice, la gente potrebbe beneficiare di una buona disponibilit\u00e0 di pacchetti ben integrati con il resto del sistema. Fortunatamente i pacchetti costruiti con le specifiche di quei linguaggi di solito contengono tutte le informazioni necessarie per il confezionamento RPM (descrizioni, licenza, dipendenze, etc), in modo che creare un pacchetto RPM di solito \u00e8 una semplice conversione di tali informazioni in formato RPM, potendo cos\u00ec automatizzare il processo. Grazie al lavoro di <a href=\"http:\/\/jquelin.blogspot.fr\/\">J\u00e9r\u00f4me Quelin<\/a> su <a href=\"https:\/\/github.com\/jquelin\/cpanplus-dist-mageia\">cpan2dist<\/a> \u00e8 ora possibile generare pacchetti RPM Mageia da moduli CPAN automaticamente. Questo \u00e8 ci\u00f2 che ci permette di avere <a href=\"http:\/\/perl.mageia.org\/stats\/\">3300 pacchetti Perl<\/a> disponibili nella distribuzione.Abbiamo bisogno di strumenti simili pure per i pacchetti di Python, Ruby e altri linguaggi.<\/li>\n<li><strong>Impostazione del sistema di compilazione<\/strong>:<br \/>\nStiamo usando un sistema di compilazione per creare i nostri pacchetti, perch\u00e9 abbiamo gi\u00e0 un sistema di generazione a disposizione per costruire la distribuzione Mageia, per cui non c\u2019\u00e8 da lavorarci molto di pi\u00f9 per configurarlo per avere anche il nostro repository di pacchetti. Tuttavia l&#8217;installazione di un sistema di compilazione Mageia non \u00e8 propriamente un compito facile e le persone che non intendono compilare una distribuzione completa non spenderanno troppo tempo per configurare un sistema di compilazione. Perci\u00f2, abbiamo bisogno di migliorare il processo di configurazione per renderlo pi\u00f9 semplice. Ci\u00f2 che attualmente manca \u00e8 la documentazione per spiegare come fare, utilizzando il nostro modulo puppet. Un futuro post su questo blog vi spiegher\u00e0 come fare.<\/li>\n<li><strong>Supporto <\/strong><strong>OBS<\/strong> :<br \/>\nUn alternativa \u00e8 utilizzare <a href=\"http:\/\/openbuildservice.org\/\">OBS<\/a> (Open Build Service),che \u00e8 un buon sistema di compilazione, con il supporto per pi\u00f9 distribuzioni. Tuttavia manca ancora il supporto per Mageia. Dobbiamo rimediare in modo che diventi possibile gestire i repository Mageia usando OBS.<\/li>\n<li><strong>S<\/strong><strong>upport<\/strong><strong>o Mageia <\/strong><strong> in Ansible <\/strong><strong>e<\/strong><strong> Salt Stack<\/strong> :<br \/>\nAnsible e Salt Stack sono entrambi interessanti strumenti di gestione della configurazione. Tuttavia, mancano ancora del supporto ad urpmi per l&#8217;installazione dei pacchetti. Aggiornamento: <a href=\"https:\/\/github.com\/pmakowski\">Philippe Makowski<\/a> ha elaborato un <a href=\"https:\/\/github.com\/pmakowski\/ansible\/blob\/devel\/library\/packaging\/urpm\">modulo urpmi per Ansible<\/a>, ma questo non \u00e8 ancora integrato a monte, per cui eventuali contributi sono i benvenuti.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>(traduzione realizzata da kyuzo) Nel progetto Mageia il team degli amministratori di sistema (n.d.t. detto sysadmin) \u00e8 responsabile della configurazione e della manutenzione di tutta la struttura mageia cos\u00ec come degli utenti e dei contributori. Per aiutare le persone a &hellip; <a href=\"https:\/\/blog.mageia.org\/it\/2013\/06\/06\/loro-fanno-mageia-il-team-degli-amministratori-di-sistema-installazione-e-configurazione-di-software-sui-server-mageia\/\">Continua a leggere<span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[82,77],"tags":[],"class_list":["post-1149","post","type-post","status-publish","format-standard","hentry","category-packaging","category-sysadm"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p15lp4-ix","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/posts\/1149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/comments?post=1149"}],"version-history":[{"count":16,"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/posts\/1149\/revisions"}],"predecessor-version":[{"id":1165,"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/posts\/1149\/revisions\/1165"}],"wp:attachment":[{"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/media?parent=1149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/categories?post=1149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mageia.org\/it\/wp-json\/wp\/v2\/tags?post=1149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}