Chapitre 5. Problèmes à connaître pour Jessie

Il y a certains paquets pour lesquels Debian ne peut pas garantir de rétroportages de base pour les problèmes de sécurité. Ceux-ci sont couverts dans les sous-sections suivantes.

Veuillez noter que le paquet debian-security-support, introduit dans Jessie, aide à suivre le statut de la prise en charge du suivi de sécurité des paquets installés.

Afin de renforcer la sécurité de l'installation par défaut, la configuration de openssh-server est maintenant réglée avec « PermitRootLogin without-password » par défaut. Si vous utilisez l'authentification par mot de passe pour l'utilisateur root, vous pourriez être affecté par ce changement.

openssh-server essaiera de détecter de tels cas et augmentera la priorité de son invite debconf.

Si vous souhaitez conserver l'authentification par mot de passe pour l'utilisateur root, vous pouvez également pré-répondre à cette question en utilisant :

# La valeur « false » est correcte même si elle prête à confusion.
 $ echo 'openssh-server openssh-server/permit-root-login boolean false' | debconf-set-selections

Si vous utilisez Puppet, soyez conscient que Puppet 3.7 n'est pas rétrocompatible avec Puppet 2.7. Entre autres choses, les règles de portée (« scoping ») ont changé et beaucoup de constructions dépréciées ont été supprimées. Veuillez consulter les notes de publication de Puppet 3.x pour quelques-unes des modifications, mais gardez à l'esprit qu'il y en a davantage dans la version 3.7.

Vérifier les fichiers de journaux de votre puppetmaster actuel à la recherche d'avertissements de dépréciation et résoudre tous ces avertissements avant de procéder à la mise à niveau simplifiera grandement les choses. Autrement ou en complément, le test des manifestes avec un outil comme le test de catalogue de Puppet pourrait également trouver des problèmes potentiels avant la mise à niveau.

Lors de la mise à niveau de Wheezy vers Jessie d'un système géré par Puppet, assurez-vous que le puppetmaster correspondant utilise au moins la version 3.7. Si le maître fonctionne avec le puppetmaster de Wheezy, le système géré sous Jessie ne sera pas capable de s'y connecter.

Pour davantage d'informations sur les changements d'incompatibilité, veuillez consulter les problèmes de mise à niveau Telly et « The Angry Guide to Puppet 3 ».

La mise à niveau vers Jessie comprend une mise à niveau de PHP de la version 5.4 vers la version 5.6. Cela pourrait affecter tous les scripts PHP locaux et il vous est recommandé de vérifier ces scripts avant de mettre à niveau. Un sous-ensemble de ces problèmes est présenté ci-dessous :

Pour plus d'informations ou la liste complète des problèmes potentiels, veuillez consulter la liste amont des modifications qui ne sont pas rétrocompatibles pour PHP pour les versions 5.5 et 5.6.

	Note
	Cette section ne s'applique qu'aux systèmes sur lesquels un serveur HTTPD Apache est installé et configuré manuellement.

De nombreux changements ont eu lieu dans la configuration du serveur HTTPD Apache dans sa version 2.4. Du côté amont, la syntaxe a changé. Notamment, les directives de contrôle d'accès ont considérablement changé et nécessiteront une migration manuelle vers les nouvelles directives.

Le module mod_access_compat est mentionné dans le guide amont de mise à niveau comme une alternative possible à la migration immédiate. Cependant, les rapports laissent penser que cela ne fonctionne pas toujours.

La gestion des fichiers de configuration a également changé dans le paquet Debian. En particulier, tous les fichiers de configuration et les sites doivent maintenant se terminer par « .conf » pour être interprétés par défaut. Cette modification remplace également l'usage actuel de /etc/apache2/conf.d/.

Note

Lors de la mise à niveau, vous pourriez également voir des avertissements concernant les fichiers de configuration placés dans /etc/apache2/conf.d/ qui sont fournis par des paquets de Debian. Cet avertissement est inévitable mais sans danger car les paquets affectés déplaceront leur configuration quand leur mise à niveau sera terminée (ce qui se produit généralement après l'envoi de l'avertissement par le serveur HTTP Apache).

Pour davantage d'informations et la liste complète des modifications, veuillez vous référer à :

Jessie est livrée avec systemd-sysv en tant que système d'initialisation par défaut. Ce paquet est automatiquement installé lors d’une mise à niveau.

Si vous avez une préférence pour un autre système comme sysvinit-core ou upstart, il est recommandé de régler le pinning d'APT avant la mise à niveau. Cela peut également être nécessaire si vous mettez à niveau des conteneurs LXC avant leur hôte. Dans ce cas, veuillez vous référer à Section 5.8.1, « Mettre à niveau des invités LXC tournant sur des hôtes sous Wheezy ».

Par exemple, pour empêcher systemd-sysv d'être installé lors de la mise à niveau, vous pouvez créer un fichier nommé /etc/apt/preferences.d/local-pin-init ayant le contenu suivant :

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

	Attention
	Soyez averti que certains paquets pourraient avoir un comportement affecté ou pourraient ne pas avoir toutes leurs fonctionnalités sous un autre système d'initialisation que celui par défaut.

Veuillez noter que la mise à niveau pourrait installer des paquets contenant « systemd » dans leur nom malgré le pinning APT. Ces paquets seuls ne peuvent pas changer votre système d'initialisation. Pour utiliser systemd comme système d'initialisation, le paquet systemd-sysv doit d'abord être installé.

Si APT ou aptitude a des difficultés à calculer un chemin de mise à niveau avec le pinning mis en place, vous pouvez l'aider en installant manuellement sysvinit-core et systemd-shim.

5.6.3. Les scripts de démarrage modifiés localement peuvent nécessiter d'être portés vers systemd

	Note
	Cette section ne concerne que les systèmes dans lesquels les scripts de démarrage fournis par Debian ont été modifiés localement.

Si vous avez modifié certains de vos scripts de démarrage fournis par Debian, sachez que ceux-ci pourraient avoir été remplacés par un fichier unit de systemd ou par systemd lui-même. Si debsums est installé, vous pouvez vérifier les scripts de démarrage modifiés localement en utilisant la commande suivante :

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

Autrement, la commande suivante peut-être utilisée en l'absence de debsums.

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

Si l'une de ces commandes désigne des fichiers et leurs paquets correspondants ou que systemd fournit désormais un fichier unit pour ce service, le fichier unit de systemd aura la priorité sur votre script de démarrage modifié localement. En fonction de la nature de la modification, il existe différentes manières d'effectuer la migration.

Au besoin, il est possible de passer outre le fichier unit de systemd pour le faire lancer le script de démarrage. Pour davantage d'informations sur les fichiers unit systemd, veuillez consulter les ressources suivantes :

• Comment convertir un script de démarrage SysV en un fichier de service systemd ?

• systemd.special — Special systemd units

• Mon service ne peut pas être en temps réel ! (contient également une brève mention sur l'invocation des scripts de démarrage à partir de fichiers unit)

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

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

5.6.7. systemd : envoie des SIGKILL trop tôt (corrigé dans 8.1)

	Note
	Ce problème a été corrigé dans la version mineure 8.1 de Jessie.

Une régression a été rapportée dans systemd après la distribution de Jessie. Le bogue se produit à l'extinction ou au redémarrage pendant lesquels systemd n'attend pas suffisamment longtemps avant d'envoyer des SIGKILL aux processus. Cela peut conduire à la perte de données dans les processus n'ayant pas sauvegardé toutes leurs données au moment du redémarrage (par exemple les bases de données).

Le problème est suivi dans le bogue nº 784720.

	Note
	Cette section est dédiée aux personnes qui compilent leur propre noyau. Si vous utilisez les noyaux compilés par Debian, vous pouvez ignorer cette section.

Les options suivantes de configuration du noyau sont maintenant requises ou recommandées pour Jessie (en plus des options déjà présentes dans les distributions antérieures) :

# Requis par udev
CONFIG_DEVTMPFS=y
# Requis par *certains* services systemd
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# Requis par "bluez" (GNOME)
CONFIG_BT=y
# Requis par cups + systemd.
CONFIG_PPDEV=y

Les services systemd nécessitant CONFIG_DEVPTS_MULTIPLE_INSTANCES=y contiennent généralement au moins une des directives suivantes :

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

Si vous n'utilisez pas systemd ou savez qu'aucun des services de systemd n'utilise les directives mentionnées, l'option de configuration peut ne pas être nécessaire à votre système.

Pour plus d'informations au sujet des prérequis, veuillez vous référer à la section "REQUIREMENTS" du fichier README dans le paquet systemd.

	Note
	Cette section ne concerne que les systèmes ayant des conteneurs et hôtes LXC. Les utilisateurs normaux n'en ont normalement pas.

La mise à niveau de Wheezy vers Jessie fera migrer votre système vers le système de démarrage systemd par défaut (voir Section 5.6, « La mise à niveau installe le nouveau système d'initialisation par défaut de Jessie »).

Lors de la migration d'un conteneur ou une machine virtuelle LXC, celle-ci aura différentes conséquences selon que le système hôte a déjà été mis à niveau vers Jessie ou non.

lxc.autodev = 1
lxc.kmsg = 0

	Note
	Cette section est dédiée aux personnes ayant installé elles-mêmes des disques chiffrés avec LUKS en utilisant le hachage whirlpool. L'installateur Debian n'a jamais géré la création de tels disques.

Si vous avez configuré manuellement un disque chiffré avec LUKS whirlpool, vous aurez besoin de le migrer manuellement vers un hachage plus fort. Vous pouvez vérifier si votre disque utilise whirlpool avec la commande suivante :

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

Pour davantage d'information sur la migration, veuillez consulter l'élément « 8.3 Gcrypt 1.6.x and later break Whirlpool » de la FAQ cryptsetup.

	Attention
	Si vous avez un tel disque, cryptsetup refusera de le déchiffrer par défaut. Si votre disque racine ou d'autres disques système (par exemple /usr) sont chiffrés avec whirlpool, vous devriez les migrer avant le premier redémarrage suivant la mise à niveau de cryptsetup.

Le bureau GNOME 3.14 de Jessie ne propose plus de prise en charge de secours pour les machines ne disposant pas de graphismes 3D de base. Pour fonctionner correctement, il nécessite soit un PC suffisamment récent (toute machine fabriquée ces 10 dernières années devrait avoir la prise en charge requise de SSE2) ou, pour les architectures autres qu'i386 et amd64, un adaptateur graphique 3D accéléré avec les pilotes EGL.

Contrairement aux autres pilotes OpenGL, le pilote AMD FGLRX pour les adaptateurs Radeon ne prend pas en charge l'interface EGL. Ainsi, plusieurs applications GNOME, dont le cœur du bureau GNOME, ne démarreront pas du tout quand ce driver sera utilisé.

Il est recommandé d'utiliser à la place le pilote libre radeon, qui est le pilote par défaut de Jessie.

Les raccourcis clavier par défaut du bureau GNOME ont changé afin de mieux correspondre à ceux utilisés sur d'autres systèmes d'exploitation.

Les réglages de raccourcis clavier précédemment modifiés par l'utilisateur seront préservés lors de la mise à niveau. Ces réglages peuvent encore être configurés depuis le centre de contrôle de GNOME, accessible dans le menu en haut à droite en cliquant sur l'icône « configuration ».

La mise à niveau du paquet base-passwd réinitialisera l'invite de commande de certains utilisateurs système à l'interpréteur de commande « nologin ». Sont concernés les utilisateurs suivants :

Si votre installation locale nécessite qu'un de ces utilisateurs ait un interpréteur de commande, vous devriez refuser la migration ou bien migrer puis changer l'interpréteur des utilisateurs correspondants. Des exemples notables incluent les sauvegardes locales faites avec l'utilisateur « backup » avec une authentification par « ssh-key ».

	Attention
	La migration se fera automatiquement si la priorité de votre question debconf est « high » ou plus.

Si vous savez que vous souhaitez conserver l'interpréteur de commande d'un utilisateur donné, vous pouvez pré-répondre à cette question en utilisant :

echo 'base-passwd base-passwd/system/nom_utilisateur/shell/shell-actuel-modifié/_usr_sbin_nologin boolean false' | debconf-set-selections

Où nom_utilisateur est le nom de l'utilisateur en question et shell_actuel_modifié est le nom tronqué de l'interpréteur. La modification se fait en remplaçant tous les caractères qui ne sont pas alphanumériques, tiret ou underscore, par des underscores. Par exemple, /bin/bash devient _bin_bash.

Le système Kontact de gestion d'informations personnelles a subi une mise à niveau majeure. La nouvelle version utilise beaucoup plus l'indexation des métadonnées et les données de chaque utilisateur doivent être migrées vers ce nouvel index.

Courriels, événements du calendrier et contacts du carnet d'adresse sont automatiquement migrés lorsque l'utilisateur se connecte et que le composant associé est lancé. Certains réglages avancés tels que les filtres de courriel et les templates personnalisés nécessitent une intervention manuelle. De plus amples détails et des suggestions de solutions aux problèmes sont réunies dans le wiki Debian.

	Note
	Ce problème est marqué comme corrigé dans Jessie. Si vous êtes toujours capable de le reproduire, veuillez le rapporter dans le bogue nº 766462. Veuillez noter que vous pourriez avoir à désarchiver le problème d'abord (veuillez consulter la documentation du serveur de contrôle BTS de Debian sur la façon de désarchiver les bogues).

Si vous avez installé plusieurs environnements de bureau, il se peut qu'aucune des « consoles virtuelles » ne montre une invite de connexion.

Ce problème semble se produire lorsque plymouth, systemd et GNOME sont tous installés. Ce problème est rapporté en tant que Bogue Debian nº 766462.

Il a été signalé que supprimer l'argument « splash » de la ligne de commande du noyau pourrait permettre de contourner le problème. Veuillez modifier /etc/default/grub et ne pas oublier de lancer update-grub après modification du fichier.

Il existe un problème de compatibilité dans grub-pc avec des cartes graphiques anciennes (par exemple la "ATI Rage 128 Pro Ultra TR") qui peut provoquer un écran noir lors du démarrage. L'écran peut afficher un message "Signal VGA hors de portée" (ou quelque chose de similaire).

Un contournement simple est de régler GRUB_TERMINAL=console dans /etc/default/grub.

Le programme crontab est maintenant plus strict et pourrait refuser de sauvegarder un fichier cron si celui-ci est invalide. Si vous rencontrez des problèmes avec crontab -e, veuillez vérifiez votre crontab.

À partir de la version 5.18 (et 5.20, celle incluse dans Jessie), Perl s'arrêtera avec une erreur fatale lorsqu'il rencontrera des chemins de modules illisibles dans @INC. Le comportement précédent était d'ignorer de telles entrées. Il est recommandé de vérifier le contenu de @INC de votre environnement à la recherche de répertoires n'étant pas lisibles par tout le monde et de prendre les mesures appropriées.

Vous pouvez voir le @INC par défaut de Perl en exécutant la commande perl -V.

Si un client demande qu'un fichier soit « ouvert pour exécution », Samba4 demandera que le bit d'exécution soit activé sur le fichier en plus des permissions de lecture habituelles. Cela a aussi pour effet que les scripts « netlogon » sont ignorés en silence s'ils n'ont pas ce bit activé.

	Note
	Cette section ne s'applique qu'aux personnes ayant manuellement modifié leur fichier /etc/initramfr-tools/initramfs.conf pour ne pas utiliser busybox.

Si vous avez à la fois busybox et cryptsetup installés et configuré initramfs pour ne pas utiliser busybox, alors votre système pourrait ne pas démarrer.

Veuillez vérifier la valeur de votre réglage de BUSYBOX dans /etc/initramfs-tools/initramfs.conf si ces deux paquets sont installés. Pour le moment, les contournements connus sont de désinstaller busybox ou d'utiliser le réglage BUSYBOX=y dans /etc/initramfs-tools/initramfs.conf.

	Avertissement
	Si vous avez dû faire une modification, n'oubliez pas de lancer update-initramfs -u pour mettre à jour votre initramfs. Autrement, vous pourriez malgré tout finir avec un démarrage cassé.

Veuillez consulter le bogue nº 783297 pour de plus amples informations.

	Note
	Cette section ne s'applique qu'aux systèmes sur lesquels un serveur mandataire squid est installé.

La configuration de squid a été modifiée de manière incompatible avec la précédente. En particulier, certains « helpers » de squid ont changé de nom. Si votre configuration utilise d'anciennes fonctionnalités ou d'anciens noms de « helpers », votre service squid pourrait échouer au démarrage après la mise à niveau.

Veuillez consulter les notes de publications de l'amont pour plus d'informations. En anglais :