csansoon/hostel-rooms

Ajouter et gérer les chambres

Les machines sont dans le document de configuration sur le serveur. Vous devez être administrateur (hostel-users). Chaque modification s'applique immédiatement.

hostel config providers        # NOM, TYPE, MACHINES
hostel config rooms            # MACHINE, TYPE, OS, PLATEFORMES, LABELS, CHAMBRES
hostel config edit             # modifier le TOML dans $EDITOR

Une machine est nommée <fournisseur>/<machine>, ou seulement <machine> lorsque le nom est unique. Les noms correspondent à ^[a-z][a-z0-9-]*$. Les exigences de plateforme (Xcode, SDK Android, KVM, bureau) sont dans hostel-platforms.

Une machine derrière un NAT (elle rejoint le serveur)

Utilisez ceci pour la plupart de vos propres machines : un Mac mini à la maison, un PC Windows, une machine Linux. La machine maintient une connexion sortante vers le serveur. Elle n'a besoin d'aucune connexion SSH entrante depuis Internet.

1. Sur votre ordinateur, générez un code machine (24 heures, valable une fois) :

   hostel config rooms add mac-mini --platform ios --label xcode-26.5 --label desktop
   hostel config rooms add win-pc --label desktop
   

   --platform et --label peuvent être répétés. --provider sélectionne le fournisseur statique (par défaut home ; le serveur l'ajoute s'il manque). Dans l'application : Front desk › Add a room.

2. Exécutez la commande affichée sur la nouvelle machine en tant qu'administrateur : sudo sur macOS et Linux, un PowerShell administrateur sur Windows. La commande télécharge hostel depuis votre serveur et exécute hostel machine join <code>.

hostel machine join crée l'utilisateur hostel (sans droits d'administration), installe la clé du serveur pour cet utilisateur, ajoute la machine à la configuration (connect = true, système d'exploitation détecté automatiquement), et installe le service qui exécute hostel machine connect :

OS	Service	Journal
Linux	unité systemd hostel-machine-connect.service (utilisateur hostel-connect)	journalctl -u hostel-machine-connect
macOS	LaunchDaemon so.hostel.machine-connect	/var/log/hostel-machine-connect.log
Windows	tâche planifiée Hostel machine connect (LOCAL SERVICE)	C:\ProgramData\hostel\machine-connect.log

Le jeton se trouve dans /etc/hostel ou C:\ProgramData\hostel ; l'utilisateur de la chambre ne peut pas le lire. Si une étape échoue, corrigez-la et exécutez à nouveau la même commande : elle continue. --no-service ignore le service et affiche la commande hostel machine connect à exécuter vous-même (--server <url> --token-file <fichier> [--server-key clé] [--ssh 127.0.0.1:22]).

3. Effectuez les étapes que join affiche et que seule une personne peut réaliser :

   • macOS : Réglages Système › Général › Partage › Connexion à distance activée, pour hostel ; Xcode pour iOS ; pour desktop, connexion automatique de hostel et aucun mot de passe après l'économiseur d'écran.
   • Windows : le serveur OpenSSH s'exécute et démarre automatiquement (Get-Service sshd) ; pour desktop, la tâche « Hostel desktop ».
   • Linux : le serveur SSH écoute sur le port 22 et autorise la connexion par clé pour hostel.

4. Vérifiez : hostel status affiche la chambre dans la minute.

Une machine statique que le serveur atteint via SSH

Utilisez ceci lorsque le serveur peut ouvrir une connexion TCP vers la machine (même LAN ou VPN). Sur la machine, créez un utilisateur standard hostel avec la clé SSH du serveur. La clé est la sortie de hostel admin pubkey (sur l'ordinateur d'un administrateur), et hostel server init l'a également affichée (« clé publique du serveur »). Sur Linux :

sudo useradd -m -s /bin/bash hostel
sudo install -d -m 700 -o hostel -g hostel ~hostel/.ssh
echo 'ssh-ed25519 AAAA... hostel-server' | sudo tee ~hostel/.ssh/authorized_keys
sudo chown hostel:hostel ~hostel/.ssh/authorized_keys && sudo chmod 600 ~hostel/.ssh/authorized_keys

Autorisez la connexion par clé SSH pour cet utilisateur. Conservez le transfert TCP activé dans sshd (la valeur par défaut d'OpenSSH ; les tunnels en ont besoin). Ajoutez ensuite la machine avec hostel config edit :

[providers.home]
kind = "static"

[providers.home.machines.mac-mini]
address = "[email protected]"    # utilisateur@hôte[:port] ; utilisateur par défaut hostel, port 22
os = "macos"                         # obligatoire : linux, macos ou windows
platforms = ["ios", "android"]       # plateformes d'appareils ; la plateforme OS est automatique
labels = ["xcode-26.5", "desktop"]
tools = { java = "21" }              # outils mise au niveau de la machine
env = { HOSTEL_IOS_RUNTIME = "26.5" }
# slots = [{ name = "a" }, { name = "b" }]   # deux baux à la fois (par défaut : un slot "a")

• slots : chaque slot n obtient les ports 7500 + 10n à 7509 + 10n pour les tunnels. Un slot peut définir ports, env et son propre user OS.
• env et tools sur le fournisseur s'appliquent à toutes ses machines ; les clés de machine remplacent les clés portant le même nom.
• Le serveur fixe la clé d'hôte SSH de la machine lors de la première connexion.
• Windows manuellement : docs/static-room-setup.md, section « Windows » (l'utilisateur, et les règles d'accès de authorized_keys qu'OpenSSH exige).
• Pour une adresse publique : autorisez SSH entrant uniquement depuis le serveur, ou utilisez connect = true (le flux join) et fermez SSH entrant.

Modifiez une clé sans l'éditeur (platforms et labels sont des listes séparées par des virgules) :

hostel config rooms set mac-mini labels=xcode-26.5,desktop
hostel config rooms set mac-mini platforms=ios

Namespace (machines cloud à la demande)

Namespace (namespace.so) crée des chambres lorsqu'un bail en a besoin : une devbox pour macOS (ou Linux), une instance pour Linux. Installez les deux CLIs en tant qu'utilisateur du serveur, et ajoutez ~/.local/bin au PATH du service :

curl -fsSL https://get.namespace.so/cloud/install.sh | sh        # nsc
curl -fsSL get.namespace.so/devbox/install.sh | bash             # devbox
sudo mkdir -p /etc/systemd/system/hostel.service.d
printf '[Service]\nEnvironment=PATH=%s/.local/bin:/usr/local/bin:/usr/bin:/bin\n' "$HOME" \
  | sudo tee /etc/systemd/system/hostel.service.d/path.conf
sudo systemctl daemon-reload && sudo systemctl restart hostel

Depuis votre ordinateur (cela affiche une URL ; ouvrez-la et sélectionnez l'espace de travail) :

hostel config providers login namespace        # --cli devbox ou --cli nsc pour un seul CLI
hostel config providers add ns --kind namespace

Ajoutez ensuite des modèles de machine avec hostel config edit :

[providers.ns]
kind = "namespace"
max_rooms = 3                        # toutes les machines de ce fournisseur ensemble
# limits = [{ machines = ["mac"], max_rooms = 1 }]

[providers.ns.machines.mac]
spec = { product = "devbox", platform = "macos", size = "m", image = "tahoe-slim" }
platforms = ["ios"]
labels = ["xcode-26.5", "desktop"]
env = { DEVELOPER_DIR = "/Applications/Xcode_26.5.app/Contents/Developer", HOSTEL_IOS_RUNTIME = "26.5" }
max_rooms = 1
max_lifetime = "3h"                  # obligatoire pour une devbox : la durée maximale du plan

[providers.ns.machines.linux]
spec = { product = "instance", machine_type = "linux/amd64:8x16" }   # optionnel : image (par défaut ubuntu:24.04)
platforms = ["android"]
labels = ["kvm"]
tools = { java = "21" }
max_rooms = 2

Coûts et limites (vérifiez le plan actuel chez Namespace) :

• Hostel n'agit que sur les chambres avec le préfixe de nom hostel-<server_id>-.
• Une devbox est éphémère : elle est supprimée après environ 15 minutes d'inactivité, et à sa max_lifetime. Une instance a une échéance fixe que le serveur prolonge.
• Une devbox macOS coûte beaucoup plus cher par minute qu'une devbox Linux.
• Les limites du plan s'appliquent à tous les baux ensemble (ils partagent une seule connexion). Sur le plan Developer : une devbox par utilisateur, 3 h maximum, pas de Windows. Une erreur « limite atteinte » marque la machine comme pleine pendant limit_retry (2 minutes).
• Seuls les types d'instance linux sont pris en charge. Android sur Namespace utilise Linux.
• Une connexion dure plusieurs jours. Lorsqu'elle se termine, les appels au fournisseur échouent : reconnectez-vous.

Le fournisseur externe (votre propre commande)

kind = "external" exécute votre commande pour chaque opération (capabilities, provision, resume, stop, extend, destroy, list, access) avec JSON sur stdin et stdout. docs/design.md, section 7, « External provider contract », contient le contrat complet. Le dépôt test/fakeprovider (conteneurs Docker) est un outil de test, pas un fournisseur pris en charge.

[providers.docker]
kind = "external"
command = ["/usr/local/bin/my-provider"]
command_env = { DOCKER_HOST = "unix:///var/run/docker.sock" }
timeouts = { provision = "5m", default = "1m" }

[providers.docker.machines.small]
os = "linux"                         # obligatoire
spec = { image = "debian:13" }       # transmis à votre commande tel quel
max_rooms = 2

Limites et chambres chaudes (machines à la demande)

Clé	Où	Défaut
max_rooms	fournisseur (toutes ses machines) / machine	aucun / 1
limits	fournisseur : [{ machines = [...], max_rooms = N }]	[]
max_lease	fournisseur, machine	2h
max_lifetime	fournisseur, machine	aucun
warm_running	fournisseur, machine : garder une chambre libre en cours d'exécution pendant cette durée	5m
warm_stopped	fournisseur, machine : garder une chambre arrêtée pendant cette durée	24h

Drainer, réparer, supprimer, détruire

hostel config rooms drain mac-mini        # pas de nouveaux baux ; les baux en cours continuent
hostel config rooms undrain mac-mini
hostel config rooms repair mac-mini       # vérifier à nouveau une chambre cassée
hostel config rooms repair mac-mini --accept-host-key
hostel config rooms destroy ns/mac        # une chambre à la demande sans bail (donner le nom de la chambre si plusieurs)
hostel config rooms remove mac-mini       # supprimer la machine ; ses jetons de chambre sont révoqués
hostel config providers remove ns         # seulement sans chambres à la demande

• Une machine avec un bail actif ne peut pas être supprimée : drainez-la et attendez.
• Une machine à la demande ne peut pas être supprimée tant qu'elle a des chambres : détruisez-les d'abord.
• hostel admin room drain|undrain|repair|destroy <nom ou ID de chambre> fait la même chose par chambre.

Machines hors ligne

Toutes les intervals.presence (30 s) le serveur vérifie chaque chambre statique inactive. Une chambre qui ne répond pas passe en Hors ligne et ne prend aucun bail. Lorsqu'elle répond à nouveau, le serveur la prépare à nouveau automatiquement. Aucune commande n'est nécessaire. hostel status affiche offline (dernière vue ...). Voir hostel-troubleshoot.