Dépôt technique

Dépôt, Ops et pipeline Gaylémon

Ce dépôt ne contient pas le serveur Palworld lui-même. Il contient la couche d'exploitation: Gaylemon Ops côté Windows, les scripts Ubuntu sous server/, les unités systemd, les collecteurs, les projections publiques, le terminal des échos et le microsite statique qui lit uniquement des JSON filtrés.

MathieuLF/gaylemon Dépôt public, scripts et microsite ↗

Rôle des dossiers

Ce que contient le dépôt

portal/ contient le tableau de bord, /terminal, /resume, /classements, /carte, /github, les styles, assets/app.js et les exemples des contrats public-*.json. scripts/ contient la console PowerShell, les synchronisations, les audits et le déploiement Windows vers Ubuntu. server/ contient les scripts exécutés sur Ubuntu, les unités systemd, les sudoers, les réglages sysctl et les tests Python. docker/ sert le microsite local avec Nginx.

Les fichiers réellement actifs sur Ubuntu sont décrits dans server/deployment-manifest.json: source, destination, propriétaire, mode, validation et politique de redémarrage.

Gaylemon Ops

La console d'exploitation

  • Gaylemon Ops Console.ps1 est l'entrée locale.
  • scripts/palworld-console.ps1 porte les actions: statut, métriques, joueurs, logs, backups, updates, tunnel API, disponibilité REST et maintenance Ubuntu.
  • Gaylemon Ops Local Services peut démarrer les helpers Windows: microsite Docker, tunnel API local et rafraîchissement des métriques.
  • Les appels REST Palworld restent locaux. Le sudoers palworld-api autorise seulement quelques lectures précises par palworld-api.sh, pas un accès root général.
  • Les actions sensibles demandent confirmation et passent par SSH ou systemctl, jamais par une commande implicite cachée.

Pipeline

Chemin des données et des opérations

  1. Ops WindowsGaylemon Ops charge scripts/lib/Gaylemon.Config.ps1, vérifie SSH, lance les commandes locales et déclenche les opérations distantes autorisées.
  2. Collecte livepalworld-stats.timer et les scripts API lisent l'API REST Palworld locale sur Ubuntu. Le site reçoit public-metrics.json avec le nombre de joueurs, la liste affichable, l'heure d'arrivée détectée et la fraîcheur des données, jamais le mot de passe admin ni l'API brute.
  3. Snapshots de savespalworld-save-snapshot.timer travaille sur une copie de sauvegarde terminée, lit les données avec PalworldSaveTools, puis écrit public-save-index.json, public-save-snapshot.json, public-save-bases.json et players/{slug}.json pour les fiches joueurs.
  4. Journal d'événementspalworld-events.timer alimente SQLite aux 20 secondes et met à jour une projection publique matérialisée. La fenêtre récente est exportée immédiatement; l’export v5 complet reste un checkpoint froid. Le portail privilégie une génération v6 atomique composée d’un manifeste, de fragments journaliers immuables, d’une tête légère et de bilans quotidiens précalculés.
  5. Déploiement Ubuntuscripts/deployer-ubuntu.ps1 prépare le manifeste résolu, met en scène sous /tmp/gaylemon-staging, valide Bash/Python/systemd/sudoers/sysctl, puis sauvegarde sous /var/backups/gaylemon-deploy avant installation.
  6. Publication statiqueLes synchronisations PowerShell recopient uniquement les exports publics dans portal/data/. Nginx revalide le manifeste avec son ETag, garde la tête, les fragments et les ressources versionnées en cache immuable, laisse les pages se rafraîchir et bloque les chemins privés.

Points d'entrée à lire

  • Gaylemon Ops Console.ps1: lanceur local UTF-8.
  • scripts/palworld-console.ps1: menu Ops, actions SSH, logs, maintenance et confirmations.
  • scripts/deployer-ubuntu.ps1 et server/deploy/gaylemon_deploy.py: livraison contrôlée vers Ubuntu.
  • server/bin/palworld-save-snapshot.py: projection publique des sauvegardes.
  • server/bin/palworld-events-collect.py: observations privées, projection SQLite incrémentale, backfill contrôlé, confiance et déduplication des échos.
  • docker/microsite/default.conf: routes canoniques /, /terminal, /resume, /classements, /carte, /github, cache public et blocage des chemins privés.
  • portal/assets/app.js: rendu du dashboard, terminal plein écran, résumé quotidien, infobulle des présences, export JSON joueur, polling et fusion des flux récents.

Contrats publics servis

  • public-metrics.json: joueurs, FPS, camps, uptime, présences affichables et onlineSinceAt.
  • public-uptime.json: résumé de disponibilité calculé depuis l'API REST Palworld.
  • public-stats.json: sessions et agrégats joueurs publiables.
  • public-save-*.json: index, profils, bases, diagnostics et projections v3.
  • players/{slug}.json: détails publics d'un joueur, utilisés par les fiches et l'export JSON d'analyse.
  • public-events.json: historique complet, non plafonné, utilisé comme source canonique.
  • public-events-manifest-v6.json et public-events-v6/{generationId}/head.json: génération active, provenance, comptes et échos les plus récents.
  • public-events-v6/{generationId}/{jour}.json et public-daily/{generationId}/{jour}.json: tête, fragments journaliers et bilans immuables. Les anciens index et pages v5 restent lisibles pour compatibilité, mais v6 est le contrat actif du portail.

Frontière public/privé

Ce qui reste hors Git et hors site

  • Pas de Level.sav, Players/*.sav, base SQLite runtime, export privé ou assets extraits du jeu.
  • Pas de Steam ID, GUID Unreal, conteneur, chemin système, adresse IP, coordonnée brute ou détail exact de coffre.
  • Pas de mot de passe admin Palworld, jeton Cloudflare ou secret SSH.
  • Pas d'attribution supposée pour les récoltes, transferts, destructions, butins aléatoires ou événements ambigus.

Unités Ubuntu

Ce que le manifeste pilote

Les unités suivies couvrent palworld.service, palworld-backup.timer, palworld-update.timer, palworld-stats.timer, palworld-save-snapshot.timer, palworld-events.timer, palworld-welcome.service et palworld-performance.service. Les sudoers suivis couvrent aussi le déploiement, la console, les stats et l'API Palworld bornée.

Le manifeste distingue les redémarrages none, recommended et game. Les changements qui touchent palworld.service sont visibles comme tels; le dépôt ne redémarre pas le jeu par surprise.

Garanties

Règles de fonctionnement

Le serveur Palworld reste prioritaire: les workers lisent des copies, tournent avec des limites de ressources et n'impliquent pas de redémarrage de palworld.service. Le backfill traite une sauvegarde à la fois et reprend avec checkpoint.

Les exports publics sont construits par allowlist. Une donnée incertaine reste absente plutôt que d'être présentée comme un fait. Les identifiants techniques restent côté SQLite ou Ubuntu; le public reçoit seulement des clés stables non réversibles et des détails lisibles.

Le tableau de bord reste compact. /terminal reste un journal filtrable par curseur, sans notion de journée dans l'URL ou l'interface. Il refuse de combiner deux générations différentes. /resume lit le bilan précalculé de la journée sélectionnée. /carte se concentre sur les repères utiles aux joueurs: aventuriers, bases, légende et contrôles de navigation.

Les fiches joueurs peuvent exporter un JSON d'analyse à partir des données publiques déjà en vigueur: Pals en équipe, Pals en Palbox, bases, constructions, stockage et métadonnées de snapshot.