Capitolo 5. Problemi di cui essere al corrente per jessie

Indice

5.1. Limitazione nel supporto per la sicurezza
5.1.1. Stato della sicurezza dei browser web
5.1.2. Mancanza di supporto di sicurezza per l'ecosistema di libv8 e Node.js
5.2. Il server OpenSSH usa in modo predefinito «PermitRootLogin without-password».
5.3. Compatibilità con puppet 2.7 / 3.7
5.4. L'aggiornamento di PHP 5.6 determina cambiamenti nel suo comportamento
5.5. Modifiche incompatibili in Apache HTTPD 2.4
5.6. L'aggiornamento installa il nuovo sistema init predefinito per Jessie
5.6.1. Gestione più rigida delle azioni di mount fallite all'avvio con systemd
5.6.2. Può essere necessario fare il port per systemd degli script init modificati localmente.
5.6.3. plymouth necessario per i prompt di avvio negli avvii con systemd
5.7. Opzioni di configurazione del kernel richieste per Jessie
5.8. Considerazioni sull'aggiornamento per host e contenitori LXC.
5.8.1. Aggiornamento di guest LXC in esecuzione su host wheezy
5.8.2. Aggiornamento di guest LXC in esecuzione su host jessie
5.8.3. Ulteriori informazioni
5.9. Migrazione manuale di dischi cifrati con LUKS whirlpool (configurazioni non standard)
5.10. Il desktop GNOME richiede grafica 3D di base
5.11. Il desktop GNOME non funziona con il driver FGLRX proprietario di AMD.
5.12. Modifiche alle scorciatoie da tastiera predefinite di GNOME
5.13. Modifiche alla shell predefinita degli utenti di sistema fornita da base-passwd
5.14. Migrazione ai nuovi programmi per e-mail, calendario e contatti di KDE
5.15. Console virtuali («getty») mancanti con ambienti desktop multipli
5.16. Messaggio «VGA signal out of range» o schemo vuoto durante l'avvio con grub-pc
5.17. Validazione più stringente dei file cron in crontab
5.18. Change in handling of unreadable module paths by perl

A volte i cambiamenti introdotti da un nuovo rilascio comportano effetti collaterali che non si possono ragionevolmente evitare o che espongono a errori da altre parti. In questa sezione sono documentati i problemi noti. Si leggano anche le errata corrige, la documentazione dei pacchetti interessati, le segnalazioni di errori e altre informazioni riportate in Sezione 6.1, «Ulteriori letture».

5.1. Limitazione nel supporto per la sicurezza

Ci sono alcuni pacchetti per i quali Debian non può garantire di fornire i backport minimi per ragioni di sicurezza. Questi verranno trattati nelle sottosezioni che seguono.

Notare che il pacchetto debian-security-support, introdotto in Jessie, aiuta a tenere traccia dello stato del supporto di sicurezza per i pacchetti installati.

5.1.1. Stato della sicurezza dei browser web

Debian 8 contiene diversi motori per browser che sono affetti da varie vulnerabilità di sicurezza. L'alto tasso di vulnerabilità e la parziale mancanza di supporto a lungo termine da parte degli autori originali complica l'attività di supporto di questi browser tramite l'applicazione delle correzioni di sicurezza alle versioni precedenti. Inoltre la dipendenza reciproca delle librerie rende impossibile aggiornare a una nuova versione. Perciò, in Jessie sono presenti browser basati sui motori webkit, qtwebkit e khtml, ma non sono coperti dal supporto di sicurezza. Non si dovrebbe usare questi browser con siti web non fidati.

Per un browser web di uso generico si raccomanda Iceweasel oppure Chromium.

Chromium, pur essendo costruito sul codice Webkit, è un pacchetto foglia che verrà mantenuto aggiornato ricompilando i rilasci correnti di Chromium per stable. Iceweasel e Icedove verranno anch'essi mantenuti aggiornati ricompilando i rilasci ESR correnti per stable.

5.1.2. Mancanza di supporto di sicurezza per l'ecosistema di libv8 e Node.js

La piattaforma Node.js è costruita sulla base di libv8-3.14 che ha un grande volume di problemi di sicurezza ma al momento non ci sono volontari all'interno del progetto o nel Team di sicurezza sufficientemente interessati e con la volontà di investire la grande quantità di tempo richiesto per limitare questi problemi in arrivo.

Sfortunatamente ciò significa che libv8-3.14, nodejs e l'ecosistema di pacchetti node-* associati attualmente non dovrebbe essere usato con contenuti non fidati, ad esempio dati non ripuliti presi da Internet.

In aggiunta questi pacchetti non riceveranno aggiornamenti durante la vita del rilascio Jessie.

5.2. Il server OpenSSH usa in modo predefinito «PermitRootLogin without-password».

Nel tentativo di rafforzare l'impostazione predefinita, la configurazione di openssh-server ora usa in modo predefinito «PermitRootLogin without-password». Questo cambiamento può avere conseguenze se ci si affida all'autenticazione con password per l'utente root.

openssh-server cercherà di rilevare questi casi e aumentare la priorità delle sue domande debconf.

Se si desidera mantenere l'autenticazione con password per l'utente root, si può anche usare una preimpostazione per questa domanda utilizzando:

$ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf-set-selections
    

5.3. Compatibilità con puppet 2.7 / 3.7

Se si sta usando Puppet, fare attenzione al fatto che Puppet 3.7 non è compatibile all'indietro con Puppet 2.7. Tra le altre cose, le regole di ambito sono state modificate e molti costrutti deprecati sono stati rimossi. Vedere le note di rilascio di Puppet 3.x per alcune delle modifiche, ma tenere a mento che ci sono ulteriori modifiche in 3.7.

Controllare nei file di log dell'attuale puppetmaster la presenza di avvertimenti riguardo aspetti deprecati e risolverli tutti prima di procedere con l'aggiornamento renderà il completamento dell'aggiornamento stesso molto più facile. In alternativa, o in aggiunta, anche testando i manifest con uno strumento come Puppet catalog test si possono trovare potenziali problemi prima dell'aggiornamento.

Quando si aggiorna un sistema gestito con Puppet da wheezy a jessie, bisogna assicurarsi che il puppetmaster corrispondente esegua almeno Puppet versione 3.7. Se il master esegue puppetmaster di wheezy, il sistema jessie gestito non sarà in grado di collegarvisi.

Per maggiori informazioni sui cambiamenti che causano incompatibilità guardare Telly upgrade issues e «The Angry Guide to Puppet 3».

5.4. L'aggiornamento di PHP 5.6 determina cambiamenti nel suo comportamento

L'aggiornamento a Jessie include un aggiornamento di PHP da 5.4 a 5.6. Questo può avere effetto su qualsiasi script PHP locale ed è consigliato controllare questi script prima dell'aggiornamento. Quello che segue è una selezione di questi problemi:

  • Per prevenire attacchi «uomo-nel-mezzo» contro trasferimenti cifrati, i flussi client ora verificano i certificati dei peer in modo predefinito.

    Come risultato di questo cambiamento, il codice esistente che usa wrapper di flusso ssl:// o ssl:// (es. file_get_contents(), fsockopen(), stream_socket_client()) può non connettersi più con successo se non viene disabilitata manualmente la verifica dei peer attraverso l'impostazione «verify_peer» nel contesto dei flussi.

    Per maggiori informazioni su questo particolare problema leggere questo documento.

  • PHP cambia la gestione della sensibilità a maiuscole e minuscole in molti casi:

    • Tutta la gestione interna della sensibilità a maiuscole e minuscole per i nomi di classi, funzioni e costanti viene fatta in accordo con le regole ASCII. Le impostazioni attuali della localizzazione vengono ignorate.

    • Le parole chiave «self», «parent» e «static» sono ora sempre insensibili a maiuscole e minuscole.

    • La funzione json_decode() non accetta più le varianti in minuscolo di valori «booleani».

  • Le funzioni per GUID di logo (es. php_logo_guid()) sono state rimosse.

  • Non è più possibile sovrascrivere chiavi in array scalari statici. Vedere il bug PHP 66015 per un esempio e per ulteriori informazioni su questo particolare problema.

  • Le funzioni mcrypt_encrypt(), mcrypt_decrypt() e mcrypt_{MODE}() non accettano più chiavi o IV con dimensioni non corrette. Inoltre un IV è ora necessario se la modalità di cifratura dei blocchi usata lo richiede.

  • Per ragioni legali, l'implementazione JSON fornita con PHP è stata sostituita con la versione fornita dal modulo PECL «jsonc». Può essere necessario fare una revisione del codice che prende come assunto (se lo fa) i dettagli più fini dell'implementazione dell'analizzatore JSON di PHP.

Per maggiori informazioni sull'elenco completo dei potenziali problemi, guardare l'elenco degli autori a monte dei cambiamenti incompatibili all'indietro di PHP 5.5 e 5.6.

5.5. Modifiche incompatibili in Apache HTTPD 2.4

[Nota]Nota

Questa sezione riguarda solo i sistemi in cui il server HTTPD Apache è installato ed è stato configurato manualmente.

Ci sono stati diversi cambiamenti nella configurazione del server HTTPD Apache nella versione 2.4. Dalla parte degli autori a monte è cambiata la sintassi. In particolare le direttive di controllo degli accessi sono cambiate in modo considerevole e necessitano di una migrazione manuale alle nuove direttive.

Il modulo mod_access_compat è indicato nella guida per l'aggiornamento degli autori a monte come una possibile alternativa per la migrazione immediata. Tuttavia le segnalazioni fanno pensare che possa non funzionare sempre.

Nella pacchettizzazione Debian è anche cambiata la gestione dei file di configurazione. In particolare, tutti i file e le posizioni di configurazione ora devono terminare in modo predefinito con «.conf» per essere analizzati. Questo cambiamento rimpiazza anche l'uso attuale di /etc/apache2/conf.d/.

[Nota]Nota

Durante l'aggiornamento si possono anche vedere avvertimenti relativi ai file di configurazione posti in /etc/apache2/conf.d/ che sono forniti da pacchetti di Debian. Questo avvertimento è inevitabile ma non crea problemi dato che i pacchetti interessati sposteranno la loro configurazione una volta completato il loro aggiornamento (il che generalmente avviene dopo che Apache HTTPD ha emesso il suo avvertimento).

	TODO: problemi noti dove ciò non è vero: #669735,
        #718483, #669796, #669777. La loro risoluzione è
	attesa prima del rilascio di Jessie.

Per maggiori informazioni e per l'elenco completo dei cambiamenti fare riferimento a:

  • Il documento Upgrading to 2.4 from 2.2 fornito da Apache per le modifiche a monte.

  • Il file /usr/share/doc/apache2/NEWS.Debian.gz fornito dal pacchetto apache2.

5.6. L'aggiornamento installa il nuovo sistema init predefinito per Jessie

Jessie ships with systemd-sysv as default init system. This package is installed automatically on upgrades.

If you have a preference for another init such as sysvinit-core or upstart, it is recommended to setup APT pinning prior to the upgrade. This may also be required if you are upgrading LXC containers before the host. In this case, please refer to Sezione 5.8.1, «Aggiornamento di guest LXC in esecuzione su host wheezy».

As an example, to prevent systemd-sysv from being installed during the upgrade, you can create a file called /etc/apt/preferences.d/local-pin-init with the following contents:

Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1
  
[Attenzione]Attenzione

Fare attenzione che alcuni pacchetti possono avere un comportamento ridotto o possono mancare di alcune funzionalità in un sistema init non predefinito.

Notare che l'aggiornamento può installare pacchetti contenenti «systemd» nel loro nome anche usando i pin di APT. Questi da soli non modificano il sistema init. Per usare systemd come sistema init, deve prima essere installato il pacchetto systemd-sysv.

If APT or aptitude issues computing an upgrade path with the pin in place, you may be able to help it by manually installing both sysvinit-core and systemd-shim.

5.6.1. Gestione più rigida delle azioni di mount fallite all'avvio con systemd

Il nuovo sistema init predefinito systemd-sysv ha una gestione più rigida delle azioni di mount automatiche («auto») fallite all'avvio rispetto a sysvinit. Se un montaggio «auto» fallisce (senza l'opzione «nofail») systemd ripiegherà su una shell di emergenza invece di continuare l'avvio.

Per tutti i punti di mount rimovibili o «opzionali» (es. unità di rete non critiche) elencate in /etc/fstab è raccomandato l'uso dell'opzione «noauto» oppure dell'opzione «nofail».

5.6.2. Può essere necessario fare il port per systemd degli script init modificati localmente.

[Nota]Nota

Questa sezione è valida solo per i sistemi in cui gli script init forniti da Debian sono stati modificati localmente.

Se alcuni degli script init forniti da Debian sono stati modificati, tenere a mente che essi possono ora essere stati sorpassati da un file unit di systemd o da systemd stesso. Se debsums è installato si può controllare la presenza di script init modificati localmente usando il seguente comando di shell:

debsums -c -e | grep ^/etc/init.d
  

In alternativa, in assenza di debsums, si può usare quanto segue:

  dpkg-query --show -f'${Conffiles}' | sed 's, /,\n/,g' | \
    grep /etc/init.d | awk 'NF,OFS="  " {print $2, $1}' | \
    md5sum --quiet -c

Se uno dei due comandi segnala dei file e i loro pacchetti corrispondenti o systemd ora forniscono un file unit per systemd per tale servizio, il file unit di systemd avrà la precedenza rispetto allo script init modificato localmente. A seconda della natura del cambiamento ci sono diversi modi per fare la migrazione.

Se necessario, è possibile scavalcare il file unit di systemd per fare in modo che avvii lo script sysvinit. Per maggiori informazioni sui file unit di systemd guardare le seguenti risorse:

5.6.3. plymouth necessario per i prompt di avvio negli avvii con systemd

Se l'avvio è interattivo (es. se serve una password per un disco cifrato), assicurasi di avere installato e configurato plymouth. Fare riferimento a /usr/share/doc/plymouth/README.Debian per informazioni su come configurare plymouth.

Senza plymouth può succedere che il prompt di avvio sparisca. Le segnalazioni suggeriscono che il prompt di cryptsetup accetti comunque l'input a dispetto del fatto che non è visibile. Se ci si imbatte in questo problema digitare la password corretta potrebbe comunque funzionare.

5.7. Opzioni di configurazione del kernel richieste per Jessie

[Nota]Nota

Questa sezione riguarda solo coloro che compilano da soli il proprio kernel. Se si usano i kernel compilati da Debian, questa sezione può essere saltata.

Le seguenti opzioni di configurazione del kernel sono adesso richieste oppure raccomandate per Jessie (in aggiunta a quelle già esistenti dai rilasci precedenti):

# Richiesta per udev
CONFIG_DEVTMPFS=y
# Richiesta per *alcuni* servizi systemd
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

I servizi di systemd che richiedono CONFIG_DEVPTS_MULTIPLE_INSTANCES=y tipicamente contengono almeno una delle seguenti direttive:

PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=yes
  

Se non si usa systemd o si è certi che nessuno dei servizi systemd usi le direttive suddette, l'opzione di configurazione potrebbe non essere richiesta per il proprio particolare sistema.

Ulteriori informazioni sui requisiti possono essere trovate in /usr/share/doc/systemd/README.gz (dal pacchetto systemd).

5.8. Considerazioni sull'aggiornamento per host e contenitori LXC.

[Nota]Nota

Questa sezione riguarda solo i sistemi che hanno contenitori e host LXC. I comuni sistemi degli utenti finali solitamente non li hanno.

L'aggiornamento da wheezy a jessie migra il sistema in modo predefinito al sistema init systemd (vedere Sezione 5.6, «L'aggiornamento installa il nuovo sistema init predefinito per Jessie»).

Quando si aggiorna un contenitore LXC, una macchina virtuale LXC, ciò ha conseguenze diverse a seconda del fatto che il sistema host sia stato o meno già aggiornato a jessie.

5.8.1. Aggiornamento di guest LXC in esecuzione su host wheezy

Se si sta aggiornando un contenitore LXC ospite che è in esecuzione su un sistema host Wheezy, allora è necessario evitare che l'ospite venga automaticamente migrato a systemd. La migrazione viene evitata usando il pinning, come descritto in Sezione 5.6, «L'aggiornamento installa il nuovo sistema init predefinito per Jessie».

Questo è necessario dato che l'host Wheezy manca della funzionalità di avviare un sistema con in esecuzione systemd.

Sarà possibile passare a systemd all'interno dell'ospite LXC una volta fatto l'aggiornamento del sistema host a Jessie. Vedere il paragrafo successivo per gli aspetti che necessitano di adattamenti negli host Jessie.

5.8.2. Aggiornamento di guest LXC in esecuzione su host jessie

Per poter avviare ospiti LXC con systemd è necessario adattare la configurazione del proprio contenitore LXC. Tale configurazione può solitamente essere trovata in /var/lib/lxc/NOME_CONTAINER/config. È necessario aggiungere le due impostazioni seguenti alla configurazione:

lxc.autodev = 1
lxc.kmsg = 0

5.8.3. Ulteriori informazioni

Si possono trovare ulteriori informazioni su LXC in Debian nel wiki Debian.

5.9. Migrazione manuale di dischi cifrati con LUKS whirlpool (configurazioni non standard)

[Nota]Nota

Questa sezione riguarda solo coloro che hanno impostato da soli i dischi cifrati LUKS usando l'hash whirlpool. L'installatore Debian non ha mai supportato la creazione di tali dischi.

Se è stato impostato manualmente un disco cifrato con LUKS whirlpool è necessario migrarlo manualmente ad un hash più robusto. Si può verificare se il proprio disco usa whirlpool usando il comando seguente:

    # /sbin/cryptsetup luksDump <device-disco> | grep -i whirlpool
  

Per maggiori informazioni sulla migrazione vedere la voce «8.3 Gcrypt 1.6.x and later break Whirlpool» delle FAQ di cryptsetup.

[Attenzione]Attenzione

Se si possiede uno di questi dischi, cryptsetup in modo predefinito si rifiuta di decifrarlo. Se il disco radico o altri dischi di sistema (es. /usr) sono cifrati con whirlpool, questi devono essere migrati prima del primo ravvio successivo all'aggiornamento di cryptsetup.

5.10. Il desktop GNOME richiede grafica 3D di base

Il desktop GNOME 3.14 in Jessie non ha più il supporto di ripiego per macchine senza grafica 3D di base. Per funzionare correttamente necessita di un PC abbastanza recente (qualsiasi PC prodotto negli ultimi 10 anni dovrebbe avere il supporto SSE2 richiesto) o, per le architetture diverse da i386 e amd64, un adattatore grafico con accelerazione 3D con driver EGL.

5.11. Il desktop GNOME non funziona con il driver FGLRX proprietario di AMD.

A differenza di altri driver OpenGL, il driver FGLRX di AMD per gli adattatori Radeon non supporta l'interfaccia EGL. Pertanto svariate applicazioni GNOME, incluso il nucleo centrale del desktop GNOME, non si avviano per nulla quando è in uso tale driver.

È raccomandato invece l'uso del driver libero radeon che è quello predefinito in jessie.

5.12. Modifiche alle scorciatoie da tastiera predefinite di GNOME

Le scorciatoie da tastiera predefinite nel desktop GNOME sono state cambiate allo scopo di riflettere più da vicino quelle di alcuni altri sistemi operativi.

Le impostazioni delle scorciatoie modificate in passato dall'utente vengono preservate durante l'aggiornamento. Queste impostazioni possono sempre essere configurate dal centro di controllo di GNOME, a cui si accede dal menu in alto a destra facendo clic sull'icona "impostazioni".

5.13. Modifiche alla shell predefinita degli utenti di sistema fornita da base-passwd

L'aggiornamento del pacchetto base-password reimposta la shell degli utenti di sistema che è fornita dalla shell «nologin». Tra questi utenti sono inclusi:

  • daemon

  • bin

  • sys

  • games

  • man

  • lp

  • mail

  • news

  • uucp

  • proxy

  • www-data

  • backup

  • list

  • irc

  • gnats

  • nobody

Se la configurazione locale richiede che uno o più di questi utenti abbia una shell si dovrebbe indicare di non volere la migrazione oppure fare la migrazione e poi cambiare la shell degli utenti appropriati. Esempi tipici includono backup locali fatti usando l'utente «backup» con un'autenticazione «ssh-key».

[Attenzione]Attenzione

La migrazione avviene automaticamente se la priorità delle domande poste da debconf è «alta» o superiore.

Se si sa già che si desidera mantenere la shell attuale di un dato utente, si può fare il preseed delle domande usando quanto segue:

    echo 'base-passwd base-passwd/system/nome_utente/shell/nome_shell_attuale_rimaneggiato/_usr_sbin_nologin boolean false' | debconf-set-selections
  

Dove nome_utente è il nome dell'utente in questione e nome_shell_attuale_rimaneggiato è il nome rimaneggiato della shell. Questo nome viene ottenuto sostituendo tutti i caratteri non alfanumerici e quelli che non sono trattini o trattini bassi con trattini bassi. Es. /bin/bash diventa _bin_bash.

5.14. Migrazione ai nuovi programmi per e-mail, calendario e contatti di KDE

Il sistema di gestione delle informazioni personali Kontact ha subito un importante aggiornamento. La nuova versione fa un uso molto più esteso dell'indicizzazione di metadati e ogni dato dell'utente deve essere migrato in questi nuovi indici.

Le e-mail, gli eventi del calendario e i contatti della rubrica vengono migrati automaticamente quando l'utente fa il login e il componente appropriato viene avviato. Alcune impostazioni avanzate, come filtri per e-mail e modelli personalizzati, richiedono un intervento manuale. Ulteriori dettagli e suggerimenti per la risoluzione dei problemi sono raccolti nel wiki Debian.

5.15. Console virtuali («getty») mancanti con ambienti desktop multipli

Se si ha più di un ambiente desktop installato può accadere che nessuna delle «console virtuali» mostri un prompt di login.

Questo problema sembra verificarsi quando plymouth, systemd e GNOME sono tutti installati. È stato segnalato come Bug Debian n. 766462.

È stato riportato che la rimozione dell'argomento «splash» dalla riga di comando del kernel può aggirare il problema. Vedere /etc/default/grub e ricordarsi di eseguire update-grub dopo aver aggiornato il file:

5.16. Messaggio «VGA signal out of range» o schemo vuoto durante l'avvio con grub-pc

C'è un problema di compatibilità in grub-pc con le schede grafiche più vecchie (es. la "ATI Rage 128 Pro Ultra TR") che può causare la visualizzazione di una schermata vuota all'avvio. Il monitor può mostrare un messaggo «VGA signal out of range» (o qualcosa di simile).

Un semplice modo di aggirare il problema è impostare GRUB_TERMINAL=console in /etc/default/grub.

5.17. Validazione più stringente dei file cron in crontab

Il programma crontab è ora più severo e potrà rifiutarsi di salvare un file cron cambiato se non è valido. Se si hanno problemi con crontab -e revisionare il proprio crontab alla ricerca di errori.

5.18. Change in handling of unreadable module paths by perl

From version 5.18 (and 5.20, which is included in jessie), perl will exit with a fatal error if it encounters unreadable module paths in @INC. The previous behaviour was to skip such entries. It is recommended to check the contents of @INC in your environment for directories which are not world-readable, and take appropriate action.

You can see the default @INC for perl by running perl -V.