ADD new article

master
Alexandre LUCAZEAU 2022-04-24 19:00:32 +02:00
parent 78e1fe11ea
commit 1e26fa5028
No known key found for this signature in database
GPG Key ID: 3C8ADB07A8217BD3
5 changed files with 279 additions and 11 deletions

View File

@ -0,0 +1,49 @@
---
Date: 2022-04-21
Author: Alexandre LUCAZEAU
Title: Nixos partout même là-bas
Slug:
categories: Nixos
Tags:
- nixos
- ovh
- kimsufi
- dedicated server
- scalway
- nixos-infect
- caddy
---
# Nixos sur serveur dédié
Le choix d'une distribution est important. Non pas pour les applications packagées, mais pour la facilité d'installation et de maintenance.
Sur un serveur, une distribution Rolling Release va créer de l'emplois : trop de travail régulier.
Centos était un choix souvent fait pour la longévité de son support. Mais les montées de version n'existe pas. Debian est souvent un bon choix, communautaire, et pérenne. Mais ça demande aussi du travail.
Mais le suivi d'inventaire applicatif, devient vite pénible. L'approche Nixos, répond à toutes ces difficultés. Le problème, c'est son absence chez les hébergeurs. Pourtant, elle mérite qu'on s'y attarde. Heureusement, il existe un script **nixos-infect**
**nixos-infect** va remplacer le système existant par une Nixos toute neuve. Le script fonctionne sur plusieurs plateforme VPS, et je l'ai testé sur un serveur Kimsufi.
# Installation de Nixos sur un serveur dédié Kimsufi
OVH ne propose donc pas Nixos parmis les **60** possibilités revendiquées sur la page d'accueil.
Par contre on peut installer Debian 11 et profiter de l'outil pour faire le partitionnement des disques, puis transférer sa clé publique SSH sur le compte root
cat ~/.ssh/id_ed25519-perso.pub |ssh root@37.187.xxx.8 'cat >> .ssh/authorized_keys'
Enfin depuis notre nouveau serveur
curl https://raw.githubusercontent.com/elitak/nixos-infect/master/nixos-infect | NIX_CHANNEL=nixos-21.11 bash -x
Et c'est tout. Y a pas plus simple pour avoir un système opérationnel :D
Il reste plus qu'a supprimer l'ancienne fingerprint pour se reconnecter en SSH
ssh-keygen -f $HOME/.ssh/known_hosts -R 37.187.103.8
A partir de maintenant, vous pouvez enrichir votre configuration Nixos.
Vous trouverez ma configuration complète sur le git. Si vous l'utilisez, pensez à modifier la configuration SSH pour dans un premier temps autoriser les mots de passes, sinon, vous risquez de vous trouver à la porte.
Cette configuration utilise **caddy** comme serveur web, avec export des metrics - caddy et node-exporter.
L'idéal étant de revoir l'ensemble pour l'intégrer à un système comme flake, deploy-rs ou nixops. Affaire à suivre

119
posts/gpg.md Normal file
View File

@ -0,0 +1,119 @@
---
title: "gpg, manuel simplifié d'utilisation"
date: 2022-01-26
tags:
- gpg
- rsa4096
- ecc2559
categories :
- commandline
draft: false
description : "Utilisation de gpg"
---
Cette page est un mémo sur **gpg**, pour aider ma mémoire. Je mettrai certainement à jour cette page, selon mes usages.
# RSA ou ECC ?
RSA est le format le plus répandu, mais il n'est pas le plus adapté aux environnement actuels.
Le choix entre RSA et ECC se fait en fonction de votre environnement. Si vous utilisez des vieux trucs, il faut du RSA, sinon ECC sera parfait. Pour une sécurité équivalente, ECC nécessite une clé plus petite que RSA, et donc moins de cycle CPU, donc moins de ressources CPU consommées sur smartphone ou sur vieux pc ou équipements de faible puissance.
# Création de la clé maitre
Cette clée sera utilisée pour créer les sous clés, pour les révoquer ou pour augmenter leur durée de vie.
Faut-il lui donner une durée de vie à la clé maître ? Perso, j'ai choisi d'avoir une date d'expiration d'un an pour ma clé Pro, et une date d'expiration proche de mon espérance de vie imaginaire pour ma perso.
L'expiration sur la clé primaire n'est pas bloquant. Comme on utilise pas au quotidien la clé primaire, cela protège notre environnement en cas de perte, vol etc... La date d'expiration d'une sous clé, empêche son utilisation. Il est facile de la prolonger.
# Puis-je supprimer une sous clée ?
Oui ! Pour cela, il suffit de sélectionner la sous clé, puis on la supprime.
gpg2 --list-keys
gpg2 --edit-key --expert F136FE1BA10321C71D4D0646091E0FFD2A6E770F
La sélection de clé se fait par la commande **key** suivi d'un numéro d'ordre. Le compteur commence à 0. 0 étant la clé maitre.
Une clé apparait sélectionnée par l'adjonction du caractère ** * ** après **ssb**
Pour supprimer les clés ainsi sélectionner il suffit de tapper la commande **delkey**
# Puis-je supprimer une clée maitre ?
Lorsque l'on crée une nouvelle clée, on crée une partie public et une partie privée. Il faut d'abord supprimer la partie privée, puis la partie public :
gpg --delete-secret-key F136FE1BA10321C71D4D0646091E0FFD2A6E770F
gpg --delete-keys F136FE1BA10321C71D4D0646091E0FFD2A6E770F
ou les 2 à la fois :
gpg --delete-secret-and-public-key F136FE1BA10321C71D4D0646091E0FFD2A6E770F
Ces commandes suppriment la clée primaire (public et privée) et les sous clés publics. Les sous clées privées restent présentent dans le répertoire **.gnupg/private-keys-v1.d/**
Il faut également penser à supprimer l'ancien certificat de révocation :
rm .gnupg/openpgp-revocs.d/F136FE1BA10321C71D4D0646091E0FFD2A6E770F.rev
Les certificats de révocation sont automatiquement générés à la création de la clé ou de la sous-clé
# Création de la clé maitre
gpg2 --quick-generate-key 'Alexandre LUCAZEAU monmail@domaine.com' ed25519 cert 1y
Ici on a créé une clée ellyptique du type ed25519 capable de certifier des sous clés et qui expire dans 1 an.
# Création des clées secondaires
On crée une sous-clée pour signer, une sous-clée pour chiffrer et une sous-clée pour l'authentification. Il m'arrive de devoir me connecter sur du matériel un peu ancien. J'ai donc une seconde sous-clé dédiée à l'authentification, mais en RSA4096
gpg --quick-addkey F136FE1BA10321C71D4D0646091E0FFD2A6E770F ed25519 sign 1y
gpg --quick-addkey F136FE1BA10321C71D4D0646091E0FFD2A6E770F ed25519 encr 1y
gpg --quick-addkey F136FE1BA10321C71D4D0646091E0FFD2A6E770F cv25519 auth 1y
gpg --quick-addkey F136FE1BA10321C71D4D0646091E0FFD2A6E770F rsa4096 auth 1y
# Mise en sécurité
Notre clée primaire est la plus importante, c'est celle qui ne doit pas disparaitre ou être volée.
La deuxième donnée importante, ce sont les certificats de révocation. Vous en aurez besoin en cas de compromission.
La littérature sur internet conseil même d'imprimer sur papier les éléments.
## Sauvegarde et suppression de la clé primaire
### Export de la clée privée et des sous clés :
gpg --export-options backup --export-secret-keys $KEYID|gpg --symmetric > masterkey.key
### Suppression de la clée primaire, car elle n'est plus nécessaire sur notre poste :
gpg --delete-secret-keys $KEYID
## Restauration et définition du niveau de confiance
### Test de restauration des clés privées
Ce test est à faire avant toute exploitation de la clé ;-)
#### Dechiffrer notre **masterkey.key** en clé gpg
gpg -o export.gpg -d masterkey.key
##### Importer dans le trousseau
gpg --import-options restore --import backup-cle-prive.gpg
### Définition du niveau de confiance de la clé
Il est possible d'établir un niveau de confiance à la clé. Pour cela, il suffit de l'éditer, puis d'utiliser la commande **trust** et de valider le choix. **5** étant le niveau ultime.
# Révocation
## Générer un certificat de révocation pour la clé principale
gpg --output revoke.asc --gen-revoke $KEYID
## Révoquer une sous clé
Afficher les id des clés et de leurs sous clés :
gpg --list-secret-keys --keyid-format LONG
Editer la clée principale
gpg --expert --edit-key <key-id>
Sélectionner la sous clé à révoquer (par exemple la deuxième clé) et la révoquer
gpg> key 2
gpg> revkey
y
gpg> quit
Save changes (y/N) y
gpg --list-secret-keys --keyid-format LONG

View File

@ -0,0 +1,65 @@
---
date: 2022-04-08
author: Alexandre LUCAZEAU
title: "Terraform + Proxmox"
slug:
draft: true
tags:
- proxmox
- terraform
- lxc
categories:
- virtualisation
description: "Utiliser Terraform pour provisionner VM et container dans Proxmox"
---
**Terraform** est un outil connu pour provisionner des machines, des instances etc.. dans des plateformes de cloud.
L'outil, modulable, peut-être utilisé avec votre serveur **Proxmox** et nous permettre d'avoir à la maison, une véritable infrastructure as code.
L'étape finale sera d'avoir des VM sous Nixos, pour avoir dans un dépôt git des environnement reproductibles à 100%.
**Terraform** va cloner une image ou un template, pour instancier une nouvelle machine virtuelle, ou un nouveau container, ayant des caractéristiques physiques décrites dans un fichier de configuration.
Il est donc nécessaire d'avoir intégrer cette image dans notre Proxmox. La machine virtuelle peut-être un template Proxmox, ou pas. On ainsi garder une VM éteinte qui servira de modèle, VM que l'on modifiera selon les besoins. Pratique pour se faire, par exemple, un template de VM LAMP.
Pour l'exemple ici, nous allons nous simplifier la vie en utilisant une image Cloud-Init Debian. La prochaine fois, on passera au template Nixos.
# Création du template dans Proxmox
Pour commencer il faut se connecter en SSH au serveur Proxmox et télécharger, via curl ou wget l'image CloudInit
A partir de cette image, on va créer un template :
qm create 9000 -name centos-8-stream-template -memory 1024 -net0 virtio,bridge=vmbr1 -cores 1 -sockets 1 -cpu cputype=kvm64 -description "Centos 8 Stream Cloud Image" -kvm 1 -numa 1
Ajouter le disque prédemment téléchargé à la VM et le stoker dans le dépôt (chez moi, il se nomme D1) :
qm importdisk 9000 CentOS-Stream-GenericCloud-8-20210210.0.x86_64.qcow2 D1
# On rattache le disque à la VM
qm set 9000 -scsihw virtio-scsi-pci -virtio0 local:9000/vm-9000-disk-0.raw
qm set 9000 -serial0 socket
# restreint le boot au disque cloud-init
qm set 9000 -boot c -bootdisk virtio0
qm set 9000 -agent 1
# activation du hotplug
qm set 9000 -hotplug disk,network,usb,memory,cpu
# 1 vcpu et 1 socket
qm set 9000 -vcpus 1
qm set 9000 -vga qxl
# nommage de la VM
qm set 9000 -name centos-8-stream-template
# Ajout du lecteur CD pour cloudinit
qm set 9000 -ide2 local:cloudinit
# Terraformer
Revenu sur notre poste de travail, nous allons voir comment terraformer des VM basées sur notre nouveau template
## Comment ça fonctionne
**Terraform** travail avec des fichiers locaux. Tous ceux présents dans le répertoire ou l'on se trouve. Cela signifie que les fichiers vont former un tout. On pourrait ainsi imaginer un répertoire par machine, ou par groupe de machines.
Bien sur, on assurera le suivi des fichiers via git.
**Proxmox** possède une API, et **Terraform** ou plutôt son module, est capable de l'utiliser. Nous allons donc créer un compte utilisateur, capable de se connecter, et d'utiliser un token pour l'authentification.
Les paramètres de connexions, et le module seront donc dans un fichier de configuration, les variables dans un autre, et le troisième fichier contiendra la description de notre infra, dans le language DSL de **Terraform**

View File

@ -1,9 +1,11 @@
---
Date: 2021-05-31 16:30
Date: 2021-05-31
Author: Alexandre LUCAZEAU
Title:
Title: Nouveau serveur à la maison
Slug:
categories: virtualisation
Tags:
- proxmox
---
# Nouvelle machine, ode à la joie
Une nouvelle machine, c'est toujours cool. Ici il s'agit d'une bête, un HP 420 Workstation, avec un xeon 6 coeurs, 32Go de ram et disque d'1To.
@ -29,12 +31,4 @@ En résumé il faut :
* Intégrer ce nouveau volume à Proxmox
Dans Proxmox, Menu **Storage**, **Add**, **LVM**, Puis au niveau de **Base storage** choisir **Existing volume groups** et valider avec les éléments idouane
# Les opérations physiques terminées, on passe la main à Ansible
L'objectif est de transformer notre nouveau Proxmox, en poste Desktop. Il s'agit donc :
* Passer les sources apt en mode community
* Ajouter un compte utilisateur simple
* Bloquer l'accès root via ssh
* Installer un bureau Sway et les outils de base
* Installer Terraform
*
# Fini ? Non, on va maintenant ajouter Puppet, une forge, une VM OPNSense et configurer notre labo
* Utiliser Terraform pour le provisionning ou tester les outils de déploiement Nixos, à voir

41
posts/proxmox2.md Normal file
View File

@ -0,0 +1,41 @@
---
date: 2022-03-17
author: Alexandre LUCAZEAU
title: "Proxmox 1 an après"
slug:
tags:
- proxmox
categories:
- virtualisation
draft: false
description: "Ré-installation et tunning"
---
Les besoins ont changés, le matériel aussi. Exit les vieux disques sata, place à du neuf.
La configuration disque est basée sur un SSD de 128Go pour le système, et deux disque sata d'1To en RAID1 pour les VMs, et container.
Après avoir installé Proxmox 7.1 sur le SSD formaté en SSD, un peu de tunning:
### Changer la valeur du swapiness pour 90% au lieu de 60%
`sysctl vm.swappiness=90`
### Supprimer les dépôts entreprise
`rm -f /etc/apt/sources.list.d/pve-enterprise.list`
### Ajout du dépot gratuit
echo "deb http://download.proxmox.com/debian buster pve-no-subscription" >> /etc/apt/sources.list
apt update
### Création du zpool
`zpool create -f -o ashift=12 datastorez mirror /dev/sda /dev/sdb`
Puis dans Proxmox :
* Storage
* Add
* zpool
* id : D1
* ZFS Pool: datastorez