GuiGui's Show

Il s'en passe des choses dans le dépôt apt principal de Debian ces jours-ci.

Wheezy a été supprimée du dépôt principal à la fin de la semaine dernière (semaine 12). Elle est désormais disponible uniquement dans les archives (archive.debian.org).

Hier / aujourd'hui, tous les bouts de jessie non couverts par la LTS (les architectures autres que i386, amd64, armel et armhf, jessie-updates et jessie-backports) ont été supprimés du dépôt principal. Les backports sont disponibles dans les archives.

Du coup, j'affine ma compréhension du cycle de vie de Debian :

• Une nouvelle version stable est publiée. Elle sera prise en charge de manière standard pendant 3 ans environ. Exemple : stretch a été publiée le 17 juin 2017 ;
  
  
• Pendant un an, la sécurité de la version stable précédente continue d'être assurée par l'équipe debian-security. L'idée est de laisser le temps aux adminsys de migrer vers la nouvelle version stable. Exemple : la sécurité de jessie (précédente version stable avec stretch) a été assurée par debian-security jusqu'en juin 2018 ;
  
  
• Ensuite, une sous-équipe de debian-security publie et maintient une LTS pendant 2 ans environ (donc la sécurité d'un système Debian est environ assurée pendant 5 ans). Depuis wheezy, il n'y a plus de dépôt séparé. Ainsi, pour jessie, les lignes suivantes dans un sources.list restent correctes : « http://deb.debian.org/debian/ jessie main contrib non-free \ deb http://security.debian.org/ jessie/updates main contrib non-free ». Notons que « http://deb.debian.org/debian/ jessie-updates main contrib non-free » est incorrecte. Dès la sortie de la LTS, on peut déjà retirer les distributions « -updates » et « -backports » de nos sources.list afin de s'éviter des surprises plus tard. Exemple : le support LTS de jessie a commencé le 17 juin 2018 et devrait s'achever mi-2020 ;
  
  
• À la fin de la LTS, la distribution est déplacée dans les archives puis supprimée du dépôt principal et du dépôt sécurité. Cela a l'air d'être le boxon : je n'ai pas trouvé le délai précis entre la fin de la LTS et le nettoyage effectif. La prise en charge de wheezy a pris fin en juin 2018. La distribution a été retirée du dépôt principal durant la 3e semaine de mars 2019 et elle n'est toujours pas retirée du dépôt sécurité (ÉDIT DU 29/04/2019 À 10H30 : c'est désormais le cas, un mois plus tard. FIN DE L'ÉDIT.). Même chose pour les distributions « -backports » et « -updates » : pas d'information disponible, mais celles de jessie ont été supprimées durant la dernière semaine de mars 2019 alors que cela semble être planifié depuis longtemps. Notons que les fichiers descriptifs dans le dépôt d'archivage vont expirer. Il faudra utiliser l'option apt « Acquire::Check-Valid-Until false; ».

Nous avons un serveur LDAP OpenLDAP. Nous constatons qu'il cesse parfois de répondre aux requêtes.

Regardons le journal (par défaut, c'est rangé dans /var/log/syslog, mais ici, nous rangeons dans un fichier distinct) :

slapd[16769]: warning: cannot open /etc/hosts.allow: Too many open files
slapd[16769]: warning: cannot open /etc/hosts.deny: Too many open files
[…]
slapd[16769]: daemon: accept(8) failed errno=24 (Too many open files)

Trop de fichiers ouverts amènent à ne plus accepter les connexions entrantes (accept() est un appel système permettant… d'accepter une connexion entrante).

Pourtant, OpenLDAP utilise seulement deux fichiers dans /var/lib/ldap pour stocker et verrouiller les données… Comment peut-il dépasser une quelconque limite ? Regardons le nombre et la nature des fichiers ouverts par slapd (16769 est l'identifiant du processus slapd) :

$ ls -lh /proc/16769/fd | wc -l
988

$ ls -lh /proc/16769/fd
[…]
lrwx------ 1 root root 64 Mar 26 18:36 95 -> socket:[21061503]
lrwx------ 1 root root 64 Mar 26 18:36 97 -> socket:[21061505]
lrwx------ 1 root root 64 Mar 26 18:36 98 -> socket:[21119854]
lrwx------ 1 root root 64 Mar 26 18:36 99 -> socket:[21119861]
[…]

Hum, des sockets… Donc un grand nombre de fichiers ouverts s'explique par un "grand" nombres de connexions persistantes établies par nos utilisateurs.

Creusons avec ss (ss -tapn | grep -E ":(389|636)" | grep -v 'LISTEN' | awk '{print $5;}' | cut -d ':' -f 1 | sort | uniq -c, par exemple) : très peu de connexions en attente de fermeture, les connexions sont réparties donc ce n'est pas un serveur qui s'est emballé. Un grand nombre de connexions n'est pas étonnant vu les différents éléments susceptibles de les déclencher (site web, authentification RADIUS, authentification GNU/linux, mapping UID/GID sur les montages NFS/CIFS par les machines GNU/Linux, etc.).

À combien est positionnée la limite du nombre de fichiers ouverts pour le processus slapd ? (16769 est l'identifiant du processus)

$ grep -i "open files" /proc/16769/limits 
Max open files            1024                 4096                 files

Ha, oui, nous en sommes vraiment très proche de la limite soft…

À partir de là, nous avons plusieurs possibilités dont l'augmentation de la limite ou réduire le timeout après inactivité TCP.

Par simplicité (je n'ai pas vraiment envie de tuner mon sous-système TCP pour un service si banal), j'ai choisi la première option.

Changer ce genre de limite a toujours été une plaie. /etc/security/limits.conf ne fonctionne pas, et, en général, on se contente d'utiliser la commande ulimit dans le script d'init.

Systemd permet de positionner plus facilement ce genre de limites :

• mkdir /etc/systemd/system/slapd.service.d/
  
  

• Dans /etc/systemd/system/slapd.service.d/override.conf, saisir :

  [Service]
  LimitNOFILE=2048

  
  

• systemctl daemon-reload
  
  
• systemctl restart slapd
  
  

• grep -i "open files" /proc/27079/limits

  Max open files            2048                 2048                 files

Notes :

• La création du fichier de surcharge peut être simplifiée en utilisant simplement la commande systemctl edit slapd ;
  
  
• La surcharge fonctionne alors que le paquet Debian OpenLDAP ne livre pas d'unit systemd pour slapd, mais un script sysVinit ;
  
  
• On peut tester la limite avec une boucle shell + telnet (qui permet d'obtenir des connexions qui durent dans le temps, contrairement aux outils de manipulation LDAP comme ldapsearch). Exemple : for i in $(seq 1 500); do telnet ldap.exemple 389 & done. Pour arrêter les connexions : killall -9 telnet.

Quand la fiction satirique égale la réalité, ça fait flipper.

:D

:D

:DDDD