Installer et configurer ses plugins sans casser son serveur

Installer un plugin, c'est déposer un fichier dans un dossier. Ce qui fait tomber les serveurs, c'est tout ce qu'on fait avant et après.

Ne téléchargez que depuis quatre endroits

SpigotMC, Hangar (le dépôt officiel de PaperMC), Modrinth, et les releases GitHub du développeur. Rien d'autre.

Les sites qui proposent des versions « premium gratuites » distribuent des .jar modifiés. Un plugin a tous les droits sur votre serveur et sur la machine qui l'héberge : c'est la porte d'entrée la plus simple qui existe vers votre base de données et vos sauvegardes. Un plugin payant qu'on ne veut pas payer, on s'en passe.

Vérifier la compatibilité avant, pas après

Deux numéros doivent concorder :

• La version du jeu. Un plugin annoncé pour 1.20 fonctionnera souvent en 1.20.4, rarement en 1.21. La page du plugin indique les versions testées : croyez-la.
• La plateforme. Paper accepte les plugins Spigot et Bukkit. L'inverse n'est pas vrai : un plugin qui exige les API de Paper ne démarrera pas sur Spigot.

Les dépendances

Trois plugins reviennent comme dépendances de tout le reste :

• Vault : l'intermédiaire entre l'économie, les permissions et les plugins qui s'en servent.
• PlaceholderAPI : les variables %joueur_nom% et consorts, utilisées par les tablists, les scoreboards et les messages.
• ProtocolLib : pour les plugins qui manipulent les paquets réseau.

Un plugin qui réclame une dépendance absente écrit clairement Unknown dependency au démarrage et se désactive. C'est l'erreur la plus facile à lire de tout Minecraft : profitez-en.

Le premier démarrage sert à générer les configurations

La bonne séquence est toujours la même :

1. Arrêtez le serveur. Proprement, avec stop dans la console, jamais en tuant le processus.
2. Déposez le .jar dans plugins/.
3. Démarrez. Le plugin crée son dossier et sa configuration par défaut.
4. Arrêtez de nouveau, éditez la configuration, redémarrez.

Éditer une configuration pendant que le serveur tourne ne sert à rien : il l'a déjà lue, et il la réécrira peut-être par-dessus en s'arrêtant.

YAML : les trois pièges

Les fichiers de configuration sont en YAML, et YAML est intransigeant.

• Les tabulations sont interdites. Uniquement des espaces. La moitié des could not load config viennent de là.
• L'indentation porte le sens. Deux espaces de trop déplacent un réglage dans une autre section.
• Les valeurs ambiguës se mettent entre guillemets. oui, non, on, off sont interprétés comme des booléens ; un mot de passe commençant par un chiffre veut aussi ses guillemets.

Passez chaque fichier modifié dans un validateur YAML avant de redémarrer. Cela prend dix secondes et évite un serveur qui refuse de se lever à minuit.

Les permissions : des groupes, jamais des joueurs

Installez LuckPerms. Il n'y a pas de débat sur ce point depuis des années.

Et donnez les permissions à des groupes, pas à des joueurs. Un serveur où chaque modérateur a reçu ses droits à la main devient impossible à auditer au bout de trois mois : personne ne sait plus qui peut faire quoi, et le jour où un modérateur part, il reste des droits orphelins.

Trois ou quatre groupes suffisent pour commencer : default, vip, moderateur, admin. Chacun hérite du précédent.

Gardez l'opérateur pour vous seul, et jamais pour un groupe. op court-circuite toutes les permissions, y compris celles que vous aviez pris soin de retirer.

Pourquoi /reload est une mauvaise idée

/reload recharge les plugins sans redémarrer le serveur. C'est commode, et c'est la cause d'une part remarquable des bugs inexplicables : les plugins gardent des références aux objets de l'ancien chargement, les tâches planifiées se dédoublent, et des fuites de mémoire s'installent.

Beaucoup de plugins offrent leur propre commande de rechargement : /luckperms reload, /essentials reload. Celles-là sont sûres, parce que le plugin sait ce qu'il recharge. Utilisez-les. Pour le reste, redémarrez.

Retrouver le plugin fautif en quatre redémarrages

Le serveur plante, la console est illisible, et vous avez vingt-cinq plugins. Procédez par dichotomie :

1. Déplacez la moitié des plugins dans un dossier à part. Démarrez.
2. Si le problème disparaît, le coupable est dans la moitié retirée ; sinon, dans celle restée.
3. Recommencez sur la moitié incriminée.

Vingt-cinq plugins se ramènent à un en cinq essais. C'est beaucoup plus rapide que de lire la pile d'appels, et cela marche même quand le message d'erreur ne nomme personne.

Avant cela, prenez tout de même trente secondes pour ouvrir logs/latest.log et chercher la première ligne contenant Caused by : une fois sur deux, le nom du plugin y est écrit.

Tenez une liste

Un fichier texte, à côté des sauvegardes, avec pour chaque plugin : son nom, sa version, d'où il vient, et à quoi il sert chez vous.

Le jour où vous migrez de machine, où vous montez de version, ou où vous reprenez le serveur après six mois, cette liste vaut toutes les explorations de dossier. Et versionnez le dossier plugins/*/config.yml : savoir ce qui a changé la veille du jour où tout a cassé est le plus court chemin vers la réparation.

---

Votre serveur tourne et vos plugins sont en place ? Référencez-le, et pensez à brancher Votifier pour récompenser les votes automatiquement.