Journal ApacheCheck, le retour (entre autres)

Posté par xulops (site web personnel) le 04 septembre 2021 à 19:09. Licence CC By‑SA.

Étiquettes :

sept.

2021

Apache/Nginx Check

J’avais présenté ici le script ApacheCheck lors de sa première release, un script PHP qui analyse la configuration d’un serveur Apache et ses paramètres d’exécution, tels que consommation mémoire, usage CPU et accès disque.

Depuis les versions se sont enchaînées, au gré de mes idées et des retours que j’ai pu avoir ici ou là. Voici donc aujourd’hui la version 2.0, qui intègre toutes les améliorations successives, et, pour justifier ce changement de version majeur, intègre la prise en compte de Nginx.

Quoi ? Si le script analyse aussi la configuration de Nginx, pourquoi s’appelle-t-il encore ApacheCheck ? C’est une bonne question !
En fait, je ne suis pas contre changer le nom, mais encore faut-il en trouver un qui corresponde à la finalité du code. J’ai bien mentalement jonglé avec ApacheNginxCheck (dans le genre impossible à taper sans choper une luxation du petit doigt), ou encore LAEMPCheck (le _ pouvant signifier A ou E, car oui, avec Nginx, c’est un serveur LEMP, le E venant de EngineX, le nom sous-entendu de Nginx), mais rien de vraiment convainquant n’en est ressorti. Donc si quelqu’un a une idée lumineuse… en attendant il garde son nom d’origine.

De toute façon, la partie Nginx du script est encore assez expérimentale. Si un Apache en fonctionnement n’est déjà pas un grand bavard (sans module server-status ou mod-info), c’est encore pire pour Nginx pour lequel le nombre de processus est fixe et lancé dès le départ avec un nombre important de connexions autorisées par processus. La documentation de Nginx n’est malheureusement pas aussi mature que celle d’Apache. Bref, c’est jeune, c’est expérimental, ~~c’est bon, mangez-en~~… et les retours d’expériences sont les bienvenus.

LatencyCheck

J’en profite de la rédaction de ce journal pour annoncer la sortie d’un autre script PHP : LatencyCheck
L’idée vient de ce post sur le forum LinuxFr. Le but est de surveiller la latence d’une ou plusieurs IP, en pouvant choisir son intervalle de mesure, le nombre total de mesure, la méthode de mesure, le port, la sortie dans un fichier…
Ca ne sert peut-être à rien, mais c’est disponible et libre (Licence Apache 2.0).

# test root

Posté par Yann 'Ze' Richard (site web personnel) le 05 septembre 2021 à 13:16. Évalué à 5.
```
// root ?
$user = getenv("USER");
if ($user != "root") {
    display("[!!] Fatal error : this script must run as root user");
    exit();
}
```
Ce test ne fonctionne pas quand on utilise un utilisateur ayant un uid égal à 0 mais qui n'est pas nommé "root". Le meilleur test ici serait de tester la valeur de l'uid (via posix_geteuid() )
- [^] # Re: test root
  
  Posté par xulops (site web personnel) le 05 septembre 2021 à 15:00. Évalué à 2.
  Merci pour ce retour.
  
  En fait, je n'ai pas utilisé les fonctions PHP posix_… suite à ce commentaire d'Andy sur php.net. Ce commentaire date de 11 ans, mais je n'ai aucun moyen de savoir si maintenant toutes les distribs compilent PHP avec ces fonctions, donc dans le doute je fais sans.
  
  Mais ce n'est pas grave, pas besoin des fonctions PHP posix_… pour récupérer l'uid d'un user, il y a déjà la fonction get_user_uid dans le script qui fait ça, donc j'ai modifié le script (v2.0.1) de la façon suivante pour tester si l'uid est égal à 0 au lieu du nom du user :
```
// root ?
$user = getenv("USER");
$user_uid = get_user_uid($user);
if ($user_uid != 0) {
    display("[!!] Fatal error : this script must run as root user");
    exit();
}
```
  - [^] # Re: test root
    
    Posté par Gil Cot ✔ (site web personnel, Mastodon) le 06 septembre 2021 à 04:25. Évalué à 2.
    
    Ça marche avec sudo ça ?
    
    “It is seldom that liberty of any kind is lost all at once.” ― David Hume
    - [^] # Re: test root
      
      Posté par xulops (site web personnel) le 06 septembre 2021 à 04:50. Évalué à 1.
      
      Oui, c'est moi ça marche® avec sudo.
      C'est peut-être la différence entre getenv("USER") et getenv("LOGNAME").
      - [^] # Re: test root
        
        Posté par Gil Cot ✔ (site web personnel, Mastodon) le 06 septembre 2021 à 05:43. Évalué à 2.
        
        OK, bon à savoir (je ne me souvenais plus laquelle des variables d'environnement ne changeait pas, et puis je n'étais pas sûr de ce que récupérait exactement PHP)
        
        “It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Nom du script

Posté par srb (site web personnel) le 05 septembre 2021 à 17:44. Évalué à 10.

Quitte à renommer, il me semble préférable d'utiliser un nom plus générique (« webservercheck » ?). Si jamais d'autres serveurs sont ajoutés dans le futur, il n'y aura pas besoin de renommer à nouveau.
- [^] # Re: Nom du script
  
  Posté par Christophe "CHiPs" PETIT (site web personnel) le 06 septembre 2021 à 11:26. Évalué à 1.
  
  httpdCheck ?
  - [^] # Re: Nom du script
    
    Posté par xulops (site web personnel) le 06 septembre 2021 à 13:29. Évalué à 1.
    
    httpdcheck est effectivement parlant.
    Mais si on laisse entendre que ça supporte tous les web servers, faudrait ajouter le support de :
    - Lighttpd
    - caddy
    - OpenLiteSpeed
    - Hiawatha
    - uhttpd
    - H2O
    - Cherokee
    - …
    
    J'ai du pain sur la planche ! Bon en fait non, je ne vais pas me lancer là-dedans, hein.
    
    Et si je faisais un genre de lien symbolique ? Le script pourrait ainsi avoir deux noms apachecheck et nginxcheck, peu importe celui qu'on lance puisque c'est le même et qu'il découvre lui-même lequel de Apache ou Nginx écoute sur le port indiqué (par defaut le port 80).
    - [^] # Re: Nom du script
      
      Posté par Gil Cot ✔ (site web personnel, Mastodon) le 06 septembre 2021 à 14:29. Évalué à 6.
      
      Il est possible de se lancer dans le support de tous les serveurs web ou presque sans pour autant en coder plus que ces deux pour l'instant : il faut rendre le code modulaire (ce qui peut amener à faire des fonctions qui ne sont utilisés qu'une fois pour l'instant mais dans l'optique de cette mutualisation future –cf. discussions sur le précédant journal) et extensible (dans le sens où chaque type de serveur pris en charge soit une/un extension/plugin)
      
      “It is seldom that liberty of any kind is lost all at once.” ― David Hume
      - [^] # Re: Nom du script
        
        Posté par xulops (site web personnel) le 07 septembre 2021 à 10:06. Évalué à 1.
        
        Les commentaires du précédent journal se sont focalisés sur la manière de développer, alors que le code n'est vraiment pas le problème (pas pour moi en tout cas).
        Supporter beaucoup de web servers, c'est d'avoir le temps et l'énergie de les installer, de lire toutes les docs, comprendre tous les paramètres, faire beaucoup de tests (au repos, en charge, avec ou sans tel ou tel module…), etc.
        C'est du boulot, pour des parts d'utilisateurs de plus en plus faibles (Apache et Nginx couvrent environ 70% des web servers). Je ne dis pas que c'est inutile ou inintéressant, mais je ne vais pas me lancer là-dedans maintenant. Plus tard peut-être…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.