Red Hat Enterprise Linux AS 4 Release Note

La versione di glibc presente con Red Hat Enterprise Linux 4, esegue dei controlli interni in modo da prevenire e rilevare in anticipo qualsiasi corruzione dei dati. Per default, se si rileva una corruzione dei dati, verrà visualizzato un messaggio simile al seguente (oppure registrato tramite syslog se stderr non è aperto):

*** glibc detected *** double free or corruption: 0x0937d008 ***

Per default, il programma che genera questo errore verrà eliminato 'killed'; tuttavia tale procedura (e la generazione del messaggio di errore) può essere controllata tramite la variabile dell'ambiente MALLOC_CHECK_. Le seguenti impostazioni sono supportate:

Se siete in possesso di un programma di terzi, ISV in grado di attivare questi controlli ed in grado di visualizzare un messaggio d'errore, è consigliato eseguire un rapporto sul problema in questione con il rivenditore dell'applicazione, in quanto tale problema indica la presenza di un bug pericoloso.

Anche se Red Hat Enterprise Linux 4 include un supporto per rawio, tale interfaccia risulta ora sconsigliata. Se la vostra applicazione esegue un accesso al dispositivo utilizzando questa interfaccia, Red Hat vi consiglia di modificare la stessa applicazione in modo da poter aprire il dispositivo a blocchi utilizzando O_DIRECT. L'interfaccia rawio sarà ancora esistente con Red Hat Enterprise Linux 4, ma verrà considerata una sua rimozione nelle future release.

Asynchronous I/O (AIO) sui file system è solo supportato in O_DIRECT, o in modalità non-buffered. Da notare anche che l'interfaccia di controllo asincrona non è più presente, e gli AIO presenti sui pipe non sono più supportati.

Il sottosistema sound è ora basato su ALSA; i moduli OSS non sono più disponibili.

Gli ambienti del sistema che utilizzano la funzionalità "hugepage" del kernel, devono essere a conoscenza che il nome della voce /proc/ che controlla questa caratteristica, è stato modificato tra Red Hat Enterprise Linux 3 e Red Hat Enterprise Linux 4:

La release iniziale di Red Hat Enterprise Linux 4 non supporta le unità del disco fisso USB. Tuttavia gli altri dispositivi di storage USB, come ad esempio il flash media, il CD-ROM e i dispositivi DVD-ROM, sono attualmente supportati.

Il kernel presente con Red Hat Enterprise Linux 4 include il nuovo driver megaraid_mbox di LSI Logic, il quale sostituisce il driver megaraid. Il driver megaraid_mbox presenta un design migliore, risulta essere compatibile con il kernel 2.6, ed include il supporto per gli ultimissimi hardware. Tuttavia, megaraid_mbox non supporta alcuni degli hardware più vecchi, supportati invece da megaraid.

Gli adattatori che presentano un PCI vendor ID ed una coppia ID del dispositivo, non sono supportati dal driver megaraid_mbox:

vendor, device

0x101E, 0x9010
0x101E, 0x9060
0x8086, 0x1960

Il comando lspci -n può essere utilizzato per visualizzare gli ID degli adattatori installati in una particolare macchina. I prodotti che presentano questi ID vengono riconosciuti (e non solo) dai seguenti modelli:

Sia Dell che LSI con l'avvento del kernel 2.6, non supportano più questi modelli. Come risultato questi adattatori non sono supportati in Red Hat Enterprise Linux 4.

La release iniziale di Red Hat Enterprise Linux 4 non include iSCSI software initiator o il target support. Il supporto per iSCSI verrà probabilmente aggiunto negli aggiornamenti futuri di Red Hat Enterprise Linux 4.

Il driver Emulex LightPulse Fibre Channel (lpfc) è attualmente sotto revisione per una sua possibile inclusione nel kernel 2.6 di Linux. Il suddetto driver è stato incluso in Red Hat Enterprise Linux 4 solo per scopi di prova. Sono previste alcune modifiche al driver in questione. Se si verificassero dei problemi, o se per qualsiasi ragione non risulta essere più utile una sua inclusione nel kernel 2.6 di Linux, il suddetto driver verrà rimosso dalla release finale di Red Hat Enterprise Linux.

Il driver lpfc presenta le seguenti problematiche:

In passato il processo di aggiornamento del kernel non ha modificato il kernel di default nella configurazione del boot loader del sistema.

Red Hat Enterprise Linux 4 modifica questo comportamento in modo da impostare i kernel appena installati come default. Tale procedura viene applicata su tutti i metodi di installazione (incluso rpm -i).

Il suddetto comportamento viene controllato attraverso due righe nel file /etc/sysconfig/kernel:

Per poter eliminare la ridondanza presente quando si fornisce un pacchetto separato per il codice sorgente del kernel, quando lo stesso codice sorgente è già esistente nel file .src.rpm del kernel stesso, Red Hat Enterprise Linux 4 non include più il pacchetto kernel-source. Gli utenti che necessitano di un accesso alle sorgenti del kernel, sono in grado di ottenere tali sorgenti attraverso il file kernel .src.rpm. Per creare un albero della sorgente da questo file, seguire le seguenti fasi (da notare che <version> si riferisce alla specificazione della versione del kernel attualmente in esecuzione):

Procedere normalmente.

obj-m    := foo.o

KDIR    := /lib/modules/$(shell uname -r)/build
PWD    := $(shell pwd)

default:
    $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

              

Red Hat Enterprise Linux 4 include una versione aggiornata del client email grafico di Evolution. Questa versione aggiunge un certo numero di nuovi contenuti, incluso:

Il pacchetto gimp-perl è stato rimosso da Red Hat Enterprise Linux 4 poichè GIMP è stato aggiornato alla versione 2.0, ed i binding di Perl non erano pronti nè facevano parte del pacchetto principale.

Gli utenti degli script di Perl in GIMP dovrebbero installare il modulo Gimp Perl direttamente da http://www.gimp.org/downloads/.

ja_JP.eucJP diventa ja_JP.UTF-8

ko_KR.eucKR diventa ko_KR.UTF-8

zh_CN.GB18030 diventa zh_CN.UTF-8

zh_TW.Big5 diventa zh_TW.UTF-8

Lingue indiane — iiimf-le-unit

Giapponese — iiimf-le-canna

Coreano — iiimf-le-hangul

Cinese Semplificato — iiimf-le-chinput

Cinese Tradizionale — iiimf-le-xcin

ami causa il montaggio di iiimf-le-hangul

kinput2 causa il montaggio di iiimf-le-canna

miniChinput causa il montaggio di iiimf-le-chinput

xcin causa il montaggio di iiimf-le-xcin

Per default, il mail transport agent (MTA), di Sendmail non accetta le connessioni di rete da host diversi dal computer locale. Se desiderate configurare Sendmail come server per altri clienti, bisogna modificare /etc/mail/sendmail.mc e cambiare la riga DAEMON_OPTIONS per consentire il collegamento dei dispositivi di rete (o commentare questa opzione usando il delimitatore dnl). In seguito è necessario rigenerare /etc/mail/sendmail.cf eseguendo il seguente commando (come root):

make -C /etc/mail

Perchè questo funzioni, è necessario installare il pacchetto sendmail-cf.

Con la configurazione di sicurezza di default di SELinux, httpd viene coperto dalla targeted policy. Ciò aumenta la sicurezza e la stabilità del Web sesrver, garantendo o rifiutando in modo specifico un accesso httpd agli oggetti del sistema. Tuttavia tale operazione potrebbe intaccare in modo negativo, tutte le configurazioni che in precedenza erano in funzione (come ad esempio le configurazioni che utilizzano PHP), per questo motivo è importante capire il funzionamento di SELinux per poter assicurare che la vostra configurazione sia sicura ed efficiente.

Per esempio, un Boolean può essere impostato per conferire un permesso specifico a httpd, in modo tale da poter leggere gli oggetti in ~/public_html/, fino a quando essi sono etichettati con un contesto di sicurezza httpd_sys_content_t. Il demone Apache non è in grado di accedere gli oggetti (file, applicazioni, dispositivi, e altri processi) che non presentano un contesto di sicurezza, attraverso il quale viene garantito in modo specifico, da parte di SELinux, un accesso a httpd.

Garantendo un accesso ad Apache solo per gli oggetti che garantiscono la funzione di Apache stesso, il sistema risulta protetto contro demoni httpd che risultano essere compromessi o configurati in modo non corretto.

Poichè è necessaria una directory standard di Linux e di permessi dei file insieme con le etichette di contesto del file di SELinux, è necessario che gli amministratori e gli utenti siano a conoscenza su come rietichettare un file. Alcuni esempi su questa procedura riguardano i seguenti comandi (uno su come rietichettare in modo ricorsivo i contenuti di una directory, e un altro su come rietichettare un file singolo):

chcon -R -h -t httpd_sys_content_t public_html
chcon -t httpd_sys_content_t public_html/index.html

            

Un file o una directory che non risulta essere etichettato con un contesto presente nell'elenco di tipi di Apache abilitati, genererà un errore 403 Forbidden.

Potete configurare i valori Boolean oppure disabilitare in modo selettivo, la copertura della policy targeted solo per l'Apache (o qualsiasi dei demoni) che utilizza system-config-securitylevel. Con il pannello SELinux, all'interno dell'area Modifica la policy di SELinux, potete modificare i valori di Boolean per Apache. Se desiderate, potete selezionare Disabilita la protezione SELinux per il demone httpd, la quale disabilita la transizione da unconfined_t (il tipo di default che si comporta in modo trasparente come lo standard Linux security senza SELinux) per il demone specifico, es. httpd_t. Disabilitando questa transizione si disabilita effettivamente la copertura SELinux per il demone in questione, ritornando lo stesso allo standard Linux security.

Per maggiori informazioni su Apache e sulla policy di SELinux, consultate Red Hat SELinux Policy Guide su http://www.redhat.com/docs.

Per default, il demone httpd viene avviato utilizzando il locale C, invece di utilizzare l'impostazione locale del sistema configurato. Questo comportamento può essere modificato impostando la variabile HTTPD_LANG nel file /etc/sysconfig/httpd.

Il file di configurazione /etc/php.ini di default è stato modificato in modo da utilizzare i default di "produzione" invece dei default di "sviluppo"; le differenze più importanti sono:

Il pacchetto utilizza ora SAPI "apache2handler" per una integrazione con Apache httpd 2.0, invece di SAPI "apache2filter". Se si esegue un aggiornamento da release precedenti, le direttive SetOutputFilter dovrebbero essere rimosse dal file /etc/httpd/conf.d/php.conf.

Le seguenti modifiche sono state eseguite sul pacchetto dei moduli di estensione PHP:

Red Hat Enterprise Linux 4 include il nuovo pacchetto xorg-x11-deprecated-libs. Questo pacchetto contiene le librerie relative a X11 non più supportate, e quindi le stesse potrebbero essere rimosse dalle future versioni di Red Hat Enterprise Linux. Strutturando le librerie non supportate in questo modo, viene mantenuta la compatibilità binaria con le applicazioni esistenti, conferendo il tempo necessario ai provider software di terzi, alla rimozione delle proprie applicazioni da queste librerie.

Attualmente questo pacchetto contiene la libreria di stampa X (libXp). Questa libreria non dovrebbe essere usata per lo sviluppo di nuove applicazioni. Le applicazioni che attualmente utilizzano questa libreria dovrebbero essere migrate sulle API di stampa libgnomeprint/libgnomeprintui supportate.

Con le recenti versioni di Red Hat Enterprise Linux nei sistemi X Window, si è fatta un pò di confusione per quanto riguarda le problematiche relative ai font. (e precedentemente con versioni di Red Hat Linux.) Al momento sono presenti due sottosistemi font, ognuno dei quali con diverse caratteristiche:

- Il sottosistema originale (che ha oltre 15 anni) è definito il "sottosistema principale di font X". I font di questo sottosistema non sono anti-alias, sono gestiti dal server X , e hanno nomi come:

-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1

Il sottosistema di font più recente è noto come "fontconfig", e permette alle applicazioni di accedere direttamente ai file dei font. Fontconfig è usato spesso con la libreria "Xft", che consente alle applicazioni di visualizzare i font di fontconfig sullo schermo con antialiasing. Fontconfig usa nomi più facili da ricordare per gli utenti come:

Luxi Sans-10

Col tempo, fontconfig/Xft sostituirà il sottosistema di font X. Attualmente, le applicazioni che usano i toolkit Qt 3 o GTK 2 (che includono le applicazioni di GNOME e di KDE) usano il sottosistema dei font di fontconfig e di Xft. Il resto usa per lo più i font di X.

In futuro, Red Hat Enterprise Linux potrebbe supportare solo fontconfig/Xft invece del server dei font XFS, come metodo predefinito di accesso ai font locali.

NOTA BENE: Una eccezione sull'uso del sottosistema dei font, è OpenOffice. org, (il quale usa la propria tecnologia rendering).

La procedura per aggiungere nuovi font al vostro sistema Red Hat Enterprise Linux 4 varia a seconda del sottosistema che deve utilizzare i nuovi font. Per il nucleo del sottosistema di font X, dovete:

1. Create la directory /usr/share/fonts/local/ (se non è esistente):

mkdir /usr/share/fonts/local/

2. Copiare il nuovo file dei caratteri in /usr/share/fonts/local/

3. Aggiornate le informazioni sui font emettendo i seguenti comandi (notare che a causa delle restrizioni nella formattazione, i seguenti comandi potrebbero apparire su più righe, ogni comando dovrebbe essere inserito su di una riga):

ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale

mkfontdir /usr/share/fonts/local/

4. Se avete creato /usr/share/fonts/local/, dovete aggiungerlo al percorso di X font server (xfs):

chkfontpath --add /usr/share/fonts/local/

Aggiungere nuovi font al sottosistema fontconfig è più semplice; è sufficiente copiare il nuovo file di font nella directory /usr/share/fonts/ (i singoli utenti possono modificare la propria configurazione di font copiando il file nella directory ~/.fonts/).

Dopo aver copiato il nuovo font, utilizzate fc-cache per aggiornare le infomazioni sui font memorizzate nella cache:

fc-cache <directory>

(Dove <directory> potrebbero essere le directory /usr/share/fonts/ o ~/.fonts/.)

I singoli utenti possono anche installare i font in modalità grafica, aprendo fonts:/// in Nautilus, e trascinandovi i nuovi file di font.

NOTA: Se il nome del file di font termina con ".gz", vuol dire che è stato compresso con gzip, e deve essere decompresso (usando il comando gunzip) se si vuole che il sottosistema fontconfig utilizzi il font.

Con la transizione al nuovo sistema basato su fontconfig/Xft, il funzionamento delle applicazioni GTK+ 1.2 non viene compromesso dalle modifiche effettuate tramite la finestra di dialogo Font Preferences. Per queste applicazioni, è possibile configurare i font aggiungendo le seguenti righe al file ~/.gtkrc. mine:

style "user-font" {

fontset = "<specificazione-font>"

}

widget_class "*" style "user-font"

(Dove <specificazione-font> rappresenta la specifica di un font nello stile usato dalle tradizionali applicazioni X, come "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*".)

Il set completo di comandi LVM2 è stato installato in /usr/sbin/. Negli ambienti d'avvio dove /usr/ non è disponibile, è necessario aggiungere un prefisso ad ogni comando con /sbin/lvm.static (per esempio /sbin/lvm.static vgchange -ay).

In ambienti dove /usr/ è disponibile, non è più necessario aggiungere come prefisso lvm ad ogni comando (per esempio /usr/sbin/lvm vgchange -ay diventa /usr/sbin/vgchange -ay).

I nuovi comandi LVM2 (come ad esempio /usr/sbin/vgchange -ay e /sbin/lvm.static vgchange -ay), rilevano se state eseguendo un kernel 2.4, invocando in modo trasparente i vecchi comandi LVM1. I comandi LVM1 sono stati rinominati in modo da terminare con ".lvm1" (per esempio, /sbin/vgchange.lvm1 -ay).

Il name service cache daemon nscd è in grado ora di mantenere una cache persistente durante le procedure di avvio del sistema. Ogni database (rispettivamente utente, gruppo e host) può essere selezionato in modo da risultare persistente, impostando la linea appropriata in /etc/nscd.conf su "yes". Le entry non vengono rimosse dalla cache fino a quando esse non risultano essere di alcun utilizzo. Tutte le entry che risultano essere scadute, ma il loro utilizzo risulta essere ancora di una certa utilità, vengono automaticamente ricaricate, tale procedura risulta essere utile in situazioni dove le directory ed i name service diventano temporaneamente non disponibili.

Con l'impostazione di default della configurazione di sicurezza di SELinux, il suddetto demone viene coperto dalla targeted policy. Ciò non fà altro che aumentare la sicurezza garantendo o rifiutando in modo specifico l'accesso agli oggetti del sistema usati normalmente dal demone. Tuttavia, poichè tale procedura potrebbe potenzialmente rendere inoperativi alcune configurazioni precedentemente in funzione, è importante comprendere il funzionamento di SELinux, per poter assicurare che la vostra organizzazione sia sempre sicura ed efficiente.

Per maggiori informazioni sulla policy di SELinux, consultate Red Hat SELinux Policy Guide su http://www.redhat.com/docs.