Product SiteDocumentation Site

2. Cambiamenti in Fedora per Amministratori di Sistema

2.1. Installazione

2.1.1. Supporto al Provisioning fine LVM in Anaconda

L' installer di Fedora ora supporta la creazione fine di volumi LVM nelle installazioni a interfaccia grafica e nel kickstart automatizzato. Questo cambiamento include una nuova variante di partizionamento automatica come anche nuove opzioni per creare volumi precisi in schemi di partizioni personalizzati

2.1.2. docdirs senza versione

La documentazione di pacchetto è ora installata in una cartella non versionata /usr/share/doc/packagename. In precedenza il nome della cartella conteneva la versione del pacchetto oltre al nome del pacchetto.

2.2. Sicurezza

2.2.1. FreeIPA guadadna il supporto al trust transitivo

FreeIPA 3.3.2 aggiunge il supporto per foreste complesse di Active Domain contenente domini multipli. Utenti di un multipli domini AD possono accedere alle risorse FreeIPA. Gli amministratori FreeIPA possono selettivamente bloccare gli accessi per ogni dominio AD.

2.2.2. SSSD aggiunge il mapping ID per le condivisioni CIFS

Il System Security Services Daemon di Fedora 20 ha aggiunto il supporto per il mapping tra Windows SID e ID POSIX. Amministratori che usano SSSD nelle loro reti possono stabilire controlli di accesso usando due nuove utility, setcifsacl e getcifsacl.
Maggiori informazioni possono essere trovare nel documento di design a monte https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient e le pagine man per setcifsacl, getcifsacl, e altri pacchetti relativi a SSSD

2.2.3. Strumenti per Certificati di Sistema Condivisi

La funzionalità di Fedora dei Certificati di Sistema Condivisi è stata ampliata in questo rilascio con l'applicazione p11-kit-trust. Questo pacchetto permette modifiche a anchor trust, chiavi in blacklist e certificati. Con un singolo comando, gli amministratori possono fare cambiamenti ai loro database di certificati di sistema al posto di aggiungere un file in una directory speciale ed eseguire un comando speciale. Questo nuovo strumento prosegue lo sviluppo della funzionalità dei Certificati di Sistema Condivisi.

2.3. File System

2.3.1. Cache SSD per device a blocchi

Fedora 20 offre supporto sperimentale per aggiungere dischi a stato solido (SSD) come cache veloci e trasparenti ai tradizionali storage a rotazione (HDD). Filesystem con cache su dispositivi a blocco SSD offrono sia la velocità degli SSD che il volume di un HDD. Sia gli schemi di partizionamento tradizionali che LVM posso ottenere benefici da questa funzionalità.

Fare backup!

Eseguire sempre un backup dei propri dati prima di fare cambiamenti a basso livello, come migrazioni a dispositivi bcache. Fino a quando strumenti come blocks non sono pacchettizzati per Fedora, gli utenti sono avvisati di implementare bcache creando dispositivi bcache puliti e popolando il filesystem da un backup recente.

2.4. Virtualizzazione

2.4.1. Emulazione ARM su Host x86

Alcuni cambiamenti sono stati fatti per pemettere una più regolare emulazione di macchine virtuali guest ARM su host x86 usando strumenti libvirt standard, incluso virsh, virt-manager e virt-install.qemu ha un emulatore ARM che lavora bene ed è attivamente usato nello sviluppo di Fedora ARM. Tuttavia libvirt e virt-manager hanno un problema nel lanciare macchine virtuali qemu-system-arm, per lo più a causa di assunzioni nell'encoding x86 nella linea di comando generata che causa qemu-system-arm errore alla partenza. Cambiamenti sono stati fatti per risolvere questo problema. Maggiori informazioni possono essere trovate in https://fedoraproject.org/wiki/Changes/Virt_ARM_on_x86

2.4.2. Libvirt Controllo di Accesso Client

Il client libvirt permette le regole di permesso che possono essere applicate a tutte gli oggetti gestiti e alle operazioni API, così da permettere a tutte le connessioni client di essere limitate a un minimo set di regole e privilegi. Ci sono tre livelli di accesso che possono essere assegnati.
Accessi Unauthenticated sono inizialmente usati per tutte le connessioni. Questo stato permette tutte le operazioni API che sono richieste per completare l'autenticazione. Eseguendo una autenticazione con successo, due o pù livelli possono essere assegnati: Senza restrizioni, che da pieno accesso alle tutte le operazioni API, e Con restrizioni, che permette l'accesso in sola lettura.
Amministratori di sistema possono impostare regole di permesso per connessioni autenticate. Ogni chiamata API in libvirt ha un set di permessi che sono validati contro gli oggetti che sono usati. Per esempio, l'utente A vuole cambiare un parametro nell'oggetto dominio. Quando l'utente prova a salvare, il metodo virDomainSetSchedulerParametersFlags eseguirà un controllo che il client ha il permesso di scrittura sull'oggetto dominio. Il filtraggio può essere fatto per vedere quale client ha i permessi su quale oggetto per permettere una più semplice gestione dei permessi. La documentazione per il controllo di accesso polkit può essere trovato a http://libvirt.org/aclpolkit.html.
Il file di configurazione libvirtd.conf è responsabile delle impostazioni di permesso di accesso. Usa il parametro access_drivers per permettere questa operazione. Osserva che se più di un driver di accesso è richiesto, tutti devono avere successo per garantire il permesso di accesso.
Maggiori informazioni possono essere trovate su https://fedoraproject.org/wiki/Changes/Virt_ACLs e http://libvirt.org/acl.html

2.4.3. Snapshot Virt-manager

Virtual Machine Manager, o virt-manager, permette una gestione facile e il monitoraggio degli snapshot delle macchine virtuali o dei guest KVM. Osservare che virt-manager metterà in pausa la macchina virtuale guest per pochi secondi mentre esegue uno snapshot. Maggiori informazioni sono disponibili qui:
http://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots
http://fedoraproject.org/wiki/Features/Virt_Live_Snapshots
http://libvirt.org/formatsnapshot.html
Sezione Snapshot di man 1 virsh
http://fedoraproject.org/wiki/QA:Testcase_Virt_Snapshot_UI

2.4.4. Network definita dal software Ryu

Fedora 20 introduce Ryu, software che permette l'effettivo networking per la virtualizzazione OpenStack. Come blocco costruttivo di un controller OpenFlow, Ryu fornisce reti di Livello 2 isolate per Openstack.

2.5. Database Server

2.5.1. MongoDB

MongoDB è stato aggiornato alla version 2.4 aggiungendo la ricerca full text, il supporto per un più grande array di indici geospaziali e dei miglioramenti di sicurezza. Per maggiori informazioni su questa nuova versione leggere le note di rilascio http://docs.mongodb.org/manual/release-notes/2.4/.

2.5.2. Hadoop

Fedora 20 offre il meglio della fiorente piattaforma Hadoop e molti altri pacchetti. Per una revisione dettagliata di Hadoop in Fedora, guarda https://fedoraproject.org/wiki/Changes/Hadoop
La pacchettizzazione della piattaforma Hadoop è l'ultimo lavoro del Fedora Big Data SIG. Puoi trovare il Special Interest Group su https://fedoraproject.org/wiki/SIGs/bigdata, il punto di riferimento per i tuoi sforzi partecipativi

2.6. Server di Posta

2.6.1. sendmail non di default

Fedora 20 non include più un mail transfer di default. Le precedenti release di Fedora includono sendmail, ma ha una utilità limitata senza una configurazione manuale

2.7. Samba

2.7.1. SSSD aggiunge il mapping ID per le condivisioni CIFS

Informazioni su questa caratteristica possono essere trovate nella sezione Security.

2.8. Demoni di sistema

2.8.1. Syslog rimosso dalla installazione di default

syslog non è più incluso in installazioni di default. Il servizio di logging journald serve nella maggior parte dei casi alla stessa maniera, o meglio di, syslogd.
Gli utenti abituati a controllare /var/log/messages per i log di sistema dovrebbero invece usare journalctl.
journalctl esempi di comando
new journalctlvecchi messaggi
journalctlless /var/log/messages
journalctl -ftail -f /var/log/messages
journalctl --unit named.servicegrep named /var/log/messages
journalctl -bMostrare i log di boot corrente, non ha un semplice equivalente.

2.8.2. systemd

2.8.2.1. Nuovi tipi di unità: Scope
Systemd ha ora due nuovi tipi di unità, scope e slice.
Le unità scope sono automaticamente create da systemd da processi esistenti. Raggruppando un processo e suoi figli insieme, una unità scope può essere usata per organizzare processi, applicare unità risorse, o uccidere un gruppo di processi. Le sessioni utente sono un esempio di processi contenuti in una unità scope.
Le unità slice sono usate per raggruppare unità che gestiscono processi in una gerarchia che permette il controllo di risorse allocate allo slice. Gli slice di default sono machine.slice, per le macchine virtuali e i container; system.slice, per i dispositivi di sistema; e user.slice, per le sessioni utente. Questi slice di default sono popolati automaticamente.
Unità Instanza, come getty@.service, sono generati su richiesta usando il template definito nel loro file di configurazione. Ogni tipo di template è dato ad un subslice del system slice, e le istanze sono contenute in quel slice.
Unità scope e service assegnate ad uno slice sono discendenti del nodo slice nell'albero di gruppo di controllo. Un nome slice descrive la sua posizione relativa rispetto allo slice di radice. L'output sotto dimostra come user-1000.slice è un figlio di user.slice, che a sua volta è figlio di ., la radice slice. Ogni sessione è ulteriormente confinata in una unità scope all'interno dello slice dell'utente.
	    systemctl status user.slice

  Loaded: loaded (/usr/lib/systemd/system/user.slice; static)
  Active: active since Sun 2013-09-08 01:23:40 MDT; 18h ago
    Docs: man:systemd.special(7)
  CGroup: /user.slice
          ├─user-1000.slice
          │ ├─session-21.scope
          │ │ ├─9226 sshd: pete [priv]
          │ │ ├─9229 sshd: pete@pts/4
          │ │ ├─9230 -bash
          │ │ ├─9262 sudo su -
          │ │ ├─9270 su -
          │ │ ├─9271 -bash
          │ │ └─9509 screen -R
          │ ├─session-18.scope
          │ │ ├─ 7939 sshd: pete [priv]
          │ │ ├─ 7942 sshd: pete@pts/0
          │ │ ├─ 7943 -bash
          │ │ ├─ 7982 sudo su -
          │ │ ├─ 7988 su -
          │ │ ├─ 7989 -bash
          │ │ ├─ 8206 SCREEN
          │ │ ├─ 8207 /bin/bash
          │ │ ├─ 8237 /bin/bash
          │ │ ├─ 8486 less NEWS
          │ │ ├─ 8489 /bin/bash
          │ │ └─10637 systemctl status user.slice
          ## truncated ##

I servizi posso essere addizionati ad uno slice con la direttiva Slice=slicename nel loro file di configurazione dell'unità. Argomenti che permettono limitazioni delle risorse all'interno di uno slice o unità di servizio sono descritte in man systemd.directives. Vedere anche man systemd.slice e man systemd.cgroup.
2.8.2.2. systemd-cryptsetup per TrueCrypt
Il support per TrueCrypt in Fedora è ampliato dal support di systemd-cryptsetup per la tecnologia, permettendo una facile autenticazione durante il boot.
2.8.2.3. Filtraggio di stato unità con systemctl
systemctl ora supporta il filtraggio delle unità nella lista di output per stato del caricamento. L' opzione --state accetta ogni valore o lista separata da virgola dei valori di stato LOAD, SUB, o ACTIVE. Per esempio,
	   systemctl --state failed 

2.8.3. journald

2.8.3.1. Vedere i log di uno specifico boot
journalctl può ora essere usato per vedere i log di uno specifico boot. Per esempio, per vedere i log del boot corrente:
	  journalctl -b
O, vedere i log per boot precedente:
	  journalctl -b -1
In aggiunta alla sequenza di boot relativa, journald assegna un ID di boot su 128-bit a cui ci si può riferire. Per esempio:
	  journalctl -b 38fd9c3303574ed38e822233457f6b77
2.8.3.2. Riferirsi al journal con i cursori
journalctl può riferirsi al journal attraverso un identificatore record conosciuto come cursor. Similmente ad un hash git, il cursor identifica in maniera univoca un punto nel journal.
Se si aggiunge --show-cursor ad una richiesta journalctl, l'ultima linea di output conterrà il valore del cursore:
	  journalctl -b -u network --show-cursor --since 15:00
	  Sep 08 15:37:59 localhost.localdomain network[4074]: [FAILED]
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: network.service: control process exited, code=exited status=1
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking.
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: Unit network.service entered failed state.
	  -- cursor: s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831
Il cursore può essere usato per identificare il punto nel journal in un più ampia query per fornire il contesto:
	  journalctl -c "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"
Gli script che parsificano l'output journalctl possono immagazzinare il valore del cursore e usarlo nella loro prossima esecuzione per riprendere da dove avevano lasciato:
	  journalctl --after-cursor "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"