MBR

En cas de suppression puis création de partition en milieu de disque, il peut arriver que les partitions ne soient plus numérotées dans l’ordre de leur positionnement sur le disque.

Bien que non gênante en fonctionnement, cette situation diminue la lisibilité du disque et augmente les risques de confusion lors de manipulations de partitions.

Pour remédier à ceci, on peut renuméroter les partitions dans leur ordre logique.

Pour les partitions MBR, il faut le faire à la main : on dumpe la table de partition, on la modifie, puis on la réécrit sur le disque.

dev=/dev/sdX

sudo sfdisk --dump ${dev} > sdX.bkp

nano sdX.bkp
# changer le chiffre

sudo sfdisk -f {dev} < sdX.bkp
# débrancher/rebrancher disque (ou reboot) pour forcer la relecture de la table de partition

Source

GPT

Pour les partitions GPT, voir cet article

Récap

USB 2.0 : 480Mbps théorique, soit ~ 60Mo/s théorique (souvent 30-45 en réalité)
4 broches

USB 3.0 : 5Gbps théorique, mais 4Gpbs “théoriques réels” car codage 8b/10b, donc 500Mo/s théoriques (en pratique ~450 Mo/s)
9 broches
3.0 = 3.1 Gen 1 = 3.2 Gen 1x1 = SS = SS-5

3.1 = 3.1 Gen 2 = 3.2 Gen 2x1 = SS-10 ; 10Gbps théoriques

3.2 = 3.2 Gen 2x2 = SS-20 ; 20 Gbps théoriques

USB 4.0 = SS-40 ; 40Gbps théoriques ; n’existe qu’en USB-C.

Identifier vitesse théorique d’un périph de stockage sous Linux

On peut bien sûr mesurer les débits via un transfert de fichier, ou fio, mais on peut aussi constater directement le débit via lsusb. Pour ceci, il faut déjà identifier l’USB-ID d’un matériel ; par exemple avec un boitier SATA-USB3 Orico, un lsusb nous donne :
Bus 003 Device 032: ID 152d:0576 JMicron Technology Corp. / JMicron USA Technology Corp. Gen1 SATA 6Gb/s Bridge

C’est donc l’identifiant 152d:0576 pour ce matériel. On le stocke :
usbid=152d:0576

On peut alors lancer lsusb -tv pour avoir l’arbre USB détaillé. La vitesse théorique d’un périphérique est indiquée en fin de ligne. L’USB-ID du matériel étant indiqué à la ligne suivante, on peut filter avec grep en récupérant la ligne précédente ainsi :
lsusb -tv | grep ${usbid} -B 1

Si on veut tester différents branchements sans toucher au clavier, on peut lancer un monitoring automatique avec :
watch -n 0.5 "lsusb -tv | grep ${usbid} -B 1"

On peut monitorer plusieurs appareils avec une commande du genre
watch -n 0.5 "lsusb -tv | grep -e ${usb1} -e ${usb2} -e ${usb3} -B 1"

Connecteurs et USB-C

Il y’a plusieurs connecteurs, USB-A, USB-B, mini-B, micro-B, etc. Les câbles peuvent être équipés de différents nombres de broches en fonction de leur utilisation prévue (courant uniquement, wattage possible, courant + données, USB-2, USB-3 etc)

L’USB-C, au même titre que les autres, est simplement un format physique. Ses possibilités théoriques sont + étendues, mais non garanties. Il est possible d’avoir un câble C <-> C qui ne fasse que le transfert de courant sans données, ou bien qui ne fonctionne qu’en USB-2. Un connecteur USB-C peut également faire transiter des signaux non-USB (DisplayPort, HDMI, jack, électricité jusqu’à 240W).
Un cable USB-C possède (jusqu’à ?) 24 broches. Contrairement à l’USB-A, il ne me semble pas possible d’identifier visuellement le capacités d’un câble USB-C.

On peut également avoir des adaptateurs USB-C vers un autre format. Les capacités de ceux-ci dépendent également de leur conception. Il est possible d’avoir un adaptateur C <-> A qui soit limité à la vitesse USB2, voire qui ne fasse que le courant.

Dans le cas d’adaptateurs C <-> A en USB3, il est possible que les performances dépendent du sens d’insertion de l’USB-C. Dans mon expérience, pour bénéficier de l’USB-3, il faut que l’ensemble de la chaîne respecte le sens “classique”, à savoir la partie pleine du connecteur mâle vers le bas. Si on renverse un connecteur USB-C, alors le débit pourrait n’être que 480Mbps (USB2).
Je suppose que ceci dépendra de la conception des adaptateurs.

SATA <-> USB

Selon la conception de la puce, il est possible que l’adaptateur soit vu même sans disque, ou bien qu’il nécessite le branchement d’un disque SATA pour être détecté. Penser à tester les 2.

Il faut évidemment backuper tout le nécessaire avant la moindre manipulation.

Sous Linux

Source
sudo gdisk /dev/sdX
r f

Sous Windows

Se fait avec l’utilitaire MBR2GPT.EXE.
Ne fonctionne que pour un disque système !

Cet utilitaire va également créer/rendre bootable une partition ESP, et créer les fichiers de démarrage Windows pour protocole EFI.
Il est disponible à partir de Windows 10 1703. Il est prévu pour être utilisé en WinPE/WinRE, mais peut être utilisé directement sur l’OS en cours de fonctionnement avec le flag /AllowFullOS. un certain nombre de fonctionnalités risquent cependant de ne pas fonctionner. Il est donc préférable de redémarrer en WinRE (Paramètres -> Mises à jour et Sécurité -> Récupération -> Démarrage avancé -> Redémarrer) puis Invite de commande.
(possible depuis USB install ?)

Tout d’abord identifier le numéro du disque à convertir avec diskpart, list disk. Dans notre exemple, c’est le disque 9.
mbr2gpt.exe /validate /disk:9 pour vérifier que c’est faisable (voir les pré-requis sur le lien ci-dessus).
mbr2gpt.exe /convert /disk:9 pour effectivement lancer la conversion (+ création de la partition ESP, formatage en FAT32, ajout des fichiers de démarrage pour le protocole EFI etc…)

Il sera nécessaire de paramétrer le boot en EFI car ceci va de paire (sous Windows) avec une table de partition GPT.

Détruit toutes les données sur la clé !
On repère le chemin de la clé USB et on le stocke dans une variable (à adapter) :
DEVICE=/dev/sdX

Avec table GPT :

Préparation des partitions

Créer table de partition GPT. Créer 3 partitions :

• 500M FAT32 - drapeau esp (sdX1)
• 1M non formaté - drapeau bios_grub (sdX2)
• le reste en fat32 (sdX3)

Puis on les monte :
pmount ${DEVICE}1 efi
pmount ${DEVICE}3 boot

Installation de GRUB pour le mode EFI

Pour l’EFI 64 bits :
sudo grub-install --removable --no-nvram --root-directory=/media/boot --boot-directory=/media/boot --efi-directory=/media/efi --target=x86_64-efi

Ceci installe les exécutables efi SHIM (BOOTX64.efi) et GRUB (grubx64.efi) dans la partition EFI, avec un fichier de configuration minimaliste (grub.cfg) qui va définir le chemin des ressources et configuration de GRUB sur la 3e partition.
Ceci installe aussi les ressources (modules, police etc) de GRUB dans le dossier /boot/grub de la partition principale.

Je n’ai pas réussi à faire fonctionner shim (écran bleu “Boot restoration)”, donc je le désactive pour l’instant, et tant pis pour le secureboot :
mv /media/efi/EFI/BOOT/BOOTX64.EFI /media/efi/EFI/BOOT/BOOTX64.EFI.SHIM && mv /media/efi/EFI/BOOT/grubx64.efi /media/efi/EFI/BOOT/BOOTX64.EFI

Installation de GRUB pour le mode BIOS

Ceci semble fonctionner sans créer une table hybrid-mbr. On installe donc simplement GRUB sur le disque :
sudo grub-install --removable --no-nvram --root-directory=/media/boot --boot-directory=/media/boot --target=i386-pc ${DEVICE}

S’il y’a une erreur liée aux listes de blocs, c’est que le drapeau bios_grub n’a pas été positionné sur la 2e partition.

Configuration

Grub devrait alors pouvoir démarrer, mais n’est pas configuré ! On va donc créer un fichier de configuration minimaliste, simplement pour vérifier que la clé est bien démarrable :

cat > /media/boot/grub/grub.cfg <<EOF
insmod efi_gop
insmod font
insmod gfxterm
insmod png
loadfont /grub/fonts/unicode.pf2
set gfxmode=auto
set gfxpayload=keep
terminal_output gfxterm

search.fs_uuid AAAA-AAAA efi
search.fs_uuid BBBB-BBBB root

menuentry "Tetrefis" {
        insmod chain
        chainloader (\$root)/grub/EFI-loaders/tetris.efi
}
EOF

On met les bonnes valeurs d’UUID :

sed "s/AAAA-AAAA/$(/usr/sbin/blkid -s UUID -o value ${DEVICE}1)/" /media/boot/grub/grub.cfg -i
sed "s/BBBB-BBBB/$(/usr/sbin/blkid -s UUID -o value ${DEVICE}3)/" /media/boot/grub/grub.cfg -i

On peut enfin démonter les 2 partitions :
pumount efi && pumount boot
et tester la clé.

GRUB devrait alors être bootable et afficher le menu (même si l’entrée est actuellement non-fonctionnelle). Pour plus de détails sur la configuration de GRUB et le démarrage de différents systèmes (exécutables EFI, noyaux linux, ISOs etc), voir un prochain article.

SATA:

Détruit toutes les données sur le disque

Si plantage pendant la procédure, le disque peut être rendu inutilisable !

Ne PAS utiliser via adapt USB, peut mener à un disque briqué. Uniquement SATA directement.

Ici, sous Debian Bullseye. Peut être différent sous d’autres versions de hdparm.

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

Principe :

• mettre un mot de passe ATA sur le disque
• lancer la commande ATA Secure Erase

Ainsi toutes les cellules sont marquées vides et les perfs reviennent

Commandes :

device=/dev/sdX

• démonter toutes les partitions du disque

sudo umount ${device}*

• vérif si security est pas frozen, et si security-erase-enhanced est supporté :

sudo hdparm -I $device | grep -Ei 'security|frozen|locked|erase|enhanced|enabled|supported'

donne

Security: 
       Master password revision code = 65534
               supported
       not     enabled
       not     frozen
               supported: enhanced erase

Si “frozen”, on peut essayer de mettre en veille puis réveiller le pc.

• on setup le password “p”

sudo hdparm --user-master u --security-set-pass p $device

• on vérifie que le mot de passe est bien pris en compte

sudo hdparm -I $device  | grep -Ei 'supportsecurity|frozen|locked|erase|enhanced|enabled|supported'

donne

Security: 
       Master password revision code = 65534
               supported
               enabled
               supported: enhanced erase

• on lance la commande ATA Secure Erase (Enhanced si disponible)
  ATTENTION NE PAS INTERROMPRE L’OPERATION SOUS PEINE DE BRIQUER LE DISQUE

time sudo hdparm --user-master u --security-erase-enhanced p $device

## ou 
time sudo hdparm --user-master u --security-erase p $device

Ceci a mis environ 30 secondes pour un SSD Crucial de 500Go, 80s pour un ssd intel de 180Go et ~10h pour un HDD de 6To.

Pour nvme ? https://superuser.com/questions/1530363/how-to-securely-erase-an-nvme-ssd

apt-get install nvme-cli

nvme list

nvme format -s1 /dev/nvmeXn1

Signal symétrique ou asymétrique

Un signal asymétrique circule sur une paire de fils, la masse et le signal (+). Il est simple, mais est relativement sensible aux perturbations éléctromagnétiques.

Un signal symétrique circule sur 3 fils, la masse, le signal (+) et le “négatif” du signal (-). Ceci nécessite 1 cable supplémentaire, mais permet d’effectuer une addition des 2 signaux, ce qui annule les perturbations.
Il permet aussi de couvrir des distances + longues sans trop de perte de signal.

On peut convertir un signal asymétrique en signal symétrique (et vice-versa) via un boîte de direct (ou DI, direct injection box).
https://www.projethomestudio.fr/boitiers-direct-di-guide/

Câbles et appareils

Un câble à 3 parties (XLR ou jack TRS) permettra de transporter indifféremment 2 signaux asymétriques (stereo) ou bien 1 signal symétrique.

Il faut toutefois que les appareils en émission et en réception soient prévus pour générer et recevoir le même type de signal. Si on branche une source symétrique sur une réception stereo, une enceinte recevra le signal “normal”, et l’autre enceinte recevra le même signal avec une polarité inversée, ce qui devrait créer un rendu assez peu agréable.
Il faut donc vérifier clairement le type de signal prévu pour chaque connecteur !

https://www.bax-shop.fr/blog/cable/les-connexions-symetriques-et-asymetriques-expliquees/ https://www.formation.crossmediavignon.fr/Les-connecteurs-audio.html

Niveau des signaux

https://www.projethomestudio.fr/niveau-ligne-micro-instrument/

Tous les appareils ne génèrent pas le même niveau de signal (en dBV).

Le niveau microphone est particulièrement faible. Il doit être amené au niveau ligne par un préampli.
Le niveau instrument correspond au niveau de sortie des guitares et basses électriques. Il doit aussi être amené au niveau ligne.
Le niveau ligne (line) est le niveau de la plupart des synthés, ordis etc, ainsi que pour la connexion de différents appareils de sonorisation entre eux.

Il est important de brancher une source sur une entrée adaptée à son niveau de signal.

Il y’a en réalité 2 niveaux ligne : le niveau des appareils grand public (-10dBV) et le niveau des appareils pro (+4dBU). On peut utiliser des boitiers pour convertir de l’un vers l’autre (mais la conversion du niveau grand public vers le niveau pro va amplifier aussi le bruit).

XLR

Câble majoritairement utilisée pour les micros, et le branchement des enceintes sur la table de mixage.
Le signal voyage toujours du côté femelle vers le côté mâle (du point de vue du câble).

Il y’a le plus souvent 3 cables : la masse, le point chaud (+) et le point froid (-).
Ceci permet de faire circuler un signal symétrique, ou bien 2 signaux asymétriques (et donc de la stereo, même si en pratique ce n’est quasiment jamais utilisé ainsi).

Il y’a parfois seulement 2 câbles soudés : la masse et point chaud, (+).
Le cable est alors dit asymétrique (car uniquement capable de transporter un signal asymétrique) ; il sera moins cher, mais offre moins de possibilités.

JACK

3.5mm : format écouteurs. Les prises sont uniquement asymétriques : soit 2 parties (masse/signal mono), soit 3 (signal/droite/gauche).

6.5 mm : format guitares. 2 versions : câble TS (tip/sleeve) à 2 parties, ou TRS (tip/ring/sleeve) à 3 parties. Utilisé pour de la connexion symétrique ou de la connexion stéréo, en fonction des appareils/prises.

Enceintes

Les enceintes de monitoring sont des enceintes dont le son est prévu pour être le + neutre possible, contrairement à des enceintes hifi, dont le son est arrangé pour donner une couleur particulière.

Micros

Micros statiques (ou à condensateur) -> besoin d’alim fantôme. Il faut toujours brancher le micro à la table/carte AVANT d’allumer l’alim fantôme.
Micros dynamiques : pas besoin alim fantôme mais ne devrait pas poser problème ? Micros à ruban : alim fantôme dangereuse ?

Table de mixage

PFL : pré-fade listen -> le niveau de signal avant le fader général de la piste.

https://www.bax-shop.fr/isolateur-de-boucle-de-masse/art-dti-isolateur-de-boucle-de-masse#reviews

Très inspiré de cet article.

Les touches mortes sont des touches modificatrices qui, seules, ne produisent pas d’entrée clavier. Elles doivent être suivies d’une autre touche qui sera alors modifiée (par exemple le circonflexe, le backtick qui peut devenir un accent grave etc). Il faut répéter l’appui sur la touche pour obtenir le caractère seul.

Dans mon cas, je souhaite utiliser le backtick lors du premier appui. Pour ceci, il faut déjà identifier l’ID de l’evenement lorsque j’appuie sur la touche en question. Lancer
xev
appuyer sur la touche à paramétrer, et regarder le “keycode”. Pour le backtick, c’est 16.

Ensuite, on vérifie le comportement de cette touche (modifier l’ID si besoin) :
xmodmap -pke | grep " 16 "
qui me donne
keycode 16 = egrave 7 egrave 7 dead_grave Egrave dead_grave

Le “dead_” signifie que la touche se comporte comme une touche morte. Le “grave” signifie le backtick. On remplace donc l’entrée par :
keycode 16 = egrave 7 egrave 7 grave Egrave grave

et le backtick s’affiche directement lors du premier appui !

Je suppose que ce réglage ne tient pas un reboot, voire une déconnexion de session. À vérifier.

Ressources en vrac

Doc debian-fr.xyz
Doc officielle Debian
Doc ArchLinux
Doc Ubuntu, un peu vieille
https://ignace72.eu/utiliser-un-onduleur-eaton-sur-gnu-linux.html

Présentation

NUT (Network UPS Tools) est un ensemble de logiciels qui servent à surveiller les onduleurs et réagir à leur état. Il y’a :

• le démon nut-driver (commande upsdrvctl) qui communique avec l’onduleur
• le démon nut-server (commande upsd) qui permet de répondre à des requêtes (locales ou réseau)

Ces 2 démons doivent être lancés sur le poste qui communique en USB avec l’onduleur.

• le logiciel upsc qui va interroger les démons upsd (en local ou sur d’autres postes)
• le démon upsmon qui permet d’interroger différents démons upsd et lancer des alertes

Dépôt git du projet

Dans l’exemple ici, il y’a un seul pc qui contrôlera NUT et qui sera relié à l’onduleur ; on ignore donc toutes les configurations réseau.
L’onduleur utilisé est un Eaton Ellipse ECO 800.

Install de NUT et vérification du branchement de l’onduleur

apt install nut
sous Debian.
C’est un paquet virtuel qui dépend de nut-client et nut-server.
nut-client contient entre autres les exécutables upsc, upscmd, upsmon.
nut-server contient entre autre upsd, upsdrvctl.

Brancher l’onduleur via USB.
lsusb donne :
Bus 006 Device 005: ID 0463:ffff MGE UPS Systems UPS

On peut vérifier que le fichier appartient bien au groupe nut (adapter les chiffres au résultat ci-dessus) :
ls -l /dev/bus/usb/006/005

Pilote de l’onduleur

sudo nano /etc/nut/ups.conf

Chaque onduleur doit être défini sous la forme

[upsname]
       driver = <drivername>
       port = <portname>

avec éventuellement d’autres options facultatives. On peut mettre auto pour le port. Le champ desc semble être là pour mettre une description plus complète commentaire).

Pour identifier la liste des pilotes en fonction du matériel, consulter cette page.
Pour un Eaton Ellipse Eco 800, c’est usbhid-ups. Si on clique sur le nom du pilote, on accède à ses otions de configuration.

On peut aussi tester la commande nut-scanner, qui renvoie un bloc de configuration auto-detecté (+ d’infos avec sudo).

Cela me donne le bloc suivant à ajouter à la fin du fichier :

[eaton800]
    driver = usbhid-ups
    port = auto
    desc = "Eaton Ellipse ECO 800"

Lancement

On peut vérifier en lançant manuellement :
sudo upsdrvctl start eaton800

Le processus sera visible via
ps aux | grep usbhid

On peut lancer le service
sudo service nut-driver start
mais visiblement, si le service nut-server n’est pas en route, il quitte au bout de quelques secondes.

Configuration du démon upsd

Celui-ci sert à mettre les informations de l’onduleur à disposition de clients.

Lancement manuel

À fin de compréhension et de debug. On peut lancer upsd manuellement avec le chemin
/usr/lib/nut/upsd
La commande upsd intégrée dans le path (/usr/sbin/) est un script qui va lancer la commande ci-dessus uniquement si la configuration du fichier upsd.conf autorise le lancement.

Si on a l’erreur Can't connect to UPS [...] au lancement, c’est probablement que le processus driver (upsdrvctl) n’est pas lancé.
Sinon on doit avoir Connected to UPS [...]

On peut vérifier le bon lancement du processus via
ps aux | grep upsd | grep nut

Lancement via service

Cette méthode permettra le démarrage automatique de l’ensemble des services nut.
sudo nano /etc/nut/nut.conf
mettre MODE=standalone

On démarre le service :
sudo service nut-server start

Utilisateur

Il faut définir (au moins) un utilisateur dans upsd car une authentification sera nécessaire pour effectuer certaines commandes, notamment celles d’upscmd qui permettent de contrôler l’onduleur (bip, extinction etc).

Pour ceci,
sudo nano /etc/nut/upsd.users et ajouter à la fin un bloc par utilisateur, de type :

[myadmin]
        password = mypass
        #allowfrom = localhost
        actions = SET
        actions = FSD
        instcmds = all
        upsmon master

Détail des options : man upsd.users
(ou https://linux.die.net/man/5/upsd.users )
Actuellement (2022), fsd (forced shutdown) et set (définir des variables sur l’onduleur) sont les 2 seules actions.
instcmds sont les options disponibles dans upscmd -l.

Logiciels clients

upsrw ??

upscmd

upscmd permet de s’adresser directement à l’onduleur.

upscmd -l eaton800
pour voir les commandes supportées par l’onduleur (par exemple contrôler le bip, forcer l’extinction etc)

upscmd eaton800 command:enable
pour lancer la commande en question sur l’onduleur

Sur mon Ellipse ECO 800, il semlble que beeper.disable n’ait pas d’effet, et que load.off et shutdown aient le même effet : couper les prises de courant de l’onduleur ET éteindre l’onduleur, le rendant injoignable sans rallumage manuel de l’onduleur.

upsc

upsc permet de s’adresser à un démon upsd.

upsc -L [host]
pour lister tous les onduleurs détectés sur host ; si l’host n’est pas spécifié, c’est localhost.

Si on a le message d’erreur Error: Connection failure: Cannot assign requested address, c’est que upsc n’arrive pas à communiquer avec upsd ; soit que ce dernier n’est pas lancé, soit qu’il n’accepte pas la requête (voir dans ce cas la directive LISTEN du fichier upsd.conf, même s’il me semble qu’il n’est pas nécessaire de la configurer si tout se fait en local sur 1 seul poste).

upsc eaton800[@host]
pour voir les données actuelles de l’onduleur ; on peut quérir un seul attribut en le mentionnant ; par exemple
upsc eaton800 ups.status
qui peut être OL (OnLine, sur secteur), OB (OnBattery)
ou encore upsc eaton800 battery.charge

Si non a l’erreur Error: Driver not connected, c’est que upsc arrive à communiquer avec upsd, mais que upsd n’arrive pas à communiquer avec le pilote (par exemple processus pilote qui a été tué).

Si prise USB débranchée -> “Error: Data stale”

Monitoring automatique - upsmon

upsmon est le composant qui va surveiller l’état de l’onduleur, et lancer des actions selon l’état (surt batterie, batterie critique etc).
On définit au moins 1 onduleur à surveiller :

sudo nano /etc/nut/upsmon.conf

Le fichier documente chaque section.
Il faut une ligne MONITOR par onduleur ; par exemple
MONITOR eaton800@localhost 1 myadmin mypass master

Le “1” correspond au nombre d’alims qui sont alimentés par l’onduleur en question ; pour la plupart des pcs standard, qui n’ont qu’une seule alim, ce sera 1.

On peut toutefois entrer “0” si le pc surveille l’onduleur mais n’est pas branché dessus ; il effectuera les actions d’alerte (mail etc.) mais ne s’éteindra pas en cas de batterie critique. En ca cas, il faut aussi définir la variable MINSUPPLIES à 0 (pour déclarer que le poste peut fonctionner sans aucun onduleur).

master & slave

En général, un poste branché sur l’onduleur ET capable de communiquer avec lui sera considéré comme master ;
Un poste branché sur l’onduleur mais sans communication de données sera considéré comme slave.

En action automatique, un poste master ne s’éteindra que lorsque tous les slaves seront éteints.

NOTIFYCMD

https://networkupstools.org/docs/user-manual.chunked/ar01s07.html

Toujours dans upsmon.conf, on peut définir la commande appelée pour informer l’admin lorsqu’un événement se produit (coupure courant, batterie faible etc). C’est le paramètre NOTIFYCMD.

Cette commande ne sera exécutée que pour les alertes possédant le flag EXEC !! (voir plus bas)

Ce peut être un script custom, ou bien le planificateur intégré à NUT (upssched). Le message de l’événement sera envoyé à cet exécutable en tant que 1er et seul argument.

Penser aux droits d’accès ! La commande sera exécutée par l’utilisateur nut (sur Debian), il doit pouvoir y accéder en exécution.

NOTIFYMSG

Permet de personnaliser le message associé à chaque alerte.

NOTIFYFLAGS

Définit le type d’actions à effectuer pour chaque type d’alerte. Il y’a :

• WALL : prévient chaque utilisateur sur le système
• SYSLOG : inscrit dans le syslog
• EXEC : lance la commande définie à NOTIFYCMD
• IGNORE : ne rien faire

Il faut noter FLAG+FLAG+FLAG, par exemple
EXEC+SYSLOG+WALL

Lancement via service

sudo service nut-client start

upssched

upssched est un script qui permet de gérer la planification des alertes plus finement. Par exemple de définir un délai avant de déclencher l’alerte, pour ne pas êztre prévenu en cas de micro-coupure de courant.
On le configure via le fichier /etc/nut/upssched.conf.

Je n’aborde pas son usage ici.

GUI

nut-monitor
nut-cgi (interface web)

Journaux et contrôle des services

Voir les journaux de nut-driver (upsdrvctl) :

sudo journalctl -u nut-driver
sudo service nut-driver status

Voir les journaux de nut-server (upsd) :

sudo journalctl -u nut-server
sudo service nut-server status

Voir les journaux de nut-client (nut-monitor, upsmon) :

sudo journalctl -u nut-monitor
sudo service nut-monitor status
sudo service nut-client status

sudo service ups-monitor ??

(OPAL 1 est un peu différent et n’est pas analysé ici)

Généralités

La norme OPAL 2.0 est une norme qui définit notamment un standard pour qu’un péripĥérique de stockage (disque dur, ssd etc) auto-protège ses données par du chiffrement. C’est un SED, un Self-Encrypting Disk.
C’est donc une puce dans le disque lui-même qui s’occupe de chiffrer et déchiffrer les données (libérant ainsi le CPU de ces tâches, et réduisant la surface d’attaque concernant les failles CPU/RAM ; d’autres attaques concernant ce type de chiffrement sont toutefois existantes).

Le chiffrement du disque se fait un peu à la manière de LUKS : la clé qui va réellement chiffrer les données (Data Encryption Key, DEK) est elle-même chiffrée par le mot de passe utilisateur (Authentication Key, AK).
Ainsi, il est facile de changer le mot de passe du disque sans tout rechiffrer (la DEK ne change pas, mais est rechiffrée avec la nouvelle AK).
Il est également instantané et simple d’effacer de manière sécurisée et intégralement un disque, simplement en regénérant une nouvelle DEK. Ainsi, le reste du contenu n’a pas besoin d’être effacé, puisqu’il est indéchiffrable, la clé ayant été supprimée. C’est le Secure Disk Erasure.

Sur un disque OPAL, les données sont TOUJOURS chiffrées par une DEK, mais en l’absence de AK, la DEK est lisible en clair et donc utilisée de manière transparente (voir MSID).

Spécifications d’OPAL sur le site du TCG : https://www.trustedcomputinggroup.org/wp-content/uploads/TCGandNVMe_Joint_White_Paper-TCG_Storage_Opal_and_NVMe_FINAL.pdf

Un diaporama qui schématise bien OPAL et différentes attaques

USB

La disponibilité de l’interface OPAL via un adaptateur USB va dépendre de l’adaptateur en question. Ce fil mentionne un adaptateur qui semble fonctionner avec les disques M.2 SATA et NVMe.

Doc chez ArchLinux

Terminologie

• SD : Storage Device : le support de stockage (disque, SSD, clé USB etc)
• MEK (ou DEK) : Media (ou Data) Encryption key : la clé qui chiffre les données sur le disque ; chiffrée par la KEK
• AC : Authentication Credentials : le mot de passe utilisateur (“password”)
• AK : Authentication Key (ou PIN) : dérivée de l’AC
• KEK : Key-Encryption-Key : dérivée de l’AK, chiffre la DEK
• TPer : Trusted Peripheral
• MSID : Manufacturer Secure ID : une clé fixe, lisible par tout le monde directement sur le disque, qui fait office de AK par défaut.
• PSID : Physical Security ID : présent physiquement sur le disque (ou la boîte), permet de réinitiliser le disque (avec PERTE de données). Il est optionnel pour OPAL v2.00, et obligatoire pour OPAL v2.01
• Verrouillage (Locking) : Création/suppression de la MEK (déchiffrée) dans la RAM du disque. Lorsqu’elle est absente, le disque est verrouillé. Une fois la MEK accessible grâce au password, elle est stockée dans la RAM du disque jusqu’à la prochaine coupure d’alimentation (ou verrouillage manuel ?). Le disque est alors déverrouillé.

Locking Range

Les intervalles de verrouillage sont des sections continues sur le disque, exprimées en LBA, qui peuvent être verrouillées de manière indépendantes les unes des autres. Chaque intervalle a sa propre MEK.
Ceci permet, il me semble, de partager un disque entre plusieurs utilisateurs, en ne laissant chacun accéder qu’aux données qui lui sont autorisées.
Ceci permet également d’avoir certains intervalles qui ne sont PAS chiffrés.

Le Global Range représente l’ensemble des intervales qui ne sont pas définis explicitement (les Local Ranges). C’est le range 0.

Lorsqu’on définit un nouvel intervalle, les données déjà présentes dessus sont détruites.

On peut lister les LockingRange ainsi :
sudo ./sedutil-cli --listLockingRanges mYpAsSwOrD /dev/sdX

Authentification pré-boot

La Preboot-Authentication (PBA) est un MBR particulier (shadow MBR) qui contient une instance de sedutil permettant de déverrouiller le disque, pour ensuite pouvoir le démarrer.
Selon cette discussion, MBREnable = Y dit au disque de présenter ce shadow MBR lors du boot, alors que MBRDone = Y dit au disque de ne PLUS présenter ce shadow MBR.

Sous Debian

La gestion d’un disque OPAL sous Linux se fait avec l’utilitaire sedutil. C’est un utilitaire open-source, développée par la Drive Trust Alliance.
Il n’est, en 2021, pas disponible dans les dépôts Debian, et doit donc être téléchargé ou compilé depuis le lien ci-dessus.

Pour pouvoir gérer les disques SATA, il faut activer le paramètre allow_tpm du module libata. Pour le faire de manière permanente, il faut ajouter libata.allow_tpm=1 à /etc/default/grub (ligne GRUB_CMDLINE_LINUX_DEFAULT=), mettre à jour la config de GRUB et redémarrer.
Pour le faire de manière temporaire sans redémarrage du système, il semble qu’il faille écrire 1 dans le fichier /sys/module/libata/parameters/allow_tpm, mais je n’arrive pas à obtenir l’accès en écriture sur mon système.

Ceci ne semble pas nécessaire pour les disques NVMe. Par contre, il semble qu’il faille être root.

Utilisation de sedutil

Cet utilitaire nécessite souvent les droits root pour agir directement sur le périphérique.

Syntaxe

Codes d’erreur :

• NOT_AUTHORIZED : mauvais mot de passe
• AUTHORITY_LOCKED_OUT : trop d’essais infructueux, il faut éteindre/rallumer le disque

Lister les disques et leur support d’OPAL :

sudo sedutil-cli --scan
/dev/sda No -> Pas de support d’OPAL
/dev/sda 12 -> Support d’OPAL (“12” pour support de OPAL 1 et 2, “2” pour support d’OPAL 2 uniquement, il me semble)

Lister les détails d’un périphérique :

sudo ./sedutil-cli --query /dev/nvme0
On y voit notamment le statut de verrouillage (LockingEnabled) et de shadowing du MBR (MBREnabled) :

Locking function (0x0002)
    Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = Y, MediaEncrypt = Y

PSID revert - DÉTRUIT TOUTES LES DONNÉES SI VERROUILLAGE ACTIVÉ

Ceci va réinitialiser https://www.reddit.com/r/sysadmin/comments/9ogdnk/psid_revert_of_encrypted_ssd_not_possible/
sudo ./sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID PSIDPASSWORD /dev/sdX
sudo ./sedutil-cli --PSIDrevert PSIDPASSWORD /dev/sdX
Si le constructeur a mis des tirets dans le PSID, il faut les enlever (sinon on aura l’erreur “One or more header fields have 0 length”). Il doit faire 32 caractères de long.

Initialisation du chiffrement

sudo sedutil-cli --initialSetup mYpAsSwOrD /dev/sdX
Définit les mot de passe SID et Admin1 (avec le password fourni) (c’est le takeownership).
Active le shadowing de MBR.

Ceci équivaut aux suites de commandes (à vérifier) :

sudo ./sedutil-cli --takeOwnership mYpAsSwOrD /dev/sdX
# définit les password SID et Admin1

sudo ./sedutil-cli --activateLockingSP mYpAsSwOrD /dev/sdX
# active la possibilité de chiffrement ? (LockingEnabled)

sudo ./sedutil-cli --setMBREnable on mYpAsSwOrD /dev/sdX
#

On peut ensuite effectivement chiffrer le disque :
sudo ./sedutil-cli --enablelockingrange 0 mYpAsSwOrD /dev/sdX

Le disque devient ainsi non-lisible sans le mot de passe (y compris le MBR, il n’apparaîtra pas dans fdisk).
On voit “Locked = Y” lorsqu’on lance query

Déverrouillage d’un disque chiffré

sudo ./sedutil-cli --setlockingrange 0 rw mYpAsSwOrD /dev/sdX
Il redevient ainsi libible, y compris le MBR.
On peut également définir le volume en lecture seule :
sudo ./sedutil-cli --setlockingrange 0 ro mYpAsSwOrD /dev/sdX
ou le verrouiller :
sudo ./sedutil-cli --setlockingrange 0 lk mYpAsSwOrD /dev/sdX

Suppression du chiffrement

https://github.com/Drive-Trust-Alliance/sedutil/wiki/Remove-OPAL

On peut désactiver le chiffrement SANS suppresion des données avec :
sudo ./sedutil-cli --revertnoerase mYpAsSwOrD /dev/sdX
(il faut avoir deverrouillé le disque avant, en RX ou RO, sinon erreur FAIL)