Juin en anglais

Voilà une recette particulièrement simple & peu coûteuse pour faire une boisson simili-lactée, quand on a la flemme d’aller dans un boba shop. Il faut quand même s’armer d’une heure de patience pour pouvoir déguster le breuvage, vous voilà prévenu·prévenue.

Les ingrédients

Pour 1 personne.

  • 2 tasses de lait végétal (je conseille du lait d’avoine, ou bien du soja douceur)
  • 4 cuillères à café de sucre roux
  • 1 cuillère à café de café soluble
  • Des glaçons (facultatif)

Le matériel

  • Une petite casserole (500mL)
  • Une tasse (~25mL)
  • Une cuillère à café
  • Une spatule
  • Le contenant final de votre choix (mug, gobelet à bubble tea…)

Préparation

  • Verser le lait végétal dans la casserole.
  • Ajouter le sucre roux et faire cuire le mélange jusqu’à ébullition, à feu moyen. Attention, le lait végétal ne bouillit pas exactement comme l’eau : considérez que le mélange a atteint le stade d’ébullition quand des bulles apparaissent tout le long du bord de la casserole. Bien remuer régulièrement avec la spatule, pour éviter que le sucre ne brûle au fond de la casserole.
  • Retirer du feu.
  • Ajouter le café et mélanger.
  • Laisser reposer 20 minutes. (ne pas hésiter à utiliser un minuteur)
  • Verser le tout dans le contenant final.
  • Mettre au frigo au moins 40 minutes.

Dégustation

Sortez votre préparation du frigo; si vous avez des glaçons, c’est le moment de les ajouter à votre boisson. Vous voilà avec un brown sugar milk coffee maison, n’hésitez pas à le remuer un peu avant de le boire.

#recette #vegan #boisson

Edito

Cet article a été rédigé et publié en quelques minutes, son accessibilité est moins travaillée que d’habitude.

Environnement

  • OS serveur : Debian 10 à jour
  • OS client : Distribution GNU/Linux à jour
  • Un utilisateur avec les droits sudo sur chaque machine

Côté serveur #1

sudo apt install wireguard
wg genkey | tee private_key | wg pubkey > public_key
sudo mkdir /etc/wireguard/helper

Créer et éditer le fichier de configuration du serveur, pour cet exemple, c’est wg0.conf.

[Interface]
Address = 10.200.200.1/24
ListenPort = 51821
PrivateKey = [coller ici le contenu du fichier 'private_key' généré précedemment]
PostUp = /etc/wireguard/helper/add-nat-routing.sh
PostDown = /etc/wireguard/helper/remove-nat-routing.sh

Créer et éditer le fichier /etc/wireguard/helper/add-nat-routing.sh.

#!/bin/bash
IPT="/sbin/iptables"
IPT6="/sbin/ip6tables"          
 
IN_FACE="eth0"                   # interface réseau connectée à Internet
WG_FACE="wg0"                    # interface réseau connectée à WireGuard
SUB_NET="10.200.200.0/24"            # sous-réseau de WireGuard en IPv4
WG_PORT="51821"                  # port UDP utilisé par WireGuard 
SUB_NET_6="fd42:42:42:42::/112"  # sous-réseau de WireGuard en IPv6
 
## règles IPv4 ##
$IPT -t nat -I POSTROUTING 1 -s $SUB_NET -o $IN_FACE -j MASQUERADE
$IPT -I INPUT 1 -i $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -I INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
 
## IPv6 (à décommenter si utilisation d’IPv6, non testé) ##
## $IPT6 -t nat -I POSTROUTING 1 -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE
## $IPT6 -I INPUT 1 -i $WG_FACE -j ACCEPT
## $IPT6 -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
## $IPT6 -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT

Créer et éditer le fichier /etc/wireguard/helper/remove-nat-routing.sh.

#!/bin/bash
IPT="/sbin/iptables"
IPT6="/sbin/ip6tables"          
 
IN_FACE="eth0"                   # interface réseau connectée à Internet
WG_FACE="wg0"                   # interface réseau connectée à WireGuard
SUB_NET="10.200.200.0/24"            # sous-réseau de WireGuard en IPv4
WG_PORT="51821"                 # port UDP utilisé par WireGuard 
SUB_NET_6="fd42:42:42:42::/112"  # sous-réseau de WireGuard en IPv6
 
# règles IPv4 #
$IPT -t nat -D POSTROUTING -s $SUB_NET -o $IN_FACE -j MASQUERADE
$IPT -D INPUT -i $WG_FACE -j ACCEPT
$IPT -D FORWARD -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT -D FORWARD -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -D INPUT -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
 
# règles IPv6 (à décommenter si utilisation d’IPv6, non testé) #
## $IPT6 -t nat -D POSTROUTING -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE
## $IPT6 -D INPUT -i $WG_FACE -j ACCEPT
## $IPT6 -D FORWARD -i $IN_FACE -o $WG_FACE -j ACCEPT
## $IPT6 -D FORWARD -i $WG_FACE -o $IN_FACE -j ACCEPT

Rendre les scripts exécutables

sudo chmod +x /etc/wireguard/helper/*.sh

Créer et éditer le fichier /etc/sysctl.d/10-wireguard.conf

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Prendre en compte les modifications de sysctl.d

sysctl -p /etc/sysctl.d/10-wireguard.conf

Supprimer le fichier private_key

Côté client #1

wg genkey | tee private_key | wg pubkey > public_key

Créer et éditer le fichier de configuration client de WireGuard, dans cet exemple wg0-client.conf.

[Interface]
Address = 10.200.200.2/32
PrivateKey = [coller ici le contenu du fichier 'private_key' **généré côté client**]
DNS = 80.67.169.12, 80.67.169.40

[Peer]
PublicKey = [coller ici le contenu du fichier 'public_key' **généré côté serveur**
Endpoint = [adresse IP Internet du serveur]:51821
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 21

Supprimer le fichier private_key.

Côté serveur #2

Éditer /etc/wireguard/wg0.conf.

[…]

[Peer]
PublicKey = [coller ici le contenu du fichier 'public_key' **généré côté client**]
AllowedIPs = 10.200.200.2/32

Démarrer WireGuard, puis l’activer au démarrage du serveur.

sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0.service

Côté client #2

Démarrer WireGuard.

sudo wg-quick up wg0-client

Source

#IT #WireGuard #VPN

Environnement utilisé

Un CPX21 de l’offre Cloud de Hetzner. Je pense que les modifications restent intéressantes pour toute autre configuration équivalente ou moins puissante que celle-ci. Le serveur tourne sous Debian 10.

Pré-requis

Avoir déjà configuré son serveur SSH pour se connecter avec un utilisateur ayant accès aux droits d’administration.

Installer et configurer zRAM

zRAM est un outil permettant de compresser la RAM, pour gagner en mémoire vive disponible. Pour plus de détails, je vous recommande de lire l’introduction de cette page de documentation.

On installe le paquet.

sudo apt install zram-tools

Une fois installé, zRAM se lance tout seule avec une configuration par défaut. Pour configurer zRAM, on édite le fichier /etc/default/zramswap. On modifie la valeur PERCENTAGE pour augmenter la capacité que peut gérer zRAM, la valeur par défaut devrait être 10, on la passe à 100. On relance le service. pour que la modification fasse effet.

sudo systemctl restart zramswap.service

Installer GitLab

Suivre cette documentation

Limiter le nombre de processus

Par défaut, GitLab fait tourner un nombre important de processus, ce qui fait fortement ralentir les serveurs peu puissants. Pour résoudre ce problème, on va éditer /etc/gitlab/gitlab.rb et réduire le nombre de processus simultanés utilisés par les services de GitLab.

[…]
puma['worker_processes']=1
[…]
sidekiq['max_concurrency']=5

On relance GitLab pour que les modifications soient prises en compte.

sudo gitlab-ctl reconfigure

Une fois GitLab relancé, tout devrait fonctionner correctement et l’utilisation de la RAM du serveur ne devrait pas exceder 90%.

Sources

#IT #SysAdmin #GitLab

Pré-requis

Avoir déjà configuré son serveur SSH pour se connecter avec un utilisateur ayant accès aux droits d’administration.

Mettre en place l’environnement

Tout ce qui est indiqué dans cette partie a lieu sur le serveur

Pour notre exemple, nous allons assumer que vous souhaitez créer un utilisateur qui va publier du contenu web. Les répertoires indiqués le sont à titre d’exemples, adaptez les chemins en conséquence de vos besoins.

Créer l’utilisateur et son groupe

On créé l’utilisateur, puis son groupe, on rajoute l’utilisateur au groupe et enfin, on s’assure qu’il ne puisse accéder qu’au client SFTP.

sudo useradd <username>
sudo groupadd <groupname>
sudo gpasswd -a <username> <groupname>
sudo usermod -s  /usr/lib/openssh/sftp-server <username>

Créer le répertoire de l’utilisateur

On créé le répertoire, on s’assure qu’il appartiennent bien à l’utilisateur root, de le protégér d’écriture de la part d’autres utilisateurs, puis on le définit comme répertoire d’accueil de l’utilisateur.

sudo mkdir /srv/www/domain.tld/
sudo chown root /srv/www/domain.tld
sudo chmod go-w /srv/www/domain.tld
sudo usermod -d /srv/www/domain.tld/ <username>

Créer le répertoire web

C’est dans ce répertoire que l’utilisateur aura les droits pour créer, supprimer et éditer des fichiers et dossiers. On créé le répertoire, on nomme l’utilisateur et son groupe propriétaires puis on leur donne les droits nécessaires.

sudo mkdir /srv/www/domain.tld/public_html
sudo chown <username>:<groupname> /srv/www/domain.tld/public_html
sudo chmod ug+rwX /srv/www/domain.tld/public_html

Finaliser l’environnement

N’oubliez pas de rajouter la clef publique SSH de votre utilisateur dans le dossier nécessaire.

On créé le répertoire .ssh nécessaire et le fichier authorized_keys dans lequel on va mettre la clef publique, enfin, on rend l’utilisateur propriétaire et on s’assure qu’il puisse lire le fichier.

sudo mkdir /srv/www/domain.tld/.ssh
sudo touch /srv/www/domain.tld/.ssh/authorized_keys
sudo chown -R <username>:<groupname> /srv/www/domain.tld/.ssh
sudo chmod u+rX /srv/www/domain.tld/.ssh

Il n’y a plus qu’à copier-coller la clef publique SSH dans le fichier authorized_keys.

Bloquer l’utilisateur dans l’environnement

Tout ce qui est indiqué dans cette partie a lieu sur le serveur

On édite le fichier /etc/ssh/sshd_config on vérifie si la directive Subsystem est bien comme indiquée ci-dessous, sinon, on la corrige ou la créé.

[…]
Subsystem sftp internal-sftp
[…]

On cherche le bloc AllowUsers, s’il est commenté (avec un en début de ligne #), on le décommente (on efface le #) et puis on y ajoute notre utilisateur.

[…]
AllowUsers <username>
[…]

On se rend à la fin du fichier de configuration, et on rajoute la partie suivante.

[…]
Match User <username> # On indique que notre partie concerne l’utilisateur
	ChrootDirectory /srv/www/domain.tld # Là où on veut enfermer l’utilisateur
	AllowTCPForwarding no
	X11Forwarding no
	ForceCommand internal-sftp # On force l’utilisateur à utiliser seulement le terminal SFTP

On redémarre SSH pour que la nouvelle configuration soit prise en compte.

sudo systemctl restart sshd.service

Côté client

Sur le PC de l’utilisateur·trice, on génère simplement la clef, et on utilisera SFTP pour se connecter de manière sécurisée.

Tester la connexion à l’environnement

En essayant de se connecter via SSH avec l’utilisateur SFTP, on devrait obtenir le message suivant : This service allows sftp connections only.. SFTP devrait se connecter sans soucis, la commande pwd affichant /. Toute tentative d’ajouter du contenu dans le dossier racine devrait échouée mais une fois dans le dossier /public_html, l’utilisateur devrait pouvoir ajouter, éditer et supprimer des fichiers et dossiers.

Sources

Pour aller plus loin…

Créer un seul groupe pour les utilisateurs SFTP

Si on doit créer plusieurs utilisateurs, avoir un seul groupe à gérer peut être plus pratique. On peut par exemple l’appeler sftp. À la création de nouveaux utilisateurs, on n’aura qu’à directement ajouter ces derniers au groupe comme indiqué au début de ce billet.

Un lien pour approfondir

#IT #SysAdmin #SFTP #Linux