Webmin est un outil basé sur Perl, permettant l’administration très complète d’un système informatique. Il existe depuis 1997, et est actuellement en version 2600, donc un projet toujours très actif.

Il fonctionne sur Linux (RHEL, Fedora, CentOS, OpenSUSE, AlmaLinux, Rocky Linux, Oracle Linux, Debian, Ubuntu, Mint, LMDE, …) mais aussi sur BSD, MacOS, AIX et autres Unix. Je l’ai fait tourner, en son temps, sur SunOS et Solaris, ainsi que sur HP-UX également. Il semblerait qu’il y a eu une version pour Windows, à l’époque de XP, mais beaucoup moins mature que la branche Unix, et qui a disparu aujourd’hui.

L’outil présente une interface strictement web, parfaitement compatible avec tout type de browser (aucun plug-in spécifique à charger). Le service est, par défaut, accessible sur le port 10.000, via http ou https.

L’accès à Webmin est strictement limité à des utilisateurs disposant d’un compte Webmin. Le seul compte actif lors de l’installation est “root”, avec pour authentifiant, le mot de passe du compte root du système sous-jacent.

Cette situation peut être totalement modifiée: on peut créer des comptes Webmin correspondant ou non à des comptes Unix locaux, supprimer ce compte “root”, etc… Il est juste un peu compliqué de se loguer, la première fois, si le compte local “root” n’a pas de password configuré, ou si un login sur ce compte “en direct” n’est pas autorisé, mais ça peut se corriger.

Le service web est intégré dans le logiciel. Donc il ne dépend pas d’un service tiers, genre Apache ou Nginx. C’est pratique lorsqu’on désire gérer un serveur web local, justement…

Point de vue sécurité, il tourne sur plein de machine exposées à l’Internet, mais il reste prudent, à priori, d’en restreindre l’accès à tout hasard, par exemple en ne permettant l’accès au port 10.000 qu’à certaines adresses IP sources, ou via un VPN, voir via une connexion locale (un tunnel TCP dans une session SSH, …)

Le but n’étant pas d’administrer la machine (mais c’est un excellent outil pour ce faire) je vais en rester là concernant Webmin pour le moment.

Usermin.

Usermin est une sorte de “petit frère” de Webmin, destiné non pas à l’administration de la machine, mais à des utilisateurs du serveur. Les personnes qui peuvent se connecter via Usermin sont, par défaut, tous les comptes “users” du système sous-jacent. Mais on peut mettre toutes les restrictions souhaitables, via la page ad-hoc de Webmin, qui s’appelle “Usermin Configuration”/”Allowed Users and Groups”.

On peut aussi décider de quel(s) module(s) chaque utilisateur pourra accéder ou non. On peut aussi définir certains modules de Usermin qui seront accessibles anonymement. On peut donc faire du contrôle d’accès aux fonctionnalités offertes par Usermin, via l’interface d’administration Webmin.

Le service Usermin tourne, par défaut, sur le port 20.000, en http ou https.

Un exemple d’interface Usermin accessible sans devoir s’authentifier est visible ici:
https://bookings.intertel.club/custom2/form.cgi?id=1714560152

On peut évidemment configurer un alias, pour avoir une URL “plus sexy”, via Apache ou Nginx (reverse proxy).

Les modules disponibles sous Usermin sont donc bien plus restreints que sous Webmin: pas d’administration du système. Plutôt des outils permettant d’accéder à des fichiers, de configurer des événements récurrents, d’accéder à sa mailbox, etc…

Parmi les innombrables modules disponibles sous Webmin/Usermin, celui qui nous intéresse ici est “Custom Commands”. Comme son nom l’indique, il permet de définir des commandes personnalisées, toujours simplement à travers une simple interface web.

Toute la puissance du module “Custom Commands” est qu’il est très générique. A travers l’interface Webmin, on peut le cloner (donc créer autant d’écrans “Custom Commands” que nécessaire), renommer les clones (donc donner des noms explicites à ces écrans), les regrouper dans divers onglets, également configurables directement via l’interface web.

On aboutit alors à quelque-chose du genre:

Voici donc une nouvelle catégorie dans Webmin/Usermin, qui s’appelle “GateKeeper”, notre solution de gestion de centre de recyclage.

Chaque ligne en dessous correspond à un écran contenant tous les clones du module “Custom Commands” (ou autres modules, au choix) qu’on y aura mis.
Par exemple:

Sous cette catégorie “GateKeeper Locks”, on trouve:

Chaque ligne correspond à un clone du module “Custom Commands”, renommé pour correspondre à son usage.

A noter que, puisque nous sommes ici sous Webmin, avec un login d’administrateur, nous voyons les options de designer de ces commandes:

• Create new custom command
• Edit
• …

Si on clique sur une de ces commandes, on entre dans le formulaire typique d’une “Custom Command”:

On a affaire à des champs libres, ou de type “pull-down menus”, ou des champs de type “date”, ou des menus à choix multiples, des cases cochables, etc…

Une fois tous les paramètres souhaités introduits (certains champs peuvent être obligatoires, d’autres non), on clique sur “Exécuter” et la commande liée à cet écran s’exécute. Le résultat, qui peut être du “simple texte” ou un résultat structuré en HTML, est affiché dans le web browser, comme par exemple:

Typiquement, derrière ce type d’écran se cache un simple programme, écrit dans le langage de son choix (ici c’est tout simplement généralement du BASH script), pouvant donc faire appel à tout type de commande, dont des requêtes SQL.

Pour voir de quoi on parle, il suffit de cliquer sur “Edit”. On entre alors dans le module en mode “programmeur”:

On voit ici qu’il est très simple de donner un nom à cette “Custom Command”, que ce qui est exécuté est un simple script (“~/bin/ViewLockTypes.sh“), qu’on peut préciser sous quels droits cette commande s’exécute, dans quel environnement, quel répertoire, combien de temps elle doit prendre au maximum, etc…

On peut aussi lui ajouter des paramètres, de divers types, qui sont passés par variables environnementales.

Le script est ici très simple:

#!/bin/bash

cat << eof
<style>
   table { padding-right: 10px; padding-left: 10px; 
}
td { vertical-align: top; 
     text-align: left;
}
th {
     text-align: left;
     border-left:   50px solid white;
     border-right:  50px solid white;
     padding-left:  50px solid white;
     padding-right: 50px solid white;
}
th, td {
    padding: 15px;
    text-align: left;
}
table#t01 tr:nth-child(even) {
    background-color: #c2f7be;
}
table#t01 tr:nth-child(odd) {
   background-color: #fff;
}
table#t01 th {
    background-color: black;
    color: white;
}
</style>
<table style="border: 5px solid black; padding: 50px solid white;">
  <tr align="top" style="padding: 20px solid; border: 5px solid;">
    <td style="padding: 20px solid">
eof
psql -q -U abilit -h 127.0.0.1 gatekeeper_prod << eof
\H
\pset title 'Liste des causes possibles de blockages de cartes:'
\pset tableattr id="t01"
SELECT note AS "Cause de blockage" 
from lock_types 
ORDER BY note asc;
eof
cat << eof
    <p><br></p>
    </td>
  </tr>
</table>
eof

On a totalement le contrôle de ce qu’on veut faire. On peut donc faire des “extracts” d’une base de données, laisser l’accès à ce type d’extracts à certains comptes Usermin, permettre de passer des paramètres, par exemple pour chercher la fiche d’un membre correspondant à un certain numéro de membre, ou sortir la liste des participants à un événement sur base d’une certaine date, etc…

Bien sûr, le script (ou autre) peut également écrire dans la database. L’authentification vis-à-vis de la RDBMS est faite ici par le user sous lequel le script s’exécute, ainsi que par le fait que la connexion est de type locale, donc ça n’ouvre pas de risque d’accès illégitime à distance.

Il est évidemment possible aussi de déclencher, via ce type d’écran, un mailing ou toute action qui dépend de commandes disponibles. On a des exemples de tels écrans permettant de redémarrer des fermes de serveurs ou des groupes entiers de systèmes de “digital signage”, via des connexions SSH authentifiées via certificats (RSA ou autres).

Un “simple” utilisateur peut donc, via ce système, avoir accès à des ressources sensibles, dans la limite stricte de ce qui est prévu par l’écran en question.

Comment le “simple utilisateur” accède-t-il à cet écran ?

Via Usermin.

Comme on le voit dans l’écran de configuration ci-dessus, il y a un champ “Available in Usermin”. Tant que l’écran n’est pas parfaitement au point, il n’est disponible que dans Webmin. Une fois cette option validée, il peut apparaître dans Usermin, mais seulement aux comptes Usermin autorisés à y accéder:

On peut donc décider de quel(s) comptes locaux peuvent avoir accès à Usermin, de quels modules les utilisateurs peuvent ou non avoir accès dans Usermin (par exemple pas d’accès au module “e-mails”), mais aussi préciser, par user ou par groupe de users, à quels clones de “Custom Commands” chaque compte pourra accéder ou non.

L’interface, pour l’utilisateur, via Usermin, est très proche de celle de l’administrateur/programmeur via Webmin, mais sans les possibilités de modifications, bien entendu:

… Pas de bouton “Edit” …

En résumé…

L’outil Webmin/Usermin est incroyablement plus vaste que ce que nous voulons en faire, mais il permet rapidement de développer une interface permettant de consulter et/ou modifier une base de données relationnelle, via une interface web standard, sans devoir se prendre la tête avec de la programmation d’interface graphique.

Il permet aussi de gérer facilement les comptes qui y ont accès.

Le module “Custom Commands” permet aussi de générer un écran dédié à des RDBMS plutôt qu’à des exécutables génériques, mais ça, je ne l’ai pas utilisé, donc je ne peux pas en dire beaucoup plus.

Le produit est parfaitement stable, polyglotte, mature, sécurisé et fonctionnel.

En cas de besoin, appelez-moi pour plus d’infos.