"en quoi est-ce le rôle de systemd de faire resolver DNS"
De tous les reproches que l'on peut faire à systemd, je pense que c'est bien le moindre. La résolution de noms est devenue quelque chose de chaotique sous Linux. Si tu fais un gethostbyname("foo"), il faut regarder dans /etc/hosts, demander éventuellement à mDNS (avahi?), demander au serveur DNS local, etc... Le resolveur de la glibc tente d'avoir une architecture "ouverte" pour rajouter d'autres méthodes plus ou moins dinosauresques (telles que NIS ou WINS) et c'est en partie à cause de lui qu'il est peu recommandé / impossible de faire des binaires statiques sous Linux.
Le problème pour un dévelopeur c'est que tellement de couches ont été empilées que gethostbyname() devient dangereux à utiliser. Lorsque je codais encore (je suis vieux maintenant :), on a commencé à remarqué des problèmes de stabilité énorme dans notre programme multithreadé, pour réaliser que le resolveur WINS (installé rarement mais chez certains clients) n'était pas thread-safe. Ensuite on a du patcher à la volée la glibc pour interdire la lecture de /etc/hosts car on a aussi remarqué que dans un environment hautement multi-threadé, ouvrir le fichier et le lire bloquait notre programme (sans parler de la performance). Et difficile de diagnostiquer le problème—à la fin, gethostbyname() c'est un mini programme qui tourne dans le contexte de notre programme, avec ses allocations de mémoire, etc... Et il y a d'autres problèmes—notre programme fait énormément d'I/O réseau sur un grand nombre de sockets, je ne peux pas appeler select() (limite MAX_FD), je n'ai pas de garantie que gethostbyname() ne le fasse pas, je peux juste espérer que les développeurs de la glibc (et des modules dynamiques!) codent proprement et utilisent poll().
Du coup, il est 100 fois plus propre de modifier gethostbyname() pour envoyer un simple message à un resolveur local et d'attendre la réponse plutôt que d'allouer de la mémoire, ouvrir des fichiers et des sockets, etc... Et comme on ne veut absolument pas que le resolveur local soit en panne, autant le mettre dans systemd :)
Voilà, c'était mes 2 centimes.
(Disclaimer: je n'ai aucune action systemd et je ne gère aucun système le faisant tourner :)
[^] # Re: Quoi d’intéressant?
Posté par Renaud . En réponse au journal [Bookrmark] How to troll systemd in one blog post. Évalué à 10.
"en quoi est-ce le rôle de systemd de faire resolver DNS"
De tous les reproches que l'on peut faire à systemd, je pense que c'est bien le moindre. La résolution de noms est devenue quelque chose de chaotique sous Linux. Si tu fais un gethostbyname("foo"), il faut regarder dans /etc/hosts, demander éventuellement à mDNS (avahi?), demander au serveur DNS local, etc... Le resolveur de la glibc tente d'avoir une architecture "ouverte" pour rajouter d'autres méthodes plus ou moins dinosauresques (telles que NIS ou WINS) et c'est en partie à cause de lui qu'il est peu recommandé / impossible de faire des binaires statiques sous Linux.
Le problème pour un dévelopeur c'est que tellement de couches ont été empilées que gethostbyname() devient dangereux à utiliser. Lorsque je codais encore (je suis vieux maintenant :), on a commencé à remarqué des problèmes de stabilité énorme dans notre programme multithreadé, pour réaliser que le resolveur WINS (installé rarement mais chez certains clients) n'était pas thread-safe. Ensuite on a du patcher à la volée la glibc pour interdire la lecture de /etc/hosts car on a aussi remarqué que dans un environment hautement multi-threadé, ouvrir le fichier et le lire bloquait notre programme (sans parler de la performance). Et difficile de diagnostiquer le problème—à la fin, gethostbyname() c'est un mini programme qui tourne dans le contexte de notre programme, avec ses allocations de mémoire, etc... Et il y a d'autres problèmes—notre programme fait énormément d'I/O réseau sur un grand nombre de sockets, je ne peux pas appeler select() (limite MAX_FD), je n'ai pas de garantie que gethostbyname() ne le fasse pas, je peux juste espérer que les développeurs de la glibc (et des modules dynamiques!) codent proprement et utilisent poll().
Du coup, il est 100 fois plus propre de modifier gethostbyname() pour envoyer un simple message à un resolveur local et d'attendre la réponse plutôt que d'allouer de la mémoire, ouvrir des fichiers et des sockets, etc... Et comme on ne veut absolument pas que le resolveur local soit en panne, autant le mettre dans systemd :)
Voilà, c'était mes 2 centimes.
(Disclaimer: je n'ai aucune action systemd et je ne gère aucun système le faisant tourner :)