FiveM
Minecraft
Rust
RedM
HytaleSi un de vos scripts d'administration Proxmox renvoie soudain une erreur 404 au téléchargement de build.func, la cause est connue. Fin octobre 2026, les mainteneurs de community-scripts ont nettoyé le dépôt des anciennes copies du moteur. Voici ce qui change, ce qui continue de fonctionner et comment adapter vos outils.
Ce qui s'est passé
La pull request #18294 de community-scripts/ProxmoxVE, intitulée « Drop the legacy engine copies from misc/ », a été fusionnée dans main le 31 octobre 2026. Elle supprime les copies héritées du moteur dans misc/*.func (dont build.func). misc/api.func a été retiré dans un second temps, après la réécriture de vm/owncloud-vm.sh, son dernier appelant. Le dossier misc/images/ a été déplacé vers .github/assets/.
Selon la description de la PR, plus rien ne chargeait ces fichiers depuis que ct/, install/, vm/ et tools/ ont migré vers le dépôt community-scripts/core. Le fichier est donc retiré de main : toute URL raw.githubusercontent.com/.../main/misc/build.func répond désormais 404.
Le 1er novembre, la discussion #18362 a été ouverte par un auteur de projet tiers dont les utilisateurs signalaient du code cassé. Le mainteneur MickLesk y précise que tous les scripts tournent sur le nouveau core depuis plusieurs semaines et que la suppression du code legacy était un reste oublié.
Rappel : à quoi servent les Helper-Scripts
Les Helper-Scripts sont des scripts Bash qui automatisent, sur un hôte Proxmox VE, la création d'un conteneur LXC ou d'une VM. Une fois la machine créée, vous y installez le service de votre choix, par exemple un serveur web Apache ou une base de données MySQL. Ces scripts s'appuient sur un moteur commun. C'est ce moteur, et non les scripts applicatifs, que la PR retire des copies héritées : c'est pourquoi les forks et les scripts maison qui les téléchargeaient sur main échouent désormais.
Notions clés : hyperviseur, virtualisation et serveur physique
Proxmox VE est un hyperviseur de type 1 : il s'installe directement sur le hardware d'un serveur physique et fait tourner plusieurs machines virtuelles ou conteneurs. La virtualisation répartit entre ces machines les ressources de l'hôte : processeurs, RAM, espace de stockage, adresse IP et bande passante. Une machine virtuelle (VM) embarque son propre système d'exploitation, par exemple Ubuntu ou Debian. Cette flexibilité permet de créer, copier ou arrêter une VM sans toucher au hardware de l'hôte. Un conteneur LXC partage le noyau de l'hôte, ce qui le rend plus léger. Proxmox VE repose sur Debian.
Pour administrer l'hôte, vous avez besoin d'un accès SSH avec les droits root. Le tableau suivant compare les types d'hébergement, du serveur dédié au serveur VPS (serveur privé virtuel) et à l'hébergement mutualisé, sous cet angle.
| Type d'hébergement | Accès root | Adéquation avec un hôte Proxmox VE |
|---|---|---|
| Serveur dédié | Oui | Adapté : la machine entière vous est réservée |
| VPS Linux | Oui | Peu adapté à un hyperviseur complet, mieux pour des services |
| Hébergement mutualisé | Non | Non : pas d'accès à l'hyperviseur |
Hyperviseurs : Proxmox VE face aux autres solutions
On distingue deux familles d'hyperviseurs. Un hyperviseur de type 1 s'installe directement sur le hardware des serveurs physiques, comme Proxmox VE. Un hyperviseur de type 2 s'exécute au-dessus d'un système d'exploitation existant pour faire tourner des serveurs virtuels. La virtualisation est aussi la base technique de l'hébergement cloud, où des ressources virtuelles sont louées à la demande.
| Solution | Type | Système de base | Administration |
|---|---|---|---|
| Proxmox VE | Type 1 | Debian | Interface web et ligne de commande |
| VMware ESXi | Type 1 | Système propre à VMware | Interface web et outils VMware |
| Hyper-V | Type 1 | Windows Server, avec le rôle Hyper-V | Gestionnaire Hyper-V et PowerShell |
Le choix dépend de vos outils, de vos compétences et des conditions de licence, à vérifier auprès de chaque éditeur. Proxmox VE repose sur Debian, ce qui vous permet d'utiliser les outils Linux habituels sur l'hôte.
Ce qui fonctionne encore
Les commandes en une ligne proposées sur community-scripts.org ne sont pas concernées : les scripts applicatifs utilisent déjà le nouveau moteur. Si vous installez un service avec ces commandes, rien ne change pour vous. Notre guide Helper-Scripts Proxmox VE reste la référence pour la démarche générale.
Ce qui ne fonctionne plus
- Les forks de ProxmoxVE qui font
sourced'un fichiermisc/*.funcrécupéré depuismain. - Les automatisations (Ansible, cron, CI) qui téléchargent ces fichiers à chaque exécution.
- Les scripts personnels écrits à partir des anciens modèles
ct/etinstall/de tteck, qui appellentvariables()ou les fonctions debuild.func.
Attention : la PR note aussi que le moteur PVE de core ne définit pas variables(). Un simple changement d'URL ne suffira donc pas dans tous les cas.
Repérer les appels dans vos dépôts
grep -rnE "misc/(build|install|core|tools|api)\.func" .
grep -rn "variables" --include="*.sh" .Migrer vers community-scripts/core
La PR ne fournit pas de procédure de migration formelle. Voici une démarche prudente, à valider avec la documentation du dépôt.
- Lisez le README de community-scripts/core puis
docs/loading.md: il décrit les deux racines, l'ordre de résolution, le préchargement et l'usage d'un fork. Le dépôt contient aussidocs/dev-mode.mdetdocs/testing-builds.md. - Faites charger le moteur depuis core, pas depuis les anciennes copies. Le moteur détecte l'hôte (Proxmox VE ou Incus) et charge le backend correspondant.
- Réécrivez les appels à
variables(): cette fonction n'existe plus côté PVE. - Testez sur une machine jetable, dans un environnement de test, avant de toucher à la production.
- Configurez vos scripts pour figer la version : référencez un commit ou une étiquette précise plutôt que
main.
Le dépôt est publié sous licence MIT. Il ne contient pas les scripts applicatifs, qui restent dans ProxmoxVE (ct/, install/, vm/, json/, tools/pve/).
Avant et après
| Situation | État | Action |
|---|---|---|
| Commande en une ligne de community-scripts.org | Fonctionne | Relire avant exécution |
Fork qui source misc/build.func sur main | Cassé (404) | Charger le moteur depuis core |
Automatisation qui télécharge misc/*.func | Cassée | Copie locale ou version figée |
Script personnel appelant variables() | À adapter | Réécrire selon core |
Prudence avant d'exécuter un script en root
Un script lancé sur l'hôte Proxmox a tous les droits sur l'hyperviseur, sur vos machines virtuelles (VM) et sur vos conteneurs. Quelques réflexes :
- Téléchargez le script, lisez-le, puis exécutez-le : évitez le
curl | bashaveugle. - Vérifiez que l'URL pointe vers le dépôt officiel et non vers un fork inconnu.
- Testez d'abord sur une machine non critique, et activez le pare-feu intégré (Firewall) de Proxmox VE.
- Gardez des sauvegardes (Backup) à jour : voir nos conseils de sauvegarde (les sauvegardes ElypseCloud sont une option).
- Appliquez les bonnes pratiques de sécurisation de Proxmox VE et limitez l'exposition des ports de l'interface.
Où faire tourner Proxmox VE
Proxmox VE demande un accès root complet au serveur physique, par SSH : un hébergement mutualisé ne le permet pas. Un serveur dédié est le support adapté, en hébergement dédié ; un VPS Linux sert plutôt aux services que vous hébergez à côté. Pour dimensionner votre hôte (processeurs, RAM, espace de stockage), consultez ce guide. Si vous préférez décrire vos VM et conteneurs sous forme de code plutôt que par scripts, voyez Proxmox avec Terraform.
À retenir
Les utilisateurs des commandes officielles ne risquent rien. Les auteurs de forks et de scripts maison doivent cesser de dépendre de main pour misc/*.func, passer par community-scripts/core et figer leurs versions. Nous n'avons pas pu vérifier un lien entre cette suppression et la hausse des recherches « proxmox community scripts ».