Migration Debian 11 vers Debian 12 (Reseau H.S - dhcp)

Bonjour,

Suite à une migration de Debian 11 vers 12, mon serveur DHCP ne fonctionne plus.
J’obtiens le message suivant :

Starting isc-dhcp-server (via systemctl): isc-dhcp-server.serviceJob for isc-dhcp-server.service failed because the control process exited with error code.
See "systemctl status isc-dhcp-server.service" and "journalctl -xeu isc-dhcp-server.service" for details.
 failed!
root@Monserveur:/etc/dhcp# journalctl -xeu isc-dhcp-server.service
juil. 10 15:10:53 Monserveur isc-dhcp-server[1677]: All rights reserved.
juil. 10 15:10:53 Monserveur isc-dhcp-server[1677]: For info, please visit https://www.isc.org/software/dhcp/
juil. 10 15:10:53 Monserveur dhcpd[1677]: Copyright 2004-2022 Internet Systems Consortium.
juil. 10 15:10:53 Monserveur dhcpd[1677]: All rights reserved.
juil. 10 15:10:53 Monserveur dhcpd[1677]: For info, please visit https://www.isc.org/software/dhcp/
juil. 10 15:10:53 Monserveur isc-dhcp-server[1677]: Can't open /etc/bind/local-xxxx-fr_rndc-key: Permission denied
juil. 10 15:10:53 Monserveur isc-dhcp-server[1677]: If you think you have received this message due to a bug rather
juil. 10 15:10:53 Monserveur isc-dhcp-server[1677]: than a configuration issue please read the section on submitting
juil. 10 15:10:53 Monserveur isc-dhcp-server[1677]: bugs on either our web page at www.isc.org or in the README file
juil. 10 15:10:53 Monserveur isc-dhcp-server[1677]: before submitting a bug.  These pages explain the proper
juil. 10 15:10:53 Monserveur isc-dhcp-server[1677]: process and the information we find helpful for debugging.
juil. 10 15:10:53 Monserveur isc-dhcp-server[1677]: exiting.
juil. 10 15:10:53 Monserveur dhcpd[1677]: Can't open /etc/bind/local-xxxx-fr_rndc-key: Permission denied
juil. 10 15:10:53 Monserveur dhcpd[1677]:
juil. 10 15:10:53 Monserveur systemd[1]: isc-dhcp-server.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit isc-dhcp-server.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
juil. 10 15:10:53 Monserveur dhcpd[1677]: If you think you have received this message due to a bug rather
juil. 10 15:10:53 Monserveur systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit isc-dhcp-server.service has entered the 'failed' state with result 'exit-code'.
juil. 10 15:10:53 Monserveur dhcpd[1677]: than a configuration issue please read the section on submitting
juil. 10 15:10:53 Monserveur systemd[1]: Failed to start isc-dhcp-server.service - LSB: DHCP server.
░░ Subject: L'unité (unit) isc-dhcp-server.service a échoué
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ L'unité (unit) isc-dhcp-server.service a échoué, avec le résultat failed.
juil. 10 15:10:53 Monserveur dhcpd[1677]: bugs on either our web page at www.isc.org or in the README file
juil. 10 15:10:53 Monserveur dhcpd[1677]: before submitting a bug.  These pages explain the proper
juil. 10 15:10:53 Monserveur dhcpd[1677]: process and the information we find helpful for debugging.
juil. 10 15:10:53 Monserveur dhcpd[1677]:
juil. 10 15:10:53 Monserveur dhcpd[1677]: exiting.

Le service isc-dhcp-server ne démarre plus, on dirait un souci de lecture de mon fichier /etc/bind/local-xxxx-fr_rndc-key.

Même en changeant les droits, ça ne change rien, je ne comprends pas.

Ce fichier est en include dans mon dhcpd.conf car il permet de charger le signature TSIG pour autoriser les transactions avec BIND.

Pouvez-vous m’aider ?

J’ai deux serveurs dhcp en load balancing en vrac suite aux mises à jour. J’ai restauré la sauvegarde sur le premier serveur. J’essaye de comprendre ce qui ne va pas sur le second histoire de pouvoir revenir sur une debian à jour.

Afin de compléter le message :

# named -v
BIND 9.18.16-1~deb12u1-Debian (Extended Support Version) <id:>

Merci d’avance pour votre aide.

Bonjour,

as-tu vérifié que la clef dans isc-dhcp-server est rigoureusement identiques à celle de bind?

Dans bind tu dois avoir ton fichier de clef en 644 et propriétaire root:bind.

En ce qui me concerne je fais toujours un symlink du fichier bind dans isc-dhcp-server:
ln -s ../bind/rndc.key rndc.key

Bonjour,

Merci pour ta réponse.
Mon fichier /etc/bind/local-xxxx-fr_rndc-key n’a jamais été identique au fichier /etc/bind/rndc.key.

En ce qui concerne les droits, j’ai -rw-r----- 1 root bind 167 que j’ai changé depuis en 777 pour tester -rwxrwxrwx 1 bind bind 167 sans succès.

La clef de ton DHCP doit être déclaré dans Bind sinon ca ne marche pas.
C’est d’ailleurs pour ça que je réutilise la clef bind dans dhcp.

Sinon il te faut ajouter ta clef dhcp dans la configuration de bind.

Quand aux droits et propriétés elles doivent être ceux de bind et pas de dhcp.

fait le symlink déjà pour tester tu verras bien.

Si ta clef n’a jamais été déclarée dans bind alors ca n’a jamais marché. Par contre peut etre dhcp arrivait-il a y accéder

Bonsoir,

je suis revenu à ma Debian version 11 en remettant une sauvegarde. Tout refonctionne. Mais j’aimerai quand même pouvoir migrer pour avoir une version à jour. Voici comment est configuré mon DHCP (en fait, j’ai deux DHCP et deux DNS), il y a un maitre et un esclave.
Au sujet de mon serveur esclave, j’ai un dossier /etc/bind avec un fichier : named.conf dans lequel j’ai ceci en autre :

include "/etc/bind/toto_rndc-key";

Dans named.conf.local, j’ai mes déclarations de zones avec une section controls

controls {
        inet 127.0.0.1 port 953 allow { 127.0.0.1; IP_SERVEUR; } keys {toto_rndc-key;};
};

Au redémarrage de bind9, mon serveur se synchronise avec les fichiers de déclarations IP du serveur maitre.

Au niveau DHCP, dans mon dhcpd.conf, j’ai

include "/etc/bind/toto_rndc-key";

N.B. Le fichier key avait les droits suivants :
-rw-r--r-- 1 root bind toto_rndc-key

Voilà, j’ai résumé le tout.

En migrant mes deux serveurs de Debian 11 à 12, les DHCP ne fonctionnent plus comme cité sur le premier message et le réseau ne fonctionne plus. Une idée ?

Merci d’avance.

Que dit ceci:
cat /etc/default/isc-dhcp-server
ls /sys/class/net/
ip a

N.B. Le fichier key avait les droits suivants :
-rw-r–r-- 1 root bind toto_rndc-key

Etait-ce correct ? Relatif à quelle doc ?

# cat /etc/default/isc-dhcp-server
# Defaults for isc-dhcp-server (sourced by /etc/init.d/isc-dhcp-server)

# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
DHCPDv4_CONF=/etc/dhcp/dhcpd.conf
#DHCPDv6_CONF=/etc/dhcp/dhcpd6.conf

# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
#DHCPDv4_PID=/var/run/dhcpd.pid
#DHCPDv6_PID=/var/run/dhcpd6.pid

# Additional options to start dhcpd with.
#       Don't use options -cf or -pf here; use DHCPD_CONF/ DHCPD_PID instead
#OPTIONS=""

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#       Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACESv4="ens192"
#INTERFACESv6="ens192"

ensuite

# ls /sys/class/net/
ens192  lo


~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:8a:76:f9 brd ff:ff:ff:ff:ff:ff
    altname enp11s0
    inet 192.168.200.39/23 brd 192.168.201.255 scope global dynamic ens192
       valid_lft 81881sec preferred_lft 81881sec
    inet6 fe80::250:56ff:fe8a:76f9/64 scope link
       valid_lft forever preferred_lft forever

Voilà, les commandes ont été lancées sur le serveur restauré.

Donc tout semble homogène pour Dedian 11, mais il reste à comparer à Debian 12 qui a peut-être une subtilité de différence.
J’avais un doute sur les droits ‹ root:bind › de toto_rndc-key. C’est peut-être et probablement correct, puisque ça marche dans Debian 11, mais ça ne m’enlève pas le doute, tant que je ne vois de doc pour le confirmer.
Ça va ête compliqué d’investiguer Debian 12 dans une installation Debian 11, le sujet n’étant déjà pas simple…

non du fait des droits, ça va poser des problèmes car dhcp ne tourne pas avec le user Bind.
Donc il faut faut soit copier le fichier de clef de bind dans le répertoire DHCP, soit faire, comme je te l’ai déjà dit, un symlink dans le répertoire DHCP du fichier Bind. Et il faut bien sur mettre les droits idoines sur le fichier dans le cas du fichier.

1 J'aime

Oui ce sont droit normaux du fichier dans Bind tel qu’il est installé par Bind à la première installation.

Merci à vous pour vos messages.
@Zargos je n’avais pas bien lu ta recommandation, désolé. J’ai donc remigré sur Debian 12 un premier serveur (l’esclave). J’ai fait un lien symbolique de ma clé comme préconisé :

ln -s /etc/bind/xxx_rndc-key /etc/dhcp/xxx_rndc

Ce qui donne :

# ll /etc/dhcp/xxx_rndc-key
lrwxrwxrwx 1 root root 44 11 juil. 10:44 /etc/dhcp/xxx_rndc-key -> /etc/bind/xxx_rndc-key

Dans mon fichier dhcpd.conf, j’ai modifié mon include en :

# Charger la signature (TSIG) pour pouvoir autoriser les transactions avec BIND
include "/etc/dhcp/xxx_rndc-key";

J’avais toujours les mêmes messages d’erreurs de droits

Can't open /etc/dhcp/xxx_rndc-key: Permission denied

Je ne sais pas comment changer les droits sur un lien symbolique, même avec un chown -h et chmod, rien à faire. J’ai finalement opté pour une copie du fichier et tout semble fonctionner.
Je vais donc procéder de la sorte pour l’autre serveur avant la migration.

Merci à vous pour vos aides.

Juste par curiosité @Zargos , tu t’y es pris comment pour faire fonctionner avec un lien symbolique, quelles sont tes commandes ?

1 J'aime

IL faut que je regarde ma chine de tests :slight_smile: et je te dit ça.
Ah, il faut que j’upgrade vers Bookworm d’abord :slight_smile:

J’ai trouvé, c’est un problème avec AppArmor.
Quand il est en enforce ca bloque le démarrage de dhcpd.
J’ai fait un aa-complain /usr/sbin/dhcpd et ça marche.

Il y a surement une modification à faire dans le module apparmor pour qu’on puisse passer en enforce, mais je n’ai aps encore trouvé lequel :slight_smile:

J’ai finalement trouvé,
les clef pour le DDNS doivent être mises dans /etc/dhcp/ddns-keys/.
Voici l’entrée dans le fichier /etc/apparmor.d/usr.sbin.dhcpd:

  # access to bind9 keys for dynamic update
  # It's expected that users will generate one key per zone and have it
  # stored in both /etc/bind9 (for bind to access) and /etc/dhcp/ddns-keys
  # (for dhcpd to access).
  /etc/dhcp/ddns-keys/** r,
1 J'aime

Merci, je ne connaissais pas apparmod :grinning:. C’est toujours intéressant à savoir.
N.B. Deuxième serveur à jour.

Je vais probablement faire un autre sujet pour les soucis mysql suite à la migration (je cherche quand même un peu avant).

1 J'aime

pense a mettre le flag de solution :wink:

Pas terrible pour une nouvelle installation, car le jour X ou tu auras besoin de modifier ton système, tu aurais 2 fichiers identiques aux droit près dans ton système.

lrwxrwxrwx 1 root root 44 11 juil. 10:44 /etc/dhcp/xxx_rndc-key → /etc/bind/xxx_rndc-key
Can’t open /etc/dhcp/xxx_rndc-key: Permission denied

Je ne vois pas où est le problème en laissant le lien sur le fichier, et en éditant les droits du fichier unique:

chown root:bind /etc/bind/xxx_rndc-key

Le lien n’est qu’un pointeur qui suivra les droits du fichier pointé.
Enfin, c’est toi qui vois.

ls -l /etc/bind/xxx_rndc-key
ls -l /etc/dhcp/xxx_rndc-key

Je veux bien te croire, mais en mettant en lien symbolique, même avec des droits 777 sur le fichier sur lequel pointe le lien, le serveur ne démarre pas et j’ai le message Permission denied.

C’est pour cela que j’ai fini par opter pour le deuxième fichier.

En fait tu ne peux pas utiliser de lien, il faut copier physiquement le fichier.
AppArmor empêche l’utilisation du lien. à moins de vouloir bidouiller les fichiers de configuration apparmor, qu’il vaut mieux éviter.

Effectivement, ça pourrait correspondre au mode ‹ enforce › d’apparmor.
Ça devient une zone bien obscure.

# /usr/sbin/aa-status
 apparmor module is loaded.
 16 profiles are loaded.
 16 profiles are in enforce mode.
   /usr/bin/man
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/cups/backend/cups-pdf
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/haveged
   /{,usr/}sbin/dhclient
   lsb_release
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
   tcpdump
   unbound

si ça aide :
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.fr.html#deprecated-components

  • The isc-dhcp suite has been deprecated by the ISC. The Debian Wiki has a list of alternative implementations, see DHCP Client and DHCP Server pages for the latest. If you are using NetworkManager or systemd-networkd , you can safely remove the isc-dhcp-client package as they both ship their own implementation. If you are using the ifupdown package, you can experiment with udhcpc as a replacement. The ISC recommends the Kea package as a replacement for DHCP servers. The security team will support the isc-dhcp package during the bookworm lifetime, but the package will likely be unsupported in the next stable release, see bug #1035972 (isc-dhcp EOL’ed) for more details.