Sur les 2 machines :
apt install iperf
Sur le serveur :
iperf -s
Sur le client :
iperf -c SERVER_IP
Par défaut, cela transmet du client vers le serveur (upload). On peut inverser le sens (download) avec le flag -R.
Par défaut, le test dure 10s. Ce temps peut se controler avec le paramètre -t num_sec.
On peut changer le port par défaut (5201) avec -p 5202.
Un peu de lecture ici.
htop permet de visualiser ça
sudo apt install iotop
sudo iotop
Permet de voir, à la manière de top, l’activité I/O des disques par processus. Ne distingue toutefois pas sur quel disque l’activité se produit.
sudo apt install dstat
dstat pour avoir un aperçu général.
dstat -d -D total,sdk,md0 pour n’afficher que les infos relatives aux disques (-d), et surveiller l’ensemble des I/O dans une colonne (-D total), /dev/sdk dans un autre (-D sdk)et /dev/md0 dans une autre (-D md0).
sudo apt install sysstat
iostat pour avoir des infos générales depuis le boot.
iostat -y 1 2 pour avoir des infos uniquement dans l’intervalle temporel spécifié ; ici : 1s, analyse répétée 2 fois (1 2). Si le 2e chiffre n’est pas spécifié, l’analyse sera faite en boucle.
iostat -d pour n’inclure que l’info relative aux disques.
iostat -p sdk,md0 pour n’inclure que l’info relative à ces périphériques.
iostat -t pour inclure le timestamp
En cumulant ces options, et avec l’utilisation de watch, on tombe sur un truc comme ça :
watch -t -n 0.1 iostat -p sdk,md0 -d -t -y 1 1
sudo apt install nmon
nmon puis presser la touche d
Très très très inspiré de ça : https://github.com/stefa2k/prysm-docker-compose
version: "3.6"
x-logging: &logging
logging:
driver: "json-file"
options:
max-file: "10"
max-size: "100m"
services:
medalla-prysm-beacon:
stop_grace_period: 1m
container_name: medalla-prysm-beacon
image: gcr.io/prysmaticlabs/prysm/beacon-chain:${PRYSM_DOCKER_TAG}
hostname: medalla-prysm-beacon
command: --config-file=/config/beacon.yaml
# --p2p-max-peers=1000
ports:
- 4000:4000
- 13000:13000/tcp
- 12000:12000/udp
volumes:
- ./config/beacon.yaml:/config/beacon.yaml:ro
- ${VOLUMES_PATH}/prysm/beacon:/data
<<: *logging
medalla-prysm-validator:
stop_grace_period: 1m
tty: true
stdin_open: true
container_name: medalla-prysm-validator
image: gcr.io/prysmaticlabs/prysm/validator:${PRYSM_DOCKER_TAG}
hostname: medalla-prysm-validator
depends_on:
- medalla-prysm-beacon
command: --config-file=/config/validator.yaml
volumes:
- ./config/validator.yaml:/config/validator.yaml:ro
- ${VOLUMES_PATH}/prysm/validator:/wallet
<<: *logging
# I use a custom defined network
networks:
default:
external:
name: eth_net
Les fichiers de config :
beacon.yaml
############################################################
##
## Read up on parameters on
## https://docs.prylabs.network/docs/prysm-usage/parameters/
##
############################################################
datadir: /data
###############
# Base settings
medalla: true
accept-terms-of-use: true
# p2p-max-peers: 1000
#######################
# Connectivity settings
p2p-host-ip: ""
p2p-host-dns: ""
rpc-host: 0.0.0.0
monitoring-host: 0.0.0.0
# disable scan of local network
p2p-denylist: ["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","100.64.0.0/10","169.254.0.0/16"]
# changing this also needs to be changed in docker-compose.yaml !
p2p-tcp-port: 13000
# enable db backup endpoint
enable-db-backup-webhook: true
##############################
# Connection to eth1 chain container
http-web3provider: http://goerlichain-hostname:8546
web3provider: ws://goerlichain-hostname:8546
validator.yaml :
############################################################
##
## Read up on parameters on
## https://docs.prylabs.network/docs/prysm-usage/parameters/
##
############################################################
##############
# Connectivity
beacon-rpc-provider: prysm-beacon-hostname:4000
monitoring-host: 0.0.0.0
##############
# Base settings
medalla: true
accept-terms-of-use: true
#####################################
# Validator accounts & key management
wallet-dir: /wallet
###########
# Fun Stuff
graffiti: "My funky graffiti !"
#############
# Performance
dev: true
block-batch-limit: 512
head-sync: true
Pour exécuter une instance du validateur pour gérer les fichiers (en adaptant les chemins de volumes) :
docker run --rm -it -v ./config/validator.yaml:/config/validator.yaml -v ${VOLUMES_PATH}/testnets/medalla/prysm/validator:/wallet --config-file=/config/validator.yaml
On peut ensuite choisir les commandes Prysm ; par exemple :
help , qui affiche l’aideaccountswalletOn peut spécifier des drapeaux à la suite de cette commande, mais ils doivent être placés après les commandes de prysm.
Dans ma configuration, je ne sauvegarde le mot de passe nul part sur le disque ; il faut donc le fournir au lancement du validateur ; je recommande donc la comande suivante pour démarrer le validateur :
docker-compose up -d && docker attach medalla-prysm-validator, puis quitter avec Ctrl+P - Ctrl+Q.
Pour lire les logs de la beacon chain, et pouvoir les filtrer par exemple via grep, il faut rediriger la sortie d’erreur vers la sortie standard :
docker logs medalla-prysm-beacon 2>&1 | grep Synced
Le wallet représente l’ensemble des fichiers gérés par Prysm. On a un seul wallet à la fois. Il peut être de type “importé” ou déterministe (“HD”), ou avec signature distante, mais je ne traite pas ce cas ici.
Un wallet HD va recréer les clés en fonction de la graine fournie/générée ; C’est pratique, mais le validateur (exposé en permanence à Internet) est en possession de la graine, c’est à dire de la possibilité d’accéder aux clés de validations, mais également aux clés de retrait qui permettent de récupérer l’ETH2 ; d’où le risque de sécurité.
Les fichiers seront stockés dans le dossier “derived”.
Un wallet importé va pouvoir traiter, 1 par 1, les fichiers fournis via la command import (voir la section accounts). On peut donc générer nos clés de manière externe (par exemple via eth2-deposit-cli, (ou via ethdo ?)), et n’exposer que les clés de validation, d’où la sécurité augmentée.
Les fichiers seront stockés dans le dossier “direct”.
Si les dossiers “derived” et “direct” existent tous les 2, le validateur ne démarrera pas.
Les commandes :
wallet create : permet de créer un nouveau wallet, en choisissant son type ; échouera si un wallet est déjà présent à l’emplacement indiquéedit-config : permet de modifier la configuration d’un wallet HD uniquementrecover : pour recréer un wallet HD dont on a déjà la grainehelp : self-explainingUn account représente un validateur, une paire de clés. On peut avoir plusieurs validateurs actifs en même temps. On peut rajouter un ou plusieurs validateurs aux validateurs déjà actifs.
Les commandes :
create : crée un nouveau validateur ; implique wallet create si aucun wallet n’existe dans le dossier spécifiédelete : permet de supprimer un ou plusieurs validateurslist : permet de lister les validateurs actuellement actifs dans Prysmbackup : self-explaining. Exporte clés de validation ET clés de retrait si elles sont présentes dans Prysmimport : permet d’ajouter une clé de validateur déjà existante. Semble ne rien faire si le wallet est de type HD ; implique la création d’un wallet de type importé si aucun wallet n’existe. On doit spécifier un dossier qui contient les fichiers keystore, et taper les mots de passe ; les mots de passe peuvent être différents pour chaque keystore, il faut alors les entrer au fur et à mesure de l’importationvoluntary-exit : permet de quitter le pool de validateurs. Il est impossible de recommencer à valider avec ces clés, et impossible de retirer ses ethers avant la phase 1, voire la phase 2.help : self-explaininggit clone https://github.com/ethereum/eth2.0-deposit-cli.git
# ou pour la branche de dev :
git clone https://github.com/ethereum/eth2.0-deposit-cli.git -b dev
# pour installer eth2deposit module
# à refaire à chaque update pour updater le module pip3
pip3 install ./
# si besoin de changement de version, on peut désinstaller la version en conflit avec
pip3 uninstall eth2deposit
cd eth2.0-deposit-cli
./deposit.sh new-mnemonic
Si plusieurs validateurs, crée 1 deposit_data cumulatif, et plusieurs keystore.json (le nom des fichiers contient le timestamp).
On doit pouvoir ajouter l’option --chain mainnet pour passer directement la chaine cible sans avoir à la choisir.
!!! ATTENTION A LA DOUBLE VALIDATION !!!
./deposit.sh existing-mnemonic
Choisir l’index de départ (si 2 clés ont déjà générées et que l’on souhaite en générer une nouvelle 3e, entrer 2 ; si on veut regénérer des clés dejà existantes, entrer 0 pour toutes les générer).
Choisir le nombre de clés à générer.
Les clés sont générées dans le dossier validator_keys.
Dans eth2deposit\deposit.py, ligne 30, hardcoder la graine à restaurer après mnemonic = en la mettant entre apostrophes.
user installer
pass opnsense
login apres install, si non modifié
root
opnsense
Theme :
System -> Settings -> General -> Theme
Pour définir le secret TOTP pour un user :
System -> Access -> Users
Éditer l’utilisateur
Chercher OTP seed et l’activer
Puis au niveau système :
System -> Access -> Servers
Ajouter
En nom mettre par exemple “Local_2FA”
Type : Local + TOTP
Laisser par défaut
Pour le tester, aller dans
System -> Settings -> Authentication -> Server
et cocher Local database et “Local_2FA”
On peut alors s’authentifier auprès des 2 sources (avec et sans TOTP).
Une fois que la connexion fonctionne, on peut décocher “Local Database” pour n’autoriser que le format TOTP.
Pour se connecter avec 2FA, il faut entrer le password au format
{TOTP}{PASS}
par exemple 157496MyPassw0rd
Pour enregistrer automatiquement ce format dans KeepassXC, on enregistre le pass comme :
{TOTP}MyPassw0rd
et il fera la complétion avec le code actuel.
Les interfaces sont des configurations réseau que l’on peut associer aux ports physiques du routeur, dans Interfaces -> Assignments.
Dans Interfaces -> iface_name, on peut configurer l’interface en question : lui donner un nom explicite, son adresse IP, et la passerelle qui lui est accessible.
Sous OpnSense (26.7), il peut être distribué par Dnsmasq (activé par défaut) ou Kea (désact. par défaut)
Pour on/off chaucn des 2 :
Services -> Kea DHCP -> Kea DHCPv4
Services -> Dnsmasq DNS & DHCP
Pour voir les leases pour chacun des services, on peut aller dans Services -> Kea DHCP -> Leases DHCPv[4|6]
Pour voir pour Dnsmasq : Services -> Dnsmasq DNS & DHCP -> Leases
Dnsmasq : Services -> Dnsmasq DNS & DHCP -> Hosts et “+”
Remplir “Host”, “IP addresses” et “Hardware adresses” (adresse MAC)
Les passerelles sont à configurer individuellement, dans System -> Routing -> Gateway. La petite terre indique l’interface actuellement par défaut (peut changer en fonction de l’état des liens). Un double-clic sur une passerelle permet de la configurer.
On donne l’interface par laquelle cette passerelle est accessible (par exemple WAN), on donne un nom (que l’on choisit) à cette passerelle, on entre l’IP sur laquelle elle est accessible (par exemple 192.168.1.1), et une adresse IP de monitoring (qui sera pinguée régulièrement, pour s’assurer que cette connexion est toujours vivante ; par exemple 8.8.8.8).
⚠ l’IP de monitoring ne sera jamais accessible depuis une autre interface du routeur PfSense. Faire attention de ne pas bloquer les serveurs DNS d’une interface.
⚠ Pour une connexion qui doit être utilisée même si elle est instable (par exemple une connexion basse qualité de secours, préférable à une absence de connexion), il est possible de cocher Disable Gateway Monitoring, afin qu’elle soit toujours considérée vivante.
En cliquant sur Display Advanced, on peut définir les seuils à partir desquels la connexion est considérée comme perdue.
Unbound est un resolver DNS (résout les domaine en allant interroger récursivement le système DNS).
Dnsmasq est un forwarder DNS (transfère la requête à un resolver)
Dans la config par défaut d’OpnSense Unbound tourne sur le port 53 et Dnsmasq sur le port 53053.
Unboud est le resolver par défaut.
Si par exemple on veut résoudre sub.domain.com vers 192.168.1.100
Services -> Unbound -> Overrides
Host : sub
Domain : domain.com
IP address : 192.168.1.100
On peut mettre des alias, qui sont un peu l’équivalent des CNAME ; ils partagent tous la même IP de destination.
Il est possible d’avoir une résolution des clients DHCP sous le format “hostname.domain.lan”.
Si DHCP par Kea, alors Services -> Unbound DNS -> General puis Register ISC DHCP4 Leases et Register DHCP Static Mappings.
Ainsi Unbound sera directement informé des hostnames des clients DHCP et pourra les résoudre.
Si DHCP par Dnsmasq, alors Services -> Dnsmasq DNS & DHCP -> General puis Register ISC DHCP4 leases (s’applique aussi aux baux statiques, tant que le client est conecté ; la case “Register DHCP static mappings” permet de résoudre même en l’absence de connexion du client)
Vérifier aussi DHCP domain override ; si vide, alors les clients seront ajoutés au domain système ; sinon ils seront ajoutés au domaine mentionné ici.
Vérifier aussi le domaine distribué aux client pour leur recherche, par Services -> Dnsmasq -> DHCP ranges puis Domain.
Ceci permet aux clients de faire les requêtes sur le domaine, et à Dnsmasq de résoudre les hostname.
Toutefois, si le resolver est Unbound, il faut dire à unbound d’aller interroger Dnsmasq uniquement pour répondre aux requêtes concernant ce domaine (par exemple “domain.lan”). Pour ça :
Services -> Unbound -> Query forwarding et +
Domain : domain.lan
Server IP : 127.0.0.1
Server Port : 53053
Si le routeur est défini comme serveur DNS pour les clients, il faut configurer sa résolution DNS. Pour ça, on va dans System -> General Setup. Dans le cas de multi-WAN, il est nécessaire d’avoir au moins 1 serveur DNS par passerelle.
Par souci de simplicité, je choisis le serveur DNS de cette passerelle comme adresse de monitoring pour cette passerelle. Ainsi, si c’est le serveur DNS qui tombe (empêchant la navigation internet), la connexion sera considérée comme défectueuse, et le routeur basculera sur une autre connexion.
Il peut être intéressant d’essayer d’activer Powerd dans
System / Advanced / Miscellaneous -> Enable PowerD.
En l’activant (et laissant la valeur “hiadaptative”), je suis passé de 65 Mo/s à 100 Mo/s (débit max upstream)
Aussi, dans Interfaces -> Settings -> General
essayer de désactiver “Disable hardware TCP segmentation offload”
et reboot
En “Redirect Target Port”, any dit de rediriger sur le/les ports spécifiés en entrée (Destination Port)
Si on spécifie une plage de port en entrée et un port simple en sortie, il utilise ce port comme base et décale à partir de ce port.
Par défaut, les redirections de port ne fonctionnent que depuis l’extérieur (interface WAN). Si on essaye d’y accéder depuis l’intérieur du réseaU, cela ne fonctionne pas.
Pour que les redirections de port fonctionnent depuis l’intérieur, il faut activer l’option “NAT reflection” (parfois “NAT hairpin)”. Ainsi, l’IP de destination sera traduite même si la requête vient du LAN.
Toutefois, cela ne suffit pas ; en effet, comme l’IP source est préservée lors du “Destination NAT”, le destinataire (serveur) verra que l’IP source est sur le réseau local, et lui répondra donc directement. Or ce n’est pas l’IP contactée à la base par le client, donc sa réponse sera ignorée/rejetée.
Pour éviter ce problème, il faut également créer des règles pour le SNAT (NAT Source), grâce auquel l’IP source deviendra l’IP du routeur. Ainsi, le serveur répondra au routeur, qui dé-nattera la réponse pour la renvoyer au client.
Il ya 2 modes : “Pure NAT” et “NAT + proxy”.
Le mode proxy, c’est un petit soft qui tourne sur PfSense, qui récupère le flux entrant et le retransmets vers la destination en recréant un nouveau flux. Ça doit fonctionner dans toutes les situations, mais on perd en débit et cela sollicite beaucoup le firewall.
Le mode “Pure NAT” est le mode standard exposé ci-dessus. Il est beaucoup moins lourd et permet de conserver les débits.
Il faut aller dans dans System / Advanced -> Firewall & NAT. On y voit Enable automatic outbound NAT for Reflection qui correspond au SNAT, il faut le cocher.
On y voit aussi NAT Reflection mode for port forwards, qui correspond au DNAT Reflection par défaut. On peut l’activer ici, et elle sera activée par défaut. Il est sinon possible de gérer granulairement pour chaque redirection de port, sous NAT reflection.
Firewall -> Settings -> Advanced
Automatic outbound NAT for Reflection : SNAT
Reflection for destination NAT : politique DNAT par défaut depuis le LAN
Le DNAT peut aussi se gérer indépendamment pour chaque redirection de port ; il faut activer le mode avancé, puis Options -> NAT Reflection
La traduction IP/port a lieu avant de passer le pare-feu ; ainsi, la règle nécessaire est lorsqu’un paquet se présente sur l’interface WAN, avec pour destination
Dans System -> Routing -> Gateway Groups, on ajoute un groupe de passerelle. Il faut lui donner un nom (par exemple “Gateways_Failover”).
Dans Gateway Priority, on donne une priorité à chaque passerelle existante. Si “Never”, elle ne sera pas utilisée dans ce groupe de passerelles. Toutes les passerelles d’un même Tier seront utilisées en même temps, en commençant par le Tier 1. Si les conditions de ligne défectueuse (perte de paquet, forte latence ou lien coupé) se présentent, le routeur basculera sur la/les passerelles du Tier 2, etc. (C’est aussi en mettant plusieurs passerelles dans le même Tier que l’on peut faire de l’équilibrage de charge, dont on peut affiner la forme en modifiant le poids de chaque passerelle.)
Pour Virtual IP, on laisse généralement “Interface adress”. Il peut être utile de faire différemment si on a un cluster de routeurs PfSense redondants, pour simuler une même interface entre tous les routeurs.
Le Trigger Level permet de choisir l’évenement qui déclenche un basculement vers le Tier suivant (perte de paquets, haute latence, lien coupé). Le détail des seuils peut être reglé pour chaque passerelle individuellement (voir ci-dessus).
Dans System -> Routing, une fois le groupe de passerelle créé, on peut le définir comme passerelle par défaut, pour IPv4 et/ou IPv6.
NOTE : il semble que ce ne fut pas possible pendant longtemps. Dans le cas où ce choix ne serait pas disponible, il faut aller dans Firewall -> Rules, aller dans l’onglet LAN (car le choix de passerelle s’applique aux paquets qui se présentent sur l’interface LAN, dans le but de sortir sur une autre interface), éditer chaque règle pertinente (par défaut uniquement une règle pour IPv4 et une règle pour IPv6 qui autorise tout le trafic vers les autres interfaces), cliquer Display Advanced et définir la Gateway sur le groupe précedemment créé. C’est aussi la solution à choisir pour un filtrage plus granulaire.
Pour voir l’état actuel des passerelles, on peut aller dans Status -> Gateways. Ceci donne l’état de chaque passerelle, individuellement.
On peut aller dans l’onglet Gateway groups pour voir l’état du groupe de passerelle.
La GPO est présente dans “Objets de Stratégies de groupe”. Elle n’y a aucun effet.
Elle doit être liée à un objet, qui peut être le Local system, un Domaine, un Site ou une OU (unité d’organisation).
Une fois liée, elle s’applique à cet objet, et tout ce qu’il contient.
On peut laisser le lien en place, mais le désactiver, via clic-droit sur le lien. ATTENTION, il s’agit de la notion de “Lien activé”, et non la notion d’“Appliquer” (qui est là pour forcer l’application de la GPO à la descendance).
Il est possible de désactiver les paramètres ordinateur et/ou utilisateurs d’une GPO.
Cela vaut le coup, après modification d’un GPO, d’attendre ~ une minute avant de faire gpupdate /force sur les clients, le temps qu’elle soit bien prise en compte et synchronisée sur les différents PDC.
On peut observer l’application des GPO dans l’observateur d’events
Journaux des apps et des services -> Microsoft -> Windows -> Group Policy -> Opérationnel
Quelques IDs d’events pratiques :
4004 : démarrage de l'application des GPO ordinateurs
8004 : fin de l'application des GPO ordinateurs
4005 : démarrage de l'application des GPO utilisateurs
8005 : fin de l'application des GPO utilisateurs
Lorsqu’on sélectionne une GPO, dans l’onglet Étendue, on peut voir le filtrage de sécurité, qui détermine les entités auxquelles cette GPO s’applique.
Par défaut, c’est “Utilisateurs authentifiés” qui, contrairement à ce que son intitulé laisse penser, contient les utilisateurs ET les ordinateurs du domaine.
C’est uniquement une inclusion positive, on ne peut pas faire d’exclusion.
Lorsqu’on va dans l’onglet Délégation, on peut gérer les droits d’accès à cette GPO ; notamment le droit de l’appliquer.
Si on clique sur “Avancé” (en bas à droite), on peut affiner les permissions, et on peut notamment refuser l’application de la GPO à certains utilisateurs/groupes choisis. Ceci permet de les exclure dans modifier toute la structure (OUs etc).
Attention, pour pouvoir ajouter un ordinateur, il faut sélectionner “Ordinateurs” dans les “Types d’objet” (par défaut, il est non-coché).
Les GPO sont appliquées dans l’ordre suivant, avec priorité à la dernière occurence :
Il est possible de bloquer l’héritage, ce qui bloque l’héritage reçu et non l’héritage légué.
On peut également “Appliquer” (Enforced) un lien vers une GPO. Ceci aura pour effet que cette GPO ne pourra pas être outrepassée par une GPO dans une OU descendant de celle-ci, et l’héritage sera forcé vers les descendants, même si ceux-ci le bloquent.
Dans l’onglet “Commun”, certains paramètres de GPO (uniquement la catégorie Préférences ?) ont l’option “Appliquer une fois et ne pas réappliquer”.
Ceci fonctionne comme indiqué : ça s’applique à la 1e actualisation des GPO, et plus par la suite.
Si on voulait à nouveau les réappliquer, mais 1 seule fois, on décoche la case, on valide, puis on recoche la case, et on valide ; ainsi elle sera à nouveau appliquée 1 fois à chaque poste/utilisateur, puis ignorée.
La gestion des OUs et de leurs membres se fait dans Utilisateurs et Ordinateurs Active Directory.
Les ordinateurs sont présents, en tant qu’objet Ordinateur, dans la catégorie Computers, mais également en tant que Groupe de sécurité “Ordinateurs du domaine” (donc dans la catégorie Users).
On peut sortir un ordinateur de la catégorie Computer, par exemple pour le mettre dans une OU, il restera par défaut dans le groupe “Ordinateurs du domaine”. Ceci permet de l’inclure quand même via les filtres de sécurité.
Lorsqu’on applique un filtre de sécurité, pour déterminer les (sous-)objets auxquels s’appliquer la GPO, ce sont des objets de type utilisateur, groupe, ordinateur, mais PAS des OU.
Les objets hors de ce filtre de sécurité n’ont, semble-t-il, pas le droit de lecture sur la GPO, donc impossibilité de l’appliquer.
Il me semble que cette mécanique empêche un compte hors du domaine (par exemple l’administrateur local d’un poste joint au domaine) d’appliquer quelque GPO que ce soit.
Lorsqu’une GPO est liée au domaine lui-même, elle concerne tous les objets du domaine, dont le groupe “Utilisateurs du domaine” et le groupe “Ordinateur du domaine”. Les paramètres utilisateurs et ordinateurs s’appliquent donc.
Toutefois, si on crée une OU SPECIAL_COMPUTER et une OU SPECIAL_USER, dans lesquelles on glisse respectivement un ordinateur, et un utilisateur, et que l’on lie une même GPO à ces 2 OUs, seuls les paramètres ordinateur s’appliqueront à la l’OU SPECIAL_COMPUTER et seuls les paramètres utilisateur s’appliqueront à l’OU SPECIAL_USER.
Il est possible de configurer un Loopback Processing Mode : on crée une GPO avec des règles utilisateurs, et on la lie à une unité contenant des ordinateurs. Avec l’activation du loopback, les stratégies utilisateurs s’appliquent aux utilisateurs loggés sur ces ordinateurs.
Pour ceci : modifier la GPO qui doit s’appliquer aux utilisateurs, et aller dans Config ordinateur / Stratégies / Modèles d'administration / Système / Stratégie de groupe et activer “Configurer le mode de traitement par bouclage de la stratégie de groupe utilisateur”.
La différence entre Remplacer et Fusionner est décrite dans le cadre de droite ; a priori il faut vraiment penser à choisir “Fusionner”.
Si les Modèles d’administration sont absents, il faut les ajouter.
http://woshub.com/group-policy-not-applied-troubleshooting/
Forcer une fréquence de rafraichissement des GPO certains postes et/ou utilisateurs.
Config ordi :
Stratégies -> Modèles d’administration -> Système/Stratégie de groupe
- Configurer le mode de traitement par bouclage de la stratégie de groupe utilisateur : activé
- Définir l’intervalle d’actualisation de la stratégie de groupe pour les ordinateurs : activer (choisir délai)
Config util :
Stratégies -> Modèles d’administration -> Système/Stratégie de groupe
- Définir l’intervalle d’actualisation de la stratégie de groupe pour les ordinateurs : activer (choisir délai)
Il faut un redémarrage (ou une déco session pour les users) pour que la fréquence d’actualisation soit respectée.
Défaire/désactiver le lien vers l’OU semble suffisant pour réinitialiser le réglage.
Config ordi
Stratégies -> Modèles d'aministration -> Composants Windows -> Windows Powershell
Activer l'exécution des scripts
-> Activer, et choisr la politique
Voir détail ici :
https://memo.raphaelguetta.fr/post/windows-veille-verrouillage-ecran/
Per-user : registre
HKCU
Software\Classes\CLSID\{86CA1AA0-34AA-4E8B-A509-50C905BAE2A2}\InprocServer32
(par défaut)
REG_SZ
Per-user : registre
HKCU
Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
ShowSecondsInSystemClock
REG_DWORD
1
Per-user
Config utilisateur -> Préférences -> Paramètres du panneau de configuration -> Options des dossiers
Nouveau -> Options des dossiers (au minimum Win Vista)
Choisir en graphique les options souhaitées
Per-user ; 2 actions : une qui s’active à la première ouverture de session, et une systématique
Après install :
Config utilisateur -> Stratégies -> Modèles d'administration -> Microsoft Teams
Empêcher le démarrage automatique de Microsoft Teams après l’installation -> Activé
Par registre (option systématique) :
HKCU
Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask
State
REG_DWORD
0
Config de la rotation stockée dans /etc/logrotate.d/mon-journal-a-rotater
De cette forme :
/path/to/my/logfile {
monthly # can be daily, weekly
rotate 12 # keep 12 history files
compress # gzip the old logs
delaycompress # gzip old logs except the more recent one
missingok # does not stop if a file is missing
notifempty # does not rotate if file is empty
create 644 root root # permissions, user and group for the newly created file
}
Force rotation :
logrotate -fv /etc/logrotate.d/mon-journal-a-rotater (force, and verbose)
On peut spécifier directement le fichier de configuration général, /etc/logrotate.conf, qui inclue tout ce qui se trouve dans /etc/logrotate.d/ si on veut rotater l’ensemble des logs.
Ping scan : nmap -sn 10.0.0.1-255
Nmap est plus efficace lorsqu’il est lancé avec les droits root, car il peut aller directement consulter la table ARP, alors que sans les droits root, il tente la connection sur un/des ports courants.
https://security.stackexchange.com/questions/74493/different-results-using-nmap-with-without-sudo
Parfois, même ainsi, tous les appareils en ligne ne sont pas listés (genre 10 resultats maximum). Il semble que passer l’option -v pour augmenter la verbosité aide à les visualiser tous.
Pour n’avoir que les IP affichées, on peut poser ça après notre commande nmap : | grep report | awk '{print $5}'
sudo aptitude install live-build live-tools
mkdir buster_live && cd buster_live
mkdir auto && cp /usr/share/doc/live-build/examples/auto/* ./auto/
Editer le fichier auto/config pour qu’il contienne ceci :
#!/bin/sh
set -e
lb config noauto \
--architectures 'amd64' \
--archive-areas 'main contrib non-free' \
--bootappend-live 'boot=live config locales=fr_FR.UTF-8 keyboard-layouts=fr' \
--binary-images 'iso-hybrid' \
--distribution 'buster' \
--linux-flavours 'amd64' \
--source 'false' \
"${@}"
Entrer la commande lb config, puis aller éditer le fichier config/package-lists/live.list.chroot et ajouter les paquets désirés. Je propose ceci :
live-boot
live-config
live-config-systemd
#FIRMWARE
firmware-linux firmware-atheros firmware-b43-installer firmware-bnx2x firmware-brcm80211 firmware-intelwimax firmware-iwlwifi firmware-libertas firmware-myricom firmware-netxen firmware-qlogic firmware-realtek broadcom-sta-dkms
#UTILS
nmap rcconf gparted hfsprogs ntfs-3g hfsplus hfsutils dosfstools lightdm bash-completion chntpw dcfldd bootlogd less mesa-utils numlockx ethtool grub2 ssh gdisk testdisk python-tk iftop nethogs pm-utils dmraid aptitude apt-file smartmontools debootstrap pciutils usbutils cifs-utils e2fsprogs mtools screen lvm2 net-tools mdadm lsscsi haveged rng-tools cryptsetup efibootmgr efivar ncdu wireless-tools dnsutils git iperf iperf3 lshw
# TEAMVIEWER
libqt5webkit5 qml-module-qtquick2 qml-module-qtquick-controls qml-module-qtquick-dialogs
# DESKTOP
hplip system-config-printer xsane simple-scan mate-desktop-environment caja-open-terminal mesa-utils firefox-esr-l10n-fr chromium-l10n pulseaudio pavucontrol pavumeter mate-media-common mate-media mate-settings-daemon-dev mate-settings-daemon-common mate-settings-daemon chromium engrampa unrar pluma bluez blueman pulseaudio-module-bluetooth gddrescue ddrescueview vlc rdesktop conky network-manager-gnome webcamoid cheese
Puis entrer la commande sudo lb build.
A noter qu’il est possible de décomposer la commande sudo lb build en la succession suivante :
sudo lb bootstrap
sudo lb chroot
sudo lb binary
Il est possible d’aller modifier/ajouter manuellement des fichiers entre l’étape chroot et l’étape binary. Par exemple :
sudo mkdir ./chroot/home/user/
sudo cp /etc/skel/.* ./chroot/home/user/
sudo mkdir ./chroot/home/user/Bureau/
sudo chown 1000:1000 ./chroot/home/user -R
et y ajouter des fichiers, qui seront disponibles directement sur le bureau du live.
On peut éditer les alias :
nano chroot/home/user/.bashrc
On peut aussi ajouter le .inputrc tant qu’à faire
nano ./chroot/home/user/.inputrc
Si on souhaite recommencer la création du live, on peut utiliser la commande sudo lb clean qui ne conserve que le cache des paquets, du bootstrap et la config. On peut aussi utiliser les options --binary ou bien --chroot pour conserver les étapes antérieures.
On peut également utiliser l’option --cache pour supprimer également le cache et repartir complètement à 0.