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.1.3. Fine anticipata del supporto di sicurezza per MediaWiki
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. Gli script init obsoleti dovrebbero essere eliminati completamente
5.6.3. Può essere necessario fare il port per systemd degli script init modificati localmente.
5.6.4. plymouth necessario per i prompt di avvio negli avvii con systemd
5.6.5. Interazione tra logind e acpid
5.6.6. Funzionalità crypttab non supportate in systemd (es. «keyscript=...»)
5.6.7. systemd: invia SIGKILL troppo presto [risolto in 8.1]
5.6.8. systemd: comportamento del comando «halt»
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. Modifiche alla gestione di percorsi illeggibili dei moduli da parte di perl
5.19. Considerazioni sull'aggiornamento per cluster Ganeti
5.19.1. Problemi con l'aggiornamento di cluster Ganeti con istanze basate su DRBD [risolto in 8.1]
5.19.2. Note generiche sull'aggiornamento di cluster Ganeti
5.20. Nuovi requisiti per l'esecuzione di file in Samba4
5.21. Cryptsetup può rendere non funzionante l'avvio con BUSYBOX=n
5.22. Backwards incompatible changes in the Squid webproxy

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, come dati non ripuliti presi da Internet.

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

5.1.3. Fine anticipata del supporto di sicurezza per MediaWiki

Il supporto di sicurezza degli autori a monte per la serie 1.19 di mediawiki termina durante il ciclo di vita previsto per Jessie. Il pacchetto mediawiki è incluso in Jessie per soddisfare le dipendenze in altri pacchetti.

Il supporto di sicurezza per mediawiki terminerà insieme con il supporto per Wheezy nell'aprile 2016.

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 i dettagli più fini dell'implementazione dell'analizzatore JSON di PHP.

  • L'impostazione «short_open_tag» è ora disabilitata in modo predefinito. In PHP7 è pianificata la rimozione dei tag corti («<?» e «?>»).

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).

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 viene fornita con systemd-sysv come sistema init predefinito. Tale pacchetto viene installato automaticamente durante gli aggiornamenti.

Se si preferisce un altro init come sysvinit-core o upstart, è raccomandato impostare le priorità di pin di APT prima dell'aggiornamento. Ciò può anche essere necessario se si stanno aggiornando contenitori LXC prima dell'host. In questo caso fare riferimento a Sezione 5.8.1, «Aggiornamento di guest LXC in esecuzione su host Wheezy».

Come esempio, per evitare l'installazione di systemd-sysv durante l'aggiornamento, si può creare un file chiamato /etc/apt/preferences.d/local-pin-init contenente quanto segue:

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.

Se APT o aptitude hanno problemi a calcolare un percorso di aggiornamento che tenga conto del pin, può essere possibile aiutarli installando manualmente sia sysvinit-core sia 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. Gli script init obsoleti dovrebbero essere eliminati completamente

Se si sta facendo l'aggiornamento da rilasci precedenti, il sistema può contenere script init obsoleti forniti da pacchetti (ormai) rimossi. Questi script possono avere metadati mancanti o non accurati e ciò può portare a cicli di dipendenze nella configurazione di init.

Per evitare questo problema è raccomandato rivedere l'elenco dei pacchetti che sono nello stato "rc" (rimossi ma con ancora i file di configurazione) ed eliminare completamente almeno quelli che contengono script init.

Vedere Sezione 4.8.1, «Eliminare completamente i pacchetti rimossi» per dettagli su come trovare ed eliminare completamente pacchetti rimossi.

5.6.3. 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.4. 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.6.5. Interazione tra logind e acpid

Gli eventi ACPI possono essere gestiti da logind o da acpid. Nel caso in cui entrambi i servizi sono configurati per gestire gli eventi in modi diversi ciò può portare a risultati indesiderati.

Si raccomanda di migrare ogni impostazione non predefinita in logind e di disinstallare acpid. In alternativa è anche possibile configurare logind per ignorare gli eventi ACPI aggiungendo:

HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore

a /etc/systemd/logind.conf. Notare che questo può cambiare il comportamento degli ambienti desktop che si appoggiano a logind.

5.6.6. Funzionalità crypttab non supportate in systemd (es. «keyscript=...»)

Ci sono alcune funzionalità di cryptsetup che purtroppo non sono supportate quando si usa systemd come sistema init. Sono:

  • precheck

  • check

  • checkargs

  • noearly

  • loud

  • keyscript

Se il proprio sistema fa affidamento su una qualsiasi di esse è necessario, per avviare con successo, usare sysvinit (sysvinit-core) come sistema init. Fare riferimento a Sezione 5.6, «L'aggiornamento installa il nuovo sistema init predefinito per Jessie» per istruzioni su come evitare un particolare sistema init.

Si può controllare se alcune di queste opzioni sono in uso sul proprio sistema eseguendo il comando seguente:

grep -e precheck -e check -e checkargs -e noearly -e loud -e keyscript /etc/crypttab

Se tale comando non produce output il sistema non usa alcuna delle opzioni interessate.

5.6.7. systemd: invia SIGKILL troppo presto [risolto in 8.1]

[Nota]Nota

Questo problema è stato risolto nel rilascio minore 8.1 di Jessie.

È stato segnalato il ritorno ad un problema dopo il rilascio di Jessie. Il bug si verifica durante lo spegnimento o riavvio, quando systemd non aspetta un ritardo ragionevole prima di inviare il SIGKILL ai processi. Questo può portare a perdite di dati nei processi che non hanno salvato tutti i dati al momento del riavvio (es. database in esecuzione).

Gli sviluppi di questo bug sono tracciati nel bug Debian n.784720.

5.6.8. systemd: comportamento del comando «halt»

L'implementazione di sysvinit del comando halt spegneva anche la macchina. L'implementazione di systemd-sysv arresta il sistema ma non spegne la macchina. Per arrestare la macchina e spegnerla usare il comando poweroff.

Vedere anche il bug Debian n.760923

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 di systemd
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# Richiesta per "bluez" (GNOME)
CONFIG_BT=y
# Richiesta per cups + systemd.
CONFIG_PPDEV=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.

Per ulteriori informazioni sui requisiti fare riferimento alla sezione «REQUIREMENTS» nel file README per il 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 o 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 alla shell «nologin». Tra questi utenti sono inclusi:

  • daemon

  • bin

  • sys

  • sync

  • 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 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 diversi da 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

[Nota]Nota

Questo problema attualmente è segnalato come risolto in Jessie. Se ancora si fosse in grado di riprodurlo, aggiungere informazioni al bug Debian n.766462. Notare che potrebbe essere necessario ripristinare prima il bug dagli archivi (fare riferimento alla documentazione del server di controllo del BTS Debian su come estrarre i bug dall'archivio).

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. Modifiche alla gestione di percorsi illeggibili dei moduli da parte di perl

A partire dalla versione 5.18 (compresa la 5.20 che è inclusa in Jessie) Perl terminerà con un errore fatale se incontra percorsi illeggibili di moduli in @INC. Il comportamento precedente era di controllare i contenuti di @INC nel proprio ambiente alla ricerca di directory che non fossero leggibili da tutti e di prendere le misure appropriate.

Si può vedere l'impostazione di @INC predefinita per Perl eseguendo perl -V.

5.19. Considerazioni sull'aggiornamento per cluster Ganeti

5.19.1. Problemi con l'aggiornamento di cluster Ganeti con istanze basate su DRBD [risolto in 8.1]

[Nota]Nota

Questo problema è stato risolto nel rilascio minore 8.1 di Jessie.

La versione di ganeti (2.12.0-3) rilasciata con Jessie non supporta la migrazione da installazioni con in esecuzione 2.5 o precedenti (inclusa Wheezy) nei casi in cui ci sono istanze con dischi DRBD. Si spera che questo problema venga risolto in un rilascio minore e nel frattempo è raccomandato non aggiornare i cluster Ganeti affetti. si possono trovare ulteriori informazioni su questo problema nel bug Debian n. 783186.

5.19.2. Note generiche sull'aggiornamento di cluster Ganeti

La procedura raccomandata per aggiornare un cluster Ganeti dalla versione di ganeti (2.5.2-1) di Wheezy a quella di Jessie (2.12.0-3) è di fermare tutte le istanze e poi aggiornare e riavviare tutti i nodi in una sola volta. ciò assicura che tutte le istanze siano in esecuzione con la versione di ipervisore di jessie e che tutti i nodi eseguano le medesime versioni di Ganeti e DRBD.

Notare che non è supportata l'esecuzione di un cluster con nodi misti 2.5 e 2.12. Notare anche che, a secondo dell'ipervisore, le migrazioni live delle istanze potrebbero non funzionare tra le versioni di ipervisore di Wheezy e Jessie.

5.20. Nuovi requisiti per l'esecuzione di file in Samba4

Se un client richiede l'«apertura per esecuzione» di un file Samba4 richiede che il file abbia bit di esecuzione impostato oltre ai regolari permessi in lettura. Ciò è anche la causa per la quale gli script «netlogon» sono ignorati silenziosamente se mancano di tale bit di esecuzione.

5.21. Cryptsetup può rendere non funzionante l'avvio con BUSYBOX=n

[Nota]Nota

Questa sezione riguarda solo coloro che hanno modificato manualmente il proprio /etc/initramfs-tools/initramfs.conf per non usare busybox.

Se sono installati entrambi busybox e cryptsetup e in più initramfs è stato configurato per non usare busybox, allora ciò può rendere il sistema inavviabile.

Controllare il valore della propria impostazione BUSYBOX in /etc/initramfs-tools/initramfs.conf se entrambi questi pacchetti sono installati. Al momento attuale soluzioni di ripiego note sono disinstallare busybox o impostare BUSYBOX=y in /etc/initramfs-tools/initramfs.conf.

[Avvertimento]Avvertimento

Se è stato necessario fare modifiche ricordarsi di eseguire update-initramfs -u per aggiornare il proprio initramfs. Altrimenti ci si potrebbe ritrovare comunque non un avvio non funzionante.

Per maggiori informazioni consultare il bug Debian n.783297.

5.22. Backwards incompatible changes in the Squid webproxy

[Nota]Nota

This section only applies to people that have installed the squid webproxy.

The configuration of squid has changed in an incompatible way. Notably some of the squid "helpers" have changed their name. If your configuration relies on old features no longer present or on the old names for the helpers, your squid service may fail to start after the upgrade.

Please see the upstream release notes for more information. These are: