Product SiteDocumentation Site

3. Cambiamenti in Fedora per Amministratori di Sistema

3.1. Kernel

Fedora 16 utilizza il nuovo kernel 3.1.0. A dispetto dell'elevato numero di modifiche, non ci sono cambiamenti evidenti nelle funzionalità. Anche Linus dice che non dovresti aver timore di lui:
 Ho deciso, ho chiamato la prossima versione 3.0. Sarà rilasciata molto vicino ai 20 anni di Linux, che è una buona scusa per me, sebbene onestamente, la vera ragione è che non mi trovo a mio agio con numeri così alti come 40.

3.2. Boot

Fedora 16 raccoglie i vantaggi di diverse nuove tecnologie per migliorare la velocità, la sicurezza e l'efficienza del processo di boot.

3.2.1. Trusted Boot

Trusted Boot (tboot) è un modulo opensource pre- kernel/Virtual Machine Manager che usa la tecnologia Intel(R) TXT (Trusted Execution Technology di Intel(R)), per eseguire un lancio misurato e verificato di un sistema operativo kernel/VMM. Prima di avviare il boot, esso verifica che i file di sistema non siano compromessi, offrendo maggiore protezione contro rootkits e altri tipi di malware che tentano di nascondere le loro traccie editando questi file. Trusted Boot può essere abilitato durante l'installazione e prevede un fall-back con normale boot, se non supportato dall'hardware.

3.2.2. GPT Disk Labels

Nuove Disk Label

Installazioni con partizioni manuali potrebbero richiedere step addizionali
A partire da Fedora 16, nei sistemi x86 (32 e 64 bit) non EFI, per impostazione predefinita, anaconda crea disklabel (tabelle di partizioni), GPT invece di disklabel MSDOS. In questi sistemi, negli avvii da dischi etichettati GPT, si raccomanda rigorosamente (non necessariamente richiesto in tutti i casi, dipendendo dal BIOS/firmware di sistema) di creare una piccola partition di BIOS boot (1MB). Questa partizione sarà usata dal bootloader (Grub2), come supporto di storage.
Il partizionamento automatico creerà la partizione, se necessario, mentre gli utenti che scelgono il partizionamento personalizzato dovranno crearla manualmente.
La partizione di BIOS boot è necessaria solo nei sistemi x86 non-EFI il cui dispositivo di boot è un disco etichettato GPT.

3.2.3. GRUB 2

GNU Grand Unified Bootloader (GRUB) presenta un grosso aggiornamento in Fedora 16. GRUB 2 permette migliori opzioni di configurazione, miglior supporto per architetture non x86, supporto allo scripting e alla localizzazione. GRUB 2 ha nuovi formati e file di configurazione - si prega di consultare il manuale di Grub per maggior informazioni.

Richiesto l'utente di Grub

Anaconda permette il settaggio di una password di Grub durante l'installazione. Con il Grub originale, era richiesta solo la password. Con Grub2, all'utente viene richiesto anche uno username. Può essere usato l'utente root.

3.2.4. Migrazione di SysVinit verso systemd

Fedora 15 ha visto l'introduzione di systemd, un nuovo manager di sistema e di servizi per Linux. L'integrazione di systemd continua in Verne con molti più SysV init script trasformati in file di servizio nativi di systemd. Il risultato è un processo di boot più veloce e più efficiente, con una gestione dei servizi più semplice.

3.2.5. rc.local non più pacchettizato

Lo script /etc/rc.d/rc.local di personalizzazione locale non è più incluso, per impostazione predefinita. Gli amministratori che necessitano di questa funzionalità devono soltanto crearlo, renderlo eseguibile ed esso di avvierà al boot.
Gli upgrade non sono influenzati da questo cambiamento.

3.3. Cambio del range UID

Nuovi UID e GID range

I valori di UID e GID per gli account utenti ora partono da 1000 invece che da 500 come nelle precedenti versioni.
Fedora 16 cambia la policy di allocazione di UID e GID: gli account utenti ora partono da 1000 al posto del precedente valore di 500. Questa policy è ora impostata globalmente in /etc/login.defs nelle variabili GID_MIN e UID_MIN, fare riferimento a login.defs(5) per maggiori dettagli. Gli aggiornamenti dalle precedenti versioni di Fedora mantengono la loro configurazione, facendo partire gli account utente da 500.
Se si ha bisogno di installare un nuovo sistema da zero, mentre gli account utente partono da 500 (connettere il sistema alla rete con un UID definito globalmente), installa usando uno script kickstart che include /etc/login.defs nel filesystem prima che l'installazione dei pacchetti inizi.

3.4. Virtualizzazione

3.4.1. Emulazione USB

  • E' stato aggiunto il supporto per i dispositivi USB 2.0 (EHCI).

3.4.2. CDROM Emulation

  • Molte correzioni per la compatibilità con le specifiche ATAPI
  • GET_EVENT_STATUS_NOTIFICATION: Implementa il sottocomando 'media' che aiuta a determinare gli stati di apertura/chiusura del tray e presenza/assenza di supporti nei guest. I più recenti guest di Linux (kernel 2.6.38+), fanno affidamento su questo comando per rivalidare i dischi.
  • Estensivi refactoring e pulizie del codice

3.4.3. Sicurezza

Il pacchetto qemu-kvm è stato ricompilato con il completo supporto per RELRO e PIE, che possono aiutare a mitigare certi tipi di attacchi. L'exploiting di sistemi host o di altre VM avviate nello stesso host è molto più difficile grazie a queste opzioni.

3.4.4. Note di rilascio dei progetti upstream

3.4.5. Xen

  • Supporto a Xen incorporato in qemu

3.4.6. x86

  • TSC (TimeStamp Counter) dei guest resi stabili tra le migrazioni
  • Supporto per le feature delle CPU VIA

3.4.7. Generale

  • Numerosi memory leak corretti in tutti i dispositivi virtio

3.4.8. qemu-img

  • Le performance di conversione di qemu-img sono state migliorate
  • qemu-img convert e rebase ora supportano l'opzione -p che abilita la visualizzazione dello stato di avanzamento.

3.4.9. qcow2

  • Migliorate le performance di creazione/cancellazione di snapshot interni

3.4.10. Guest Agent

  • Aggiunto il guest agent che supporta lo snapshotting.

3.5. Web Servers

httpd è stato aggiornato dalla 2.2.17 alla 2.2.19. Questa versione corregge alcuni bug di sicurezza e al software. Questa versione corregge una incompatibilità di versionamento nella 2.2.18; gli utenti sono quindi avvisati che la version 2.2.19 ora ripristina la compatibilità con moduli compilati contro la precedente versione 2.2 (oltre che la 2.2.18 che è considerata abbandonata).
  • Ripristinare la rottura della ABI nella 2.2.18 causata dal cambio di signature di ap_unescape_url_keep2f(). Questo rilascio ripristina la signature della 2.2.17 e precedenti, ed introduce ap_unescape_url_keep2f_ex().

3.6. Cloud

3.6.1. Aeolus Conductor

Aeolus Conductor è una interfaccia web e uno strumento per creare e gestire istanze cloud attraverso una moltitudine di cloud diversi, tutti dalla stessa interfaccia grafica. Ulteriori informazioni sulla UI e cosa è attualmente supportato sono disponibili all'indirizzo della home page Aeolus.

3.6.2. Condor Cloud

Condor Cloud è una implementazione cloud di tipo Infrastructure as a Service (IaaS). Permette di creare molte VM da una immagine oppure da immagini come date volute, distribuendole su di un pool di host configurati. La UI è chiamata Deltacloud API (http://deltacloud.org). Il backend è implementato attraverso Condor (http://www.cs.wisc.edu/condor/) che permette la partenza di VM usando libvirt e KVM.

3.6.3. HekaFS

HekaFS 0.7 aumenta le caratteristiche di GlusterFS aggiungendo multi-tenancy, sicurezza, e funzionalità di gestione.
L'uso di HekaFS richiede conoscenze di come si impostano chiavi OpenSSL e certificati al fine di facilitare l'autenticazione nella gestione e nei livelli di I/O.
La rete e la cifratura dello storage sono entrambi opzionali, e introducono se usate forti penalità nelle performance.
Il supporto alle caratteristiche di Quota e pagamento sono sotto attivo sviluppo di GlusterFS, e non saranno disponibili al rilascio di HekaFS.
Miglioramenti alla distribuzione/replicazione dei file locali e replicazione di grandi aree sono state pianificate come eventuali nuove caratteristiche di HekaFS, non in questo rilascio.

3.6.4. Matahari

Fedora 16 Matahari, è una collezione di API accessibili attraverso interfacce locali e remote per il monitoraggio e la gestione sistemistica. Le API Matahari sono servite attraverso una collezione di Agent. Matahari include anche un framework per l'aggiunta di nuovi Agent e API.
Gli agent disponibili sono:
  • Host - Un agent per vedere e controllare gli host
  • Networking - Un agent per vedere e controllare i dispositivi di rete
  • Services - Un agent per conrollare i servizi di sistema

3.6.5. pacemaker-cloud

Pacemaker-Cloud fornisce alta affidabilità per servizi applicativi dentro le macchine virtuali su un singolo nodo. Questa funzionalità fornisce una shell per creare immagini di macchine virtuali, associare risorse con alle macchine virtuali, e combinarle in un sistema di deploy. Un deploy può essere lanciato e monitorato per l'alta affidabilità. Se la macchina virtuale o l'applicazione fallisce, questi componenti vengono rilanciati riducendo l' MTTR (mean time to repair) aumentando la disponibilità al posto di un restart manuale eseguito da un operatore.
Le macchine virtuali guest Fedora che usano systemd non sono al momento funzionanti finchè il seguente bug non verrà inserito nella versione rawhide: Informazioni sulla discussione a questo indirizzo systemd defect 702621.

3.7. Database Server

3.7.1. systemd

MySQL e PostgreSQL sono stati aggiornati per usare nativamente le unità di systemd per la partenza, al posto degli script di init in stile SysV. Questo dovrebbe eliminare vari e sfortunati problemi che sono occorsi nella Fedora 15 a causa della scarsa gestione degli script SysV in systemd. Inoltre la gestione del caso in cui il server database è lento a partire è significativamente migliorata anche rispetto agli script SysV, dato che systemd può proprio attendere affinchè il server è realmente pronto senza rallentare il carimento al boot.

3.7.2. PostgreSQL

Le azioni service postgresql initdb e service postgresql upgrade che erano supportate degli script di init Sysv non sono fornite anche dal file di unità di systemd. Viene introdotto quindi un nuovo script standalone, postgresql-setup che fornisce queste funzioni. Per esempio, per inizializzare un nuovo database postgresql, eseguire queste azioni
sudo postgresql-setup initdb
Se si necessità di eseguire più di una istanza del server postgresql sulla stessa macchina, è possibile duplicare e modificare il file postgresql.service, come di consuetudine con i servizi systemd. (Ricordarsi che i servizi custom devono andare nella directory /etc/systemd/system/ e non in /lib/systemd/system/). Si noti che le impostazioni PGDATA e PGPORT per server alternativi devono ora essere specificate nel file di servizio personalizzato.
Copiare /lib/systemd/postgresl.service in /etc/systemd/myservice.service, sistemare PGDATA e PGPORT nel nuovo file. Per farlo, eseguire
sudo postgresql-setup initdb myservice
postgresql-setup estarrà le impostazioni di PGDATA da quel servizio al posto di postgresql.service.
I file in /etc/sysconfig/pgsql/ non sono più usati

3.8. Demoni di sistema

3.8.1. Chrony

Fedora 16 usa Chrony come client NTP (Network Time Protocol) predefinito. Chrony è progettato per lavorare bene anche con sistemi che non sono permanentemente connessi alla rete (come i portatili), ed è capace di sincronizzarsi più velocemente di ntp standard. Chrony ha numerosi vantaggi quando usato in sistemi che girano in macchine virtuali, come ad esempio un più ampio range di correzioni di frequenza che aiutano a correggere veloci deviazioni del clock, e una migliore risposta ai cambiamenti rapidi nella frequenza di clock. Inoltre occupa poca memoria e non richiede wakeup di processo non necessari, aumentando l'efficienza energetica.

3.8.2. Rimozione di HAL

Fedora 16 non include il demone HAL e libhal, che sono stati rimpiazzati con udisks, upower e libudev. Se una specifica applicazione richiede libhal per funzionare, si prega di creare una segnalazione affinchè venga portata alla nuova tecnologia.