Guides / Serveurs et performances
Whitelist, ban et op : les commandes de serveur qui ne se comportent pas comme prévu
Activer la liste blanche n'éjecte pas les joueurs déjà en ligne, /ban a besoin d'une raison pour être utile, et le niveau d'op compte plus que la liste des ops. Les détails qui piègent les administrateurs de serveur.
Les commandes d'administration paraissent simples, et elles le sont pour la plupart. Les échecs viennent de trois comportements qui ne sautent pas aux yeux à la lecture de la syntaxe.
La liste blanche ne retire pas ceux qui sont déjà là — sauf si vous le lui demandez
/whitelist on commence à appliquer la liste pour les nouvelles connexions. Le fait que les joueurs déjà connectés soient éjectés ou non dépend d'une seule ligne dans server.properties :
enforce-whitelist=trueElle vaut false par défaut, et tant que c'est le cas, les joueurs non inscrits restent connectés, que ce soit via /whitelist on ou /whitelist reload. Passez-la à true et on, reload et remove éjectent tous les joueurs connectés qui ne figurent pas sur la liste. Activer la liste blanche sans activer son application, puis partir vaquer à ses occupations, c'est l'erreur classique.
Deux autres détails :
/whitelist add <name>résout le nom auprès de l'API de Mojang sur un serveur en mode en ligne. Sur un serveur en mode hors ligne, elle inscrit à la place l'UUID hors ligne du nom, donc aucune modification manuelle dewhitelist.jsonn'est nécessaire.- Les opérateurs contournent la liste blanche par défaut, c'est pourquoi votre propre compte ne prouve jamais que la liste blanche fonctionne. Testez avec un second compte.
/ban veut une raison, et /ban-ip est une liste différente
/ban <player> [reason]
/ban-ip <address|player> [reason]La raison est facultative, et l'omettre est une erreur — c'est ce que voit le joueur banni, et c'est ce que vous lirez plus tard dans /banlist en essayant de vous rappeler pourquoi. Sans elle, l'entrée indique simplement « Banned by an operator ».
/ban et /ban-ip écrivent dans des fichiers séparés (banned-players.json, banned-ips.json). Pardonner l'un ne vide pas l'autre, ce qui est la raison habituelle pour laquelle un joueur « gracié » ne peut toujours pas se connecter. Utilisez /pardon et /pardon-ip tous les deux.
Les niveaux d'op, pas seulement la liste des ops
/op accorde le niveau 4 par défaut, soit un accès complet incluant /stop. Les quatre niveaux sont bien réels et configurables dans server.properties via op-permission-level :
| Niveau | Accorde |
|---|---|
| 1 | Contournement de la protection du point d'apparition |
| 2 | La plupart des commandes de triche, les blocs de commande |
| 3 | Gestion des joueurs — kick, ban, op |
| 4 | Tout, y compris /stop |
Les modérateurs qui ont besoin de /kick et /ban veulent le niveau 3, pas le 4. Accorder le niveau 4 à tous ceux qui aident à modérer, c'est comme ça que des serveurs se font effacer par un compte compromis.
function-permission-level est distinct et contrôle les fonctions de datapack autorisées à s'exécuter — le laisser à 2 alors que le niveau d'op est à 4 est une source fréquente de « ma fonction ne fait rien ».
Les commandes de liste
/banlist players, /banlist ips et /banlist seul existent tous et s'affichent dans la console plutôt que dans le chat lorsqu'ils sont lancés depuis le terminal du serveur. /whitelist list n'affiche que les noms, pas les UUID — lisez whitelist.json quand vous avez besoin de vérifier une identité.
Construisez n'importe laquelle de ces commandes avec les arguments dans le bon ordre dans le Générateur de commandes d'administration de serveur, qui couvre ban, ban-ip, pardon, kick, op, deop et whitelist depuis un seul formulaire.