Dans le cas où, au lancement de Chrome, le processus lsass.exe s’emballe jusqu’à prendre 100% d’un coeur, ça peut être dû à une installation d’extension qui n’aboutit jamais.

Essayer de supprimer 2 fois le dossier %appdata%\Microsoft\Protect\GUID.

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

Pour le démarrer ou l’arrer manuellement :
systemctl start mon-service.service
systemctl stop mon-service.service

User-level services

dans $HOME/.config/systemd

Pour les gérer, systemctl --user

Logs

journalctl

Pour voir les journaux système/noyau :
journalctl -k
ou
journalctl --dmesg

Pour voir le journal d’un service :
journalctl -u mon-service

Pour voir uniquement les infos d’un démarrage précis, on peut utiliser l’option journalctl -b. Sans valeur, c’est équivalent à -b 0 et concerne le démarrage actuel.
Une valeur négative montre les démarrages précédents l’actuel (-1 pour le précédent, -2 pour l’avant-dernier etc).
Une valeur positive montre les démarrages dans l’ordre chronologique (1 pour le plans ancient enregistré, 2 pour le 2e plus ancien etc)

Pour voir les entrées les plus récentes (à condition d’utiliser less en pager) :
journalctl -e -u mon-service
Implique -n 1000 qui limite le nombre de lignes à 1000
Semble impliquer -b aussi

Pour choisir un niveau d’évenement :
journalctl -p notice
debug,info,notice, warning,err,crit,alert

Paramétrage des logs

La config des journaux est stockée dans /etc/systemd/journald.conf[.d/] .

Par défaut ils sont stockés dans /var/log/journal/

On peut paramétrer la taille max du dossier avec

Journal]
SystemMaxUse=512M
SystemKeepFree=10G

Par défaut, il utilise au max 10% et laisse au minimum 15% dispo.

On peut nettoyer les logs avec

sudo journalctl --vacuum-size=1000M

pour conserver les 1G les + récents ou

sudo journalctl --vacuum-time=10d

pour conserver uniquement les 10 derniers jours.

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.

gpedit.msc sert uniquement à modifier les stratégies de groupes locales. La commande est disponible sur les Windows standards (Pro en tout cas).
gpmc.mmc sert à modifier, sur un controlleur de domaine, les GPO qui seront déployées chez les clients via Active Directory. Si cette commande n’est pas disponible sur un serveur, c’est probablement que le rôle de gestion des stratégies de groupes n’a pas été installé (ajouter des fonctionnalités -> Gestion des stratégies de groupe).

Par défaut, toutes les GPO ne sont pas disponibles dans l’outil gpmc.msc. Notamment, la catégorie “Modèles d’aministration”. Or, si on lance gpedit.msc, on voit que beaucoup de stratégies sont disponibles sous cette catégorie.

Pour ajouter des stratégies à l’outil gpmc.msc, on utilise des fichiers ADMX (ou, historiquement, ADM). Ils sont généralement déployés via les mises à jour Windows, mais ne sont disponibles que pour le système local. On les trouve dans le dossier %windir%\PolicyDefinitions, sous la forme de fichiers ADMX associés à des fichiers de localisation ADML dans des répertoires de langue (par exemple fr-FR).
On peut prendre tous ces fichiers, et les copier dans le dossier %windir%\SYSVOL\sysvol\mon.domaine.fr\Policies\PolicyDefinitions

Description du problème chez Microsoft Tuto pour l’activation par GPO

Dans certains cas, lorsque l’on est dans un domaine, et que l’on cherche à accéder à un serveur via son nom complet(FQDN, du type server.domain.example.com), alors le poste considérera que ce domaine appartient à la zone de confiance “internet”, et donc bloquera l’ouverture de certains documents, scripts, exécutables etc.
Pour corriger ce problème, on peut aller dans les options internet du poste en question, et passer les sites *.domain.example.com en zone Intranet.

Mais on peut aussi déployer ceci sur tous les postes du domaine, via GPO, ce qui évite d’avoir à le faire à la main sur chaque poste. Pour ceci, sur un controlleur de domaine :

• S’assurer que les ficheirs ADMX ont été installés
• gpmc.msc
• Configuration utilisateur -> Stratégies -> Modèles d'administration -> Composants Windows -> Internet Explorer -> Panneau de configuration Internet -> Onglet Sécurité et activer le paramètre Liste des attributions de site aux zones Lorsqu’on rentre dans les propriétés du paramètre, on peut afficher les zones, et associer *.domaine.example.com à la valeur 1.
  (1 : zone intranet ; 2 : sites de confiance ; 3 : internet ; 4 : sites ensibles)

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)

• 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
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

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.

docker info

pour avoir des infos sur les binaires qui tournent actuellement.

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 -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 --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

• 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

stats

docker stats
ou
docker stats my-app123

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

Gestion RAM et swap

https://docs.docker.com/engine/containers/resource_constraints/

Par défaut, comme visible avec docker stats, chaque container a pour limite max la quantité totale de RAM.
On peut choisir de limiter l’usage via les options --memory= et --memory-swap= .

https://docs.docker.com/engine/containers/resource_constraints/#--memory-swap-details

--memory correspond à la quantié de RAM à laquelle le conteneur a le droit.
--memory-swap correspond à la mémoire totale (RAM + swap) à laquelle le conteneur a droit. Si elle est spécifiée, il faut aussi spécifer –memory.

Ainsi, si les 2 valeurs sont égales, le conteneur ne pourra pas utiliser le swap.

On peut vérifier ces valeurs en inspectant un conteneur :
docker inspect my-app123 | grep -i Memo

ATTENTION, si --memory-swap n’est PAS spécifié alors que --memory l’est, docker va fixer memory-swap au double de memory ; donc le conteneur aura accès à autant de swap qu’il ne peut utiliser de RAM.

docker-compose

https://docs.docker.com/reference/compose-file/services/#mem_limit

my-app123
  mem_limit: 120.1GiB
  memswap_limit: 120.1GiB
  image: ...

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, 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.

• 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éfini, 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 (même restriction que pour la connexion)

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 principalement là pour documenter les ports utilisés par le conteneur, et n’aura (presque) aucun effet pratique. Cela peut se faire :

• à la création du conteneur via docker create --expose 8080:80/tcp
• dans le Dockerfile (donc dans l’image) via EXPOSE 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).

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
    stdin_open: true    # docker run -i
    tty: true           # docker run -t
    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)

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. 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:

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

Colorisation des logs

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.

Imprimer carte !!

Bolas
Chargeur solaire
Crème solaire
Éventail
jeu carte/société
Lampions
Bol tibétain / balles jonglage
Toroflux
Enceinte
Powerbank
Brumisateur
Gourde filtrante

Sacoche - Gourde - Cup - Petite montre
Papier
Marqueur
Stylo
Frontale (x2)
Piles
Bouchons d’oreille X2
Trousse toilette
Carnet
Sérum phy
Lunettes de soleil
Foulard
Trousse couture

Sachets plats préparés (pâtes !!)
Céréales sucrées (choco, x2)
Mélange céréales (“sportif”)
Couverts
Éponges
Bidons
Sachets réhydratation !!
Gel hydro-alcooolique
Sopalin
LD32W
Vapo
Sacs poubelles transparents

Tente
Matelas
Sac couchage
Couvertures survie
Plaids
Glacière
Ficelle
Outils (pince étau ; masse ; tournevis plat/cruci )
Gaffer

Titre 1

Titre 2

Titre 3

Titre 4

Titre 5

Titre 6

Elément en italique
Élément en italique aussi (étoiles)
Élement en gras

Lien html