14 Oct 2019, 00:00

Prévoir la taille des données à déplacer lors d'une réduction de partition NTFS
/sbin/ntfsresize --force --no-action -s 100G /dev/sdX1 | grep -e ERROR -e relocations

--force peut ne pas être nécessaire
-s indique la nouvelle taille de partition, par défaut en octets, et peut être suivi des suffixes k,M,G,ki,Mi ou Gi

On peut aussi

07 Oct 2019, 00:00

Notes sur systemd

Gestion des services

Les services sont stockés sous forme de fichier .services présents dans /lib/systemd/system/ et /etc/systemd/system/.
Lorsqu’ils sont activés, des liens vers ces fichiers sont présents dans des dossiers du type /lib/systemd/system/my-service.wants ou /lib/systemd/system/runlevel.wants.

Pour désactiver le démarrage automatique d’un service :
sudo systemctl disable mon-service.service
Pour le réactiver :
sudo systemctl enable mon-service.service
Vérifier s’il va démarrer automatiquement au prochain boot :
systemctl is-enabled mon-service.service
Voir s’il est en cours de fonctionnement :
systemctl status mon-service.service

06 Oct 2019, 00:00

Désactiver le formatage automatique des cellules en tant que nombre sous LibreOffice Calc

Source

Ouvrir un classeur vierge. Taper F11, pour Ouvrir les Styles et formatages.
Modifier “Par défaut” (modifie les caractéristiques de toutes les celleules, pour ce document uniquement)“, et définir le style par défaut pour les nombre en tant que “Texte”.

Fichier -> Modèles -> Enregistrer comme modèle
Ranger dans une catégorie, lui donner un nom (par ex. “FormatageAutoEnTexte”), cocher “par défaut” en bas, et valider.

Ainsi, dans tous les nouveaux documents, ce réglage sera appliqué, et les 0 en début de chaîne ne sauteront plus.

23 Sep 2019, 00:00

Obtenir tous les numéros de série des disques

Avec 12 disques (a -> l)

for i in {a..l}; do echo sd$i; udevadm info --query=all --name=/dev/sd$i | grep ID_SERIAL_SHORT; done

29 Aug 2019, 00:00

Reconfiguration GRUB2 sur système EFI, avec partition slash chiffrée via LUKS et partition boot séparée

Se fait via un live-cd démarré en EFI, de la même architecture que le système à dépanner (pour que le chroot fonctionne)

  • sdX1 : ESP (EFI System Partition)
  • sdX2 : partition slash chiffré par LUKS
  • sdX3 : partition boot

    # On déchiffre et monte slash
    cryptsetup open /dev/sdX2 slash
    mount /dev/mapper/slash /mnt
    
    # On monte l'ESP et la partition /boot
    mount /dev/sdX3 /mnt/boot
    mount /dev/sdX1 /mnt/boot/efi
    
    # On monte les fichiers systèmes temporaires
    mount -o bind /sys /mnt/sys
    mount -o bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
    mount -o bind /dev /mnt/dev
    mount -o bind /proc /mnt/proc
    mount -o bind /run /mnt/run
    
    
    chroot /mnt
    grub-install /dev/sdX
    update-grub
    # On recrée l'initramfs, afin qu'il demande le mot de passe LUKS
    update-initramfs -k all -u
    

29 Jul 2019, 00:00

Docker

Une source intéressante
Images, conteneurs et volumes
Dockerfile build

Installation sous Debian

  • On installe avec

    sudo apt install docker.io
    

    à partir de buster ; sinon, utiliser le site docker.io.

  • Puis on peut faire

    sudo adduser user docker
    

    pour ne pas avoir à taper sudo à chaque commande.

Gestion des images

  • Chercher une image Debian officielle, en se basant sur le score de l’image

    docker search --filter=stars=1000 debian
    
  • Récupérer cette image en local (stocké dans /var/lib/docker/, en grosse partie sous forme de diff dans overlay2/ )

    docker pull debian:tag
    # si :tag est omis, docker cherchera :latest
    
  • Lister les images locales

    docker image ls -a
    
    # ou
    docker images
    
  • Créer une image depuis un Dockerfile

    # In folder containing the Dockerfile
    docker build -t "my-image123:test" .
    
  • Pour supprimer une image

    docker rmi my-image123:test
    # on peut aussi utiliser l'id de l'image
    

docker build & Dockerfile

Lien qui en parle aussi
Sert à génerer des images modifiées à partir d’images existantes.
Utilise un fichier Dockerfile (nom non négociable).
Celui-ci est formaté avec une instruction FROM qui définit l’image de base utilisée. Ce peut être un nom type debian ou un ID type 00bf7fdd8baf

On peut utiliser RUN pour lancer des instructions shell pour modifier notre image (par exemple installer des paquets).

On peut gérer le programme lancé au démarrage d’un conteneur instancié sur cette image (par défaut bash chez Debian), ainsi que la commande executée par ce programme, via les instructions ENTRYPOINT et CMD. Plus de détails ici.
En gros, ENTRYPOINT est le binaire lancé lorsque le conteneur démarre (habituellement bash), et CMD est la commande éventuelle lancée par cet entrypoint. Définir un entrypoint sur autre chose que bash permet de faire du container un exécutable, qui ne lancera que ce pour quoi il est fait.
Les instructions RUN, ENTRYPOINT et CMD peuvent être écrites de 2 formes, la forme shell et la forme exécutable. Dans la forme shell, elle seront exécutées via sh -c alors qu’en forme exécutable, la commande est appelée directement :

# Shell form  
RUN /path/to/command -o option arg otherarg

# Exec form  
RUN ["/path/to/exec", "-o", "option", "arg", "otherarg"]

Un exemple de Dockerfile qui lance un serveur apache basique :

FROM debian

RUN apt-get update \
&& apt-get install -y apache2 nano

EXPOSE 8080 80

CMD apachectl -D FOREGROUND

On peut ensuite construire l’image désirée via docker build :

docker build -t nom:tag /path/to/folder/with/Dockerfile
# --rm=false : permet de ne pas supprimer les conteneurs intermédiaires (cache), même après un build successful

Gestion des conteneurs

Un conteneur est instancié à partir d’une image.

  • Créer un conteneur à partir de cette image

    # en version simple
    docker create debian
    # qui va chercher debian:latest
    # on peut aussi faire
    
    # en plus complet
    docker create -ti --name my-app123 --hostname app --net my-net123 -p 8080:80 debian:tag welcome-command
    # les options doivent être avant le nom de l'image de base
    # -t pour --tty, ce qui permettra de lancer le conteneur avec un shell root@truc:/# . Sans ça, il se coupe si rien à faire
    # -i pour --interactive , ce qui laissera la porte ouverte au conteneur pour recevoir des commandes (STDIN ouvert)
    # si aucun nom s'est spécifié, Docker en génerera un poétique
    # si aucun hostname n'est spécifié, il sera géneré aléatoirement
    # --net ou --network permet d'attacher le conteneur à un réseau choisi (doitj être créé auparavant
    # -p pour exposer les ports ; voir section réseau
    # on peut spécifier, après le nom d'image, la commande à exécuter (typiquement bash)
    
  • Démarrer ce conteneur

    docker start my-app123
    

    Le conteneur est lancé, mais ne s’affiche pas dans notre terminal (juste son nom).
    Il faut l’attacher, pour avoir le shell à l’écran et pouvoir interagir.

    docker attach my-app123
    

    Ou encore

    docker exec -it container_name bash
    

    On peut directement attacher le shell lors de la création du conteneur, mais il faut alors spécifier l’option -i pour pouvoir interagir avec le conteneur (taper des commandes).

    docker start -ia my-app123  # --interactive --attach
    # -a , --attach pour voir l'état du conteneur
    # -i pour pouvoir taper des commandes
    

    On peut ensuite détacher le conteneur avec Ctrl-P -> Ctrl-Q.

  • Éteindre ce conteneur

    docker stop my-app123
    
    docker kill my-app123 # pour forcer l'extinction
    
  • Lister les conteneurs

    docker container ls
    # ou en plus court
    docker ps
    # pour lister les conteneurs en cours d'éxécution
    
    docker ps -a
    # pour lister tous les conteneurs, même éteints.
    
    docker ps -s
    # pour lister la taille des conteneurs
    
  • Supprimer un conteneur précis

    docker container rm my-app123
    # on peut aussi utiliser l'id
    
  • Supprimer tous les conteneurs qui ne sont pas en train de tourner

    docker container prune
    # -f si on souhaite ne pas avoir de prompt de confirmation
    

docker run

Combine docker pull, docker create et docker start

docker run name
# télécharge si nécessaire l'image "name:latest", crée un container avec un nom aléatoire, et le lance
# on peut passer à docker run les mêmes arguments que docker create
docker run --name="my-app123" -p 80:80 -e TERM=xterm -d --net my-net123 --ip 172.18.0.23 demo-docker

Réseau

Doc chez docker

Docker crée une interface virtuelle pour chaque réseau créé. Par défaut, c’est la carte docker0 qui crée le réseau bridgé 172.17.0.0/24 avec l’adresse 172.17.0.1.
Il y’a différents types de réseau : bridge (réseau virtuel “simple”, choix par défaut), host (le conteneur se connecte directement via la pile réseau de la carte de l’hôte), overlay (surtout pour le swarm), macvlan.

On peut créer des réseaux (bridgés) définis sur mesure. Ces réseaux se comporteront différemment du réseau par défaut. Notamment, les machines pourront communiquer entre elles via leur adresse IP, mais également via le nom de conteneur. De plus, tous les ports de chaque conteneur seront ouverts vers tous les autres conteneurs sur le même réseau (et, par défaut, aucun port ouvert vers l’extérieur). Un conteneur peut être connecté à plusieurs réseaux.
Chaque conteneur lancés aura aussi une interface virtuelle type veth1234567.

  • lister les réseaux

    docker network ls
    
  • voir le détail d’un réseau

    docker network inspect network-name
    
  • créer un réseau

    docker network create --subnet 172.18.0.0/24 my-net123
    
  • lancer un container sur un network

    docker run --net my-net123 --ip 172.18.0.23
    
  • Connecter un conteneur sur un réseau (peut être fait à la volée pour un réseau déifni, mais le conteneur doit être éteint pour le faire sur le réseau par défaut docker0)

    docker network connect my-net123 my-app123
    
  • Déconnecter un conteneur d’un réseau (peut être fait à la volée pour un réseau déifni, mais le conteneur doit être éteint pour le faire sur le réseau par défaut docker0)

    docker network disconnect my-net123 my-app123
    
  • Supprimer un réseau

    docker network rm my-net123
    
  • retirer les réseaux inutiles

    docker network prune
    

Exposition et publication de ports

Un article intéressant

L’exposition de ports peut se faire dans le Dockerfile, ou bien à la création du conteneur. Toutefois, elle est uniquement là pour documenter les ports utilisés par le conteneur, et n’aura aucun effet pratique. Cela peut se faire via docker create --expose 8080:80/tcp ou bien dans le Dockerfile via EXPOSE 8080 80/tcp.

La publication de ports sert effectivement à “ouvrir” le port du conteneur depuis l’hôte (à la manière des routeurs). Ainsi, le service fourni par le conteneur deviandra accessible via l’IP de l’hôte sur le port choisi. Cette publication ne peut se faire que lors de la création d’un conteneur.

docker create -p 8080:80/tcp debian
# tcp est le défaut, et peut être omis, ou remplacé par udp

va rediriger le port 8080 de l’hôte vers le port 80 du conteneur. Ainsi, seul l’IP de l’hôte a besoin d’être routable.
On peut également utiliser l’option --expose, mais celle-ci ne semble avoir aucun effet si l’option -p n’est pas utilisée.

Exposer un port sur un conteneur déjà lancé

Volumes

Servent à monter un dossier de l’hôte chez le client.
Peut être déclaré dans le Dockerfile (non recommandé ici), ou au moment de la création du conteneur.

Docker-compose

Doit être installé en sus de docker.

sudo apt install docker-compose

Sert automatiser, via fichier de conf docker-compose.yml, la construction d’image sur mesure, ainsi que la création de conteneurs basé sur ces images, et leur paramétrage (port, etc…).

Si on est dans un dossier testcompose, on peut avoir le fichier docker-compose.yml suivant :

version: '3'

services:

  apache-test:
    build:
      context: apache-folder
      dockerfile: Dockerfile
    ports:
      - "8080:80"
    restart: always

Ceci définit un service apache-test, dont le Dockerfile et les fichiers pouvant être nécessaires à se construction se trouvent dans le dossier (context) apache-folder. Le port 80 sera publié via le port 8080 de l’hôte.

On peut construire l’image avec docker-compose build. Elle sera nommée testcompose_apache-test (nomdudossier_nomduservice).
Ceci crée aussi un réseau testcompose_default auquel seront liés tous les services définis dans le docker-compose.yml.

On peut aussi construire l’image, puis démarrer un container basé sur cette image, via docker-compose up.
Ceci va créer un container dont le nom est testcompose_apache-test_1.
On peut passer les conteneurs en arrière-plan avec l’option -d.

Docker secrets

Lire ici !

Variable d’environnement

Voir ici : https://vsupalov.com/docker-arg-env-variable-guide/

En gros,on a :

  • Le fichier .env : n’est pris en compte qu’au moment de l’interprétation du fichier docker-compose.yml, et sert à remplacer des variables dans ce fichier par des valeurs. Elles ne seront absolument PAS visibles par le conteneur lors de son exécution.

  • Les arguments type docker create -e VAR=val pour définir des variables qui seront accessibles dans le conteneur en exécution (on peut les lister avec la commande env lancée dans le conteneur). Ce mécanisme est utilisable dans docker-compose via la directive environment:

  • L’argument docker create --env-file=./fichier qui permet de définir un fichier dnas lequel lire des variables, qui seront accessibles comme si elles avaient été passées via -e. Ce mécanisme est utilisable dans docker-compose via la directive env_file:

Troubleshooting

Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use

Signifie que le port sur lequel on essaye de lancer une machine est déjà pris par une autre machine.

Logs

docker logs my-app

Les logs sont stockés dans le fichier /var/lib/docker/containers/<container_id>/<container_id>-json.log

On peut mettre en place une rotation des fichiers de log en éditant le fichier /etc/docker/daemon.json

{
"log-driver": "json-file",
"log-opts": {
    "max-size": "10m",    
    "max-file": "3"    
    }
} 

puis systemctl restart docker (ATTENTION : redémarre tous les containers).
N’affecte que les containers nouvellement lancés.
Source

19 Jun 2019, 00:00

Désactiver la mise en veille de la carte son sous Linux

Sous Linux, il arrive que, pour économiser de l’énergie, la carte son se mette en veille après quelques temps d’inactivité. Ceci génère chez moi des craquements assez désagréables lors de sa remise en fonctionemment, ou parfois un craquement très régulier tout le long de la veille.

Pour voir si la mise en veille est activée :

cat /sys/module/snd_hda_intel/parameters/power_save

S’il contient autre chose que 0, alors le mode powersave est activé.

Pour le désactiver, on peut ajouter le fichier /etc/modprobe.d/snd_disable_powersave.conf et entrer dedans la ligne suivante :

options snd_hda_intel power_save=0

Puis redémarrer, ou bien décharger/recharger le module.

10 Feb 2019, 00:00

Notes sur fail2ban

Généralités

2 articles qui m’ont inspiré :
http://xmodulo.com/configure-fail2ban-apache-http-server.html
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-centos-7

fail2ban se base sur l’analyse des logs pour bannir des adresses ip (via, par défaut, la création de règles iptables) qui auraient enfreint certaines règles.
Les expressions régulières qui servent à analyser les fichiers de conf se trouvent dans le dossier /etc/fail2ban/filter.d/.

Les fichiers de conf sont lus dans l’ordre suivant, sachant que c’est la dernière mention d’un paramètre redondant qui sera prise en compte :

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.local
/etc/fail2ban/jail.d/*.local

Il est conseillé de ne pas toucher aux fichier .confs (ce qui permet entre autres de ne pas perturber les mises à jour système) mais de rajouter nos propres règles dans des fichiers .local.

On voit dans jail.conf des paramètres par défaut (sous la balise [DEFAULT]) :

# "bantime" is the number of seconds that a host is banned.
bantime  = 600

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = 600

# "maxretry" is the number of failures before a host get banned.
maxretry = 5

On voit que si une ip échoue à se connecter 5 fois de suite (maxretry) en moins de 600 secondes (findtime), alors elle sera bannie pendant 600 secondes (bantime).
Il y’a aussi dans cette même section un nom fichier de filtre par défaut, qui reprend le nom de la jail :

filter = %(__name__)s

Cela dit que le fichier de filtre qui sera récupéré est le même que le nom de la jail.

Plus bas, on voit des exemples de jails, de type

[sshd]

port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Ces jails sont définies par défaut, mais non activées. Pour ceci, il faut leur donner le paramètre enabled = true. Par défaut, sous Debian, seul le service sshd est protégé par fail2ban, via le fichier /etc/fail2ban/jail.d/defaults-debian.conf.

Installation et configuration

Pour installer :

sudo apt install fail2ban

On peut ensuite créer par exemple un fichier /etc/fail2ban/jail.d/ssh.local qui contiendra :

[sshd]
enabled = true
port = 12345
findtime  = 60
maxretry = 5

afin de spécifier un port custom, et laisser le droit à 5 essais par minute.

On peut aussi créer /etc/fail2ban/jail.d/apache.local pour activer fail2ban pour apache :

# detect password authentication failures
[apache-auth]
enabled  = true
port     = http,https
findtime  = 60
maxretry = 5

pour un fail2ban sur l’authentification par mot de passe.

02 Feb 2019, 00:00

Notes sur dm-crypt et LUKS

Source principale : la FAQ (ou en tout cas un mirroir) de cryptsetup

dm-crypt et LUKS

dm-crypt chiffre/déchiffre à la volée les données grâce à la master key, qui est directement dérivée du mot de passe fourni. Aucune structure spéciale n’est visible sur le disque, c’est un pur chiffrement 1:1. Si des secteurs sont corrompus, cela n’affectera aucunement les autres secteurs. Il n’y a aucun garde-fou intégré ; si on se trompe dans la clé entrée, ou dans les paramètres de chiffrement, les données seront lues/écrites avec la mauvaise clé, donc risque non-négligeable de perte de données si fausse manipulation.

LUKS est une surcouche à dm-crypt qui stocke la master key salée puis chiffrée dans une en-tête LUKS, qui précède les données chiffrées. Cette clé est déchiffrable grâce à plusieurs mots de passe (jusqu’à 8 différents) stockés dans des “key slots”, situés dans le header également. On peut donc ajouter/supprimer des mots de passe différents pour un même volume. Avec un mauvais mot de passe, LUKS ne nous laissera pas lire/écrire des données incorrectes.
Il est essentiel de backuper ce header à part, car sans lui, il sera impossible d’utiliser les données chiffrées. Il “décrit” la manière dont les données doivent être déchiffrées. Notamment grâce au sel, qui est cryptographiquement non-retrouvable.

Installation et chiffrement

On installe

apt install cryptsetup

Il faut consacrer un périphérique (disque, partition…) à LUKS. Toutes les données dessus seront bien sûr détruites. Ici, c’est sdX.
Il est conseillé d’effacer tous les headers d’anciens FS sur la cible, pour être sûr de ne pas avoir de fsck automatique ou autres joyeusetés qui détruiraient les données chiffrées :

sudo wipefs -a /dev/sdX

On crée le conteneur luks

sudo cryptsetup -y -v luksFormat /dev/sdX

-y : double check du mot de passe
-v : verbose

On déverrouille et mappe le conteneur :

sudo cryptsetup open /dev/sdX c1

Le conteneur sera accessible sur /dev/mapper/c1 (plus tard, lorsque udisks reconnaitra tout seul le conteneur (ou le FS dessus ?), ce sera typiquement /dev/mapper/luks-bla-bla-uuid)

On formate en ext4

sudo mkfs.ext4 /dev/mapper/c1

On peut ensuite monter la partition

sudo mount /dev/mapper/c1 /mnt

Et on a une partition chiffrée, qui s’utilise comme n’importe quel périphérique !

On peut la fermer avec

sudo cryptsetup close c1

Sauvegarde et restauration de l’en-tête !

Une fois que l’on compte se servir du périphérique pour stocker durablement des vraies données, il est indispensable de backuper le header du conteneur. Sans lui (corruption, création d’une table de partition sur le disque…), plus de données !

cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /path/to/backup.img

Et pour restaurer en cas de besoin :

cryptsetup luksHeaderRestore /dev/sdX --header-backup-file /path/to/backup.img

Gestion des clés

Source

On peut créer un fichier clé aléatoire via le périphérique /dev/urandom, et le passer en read-only pour root. Pour ceci :

sudo dd if=/dev/urandom of=/root/keyfile bs=1024 count=4
sudo chmod 0400 /root/keyfile

pour un fichier de 4ko.
Puis on ajoute ce fichier clé à notre conteneur LUKS (qui doit déjà exister, et avoir donc au moins 1 mot de passe) :

sudo cryptsetup luksAddKey /dev/sdX /root/keyfile

Attention, l’en-tête du conteneur ayant été modifiée, il faut penser à mettre à jour le backup !

luksKillSlot  ??
luksRemoveKey ??

Montage automatique au boot

Pour monter automatiquement une partition chiffrée via LUKS au démarrage du système, il faut créer une entrée dans le fichier /etc/crypttab, de ce format :

mapper_name	UUID=01234567-89ab-cdef-0123-456789abcdef	none	luks

mapper_name correspond au nom du mapper qui sera présent dans le dossier /dev/mapper/, et on peut remplacer none par (par exemple) /root/keyfile si on souhaite utiliser un fichier de clé pour déverrouiller le conteneur. Il est bien sûr conseillé de laisser ce fichier clé à un endroit non accessible (par exemple sur une partition déverouillée manuellement par mot de passe).

Il me semble qu’il faut ensuite regénérer l’initramfs :

sudo update-initramfs -k all -u

Divers

Pour voir des infos sur le conteneur LUKS :

cryptsetup luksDump /dev/sdX

Pour voir des infos sur un conteneur LUKS une fois mappé (dans cet exemple sur /dev/mapper/c1) :

cryptsetup -v status c1

Voir la master key lorsque le périphérique est déverrouillé (attention aux yeux trop curieux)

sudo dmsetup table --target crypt --showkey /dev/mapper/c1

Selon plusieurs témoignages sur forum, il faut faire attention à certains installers d’OS qui proposent LUKS, et qui créent un nouveau container par-dessus l’ancien, avec un message trop peu explicite.

02 Feb 2019, 00:00

Usage du .htaccess dans Apache 2

Le fichier .htaccess est un fichier en texte clair, qui permet de définir le message affiché lors de la demande de mot de passe, ainsi que le fichier dans lequel Apache ira vérifier que l’utilisateur/mot de passe est correct (le .htpasswd).
Dans mon cas, je choisis de faire un fichier .htpasswd par répertoire, car tous les répertoires ne doivent pas être accessibles aux mêmes utilisateurs.

Je crée le .htpasswd :

cd /path/to/site/files
htpasswd -c .htpasswd user1

L’option -c sert à créer/réécrire le fichier. Si on ne la spécifie pas, ça rajoute une nouvel utilisateur qui pourra lire ce répertoire.

Ensuite, on ajoute le .htaccess, qui va directement protéger le répertoire

nano .htaccess

Dans lequel on met :

AuthType Basic
AuthUserFile "/path/to/site/files/.htpasswd"
AuthName "Identification pour ce dossier ?"
Require valid-user

Il semble indispensable d’indiquer le chemin complet vers le .htpasswd, sans quoi le serveur retourne une erreur 500.

Dans le cas où le repértoire est en dehors des répertoires standards de Apache (/usr/share ou /var/www), il faut les ajouter à la main dans le /etc/apache2/apache2.conf ou dans /etc/apache2/sites-available/00X-mon-site.conf :

<Directory /path/to/site/files/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

Ceci permet respectivement de suivre les liens symboliques (utile pour mon setup), de permettre d’outrepasser les droits localement (et donc d’utiliser le htaccess), et permet à tout le monde (toutes les IPs notamment) d’accéder au site.