Comme à chaque passage à une nouvelle version de Debian GNU/Linux, voici un résumé de tout ce qui a foiré ou changé quand je suis passé à Stretch.
Désormais, les interfaces réseau portent des noms dit cohérents. Soit tu mets à jour ton fichiers interfaces, soit tu désactives ce nouveau nommage. Attention si tu bosses sur des machines distantes en adressage static : ne rebootes pas avant d'avoir fait une modif' ;) .
Sur une seule de mes machines, celle équipée d'aspell (pour Roundcube via php-pspell), le message suivant s'est affiché durant la mise à jour :
Base de données de configuration probablement corrompue
Le réglage pour « dictionaries-common/default-ispell» est manquant mais des paquets fournissant des candidats pour ce réglage sont installés : « ifrench-gut ».
Cela peut être dû à une corruption de la base de données de configuration (« debconf »). Veuillez consulter le fichier (non traduit en français) /usr/share/doc/dictionaries-common/README.problems au chapitre « Debconf database corruption ». │
Dans cette situation, il est possible d'exécuter la commande « /usr/share/debconf/fix_db.pl » pour remettre la base de données de configuration dans un état cohérent.
Il est probable que certaines questions seront alors posées afin de replacer le système de gestion des dictionnaires dans un état (temporairement) opérationnel.
À la fin de la mise à jour, j'ai exécuté /usr/share/debconf/fix_db.pl avec succès puis j'ai vérifié : les paquets ispell et ifrench-gut ne sont pas installés… Erreur transitoire ?
Les paramètres « RSAAuthentication » et « RhostsRSAAuthentication » sont dépréciés d'où un message s'affiche dans le log.
Postfix passe en version 3.X. Elle apporte un filet de sécurité qui prévient, dans le log, des réglages implicites qui ont changé. Exemple : dans cette nouvelle version, les diffférents modules (nommés services) de Postfix ne sont plus exécutés dans un chroot par défaut. Dans mon fichier master.cf, dans la colonne « chroot », il y a la valeur implicite « - » qui signifiait « yes » avant et « no » maintenant donc Postfix émet un avertissement dans le log : /etc/postfix/master.cf: line 36: using backwards-compatible default setting chroot=y
pour chaque service configuré.
Comme je suis certain de vouloir chrooter les services Postif (car ça a toujours bien fonctionné ainsi…), je mets toute la colonne « chroot » à « y » à l'exception des services local, pipe, spawn, virtual et proxymap puis je redémarre Postfix. Notons qu'une commande de type postconf -F <nom_service>/<type>/chroot=y
pour chaque service produira le même résuultat (mise à « y » dans master.cf).
Dans la configuration de tous mes services réseau, je désactive explicitement SSLv2 et SSLv3. Avec Dovecot, cela donne ssl_protocols = !SSLv2 !SSLv3
.
Or, les devs OpenSSL ont (enfin !) totalement désactivé SSLv2 entre la version 1.0.2h et 1.1.0 (voir /usr/share/doc/openssl/changelog.gz). Ainsi, le symbole « SSLv2 » n'existe plus, donc Dovecot retourne l'erreur : imap-login: Fatal: Invalid ssl_protocols setting: Unknown protocol 'SSLv2'
. Notons que d'autres logiciel, comme Postfix, ne remontent pas d'erreur quand on interdit l'usage de SSLv2 dans leur config'. J'imagine que cette diffférence provient de la manière d'appeler les fonctions de la lib OpenSSL…
La correction est simple : dans la conf' de Dovecot, je n'utilise plus que : ssl_protocols = !SSLv3
.
Après la mise à jour, le menu de l'interface web (« connexion », « assistance/documentation », « chercher une liste/index des listes », etc.) n'était plus cliquable : dès que j'essayais de cliquer sur un sous-item du menu, pouf, le menu se ferme. Idem pour la connexion : impossible de saisir mon identifiant et mon mot de passe.
La raison est que j'utilise une configuration Apache httpd un peu plus contraignante que celle fournie par défaut avec Sympa (voir /etc/apache2/conf-available/sympa.conf ). Notamment, dans le dossier /var/lib/sympa/static_content, j'autorise le suivi des liens symboliques uniquement si le propriétaire du lien est le même que la destination du lien (« +SymLinksIfOwnerMatch »). Or, dans dans /var/lib/sympa/static_content, on trouve, par exemple external/jquery* qui est un lien symbolique root:root qui pointe vers un fichier sympa:sympa. Apache httpd ne le suivra donc pas. Or, en 2017, il faut obligatoirement du JS pour faire fonctionner un menu… Ceci explique cela.
Changer le propriétaire du lien ne résistera pas à une prochaine mise à jour. Il vaut donc mieux supprimer « +SymLinksIfOwnerMatch » des « Options » du dossier.
Sympa dispose de plusieurs paramètres pour adapter la langue. « lang » dans la conf' permet de changer la langue par défaut des mails envoyés automatiquement. Chaque utilisateur peut également configurer sa langue dans ses préférences dans l'interface web.
Quant à la langue par défaut de l'interface web (quand on ne s'authentifie pas), ça reste un mystère pour moi… Elle s'adapte à la langue annoncée par le navigateur web du visiteur grâce à l'entête HTTP « Accept-Language ». Avec mon Firefox packagé dans Debian configuré en Français, l'interface reste en anglais. Pourtant, Firefox annonce bien FR-fr puis en-US puis en… En revanche, si dans les préférences Firefox, Contenu, Langues, je supprime toutes les langues sauf le français, l'interface web de Sympa s'affiche en français. Avec curl, qui n'envoie pas l'entête « Accept-Language », l'interface est en français… Est-ce un bug de Firefox qui annonce mal la priorité de chaque langue supportée ou un bug de Sympa qui interprête mal les différente langues supportées par un navigateur web ? Aucune idée…
PHP 7 est installé durant la mise à jour, mais il n'est pas forcément activé… et comme la sécurité de PHP 5 n'est plus prise en charge dans cette version de Debian, je pense qu'il vaut mieux cesser de l'utiliser et passer en 7.0.
D'abord, il faudra porter ta configuration de /etc/php5 vers /etc/php. Par exemple, dans mes php.ini, je modifie toujours les valeurs des paramètres disable_functions, openssl.cafile, memory_limit, html_errors, post_max_size, date.timezone, session.save_path (pour pointer sur un RAMdisk / tmpfs). Elles ne sont pas importées automatiquement dans la nouvelle configuration.
Il faut désactiver PHP 5 avec a2dismod php5
puis virer les paquets php5-* et libapache2-mod-php5 puis vérifier que libapache2-mod-php7.0 et les modules php-* (oui, on note l'apparition de ces metapaquets) correspndant aux php5-* désactivés sont bien installés. Enfin, il faut activer PHP 7 avec a2enmod php7.0 && systemctl restart apache2
.
Il faut vérifier que tous tes sites web fonctionnent. S'il n'y a pas de doute à avoir avec les logiciels packagés dans Debian (c'est tout l'intérêt d'une distribution), il n'en va pas de même avec les extensions ni avec les logiciels installés en dehors du gestionnaire de paquets. Exemple : j'utilisais l'extension WordPress ContentOverSSL. Celle-ci utilise la fonction PHP ereg
qui a été supprimée dans PHP 7.0. Si tes logs sont bien fichus, tu devrais y trouver les fonctions problèmatiques, genre PHP Fatal error: Uncaught Error: Call to undefined function ereg() in </chemin/vers/fichier.php>
.
Attention, un chroot Apache httpd incomplet ne pardonne plus avec PHP 7.0. En effet, mon chroot ne contenait pas /dev/random et /dev/urandom et un file_get_contents('https://shaarli.guiguishow.info');
sortait en erreur :
PHP Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
\nerror:24064064:random number generator:RAND_bytes:PRNG not seeded in /var/www/shaarli/test.php on line 2
PHP Warning: file_get_contents(): Failed to enable crypto in /var/www/shaarli/test.php on line 2
PHP Warning: file_get_contents(https://shaarli.guiguishow.info): failed to open stream: operation failed in /var/www/shaarli/test.php on line 2
Pour réparer :
mkdir $chrootdir/dev
mknod /var/apache/chroot/dev/random c 1 8
mknod /var/apache/chroot/dev/urandom c 1 9
systemctl restart apache2
La mise à jour et le passage à MariaDB se passe bien… sauf si l'on utilise un chroot.
En premier lieu, j'ai eu une erreur relative à /usr/share/mysql/errmsg.sys
. J'y suis habitué : il faut copier ce fichier dans le chroot.
Ensuite, j'ai eu l'erreur InnoDB: ./ib_logfile0 can't be opened in read-write mode
. Le web conseille de supprimer ib_logfile0 et ib_logfile1.
ENfin, j'ai eu les erreurs InnoDB: Could not find a valid tablespace file for 'mysql/gtid_slave_pos'.
, InnoDB: Could not find a valid tablespace file for 'mysql/innodb_index_stats'.
, InnoDB: Could not find a valid tablespace file for 'mysql/innodb_table_stats'.
.
J'ai essayé de terminer le script /usr/scripts/scripts/mysql_install_db, mais il était impossible de lancer MySQL, même avec les fichiers ib_logfile* remis à leur place et le mode safe…
Dès l'origine, j'ai configuré salement ce chroot, avec des liens symboliques (et d'autres choses qu'il ne faut pas faire avec un chroot) afin de contenter MySQL. Il m'apparaît, plus de 5 ans après, que le fonctionnement dans un chroot n'est pas vraiment bien intégré dans MySQL en comparaison d'Apache ou de Postfix (la copie du fichier errmsg.sys en est une illustration). Je pense que ce chroot m'apporte plus d'ennuis que de sécurité. Donc, j'ai décidé de le supprimer. J'ai donc déinstallé MySQL (en répondant non à la question "faut-il supprimer l'ensemble des bases de données ?"), j'ai viré tout ce qui est relatif à MySQL de mon arborescence, à l'exception de /var/lib/mysql. J'ai installé MySQL et… ça a fonctionné. \o/
La nuit suivant cette ré-installation de MySQL, logrotate a terminé en erreur :
/etc/cron.daily/logrotate:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'
error: error running shared postrotate script for '/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/error.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1
La solution se trouve ici : il faut saisir le mot de passe de l'utilisateur de la base de données « debian-sys-maint » dans /etc/mysql/debian.cnf. Si tu ne le connais plus, connectes-toi en root à la base de données puis change-le avec SET PASSWORD FOR 'debian-sys-maint'@'localhost' = PASSWORD('<nouveau_mdp>');
.
Durant l'installation, dbconfig produisait des erreurs du genre "je n'arrive pas à me connecter à la base de données" mais en beaucoup moins trivial (la base de données fonctionnait et le message d'erreur était plus cryptique que ce que j'en rapporte ici). J'ai décidé de quitter dbconfig sans rien configurer. Une fois la mise à jour terminée, roundcube ne savait plus pour quels domaines il devait répondre… Je l'ai reconfiguré avec dpkg-reconfigure roundcube-core
et tout est devenu OK.
Dans mes logs, OpenDKIM s'écrivait milter socket must be specified
tandis que systemd s'écrivait opendkim.service: PID file /var/run/opendkim/opendkim.pid not readable (yet?) after start: No such file or directory
Dans Stretch, OpenDKIM abandonne son script sysvinit et utilise une unit systemd. /etc/default/opendkim n'est donc plus lu. Il faut donc indiquer la socket directement dans la configuration d'OpenDKIM (/etc/opendkim.conf).
De même, systemd s'attend à obtenir le PID d'OpenDKIM dans le fichier /var/run/opendkim/opendkim.pid . Il faut donc ajouter PidFile /var/run/opendkim/opendkim.pid
dans /etc/opendkim.conf.
Dans le modèle de configuration qui nous est proposé, remarquons la directive « UserID » qui permet de ne plus exécuter OpenDKIM en root.
OpenDNSSEC passe de sa version 1.4.6 à sa version 2.0.4 donc, forcément, ça implique une importante migration. Migration assez mal préparée dans le paquet Debian puisque le message nous indique « The enforcer does require a full migration, as the internal database has been completely revised. See the upstream documentation in the /usr/share/opendnssec/1.4-2.0_db_convert/README.md » alors que le dossier /usr/share/opendnssec/1.4-2.0_db_convert/ est vide et les fichiers nécessaires sont éparpillés dans /usr/share/opendnssec… … …
Bref, voici comment j'ai mis à jour :
echo 'SELECT zones.name FROM dnsseckeys JOIN zones on zones.id = dnsseckeys.zone_id WHERE dnsseckeys.keytype = 257 AND dnsseckeys.active IS NULL AND dnsseckeys.zone_id NOT IN (SELECT dnsseckeys.zone_id FROM dnsseckeys WHERE dnsseckeys.keytype = 257 AND dnsseckeys.state = 4);' | slite3 /var/lib/opendnssec/kasp.db
. Si c'est le cas, la doc' d'OpenDNSSEC conseille d'attendre que le rollover soit terminé pour mettre à jour ;ods-ksmutil key list --verbose
;On arrête toute la machinerie et on l'empêche de démarrer durant la mise à jour :
systemctl stop opendnssec-enforcer.service
systemctl stop opendnssec-signer.service
systemctl disable opendnssec-enforcer.service
systemctl disable opendnssec-signer.service
systemctl mask opendnssec-enforcer.service
systemctl mask opendnssec-signer.service
systemctl mask opendnssec-signerd.service
cat /usr/share/opendnssec/migrate_1_4_8.sqlite3 | sqlite3 /var/lib/opendnssec/kasp.db
;Mets à jour le contenu de la base de données d'OpenDNSSEC de la version 1.X à 2.X :
cd /usr/share/opendnssec/
./convert_sqlite -i /var/lib/opendnssec/kasp.db -o /var/lib/opendnssec/kasp.db.new
mv /var/lib/opendnssec/kasp.db.new /var/lib/opendnssec/kasp.db
ods-migrate
;cp /etc/opendnssec/zonelist.xml /var/lib/opendnssec/enforcer/zones.xml
;Démarre l'enforcer et vérifie que tes clés sont toujours là (à l'aide des KeyTags mis de côté au début ;) ) :
ods-enforcer start
ods-enforcer key list --verbose
Si tout est OK, démarre le signer et tente de signer une modification de ta zone DNS :
ods-signer start
<Fais une modification de ton fichier de zone ici>
ods-signer sign <nom_zone>
<Vérifie que ta modification est effective>
Si tout est OK, on re-active le lancement d'OpenDNSSEC au boot :
ods-signer stop
ods-enforcer stop
systemctl unmask opendnssec-signerd.service
systemctl unmask opendnssec-signer.service
systemctl unmask opendnssec-enforcer.service
systemctl enable opendnssec-enforcer.service
systemctl enable opendnssec-signerd.service
systemctl start opendnssec-enforcer.service
systemctl start opendnssec-signer.service
conf.xml :
kasp.xml :
SoftHSM passe lui aussi d'une version 1.X à 2.X, donc une migration nous attend. Notons que cette migration n'est pas obligatoire à mon sens, car le paquet softhsm version 1.X est toujours maintenu dans cette version de Debian.
Voici comment j'ai procédé :
mkdir /var/lib/softhsm/tokens
;softhsm2-util --init-token --slot 0 --label OpenDNSSEC
;softhsm2-migrate --db /var/lib/softhsm/slot0.db --token OpenDNSSEC
;<Module>/usr/lib/softhsm/libsofthsm.so</Module>
devient <Module>/usr/lib/softhsm/libsofthsm2.so</Module>
. Change le PIN si t'as configuré un nouveau USER PIN sur le coffre-fort version 2 ;apt-get autoremove --purge softhsm-common softhsm
.Coupe tout OpenDNSSEC et empêche-le de démarrer automatiquement durant le rollback :
systemctl stop opendnssec-enforcer.service
systemctl stop opendnssec-signer.service
systemctl disable opendnssec-enforcer.service
systemctl disable opendnssec-signer.service
systemctl mask opendnssec-enforcer.service
systemctl mask opendnssec-signer.service
systemctl mask opendnssec-signerd.service
apt-get install opendnssec=1:1.4.6-6 softhsm=1.3.7-2+deb8u1 opendnssec-enforcer-sqlite3=1:1.4.6-6 opendnssec-signer=1:1.4.6-6 opendnssec-common=1:1.4.6-6 libhsm-bin=1:1.4.6-6 opendnssec-enforcer=1:1.4.6-6 libsofthsm=1.3.7-2+deb8u1 softhsm-common=1.3.7-2+deb8u1
;Le bug que je rencontrais lorsque je spécifiais des suites de chiffrement PFS à utiliser lors des connexions c2s (client to server) a disparu.
De même, cette version autorise enfin des dhparam > 1024 (directives « dhfile » et « s2s_dhfile »).
J'ai remarqué de nombreux changements entre ma config' et celle qui est proposée par le paquet. Exemples :
max_user_sessions:
all: 10
devient :
max_user_sessions: 10
max_user_offline_messages:
admin: 5000
all: 100
devient :
max_user_offline_messages:
- 5000: admin
- 100
Conclusion : j'ai décidé de ne pas avoir une conf' passoire et/ou une conf' qui peut se casser d'un rien donc j'ai accepté la conf' proposée et je l'ai adaptée à mes besoins.
Les applets Java prennent enfin en charge TLS version 1.2. Utile pour les consoles à distance des BMC (même si Dell propose de l'HTML 5 depuis iDRAC 8).
Il est désormais à nouveau possible de négocier la version de TLS utilisée. Cela permettra à court terme de forcer l'usage de TLS 1.2 / TLS 1.1 sans avoir à modifier la conf' des clients…
On peut enfin activer qname minimisation, ce qui est une bonne nouvelle pour la vie privée.
On peut enfin spécifier des dhparam personnalisés.