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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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.

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

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.

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.