ADD new article
This commit is contained in:
Alexandre LUCAZEAU
parent
78e1fe11ea
commit
1e26fa5028
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
||||
|
|
@ -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**
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
||||
Loading…
Reference in New Issue