PostgreSQL

La reconnaissance — avant de toucher à quoi que ce soit

Le run démarre en lecture seule. Avant le moindre changement, Servor vérifie l'état réel de votre serveur — une vraie machine est rarement propre, et c'est ce qui existe vraiment qui décide de la suite.

• 01Postgres déjà installé ? quelle version ?
• 02service actif ?
• 03port 5432 déjà pris ?
• 04un cluster existe-t-il déjà ? ne pas le réinitialiser

Les étapes — chacune fait ses preuves

Le playbook ci-dessous guide le run ; le modèle adapte chaque commande à la distribution et à l'état découverts pendant la reconnaissance. Une étape ne compte comme faite que quand sa vérification passe.

1. 01

   Ajouter le dépôt PGDG

   Vérifié par

   ls /etc/apt/sources.list.d/pgdg.list 2>/dev/null && echo ok

   attendu : ok

2. 02

   Installer PostgreSQL ${version}

   Vérifié par

   psql --version

   attendu : la version demandée

3. 03

   Activer et démarrer

   Vérifié par

   systemctl is-active postgresql

   attendu : active

4. 04

   Vérifier la connexion

   Vérifié par

   sudo -u postgres psql -tAc 'select 1'

   attendu : 1

Les garde-fous

Les consignes non négociables que le run doit respecter, quoi qu'il trouve sur le serveur.

Les variables

Ce que vous choisissez avant de lancer — la recette s'occupe du reste.

${version}

Version majeure

Comment Servor exécute cette recette

Servor est zero-knowledge : la plateforme ne peut rien exécuter seule. Quand vous lancez cette recette, un run IA lit la reconnaissance, planifie les étapes et demande votre validation. Chaque commande approuvée est signée par votre navigateur — avec une clé que le serveur ne voit jamais — puis relayée à l'agent, qui vérifie la signature localement avant d'exécuter.