Exécuter des commandes

Servor vous permet d'exécuter des commandes sur n'importe quel serveur connecté sans ouvrir un terminal complet — au premier plan pour les tâches rapides, en arrière-plan pour les longues — et conserve chaque commande dans un historique avec recherche. Cette page couvre les trois cas, ainsi que les commandes bloquées et les lecteurs en lecture seule.

Commandes au premier plan

Les commandes au premier plan s'exécutent et vous renvoient leur sortie immédiatement — idéal pour les tâches rapides et finies comme systemctl status nginx, df -h ou git pull.

Commandes en arrière-plan

Certaines tâches durent des minutes ou des heures : une sauvegarde, une mise à niveau de paquets, un long import. Exécutez-les en arrière-plan pour qu'elles continuent même si vous fermez l'onglet ou perdez la connexion.

• Choisissez l'exécution en arrière-plan au moment d'envoyer la commande.
• La tâche continue de tourner sur le serveur, indépendamment de votre navigateur.
• Sa sortie et son statut final sont enregistrés dans l'historique, pour vérifier plus tard comment elle s'est déroulée.

C'est la façon fiable d'exécuter tout ce qui est long — contrairement à une session de terminal, une commande en arrière-plan ne meurt pas à la fin de votre session.

Épingler les commandes que vous retapez

Au-dessus du lanceur, le bouton Épingler enregistre la commande en cours comme raccourci pour ce serveur. Elle apparaît ensuite sous forme de puce : un clic la replace dans le champ, prête à être relue et lancée.

Les épingles sont locales à votre navigateur et propres à chaque serveur. Ce n'est pas de la configuration d'équipe : c'est le mémo des deux ou trois lignes que vous retapez sur cette machine. Épingler ne confère aucun droit — la puce remplit un champ, et tout ce qui suit reste le chemin signé habituel.

Historique des commandes

Chaque commande que vous exécutez — au premier plan, en arrière-plan, ou tapée dans le terminal web — est enregistrée par serveur, avec l'auteur, la date, la sortie et le code de sortie.

Commandes bloquées

Servor applique une liste noire partagée de commandes dangereuses pour vous protéger, vous et votre équipe, des erreurs catastrophiques. Si une commande correspond à la liste noire — l'exemple classique étant rm -rf / — elle est bloquée avant de s'exécuter, que vous l'envoyiez depuis le champ d'exécution, le terminal web, ou via le copilote IA.

La même protection s'applique partout où des commandes peuvent être exécutées : aucun moyen de faire passer une commande bloquée par un autre point d'entrée.

Les pipelines sont autorisés : df -h | grep /dev, systemctl status nginx && journalctl -u nginx -n 50, une substitution — écrivez la commande telle que vous la taperiez. La seule contrainte de forme est une ligne par exécution : un script de plusieurs lignes se met dans un fichier, que l'explorateur sait écrire. La liste noire, elle, s'applique à la ligne entière — rien ne se cache derrière un &&.

Une commande sur plusieurs serveurs

Depuis Serveurs › Exécuter, une même commande part sur plusieurs machines. Les cibles se cochent une par une, ou section par section : le titre d'une section coche tout ce qu'elle contient, ce qui rend « sur toute la prod » aussi rapide à demander qu'à dire.

Les exécutions sont séquentielles, pas parallèles. Une commande qui part sur tout un parc est exactement la situation où une erreur se multiplie : les résultats arrivent dans un ordre lisible, et vous pouvez arrêter après le troisième échec plutôt qu'après le quarantième.

Les lecteurs sont en lecture seule

Si votre rôle est lecteur, vous pouvez ouvrir un serveur et parcourir son historique de commandes, mais vous ne pouvez pas exécuter de commandes — le champ d'exécution et le terminal sont désactivés. C'est voulu : les lecteurs ont un accès en lecture seule partout. Pour exécuter des commandes, il faut au minimum le rôle membre. Voir rôles et permissions.

Voir aussi