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
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
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)
# On déchiffre et monte slash
cryptsetup open /dev/sdX2 slash
mount /dev/mapper/slash /mnt
cd /mnt
# On monte l'ESP et la partition /boot
mount /dev/sdX3 ./boot
mount /dev/sdX1 ./boot/efi
# On monte les fichiers systèmes temporaires
mount --rbind /sys ./sys
mount --rbind /dev ./dev
mount --rbind /proc ./proc
mount --rbind /run ./run
chroot /mnt
grub-install /dev/sdX --target x86_64-efi
update-grub
# On recrée l'initramfs, afin qu'il demande le mot de passe LUKS
update-initramfs -k all -u
Une source intéressante
Images, conteneurs et volumes
Dockerfile build
sudo apt install docker.io
à partir de buster ; sinon, utiliser le site docker.io.
sudo adduser user docker
pour ne pas avoir à taper sudo à chaque commande.
docker search --filter=stars=1000 debian
docker pull debian:tag
# si :tag est omis, docker cherchera :latest
docker image ls -a
# ou
docker images
# In folder containing the Dockerfile
docker build -t "my-image123:test" .
docker rmi my-image123:test
# on peut aussi utiliser l'id de l'image
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 -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
Un conteneur est instancié à partir d’une 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 --arg1 value --arg2
# 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)
# on peut aussi spécifier une autre commande pour outrepasser l'entrypoint, et/ou passer des arguments
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.
docker stop my-app123
docker kill my-app123 # pour forcer l'extinction
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
docker container rm my-app123
# on peut aussi utiliser l'id
docker container prune
# -f si on souhaite ne pas avoir de prompt de confirmation
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
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, les conteneurs d’un même réseau peuvent communiquer librement entre eux sur tous les ports (et, par défaut, aucun port n’est ouvert vers l’extérieur de ce réseau). Un conteneur peut être connecté à plusieurs réseaux.
Chaque conteneur lancés aura aussi une interface virtuelle (par réseau) type veth1234567.
docker network ls
docker network inspect network-name
docker network create --subnet 172.18.0.0/24 my-net123
docker run --net my-net123 --ip 172.18.0.23
docker network connect my-net123 my-app123
docker network disconnect my-net123 my-app123
docker network rm my-net123
docker network prune
L’exposition de ports peut se faire dans le Dockerfile, ou bien à la création du conteneur. Toutefois, elle est principalement là pour documenter les ports utilisés par le conteneur, et n’aura (presque) aucun effet pratique. Cela peut se faire :
docker create --expose 8080:80/tcpEXPOSE 8080 80/tcp.Il me semble que certains mécanismes peuvent faire appel aux ports exposés, par exemple la détection automatique de port par nginx-proxy.
La publication de ports sert effectivement à “ouvrir” le port du conteneur depuis l’hôte. Ainsi, le service fourni par le conteneur deviendra 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.
Un port n’a pas besoin d’avoir été exposé pour pouvoir être publié.
On peut aussi écrire uneiquement -p 80/tcp, auquel cas un port est choisi aléatoirement sur l’hôte.
Exposer un port sur un conteneur déjà lancé
Lors d’un docker ps, les ports publiés seront mentionnés sous la forme 0.0.0.0:80->80/udp, alors que les ports exposés seront mentionnés sous la forme 80/tcp.
Voir le détail des ports d’un conteneur :
docker inspect my-app123 | grep -i port -A3
On y voit les ports exposés (ExposedPorts) et les ports publiés (Ports).
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.
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
command: --arg1 value --arg2
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.
Les projects docker-compose ont un nom, qui par défaut est le nom du dossier. Ceci peut causer des messages d’erreur si plusieurs projets sont dans des dossiers qui portent le même nom (par exemple dev/myapp/ et prod/myapp ; les 2 projets s’appelleront myapp et seront “confondus” par le système). Ce nom de projet peut être défini dans le fichier .env, via la variable COMPOSE_PROJECT_NAME.
On peut lister tous les projets docker-compose via la commande suivante (source) :
docker ps --filter "label=com.docker.compose.project" -q | xargs docker inspect --format='{{index .Config.Labels "com.docker.compose.project"}}'| sort | uniq.
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 --build.
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.
On peut passer des arguments à docker-compose via l’entrée command (qui, contrairement à ce que son nom indique, ne fait que rajouter des arguments à l’entrypoint défini dans l’image, à condition que celle-ci ait été définie en forme Exec, et non Shell. Source ).
On peut écrire la commande sur plusieurs lignes, en suivant la syntaxe suivante (ne PAS échapper les fins de lignes) :
command: >
myapp
--firstoption "value"
--secondoption
--thirdoption "value"
(explication ici)
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. Le nom d’un service ne peut toutefois pas utiliser de variable.
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 dans 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:
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.
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
Un certain nombre d’applications sont conçues pour coloriser leur sortie si celle-ci est de type tty.
Ceci peut se paramétrer dans la commande docker : docker -t ou dans le fichier docker-compose.yml : tty: true
L’avantage est que la sortie visuelle d’une docker logs sera plus lisible ; l’inconvénient est ça limite les usages autres : un docker logs myapp | less nous affichera tous les caractères de coloration, rendant l’ensemble peu lisible ; de même, un grep sur une chaîne avec un changement de coloration au milieu ne fonctionnera pas.
Pour remédier à ceci, on peut utiliser la commande ansi2txt, contenue dans le paquet Debian colorized-logs, et qui supprime les caractères de colorisation. Par exemple,
docker logs myapp | ansi2txt | less
Il y’a aussi des solutions individuelles en fonction du programme de sortie ; par exemple pour less, on peut utiliser less -R pour préserver les couleurs.
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.
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.
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.
Source principale : la FAQ (ou en tout cas un mirroir) de cryptsetup
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 (Linux Unified Key Setup) 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.
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
sudo dmsetup ls --target crypt
lsblk --fs
peut aussi être utile.
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
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 ??
Pour déverrouiller 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 suffit ensuite d’ajouter les lignes nécessaires dans le fstab, soit sous la forme /dev/mapper/mapper_name, soit avec l’UUID de la partition.
Enfin, il me semble qu’il faut regénérer l’initramfs :
sudo update-initramfs -k all -u
debian-installer propose de chiffrer la partition slash. Pour ceci, il faut avoir :
/boot à part (pour se simplifier la vie ; ça semble être possible autrement, mais galère)Lors de la phase de partitionnement, on peut séléctionner “Configurer les volumes chiffrés”. On sélectionne la partition qui deviendra le slash chiffré, on laisse les options par défaut ; on choisit une phrase de passe. On peut annuler l’opération d’effacement si on ne la juge pas nécessaire. Lorsque l’on clique sur “Terminer”, le contenu du volume chiffré devient disponible, généralement en haut de la liste. On peut donc le définir en tant que partition slash.
J’ai eu des soucis lorsque j’ai voulu chiffrer le swap et le home depuis l’install. Tout a bien fonctionné en ne chiffrant que le slash lors de l’install, puis le swap et le home directement depuis l’installation.
Si il y’a besoin de faire une réparation depuis un live-cd, penser à vérifier/modifier le nom du mapper dans /dev/mapper via sudo dmsetup rename oldname newname, et le nom sous lequel il est monté dans /proc/mounts (il faut démonter/remonter si le nom du mapper a changé après le mount).
S’il y’a besoin de regénérer l’initramfs, vérifier que le nom du mapper correspond bien au nom dans /etc/crypttab.
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
Pour agrandir un conteneur :
sudo cryptsetup resize c1 # mapper namePour réduire un conteneur, GParted plante si c’est un conteneur LUKS2, ce qui est le cas par défaut.
Pour le faire à la main :
PAS ENCORE OK !!
- BACKUP DES DONNÉES !
- # démonter le conteneur, le réparer
- sudo umount /dev/mapper/mon-conteneur
- sudo fsck -f /dev/mapper/mon-conteneur
- sudo resize2fs /dev/mapper/mon-conteneur
- # déterminer la taille de secteur du conteneur LUKS2, ainsi que sa taille tout court :
- sudo cryptsetup status mon-conteneur | grep "size" | grep "sector"
- # déterminer la nouvelle taille, en soustrayant l'espace souhaité (en secteurs) ;
# par exemple, pour libérer 20G, on fait :
- new_size = ${luks_size} - (20 * 1024 * 1024 * 1024 / ${sector_size} )
- # dimensionner le conteneur :
- sudo cryptsetup resize mon-conteneur -b ${new_size}
- # si c'est une partition et qu'on veut la réduire (par exemple /dev/sdX5) :
- # déterminer le début et la fin actuels de la partition sous-jacente (en secteurs) :
- sudo parted /dev/sdX -> unit -> s -> p # noter les valeurs "Start" et "End" pour la partition qui nous intéresse.
- # trouver l'offset du conteneur LUKS :
- sudo cryptsetup status mon-conteneur | grep offset
- # calculer la nouvelle fin de partition :
- new_end = (${start_sector} + ${new_size} + ${offset} -1)
- # redimensionner la partition elle-même :
- sudo parted /dev/sdX -> unit -> s -> resizepart 5 ${new_end} # adapter le numero de partition -> yes -> q
Une source et une autre.
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 AuthConfig
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.
Cette directive doit être présente dans le fichier de configuration d’apache (dans /etc/apache2/ sous Debian, dans /usr/local/apache2/conf/httpd.conf pour l’image docker d’apache) pour autoriser, entre autres, le .htaccess.
Par défaut, c’est None, qui n’autorise rien dans les htaccess (et renverra une erreur 500 si un htaccess est utilisé). On peut remplacer None par les différents mot-clés (AuthConfig FileInfo Indexes Limit Options) ou All pour l’ensemble. Chacune de ces directives est un ensemble de sous-directives.
Pour un filtrage plus granulaire, on peut utiliser la directive AllowOverrideList pour autoriser uniquement certaines sous-directives.
Après une panne d’éléctricité, un RAID6 de 12 disques (dégradé, avec 1 disque manquant) a refusé de se remettre en route. Après vérification (par live-cd) via un cat /proc/mdstat, les 11 disques étaient tous en spare (se manifeste par un [S] ).
Pour ce raid sont utilisées les 2e partitions de chaque disque de sda -> sdk. J’ai vérifié l’état de synchronisation de tous les volumes : sudo mdadm --examine /dev/sd[abcdefghijk]2 | grep Events
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Ils sont bien synchronisés, mais pas assemblés. J’ai alors testé
sudo mdadm --assemble --force /dev/md126 /dev/sd[abcdefghijk]2
mais ai obtenu 11 jolis “Device or ressource busy”. Ce qui est normal, les disques étant intégrés dans le RAID, mais en spare. J’ai alors lancé
sudo mdadm --stop /dev/md126
suite à quoi la commande d’assemblage précédemment citée a bien fonctionné, le RAID s’est resynchronisé sans perdre de données, en prenant toutefois son temps.
Dans un autre cas, où le RAID était resté fonctionnel mais dans lequel un volume manquait (sdl2, détecté mais non intégré/synchronisé), j’ai pu le réintégrer avec la commande sudo mdadm --re-add /dev/md126 /dev/sdl2 (si re-add ne fonctionne pas, add devrait fonctionner mais prendre plus de temps).
Dans encore un autre cas, un seul disque était intégré au RAID, mais non synchronisé, car il restait en “spare”. J’ai pu forcer la réintégration avec la commande
echo check > /sys/block/md126/md/sync_action
De la lecture intéressante se trouve sur cette page.
Ici aussi : https://robbat2.livejournal.com/231207.html?nojs=1
Il doit être marqué en failed ; soit par mdadm suite à erreur de lecture ou autre, soit manuellement par :
sudo mdadm /dev/mdX --fail /dev/sdX
Il peut alors être retiré :
sudo mdadm /dev/mdX --remove /dev/sdX
Suite à quelques soucis de recherche dans la base CDDB avec Asunder, voici un mini-tuto pour abcde. Déjà,
sudo apt install abcde lame eyed3 glyrc imagemagick cdparanoia
Les préférences d’extraction se définissent dans le fichier /etc/abcde.conf ou bien dans un fichier user qui outrepassera le précédent, et que nous éditons ici : pluma ~/.abcde.conf
# VBR bonne qualité
LAMEOPTS='-V 0'
# On extrait la couverture
ACTIONS=default,getalbumart
# On range les fichiers finaux dans ce dossier :
OUTPUTDIR="/path/to/music/dir"
# On encode en mp3
OUTPUTTYPE=mp3
# Arborescence type Artiste/Album/01 - Morceau.mp3
OUTPUTFORMAT='${ARTISTFILE}/${ALBUMFILE}/${TRACKNUM} - ${TRACKFILE}'
# On ne remplace PAS les espaces par des underscores (et autres modifs)
mungefilename ()
{
echo "$@"
}
On peut ensuite lancer abcde ou encore abcde -d /dev/sr1 si on spécifie manuellement le lecteur CD.
Enfin, dans le dossier final, si on souhaite intégrer la pochette au fichier :
for i in *.mp3
do
eyeD3 --add-image cover.jpg:FRONT_COVER "$i"
done
(cf cette page)
Habituellement, lorsque je souhaite installer une Debian sur un pc avec double carte graphique Intel-Nvidia (système Optimus), il suffit d’installer bumblebee via apt install bumblebee bumblebee-nvidia (ou simplement bumblebee si on souhaite essayer avec les pilotes libres Nouveau, ce qui m’a semblé fonctionner moins souvent).
La configuration des paquets met en place toute la configuration nécessaire (glx, alternatives, modprobe/blacklist etc). Ceci installe également un module noyau bbswitch, dont le but est d’éteindre ou d’allumer à la demande la carte graphique dédiée.
Cependant, sur un poste, après avoir installé ces paquets, le pc freezait au démarrage, que le pilote soit nouveau ou nvidia. Comme le pc démarrait correctement en mode recovery, j’ai désactivé le lancement automatique du gestionnaire de connexion graphique. Ainsi, le pc démarrait correctement, je pouvais me connecter, mais dès le moindre service lightdm start ou startx, il freezait à nouveau. Après pas mal de lecture, j’ai appris que le fichier /proc/acpi/bbswitch contenait entre autre l’état de la carte graphique (ON ou OFF), et que la commande tee /proc/acpi/bbswitch <<<ON permettait de l’allumer à la demande.
Et j’ai constaté que la carte était en OFF à chaque démarrage, que si on essayait de lancer un programme graphique (même une interface graphique qui tourne sur la carte intégrée au CPU) alors que la carte dédiée était OFF, alors ça freezait. Si par contre on allumait manuellement la carte avant, on pouvait lancer l’interface, et ensuite ça fonctionnait, même si la carte était coupée. Mais si on souhaitait simplement se déconnecter, comme ceci coupe puis relance l’interface graphique, alors ça freezait à nouveau…
Mais avec le détail des cas où ca plantait, j’ai facilement trouvé ce rapport de bug, et après moult tests, modifier la ligne dans le fichier /etc/default/grub pour qu’elle ressemble à ceci :
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_osi=! acpi_osi='Windows 2009'"
suivi d’un update-grub a bien fonctionné !
Les graphiques standards sont bien lancés sur le gpu intégré, le gpu dédié est éteint la plupart du temps, allumé correctement lorsqu’on lance un programme avec optirun, et bien éteint lorsque ce programme se termine.