Interfaces

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.

Passerelles

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), je conseille 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.

DNS

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.

Dual WAN en failover

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.

Diagnostic

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.

Généralités

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.

Événements

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

Filtrage et permissions

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é).

Priorité et héritage

Les GPO sont appliquées dans l’ordre suivant, avec priorité à la dernière occurence :

1. Local
2. Site
3. Domaine
4. OU

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.

Application unique

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.

Groupes, OUs, Ordinateurs

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.

Diagnostic des GPO qui ne s’appliquent pas

• La GPO est-elle liée à l’objet désiré ? Directement ou via héritage ?
• Le lien est-il activé ?
• Des paramètres utilisateurs et/ou ordinateurs sont-ils désactivés ?
• Le filtrage de sécurité donne-t-il les autorisations de lecture à l’objet qui doit les appliquer ?
• Est-elle outrepassée par une autre GPO avec une priorité plus élevée ?
• Pour les installations de logiciel, ceci se produit avant l’ouverture de la session ; l’emplacement du fichier doit donc être accessible en lecture par le groupe “Ordinateurs du domaine”
• Pour les déploiements d’imprimante, il faut généralement déco/reco la session

http://woshub.com/group-policy-not-applied-troubleshooting/

Liste de paramétrages

https://memo.raphaelguetta.fr/post/gpo-settings

Délai GPO

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.

Powershell

Politique d’exécution des scripts

Config ordi
Stratégies -> Modèles d'aministration -> Composants Windows -> Windows Powershell
Activer l'exécution des scripts
 -> Activer, et choisr la politique

Verrouillage écran automatique

Voir détail ici :
https://memo.raphaelguetta.fr/post/windows-veille-verrouillage-ecran/

Customisation Explorer

Menu contextuel classique (Win 11)

Per-user : registre

HKCU
Software\Classes\CLSID\{86CA1AA0-34AA-4E8B-A509-50C905BAE2A2}\InprocServer32
(par défaut)
REG_SZ

Afficher secondes

Per-user : registre

HKCU
Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
ShowSecondsInSystemClock
REG_DWORD
1

Customiser options affichage

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

Office

Désactiver lancement auto Teams

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

Doc ubuntu

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.

J’ai besoin du logiciel inadyn pour mettre à jours mes enregistrements dyndns chez OVH.
La version de Inadyn packagée par Debian est trop ancienne, et non compatible avec OVH, contrairement aux versions plus récentes dispos sur github.

Compilation et installation

## Prérequis
sudo aptitude install wget libssl-dev libgnutls28-dev autoconf libconfuse2 libconfuse-dev checkinstall pkg-config

## Répertoires nécessaires pour checkinstall
sudo mkdir /usr/local/share/doc
sudo mkdir /usr/local/share/man
sudo mkdir /usr/local/share/doc/inadyn


## libite
wget -c https://github.com/troglobit/libite/releases/download/v2.1.0/libite-2.1.0.tar.xz
tar -xvf libite-2.1.0.tar.xz
cd libite-2.1.0/
./configure
make -j5
sudo checkinstall ## Valider avec entrée plusieurs fois ; modifier les valeurs si souhaité
sudo dpkg -i libite_2.1.0-1_amd64.deb
sudo ldconfig	


## inadyn
cd ..
wget -c https://github.com/troglobit/inadyn/releases/download/v2.5/inadyn-2.5.tar.xz
tar -xvf inadyn-2.5.tar.xz
cd inadyn-2.5/
./configure
make
checkinstall
sudo dpkg -i inadyn_2.5-1_amd64.deb

Fichier de conf

/etc/inadyn.conf

provider default@ovh.com {
    ssl         = true
    username    = monsite-admin
    password    = superpassword
    hostname    = {domaine.monsite.fr}
    checkip-command = /root/.local/bin/scripts/checkIP.sh
}

provider default@ovh.com:2 {
    ssl         = true
    username    = monsite-admin
    password    = superpassword
    hostname    = {autredomaine.monsite.fr}
    checkip-command = /root/.local/bin/scripts/checkIP.sh
}

Pour que les utilisateurs du serveur ne puissent lire les identifiants :

sudo chmod 600 /etc/inadyn.conf

On peut ajouter autant de hostname qu’on veut, en changeant le chiffre après default@ovh.com:.
Les username/password doivent être définis sur l’interface OVH.

Script de reconnaissance d’IP (checkIP.sh)

#!/bin/sh
curl ipecho.net/plain; echo

Chemin à mettre en concordance avec inadyn.conf.
Ne pas oublier de sudo chmod +x checkIP.sh.

Crontab

Je préfère lancer le programme ponctuellement et régulièrement via cron que de le laisser tourner en demon.
Voici mon entrée dans le crontab pour ce faire :

# Lance inadyn toutes les 5 minutes
*/5 * * * * /usr/local/sbin/inadyn -1 -f /etc/inadyn.conf > /dev/null 2>&1

graph TB
SubGraph1 --> SubGraph1Flow
    subgraph "./debian-base-install.sh"
    SubGraph1Flow(Install Base Server)
    SubGraph1Flow -- apt install --> SubGraph1Flow1(Server with dependencies)
    SubGraph1Flow1 -- clone mmg-tools in /mmg --> SubGraph1Flow2(Repository)
    SubGraph1Flow2 -- create user mmg --> SubGraph1Flow3(installed application)
    SubGraph1Flow3 -- copy docker/$ENV/* docker/ --> SubGraph1Flow4(configured application)
    SubGraph1Flow4 -- docker-compose up --> SubGraph1Flow5(running dockers)
end

SubGraph2 --> SubGraph2Flow
    subgraph "./deploy_backend.sh"
    SubGraph2Flow(Install Back End Volume)
    SubGraph2Flow -- clone mmg-server in /tmp --> SubGraph2Flow1(Repository)
    SubGraph2Flow1 -- configure files --> SubGraph2Flow2(configured application)    
    SubGraph2Flow2 -- composer install --> SubGraph2Flow3(installed application)
    SubGraph2Flow3 -- mv /tmp /volumes --> SubGraph2Flow3(application deployed in volumes)    

end
SubGraph3 --> SubGraph3Flow
    subgraph "./deploy_frontend.sh"
    SubGraph3Flow(Install Front End Volume)
    SubGraph3Flow -- clone mmg-client in /tmp --> SubGraph3Flow1(Repository)
    SubGraph3Flow1 -- npm install $ENV --> SubGraph3Flow2(installed application)
    SubGraph3Flow2 -- build sass --> SubGraph3Flow3(generated css files)
    SubGraph3Flow3 -- npm run build --> SubGraph3Flow4(built application)
    SubGraph3Flow4 -- mv /tmp /volumes --> SubGraph3Flow5(application deployed in volumes)    

end
SubGraph4 --> SubGraph4Flow
    subgraph "Missing functionnality"
    SubGraph4Flow(Install Database Volume)
    SubGraph4Flow -- manually copy existing volume --> SubGraph4Flow1(Volume set)
end

SubGraph1[Install Server] --> SubGraph2[Install Back End]
SubGraph2 --> SubGraph3[Install Front End]
SubGraph3 --> SubGraph4[Install DATABASE]   

Interface graphique basique mais fonctionnelle : gitg

Configuration

git config --global credential.helper "cache --timeout=3600"
#pour  mettre les identifiants du serveur distant en cache pendant 1h

Configuration du nom/mail enregistrés lors des commits :
git config user.name "my_username"
git config user.email "<>" (pour un mail vide)
Ça sera enregistré dans .git/config sous la forme

[user]
        name = my_username
        email = <>

Ça peut être configuré globalement avec git config --global

Remote

“remote” représente un serveur distant avec lequel on se synchronise. Il a un nom, typiquement “origin”.
Pour voir le remote actuel :
git remote -v

Pour le modifier :
git remote set-url origin
suivi de l’URL (généralement trouvable dans l’interface web du dépôt). Ceci peut être utilisé pour passer de HTTPS à SSH : par exemple pour une URL https de type :
origin https://git.example.org/myself/myproject/
il faut entrer la commande :
git remote set-url origin git@git.example.org:myself/myproject

On peut changer le nom du remote :
git remote rename oldname newname

Versionning

git init : crée les fichiers nécessaires au fonctionnement de git (.git/)

HEAD : l’emplacement sur l’arbre où l’on se situe actuellement

git status

git add : pour tracker un dossier, fichier (ou plus fin ?)
git commit : valide le diff, -m pour message custom

git diff : liste les modifications depuis le dernier commit (ajouter --cached si sortie vide)
git show [commit] : liste les différences entre le commit actuel (ou spécifié) et le commit précédent

git fetch : lit les nouvelles modification sur le serveur distant
git pull : applique ces modifications sur notre arborescence locale
git pull --rebase : pour ne pas faire de commmit lorsqu’on repositionne notre HEAD

git log : voir l’historique des commits

git branch : pour lister les branches (git branch new-feature pour créer une branche)
git checkout : changer de branche
git checkout -b new-feature : crée la branche new-feature et m’y positionne
git push --set-upstream origin new-feature : réplique la branche new-feature sur le serveur distant

git push : après avoir commit, envoie le(s) commit sur le serveur distant
git stash : met en “presse papier” les diffs actuel et se resync avec le commit le plus récent
git stash apply : réapplique ce “presse-papiers”
# le combo des 2 peut permettre de résoudre une situation “modifié des 2 côtés” en mettant de côté notre travail, récupérant les modifs sur le serveur distant puis réappliquant nos diff dessus

https://support.apple.com/fr-fr/HT201255
https://support.apple.com/fr-fr/HT204904

Alt : Boot menu
⇧ : Mode sans échec
Super+S : Mode monoutilisateur (root en CLI)

Super+R : Récupération via partition de récup (OS actuel)
Alt+Super+R : Récupération via internet (OS le plus récent compatible)
⇧+Alt+Super+R : Récupération via internet (OS d’origine, ou le plus proche encore disponible sur les serveurs)

Alt+Super+P+R : reset PRAM
Alt+⇧+Ctrl : reset SMC

D : AHT
Alt+D : AHT via internet