Archives de catégorie : Linux

iceberg during daytime

Sauvegarde Proxmox sur stockage S3 Scaleway – Glacier

Pour reprendre la suite de l’article sur la sauvegarde Proxmox via le S3 Scaleway et pousser les fichiers vers le stockage à froid « Glacier », voici la procédure pour y arriver.

Sauvegarde Proxmox sur stockage S3 Scaleway

Création de la règle de cycle de vie

Depuis la console Scaleway, rendez-vous sur votre bucket et cliquez sur la partie Règles de cycle de vie puis cliquez sur le + pour en ajouter une.

Dans l’écran suivant, indiquez le nom de la règle (ex : to-glacier) ainsi qu’un préfixe si vous le souhaitez.

Continuer la lecture de Sauvegarde Proxmox sur stockage S3 Scaleway – Glacier
people space apple industry

Sauvegarde Proxmox sur stockage S3 Scaleway

Si vous souhaitez mettre en place un espace de stockage pour vos sauvegardes de machines virtuelles (sous Proxmox), il n’est pas obligatoire de passer par un Proxmox Backup Server ou de configurer une nouvelle machine pour y faire un serveur NFS par exemple.

(Proxmox Backup Server est d’ailleurs un très bon outils que je vous recommande si vous avez la possibilité d’en mettre un en place)

La solution choisie est d’utiliser un stockage S3 (ici chez Scaleway). Vous pouvez d’ailleurs utiliser cette méthode avec d’autres fournisseurs compatibles S3 et effectuer vos sauvegardes sur différentes plateformes #multicloud. Le logiciel S3fs va être utilisé ici comme client S3.

Continuer la lecture de Sauvegarde Proxmox sur stockage S3 Scaleway

Mettre à jour ses paquets avec Rudder – CVE-2021-3156

Profitons du bulletin de sécurité CVE-2021-3156 qui fait beaucoup parler de lui pour voir comment rapidement mettre à jour son infrastructure avec Rudder.

 

Rudder

La méthode est très simple et rapide puisqu’une Directive intégrée à Rudder fait déjà une partie du travail. Il faut créer une nouvelle directive de type Packages et de la catégorie Application Management :

Cliquer ensuite sur Create with latest version :

Indiquer un nom pour cette nouvelle directive puis les paramètres suivants (laisser les autres par défaut) :

  • Package name : sudo
  • Package version : Latest available version

Sur cette même page, sélectionner directement les groupes de machines sur lesquelles vous souhaitez appliquer cette configuration, vous pouvez l’appliquer sur l’ensemble des machines en cochant : Global configuration for all nodes

Valider le tout en cliquant sur le bouton Save :

Et voilà ! Dans les 5 minutes maximum (temps par défaut entre deux vérification par les agents), l’ensemble de vos machines disposeront de la dernière version de sudo.

Conclusion :

En seulement quelques clics et deux champs à renseigner, vous mettez à jour le paquet sudo sur l’ensemble de votre infrastructure.

 

Méthode alternative via Ansible

Un simple playbook permet également de réaliser cette opération :

- hosts: all
  become: yes
  tasks:
   - name: Mise à jour de la liste des paquets
     apt: update_cache=yes

   - name: Installation aptitude
     apt: name=aptitude state=latest

   - name: list
     shell: apt list --upgradable
     register: depot

   - debug: var=depot.stdout_lines

   - name: Mise à jour de sudo
     apt: name=sudo state=latest

Gestion des clefs SSH avec Rudder

Rudder est un outil que j’utilise depuis quelques années maintenant et qui évolue régulièrement. Voici un exemple de ce qu’il est possible de faire avec pour gérer ses clefs SSH.

Rudder, c’est quoi ?

Rudder est un outil de configuration continue et d’audit. Pour résumer, nous lui donnons des directives (règles, configurations, etc…) et il s’assurent qu’elles soient tout le temps appliquées de la façon dont nous les avons définies.

Gestion des clefs SSH :

Lorsque nous devons gérer un parc de machines Linux et que nous devons y autoriser nos clefs SSH, il est fastidieux d’établir une bonne gestion sans outils. Voici comment utiliser Rudder afin de déployer nos clefs SSH sur un groupe de machines.

Continuer la lecture de Gestion des clefs SSH avec Rudder

Virtualisation, récupérer de l’espace disque.

Pour faire suite à un précédent article sur l’optimisation des disques virtuels et après plusieurs mois d’utilisation, je vous conseil d’utiliser régulièrement la commande fstrim pour récupérer de l’espace disque physique sur vos hyperviseurs.

Voici un petit playbook ansible :

hosts: debian
 become: yes
 tasks:
       - name: list
         shell: fstrim -v /
         register: depot   - debug: var=depot.stdout_lines

la partie hosts est bien entendue à modifier pour coller à votre configuration.

Voici un exemple de retour de ce playbook exécuté avec la commande ansible-playbook fstrim.yml :

ssh sudo git … let’s go !

Comment utiliser Git sur une machine distante en SSH et via la commande sudo ?

Voici la problématique en détail pour mieux comprendre le principe.

Vous êtes sur votre ordinateur et vous vous connectez sur un serveur distant via SSH. Pas de problème votre clef est utilisée et vous êtes sur le shell. Maintenant vous devez utiliser la commande git dans un dossier qui n’est accessible que par le compte root et c’est là que le problème intervient. En utilisant la commande sudo, vous exécutez la commande en tant que root et non en tant que votre utilisateur … Voici la procédure à suivre pour faire le tout sans vous prendre la tête.

Connexion SSH

La connexion ssh à une machine avec une authentification par clef est très simple (la configuration du serveur n’est pas abordée ici). Vous aurez tout d’abord dû copier votre clef via la commande :

$ ssh-copy-id user@monserveur

Première chose à faire pour vous connecter à votre serveur est d’utiliser l’option -A de d’OpenSSH :

$ ssh -A user@monserveur

Elle permet d’emporter avec vous votre identité.

Commande sudo

Une fois sur votre machine distante, vous utilisez la commande sudo qui permet entre autre de réaliser des commandes qui nécessites d’être root.

Pour lui dire d’importer avec elle votre identité qui est nécessaire pour utiliser git, vous devez utiliser le paramètre -E comme ceci :

$ cd /etc/myrepo
$ sudo -E git pull

Conclusion

Pour résumer, vous vous connectez en ssh en emportant votre identité puis vous vous servez de la commande sudo pour jouer avec git tout en important également votre identité qui vous permet de vous connecter à vos repos git.

SSH -> SUDO -> GIT


Utiliser PowerShell via SSH

Voici une solution permettant d’interagir avec un ordinateur sous Windows depuis un ordinateur sous Linux ou MacOS. La solution utilisée reste relativement simple à mettre en place et utilise des standards. Nous utiliserons Windows Server 2012R2 et un client Linux.

Installation côté Windows

PowerShell :

Récupérez la dernière version de PowerShell pour Windows ici : https://github.com/PowerShell/PowerShell Ici nous utiliserons la version 6.0.4 dans toute la suite de l’article. L’installeur Windows va placer les fichiers ici : C:\Program Files\PowerShell\6.0.4\

OpenSSH :

Récupérez la dernière version de PowerShell pour Windows ici : https://github.com/PowerShell/Win32-OpenSSH/releases/download/v7.7.2.0p1-Beta/OpenSSH-Win64.zip Pour l’installer, je vous recommande de dé-zippez son contenu à la racine du disque sur C:\. Ouvrez une invite de commande PowerShell en mode administrateur et effectuez les commandes suivantes :

PS: cd C:\OpenSSH-Win64\
PS: powershell.exe -ExecutionPolicy Bypass -File install-sshd.ps1
PS: cmd /c /D mklink c:\pwsh "C:\Program Files\PowerShell\6.0.4"

Il faut aller éditer le fichier de configuration sshd_config situé dans le dossier C:\ProgramData\ssh\ et assurez vous d’avoir les paramètres suivants :

PasswordAuthentication yes
Subsystem powershell c:\pwsh\pwsh.exe -sshs -NoLogo -NoProfile

Maintenant il suffit de lancer le service

PS: net ssh start

Path OpenSSH

Il est aussi indispensable de configurer la variable d’environnement « path » pour que les commandes SSH soient reconnues par le système. Pour cela, rendez-vous dans l’application « Modifier les variables d’environnement système ».

Sélectionnez ensuite « path » et cliquez sur « Modifier… ».

Rajoutez le texte suivant à la fin de la ligne (sans oublier le ; ) et validez.

;C:\OpenSSH-Win64\

Installation côté Linux

Pour la partie Linux, pas besoin de SSH il est normalement déjà installé sur votre machine d’administration. La méthode d’installation de PowerShell est la méthode universelle mais sachez que des paquets pour diverses distributions existes (Debian, Red-Hat).
Téléchargez la version stable en cours ici :

https://github.com/PowerShell/PowerShell/releases/tag/v6.0.4

Les commandes suivantes suffisent :

$ wget https://github.com/PowerShell/PowerShell/releases/download/v6.0.4/powershell-6.0.4-linux-x64.tar.gz
$ tar -xvzf powershell-6.0.4-linux-x64.tar.gz
$ cd powershell-6.0.4-linux-x64

Utilisation

Maintenant que tout est installé, voici comment accéder en ssh à votre serveur Windows et y exécuter des commandes via PowerShell. Cette partie reprend la documentation officielle de Microsoft.

Dans le dossier où se trouve PowerShell, lancez le script pwsh

./pwsh
PS /powershell-6.0.4-linux-x64>

Créez ensuite la connexion au serveur :

> $session = New-PSSession -HostName srv.example.com -UserName Administrateur

Vous allez devoir accepter le certificat la première fois et indiquer votre mot de passe. Vérifions que la sessions est bien là :

> $session

Si vous souhaitez vous connecter sur le Shell distant, voici la commande :

> Enter-PSSession $session

Et si vous souhaitez exécuter votre script « script.ps » situé à la racine du disque C sur la machine distante, voici ce qu’il faut faire :

> Invoke-Command $session -ScriptBlock { C:\script.ps1 }

Optimiser la taille des disques virtuels de Proxmox

Cet article vous explique comment réduire l’espace disque physique occupé par vos disques de stockage virtuels. Sous Proxmox, les disques durs virtuels sont dynamiques, c’est à dire que lorsque vous définissez un disque dur de 100 Go par exemple, en réalité, sur la machine hôte, il n’occupe que quelques Go une fois le système installé. Ce qui évite d’occuper directement les 100 Go et de perdre du temps à la création de celui-ci.

Problématique

Ce système fonctionne bien sauf qu’une fois que l’espace disque à été alloué, il restera occupé même une fois vidé.

Par exemple, nous ajoutons 50 Go de données à notre machine qui en contenait déjà 10, la taille physique du disque virtuel est donc montée à 60 Go. Si nous supprimons ensuite ces 50 Go, la taille physique ne change pas et n’est donc pas réduite. Il faut le voir comme un cliquet ( que l’on ne peux que monter ). Cet espace non utilisé ne pose pas de problème directement, peut vite ralentir les sauvegardes Proxmox en utilisant des dizaines voir centaines de Go qui ne sont plus utilisés réellement.

Solution

  • disque SCSI

Pour pouvoir réduire l’espace disque physique, il faut avoir au préalable configuré le disque dur en SCSI et avoir coché l’option Discard.

Ensuite, dans votre machine virtuelle, il suffit d’utiliser la commande fstrim (beaucoup plus connue maintenant avec l’utilisation des SSD).

Continuer la lecture de Optimiser la taille des disques virtuels de Proxmox

Géolocalisation avec Apache

world-regions-300px

Voici comment mettre en place une redirection vers un site internet en utilisant la géolocalisation directement dans un VirtualHost avec Apache.

1 – Installation des paquets :

Nous faisons cette manipulation sous Debian avec Apache 2.4 déjà installé. Il faut donc rajouter les modules permettant de gérer GeoIP :

# apt-get install libapache2-mod-geoip geoip-database-contrib
  • libapache2-mod-geoip permet de rendre apache compatible avec la géolocalisation
  • geoip-database-contrib permet de mettre à jour la base de correspondance IP <-> Pays

2 – Activation des modules :

L’activation des modules est simple et ne prend qu’une seule ligne :

# a2enmod rewrite geoip

Nous pouvons également mettre à jour la base d’IP comme ceci :

# geoip-database-contrib_update
Downloading: http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
Downloading: http://geolite.maxmind.com/download/geoip/database/GeoIPv6.dat.gz
Downloading: http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
Downloading: http://geolite.maxmind.com/download/geoip/database/GeoLiteCityv6-beta/GeoLiteCityv6.dat.gz
Downloading: http://geolite.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz
Downloading: http://geolite.maxmind.com/download/geoip/database/asnum/GeoIPASNumv6.dat.gz

Il faut savoir que le paquet installe également une tâche cron qui permet de maintenir la base à jour régulièrement. A savoir : 0 4 10 * *, soit à 4h00 du matin chaque 10 du mois.

3 – Configuration :

Nous réglons ensuite le module GeoIP pour qu’il aille chercher la bonne base d’IP en éditant le fichier de configuration du module pour Apache :

# vim /etc/apache2/mods-enabled/geoip.conf

Il suffit de dé-commenter la ligne avec le paramètre GeoIPDBFile pour lui indiquer le nouveau chemin :

<IfModule mod_geoip.c>
 GeoIPEnable On
 GeoIPDBFile /var/lib/geoip-database-contrib/GeoIP.dat
</IfModule>

Nous terminons par le vhost que l’on souhaite modifier en intégrant ces règles qui permettent de rediriger les IP Françaises vers un site Français et celles qui ne sont pas françaises vers le reste du monde :

RewriteEngine on
 RewriteCond %{ENV:GEOIP_COUNTRY_CODE} !^(FR)$
 RewriteRule ^(.*)$ http://world.site.com/ [L]
 RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^(FR)$
 RewriteRule ^(.*)$ http://france.site.fr/ [L]

Et pour finir, ne pas oublier un contrôle de configuration apache, puis un redémarrage du service qui va activer les modules et appliquer la nouvelle configuration :

# service apache2 restart

Reverse proxy avec Apache

Après Nginx voici un autre exemple de reverse proxy, cette fois-ci nous utiliserons Apache avec Redmine.

Si vous utilisez un serveur avec Redmine, voici l’url d’accès à l’application :

http://redmine.myserver.com:3000

De même que pour l’exemple de Kibana, cette URL n’est ni pratique ni jolie, ni même utilisable à travers certains réseaux qui limitent l’utilisation de certains port. Cela donne un avantage de plus quand à l’utilisation d’un reverse proxy.

Nous commençons par installer apache :

httpd_logo_wide_new

Sous Gentoo (en ayant ajouter les variables USE proxy et proxy_http :

# emerge -avq apache

Sous Debian :

# apt-get install apache2

Nous configurons ensuite le vhost correspondant à Redmine et dans le bloc <VirtualHost *:80> nous ajoutons ces lignes :

ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/

ProxyPass permet d’indiquer que nous relayons les requêtes envoyées sur la racine vers notre Redmine sur le port 3000.

ProxyPassReverse permet de retransmettre les informations entre les deux parties.Voilà, votre Redmine est joignable directement sur une URL sur le port 80 :

http://redmine.myserver.com