Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 xavier
|
dac1336e4c | ||
|
xavier
|
13dfdf01d0 |
@@ -1,67 +0,0 @@
|
|||||||
# Règles du Projet : nixos-infra
|
|
||||||
|
|
||||||
## Contexte Technique
|
|
||||||
**Stack :** NixOS 25.11, agenix, bash, SSH, Proxmox VE, LXC, KVM, IPv4, IPv6
|
|
||||||
**Environnement :** VSCodium (VSCode) sur Debian 13 + extension Continue poru l'IA, bash, SSH, Gitea, IPv4, IPv6
|
|
||||||
**Package Manager :** Nix
|
|
||||||
**Style :** Privilégier la modularité, dans la philosophie Unix. Utilisation de bash pour les tâches d'exploitation, avec un fallback sur python si bash devient impossible à maintenir.
|
|
||||||
**Tests :** Test Driven Development dans la mesure du possible.
|
|
||||||
**Matériels :** ordinateurs de bureau X86-64, un vieux Dell T62°, un vieux Dell T330, un Rpi 3B
|
|
||||||
|
|
||||||
## Conventions de Code
|
|
||||||
**Nommage :** camelCase pour les variables, PascalCase pour les composants et types. Majuscules et "_" pour les variables d'environnement shell.
|
|
||||||
**Types :** N/A
|
|
||||||
**Imports :** N/A
|
|
||||||
**Formatage :**
|
|
||||||
- Utiliser exclusivement `alejandra` ou `nixfmt-rfc-style`. Ne jamais laisser de trailing whitespaces.
|
|
||||||
- Préférer `inherit` pour les variables de même nom.
|
|
||||||
- Utiliser `with lib;` ou `with builtins;` avec parcimonie à l'intérieur des fonctions, mais préférer les chemins explicites pour la clarté.
|
|
||||||
- Toujours déclarer les arguments en début de fichier : `{ config, pkgs, lib, ... }:`.
|
|
||||||
**Modularité :** Chaque service doit être encapsulé dans un module avec une option `enable` (ex: `services.mon-service.enable = true;`).
|
|
||||||
|
|
||||||
## Architecture & Dossiers
|
|
||||||
**Architecture :**
|
|
||||||
Le but est de permettre le déploiement et la maintenance de services d'infrastructure réseau et applicatifs
|
|
||||||
(DNS, serveur de dépôts git, gestionnaire de mots de passe, file server, backup server, reverse proxy,
|
|
||||||
workstations, etc.). Le dépôt git contient l'ensemble des fichiers permettant de configurer et installer
|
|
||||||
n'importe quelle machine du parc (images d'OS, fichiers de configuration et scripts de déploiemente et maintenance).
|
|
||||||
En cible, reconstruire l'ensemble du parc doit être possible depuis une workstation Linux (pas forcément NixOS) sur lequel ce dépôt aura été cloné.
|
|
||||||
|
|
||||||
**Dossiers :**
|
|
||||||
- `/nixos-infra/hosts/servers` : Configurations spécifiques de chaque serveur (.nix, lxc.config).
|
|
||||||
- `/nixos-infra/hosts/workstations` : Configurations spécifiques de chaque station de travail (.nix, lxc.config).
|
|
||||||
- `/nixos-infra/modules/machine-types` : Modules Nix standardisant les différents types d'hotes (hyperviseur, VM, LXC, stations, etc.).
|
|
||||||
- `/nixos-infra/modules/services` : Modules Nix standardisant les différents services d'infrastructure réseau (DNS, etc.).
|
|
||||||
- `/nixos-infra/modules/user-profiles` : Modules Nix standardisant les différents profils d'utilisateurs (admin, dev, burautique, etc.).
|
|
||||||
- `/nixos-infra/overlays` : Overlays Nix (dernier recours).
|
|
||||||
- `/nixos-infra/pkgs` : Paquets personnalisés non présents dans Nixpkgs.
|
|
||||||
- `/nixos-infra/lib` : Fonctions utilitaires Nix.
|
|
||||||
- `/nixos-infra/scripts` : Scripts d'exploitation et de helpers.
|
|
||||||
|
|
||||||
Le point d'entrée pour chaque machine est hosts/<servers|workstations>/\<hostname>/configuration.nix.
|
|
||||||
|
|
||||||
## Gestion des Secrets
|
|
||||||
**Interdiction Formelle :** Ne JAMAIS écrire de mot de passe, clé d'API ou token en clair dans les fichiers `.nix`.
|
|
||||||
**Outil :** Utiliser **agenix**.
|
|
||||||
|
|
||||||
## Instructions NixOS
|
|
||||||
1. Ne pas utiliser les flakes Nix.
|
|
||||||
2. Toujours vérifier si une option (https://search.nixos.org/options), un paquetage (https://search.nixos.org/packages) ou une fonction (https://noogle.dev/) avant de l'inventer.
|
|
||||||
3. Ne pas supposer que la workstation utilisée est elle-même sous NixOS. L'environnement de développement est sous Debian Trixie jusqu'à ce que le projet soit complètement auto-porteur. Néanmoins, le paquetage "nix-bin" est installé pour disposer des binaires de Nix.
|
|
||||||
4. Utiliser nix-isntantiate pour vérifier la syntaxe et l'évaluation des fichiers Nix:
|
|
||||||
```
|
|
||||||
nix-instantiate --parse chemin/vers/fichier.nix # Vérifie la syntaxe
|
|
||||||
nix-instantiate --eval -E 'import ./hosts/machine/configuration.nix {}' # Vérifie l'évaluation
|
|
||||||
```
|
|
||||||
|
|
||||||
## Instructions Spécifiques (Guidelines)
|
|
||||||
1. Ne **jamais** exposer de mot de passe, de clef API ou tout secret en clair. Utiliser les mécanismes de gestion/protection de secrets appropriés au contexte.
|
|
||||||
2. Privilégier les clefs SSH pour l'authentification aux systèmes.
|
|
||||||
3. Limiter les longueurs des lignes à 78 caractères imprimables.
|
|
||||||
4. Signaler les éventuelles incohérences de pratiques au sein du projet ou avec les bonnes pratiques.
|
|
||||||
|
|
||||||
## Préférences de Réponses
|
|
||||||
- Langue : Français. Le code, les commentaires et la documentation restent en Anglais.
|
|
||||||
- Style : Technique, concis, orienté "Infrastructure as Code".
|
|
||||||
- Toujours expliquer brièvement *pourquoi* une option NixOS spécifique a été choisie (référence aux options officielles).
|
|
||||||
- Me signaler si et quand il aura été difficile ou impossible de respecter les instructions fournies dans .ai-rules.md .
|
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
## Nix
|
||||||
|
|
||||||
|
## General Instructions
|
||||||
|
1. Do not use Nix flakes.
|
||||||
|
2. Always check if an option (https://search.nixos.org/options), a package (https://search.nixos.org/packages) or a function (https://noogle.dev/) exists before inventing one.
|
||||||
|
3. Do not assume the development or administration workstations themselves run NixOS. The development environment is more likely Debian Trixie.
|
||||||
|
4. Use `nix-instantiate` to verify syntax and evaluation of Nix files:
|
||||||
|
```
|
||||||
|
nix-instantiate --parse path/to/file.nix # Check syntax
|
||||||
|
nix-instantiate --eval -E 'import ./hosts/machine/configuration.nix {}' # Check evaluation
|
||||||
|
```
|
||||||
|
|
||||||
|
## Code Conventions
|
||||||
|
**Naming:** camelCase for variables, PascalCase for components and types. UPPER_CASE and "_" for shell environment variables.
|
||||||
|
**Types:** N/A
|
||||||
|
**Imports:** N/A
|
||||||
|
**Formatting:**
|
||||||
|
- Use exclusively `alejandra` or `nixfmt-rfc-style`. Never leave trailing whitespace.
|
||||||
|
- Prefer `inherit` for same-name variables.
|
||||||
|
- Use `with lib;` or `with builtins;` sparingly inside functions, but prefer explicit paths for clarity.
|
||||||
|
- Always declare arguments at the beginning of the file: `{ config, pkgs, lib, ... }:`.
|
||||||
|
**Modularity:** Each service must be encapsulated in a module with an `enable` option (e.g., `services.mon-service.enable = true;`).
|
||||||
|
|
||||||
|
## Secret Management
|
||||||
|
**Strict Prohibition:** NEVER write passwords, API keys, or tokens in plaintext in `.nix` files.
|
||||||
|
**Tool:** Use **agenix**.
|
||||||
|
|
||||||
|
## Specific Guidelines
|
||||||
|
1. **Never** expose passwords, API keys, or any secrets in plaintext. Use appropriate secret management/protection mechanisms for the context.
|
||||||
|
2. Prefer SSH keys for system authentication.
|
||||||
|
3. Limit line lengths to 78 printable characters.
|
||||||
|
4. Report any inconsistencies in practices within the project or with best practices.
|
||||||
@@ -0,0 +1,14 @@
|
|||||||
|
# Project Rules: nixos-infra
|
||||||
|
|
||||||
|
## Directories
|
||||||
|
- `/nixos-infra/hosts/servers`: Server-specific configurations (.nix, lxc.config).
|
||||||
|
- `/nixos-infra/hosts/workstations`: Workstation-specific configurations (.nix, lxc.config).
|
||||||
|
- `/nixos-infra/modules/machine-types`: Nix modules standardizing different host types (hypervisor, VM, LXC, workstations, etc.).
|
||||||
|
- `/nixos-infra/modules/services`: Nix modules standardizing different network infrastructure services (DNS, etc.).
|
||||||
|
- `/nixos-infra/modules/user-profiles`: Nix modules standardizing different user profiles (admin, dev, office, etc.).
|
||||||
|
- `/nixos-infra/overlays`: Nix overlays (last resort).
|
||||||
|
- `/nixos-infra/pkgs`: Custom packages not present in Nixpkgs.
|
||||||
|
- `/nixos-infra/lib`: Nix utility functions.
|
||||||
|
- `/nixos-infra/scripts`: Operational and helper scripts.
|
||||||
|
|
||||||
|
The entry point for each machine is `hosts/<servers|workstations>/<hostname>/configuration.nix`.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
# Project Rules: nixos-infra
|
||||||
|
|
||||||
|
## Goals
|
||||||
|
|
||||||
|
The goal is to enable the deployment and maintenance of network infrastructure and application services
|
||||||
|
(DNS, git repository server, password manager, file server, backup server, reverse proxy,
|
||||||
|
workstations, etc.). The git repository contains all files needed to configure and install
|
||||||
|
any machine in the fleet (OS images, configuration files, deployment and maintenance scripts).
|
||||||
|
The target is to be able to rebuild the entire fleet from a Linux workstation (not necessarily NixOS)
|
||||||
|
where this repository has been cloned.
|
||||||
@@ -0,0 +1,7 @@
|
|||||||
|
# Project Rules: nixos-infra
|
||||||
|
|
||||||
|
## Response Preferences
|
||||||
|
- Language: English
|
||||||
|
- Style: Technical, concise, Infrastructure as Code oriented.
|
||||||
|
- Always briefly explain *why* a specific NixOS option was chosen (reference to official options).
|
||||||
|
- Notify me if and when it was difficult or impossible to follow the instructions provided in `.ai-rules.md`.
|
||||||
@@ -0,0 +1,9 @@
|
|||||||
|
# Project Rules: nixos-infra
|
||||||
|
|
||||||
|
## Technical Context
|
||||||
|
**Stack:** NixOS 25.11, agenix, bash, SSH, Proxmox VE, LXC, KVM, IPv4, IPv6
|
||||||
|
**Environment:** VSCodium (VSCode) on Debian 13 + Cline extension for AI, bash, SSH, Gitea, IPv4, IPv6
|
||||||
|
**Package Manager:** Nix
|
||||||
|
**Style:** Favor modularity, in the Unix philosophy. Use bash for operational tasks, with a fallback to Python if bash becomes unmaintainable.
|
||||||
|
**Tests:** Test Driven Development whenever possible.
|
||||||
|
**Hardware:** X86-64 desktop computers, an old Dell T620, an old Dell T330, a Rpi 3B
|
||||||
@@ -0,0 +1,35 @@
|
|||||||
|
# Role
|
||||||
|
You are an exceptional product manager with 20 years of experience and an engineer proficient in all programming languages, skilled in assisting junior developers.
|
||||||
|
|
||||||
|
# Goal
|
||||||
|
Help users complete their product design and development tasks in an easily understandable way, proactively completing all tasks without waiting for repeated prompting.
|
||||||
|
|
||||||
|
## Step 1: Project Initialization
|
||||||
|
- When a user makes a request, first review the readme.md file and all code documents in the root directory to understand the project's goals, architecture, and implementation methods. If a readme file doesn't exist, create one.
|
||||||
|
- This file will serve as a manual for users to understand all provided functions and your project plan.
|
||||||
|
- Clearly describe the purpose, usage, parameter descriptions, and return value descriptions of all functions in the readme.md file to ensure user-friendly understanding and usage.
|
||||||
|
|
||||||
|
## Step 2: Task Understanding and Execution
|
||||||
|
### Understanding User Needs
|
||||||
|
- Fully understand user needs from their perspective. Consider: "If I were the user, what would I need?"
|
||||||
|
- As a product manager, identify any gaps in user needs. Discuss and refine requirements with users until satisfaction is achieved.
|
||||||
|
- Prioritize the simplest solutions to meet user needs, avoiding overly complex or advanced approaches.
|
||||||
|
|
||||||
|
### Code Development
|
||||||
|
- Plan step-by-step, considering user needs and existing codebase.
|
||||||
|
- Choose appropriate programming languages and frameworks to implement user requirements.
|
||||||
|
- Design code structure based on SOLID principles and use design patterns to address common problems.
|
||||||
|
- Write comprehensive comments for all code modules and include necessary monitoring to track errors.
|
||||||
|
- Opt for simple, controllable solutions over complex ones.
|
||||||
|
|
||||||
|
### Problem Solving
|
||||||
|
- Thoroughly read the entire code file library to understand all code functions and logic.
|
||||||
|
- Analyze the root causes of user-reported code errors and propose solutions.
|
||||||
|
- Engage in multiple interactions with users, summarizing previous interactions and adjusting solutions based on feedback until user satisfaction.
|
||||||
|
- Initiate "System 2 Thinking Mode" for persistent bugs:
|
||||||
|
1. Systematically analyze potential root causes and list all hypotheses.
|
||||||
|
2. Design verification methods for each hypothesis.
|
||||||
|
3. Provide three distinct solutions, detailing pros and cons for user choice.
|
||||||
|
|
||||||
|
## Step 3: Project Summary and Optimization
|
||||||
|
- After completing the user's task, reflect on the task completion process, identify potential issues and improvements, and update the readme.md file accordingly.
|
||||||
@@ -30,19 +30,19 @@
|
|||||||
|
|
||||||
## **🔍 Key Decisions**
|
## **🔍 Key Decisions**
|
||||||
|
|
||||||
| Decision | Justification | Impact |
|
| Decision | Justification | Impact |
|
||||||
| ---------------------------------------------------------| ---------------------------------------------------------------------------------| --------------------------------------------------------|
|
| ---------------------------------------------------------| -------------------------------------------------------------------------------------------------------------------------------------------| ----------------------------------------------------------------------------|
|
||||||
| **No flakes** | Simplify onboarding and avoid a steep learning curve. | Configuration via `configuration.nix` + `callPackage`. |
|
| **No flakes** | Simplify onboarding and avoid a steep learning curve. | Configuration via `configuration.nix` + `callPackage`. |
|
||||||
| **Modular structure** | Separate configurations by machine type and service. | Clear and maintainable directory tree. |
|
| **Modular structure** | Separate configurations by machine type and service. | Clear and maintainable directory tree. |
|
||||||
| **Servers named by service, not by application** | Indicate what the machine does (git01 = Git forge) rather than the software (Gitea). Allows changing the underlying app without renaming. | Hosts under `hosts/servers/<service>01` (e.g. `git01`, `pass01`, `dns01`). |
|
| **Servers named by service, not by application** | Indicate what the machine does (git01 = Git forge) rather than the software (Gitea). Allows changing the underlying app without renaming. | Hosts under `hosts/servers/<service>01` (e.g. `git01`, `pass01`, `dns01`). |
|
||||||
| **`callPackage` for modules** | Make modules autonomous, portable, and reusable. | Each module is an independent Nix package. |
|
| **Modules** | Make modules autonomous, portable, and reusable. | Each module is an independent Nix package. |
|
||||||
| **Separation of `user-profiles/` and `users/`** | Distinguish generic roles (e.g., `admin`) from concrete users (e.g., `xavier`). | Flexibility to apply profiles to multiple users. |
|
| **Separation of `user-profiles/` and `users/`** | Distinguish generic roles (e.g., `admin`) from concrete users (e.g., `xavier`). | Flexibility to apply profiles to multiple users. |
|
||||||
| **`deploy.sh` script** | Automate deployment on existing machines. | Clone/update the repo + `nixos-rebuild switch`. |
|
| **`deploy.sh` script** | Automate deployment on existing machines. | Clone/update the repo + `nixos-rebuild switch`. |
|
||||||
| **`create-lxc-nixos.sh` script** | Automate the creation of NixOS LXC containers on Proxmox. | Ready-to-use container with initial configuration. |
|
| **`create-lxc-nixos.sh` script** | Automate the creation of NixOS LXC containers on Proxmox. | Ready-to-use container with initial configuration. |
|
||||||
| **Initial configuration (`initial-configuration.nix`)** | Prepare an LXC container so it can update itself via Git. | Self-sufficient containers. |
|
| **Initial configuration (`initial-configuration.nix`)** | Prepare an LXC container so it can update itself via Git. | Self-sufficient containers. |
|
||||||
| **Secret management with `agenix`** | Encrypt secrets (passwords, keys) for secure storage. | Enhanced security for sensitive data. |
|
| **Secret management with `agenix`** | Encrypt secrets (passwords, keys) for secure storage. | Enhanced security for sensitive data. |
|
||||||
| **Unprivileged LXC containers (`--unprivileged 0`)** | NixOS requires privileges to function correctly in LXC. | Functional containers with NixOS. |
|
| **Unprivileged LXC containers (`--unprivileged 0`)** | NixOS requires privileges to function correctly in LXC. | Functional containers with NixOS. |
|
||||||
| **IPv4, IPv6, VLAN support** | Final target is IPv6-first, or even IPv6-only. | IP plan management to be designed. |
|
| **IPv4, IPv6, VLAN support** | Final target is IPv6-first, or even IPv6-only. | IP plan management to be designed. |
|
||||||
|
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -93,7 +93,7 @@ nixos-infra/
|
|||||||
│ │ ├── dns/
|
│ │ ├── dns/
|
||||||
│ │ │ ├── default.nix # Implementation
|
│ │ │ ├── default.nix # Implementation
|
||||||
│ │ │ └── options.nix # Exposed options
|
│ │ │ └── options.nix # Exposed options
|
||||||
│ │ ├── gitea/
|
│ │ ├── git-forge/
|
||||||
│ │ │ └── default.nix
|
│ │ │ └── default.nix
|
||||||
│ │ ├── password-manager/
|
│ │ ├── password-manager/
|
||||||
│ │ │ └── default.nix
|
│ │ │ └── default.nix
|
||||||
|
|||||||
@@ -18,7 +18,7 @@ Usage:
|
|||||||
|
|
||||||
Options:
|
Options:
|
||||||
-h, --help Show this message.
|
-h, --help Show this message.
|
||||||
-t, --template TEMPLATE LXC template (e.g. local:vztmpl/nixos-unstable).
|
-t, --template TEMPLATE LXC template (e.g. local:vztmpl/nixos-unstable).
|
||||||
-r, --rootfs-size SIZE Root filesystem size (e.g. 8G).
|
-r, --rootfs-size SIZE Root filesystem size (e.g. 8G).
|
||||||
-c, --cores CORES Number of CPU cores.
|
-c, --cores CORES Number of CPU cores.
|
||||||
-m, --memory MEMORY RAM in MiB.
|
-m, --memory MEMORY RAM in MiB.
|
||||||
|
|||||||
Reference in New Issue
Block a user