Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Hors ligne
Nous faisons le choix de ne pas utiliser et de désactiver l'IPv6.
Pourquoi ce choix ?
Hors ligne
).Dernière modification par otyugh (25-08-2023 16:20:37)
En ligne
Dernière modification par Mezalor (25-08-2023 19:35:42)
Hors ligne
J'ai fait l'impasse sur l'IPv6 car ça complexifie la configuration (en particulier pour le pare-feu) alors que je voulais quelque chose de minimaliste.
Je pense que c’est ça qu’il aurait fallu écrire dans le guide 
La formulation actuelle ne donne aucun indice sur les raisons pour lesquelles IPv6 sera désactivé, ce qui risque de pousser le lecteur à des conclusions erronées (est-ce que IPv6 pose des problèmes de sécurité ? est-ce que ce protocole n’est pas pris en charge correctement pas Debian ? est-ce qu’il s’agit d’une technologie moribonde qui ne vaut pas le coup d’être mise en place ?).
Hors ligne
je suis un bienveillant du handicap que je suis malentendant que cas je suis exprime une dyslexique donc mes excuses car ne pas ma faute 
follow me mastondon : https://slon.yojik.net/@rodriguem82
Hors ligne
Dernière modification par Mezalor (27-08-2023 17:03:01)
Hors ligne
Pour tester si votre système supporte UEFI il suffit d'installer et de lancer le programme efibootmgr.
D'une part, il faut distinguer "supporte UEFI" et "a démarré en mode EFI". Si le système est capable de démarrer en mode EFI mais a démarré en mode BIOS/legacy, il est impossible de déterminer s'il "supporte EFI".
D'autre part, efibootmgr n'est ni nécessaire ni suffisant pour vérifier si le système a démarré en mode UEFI. Pas nécessaire, car il suffit de monter sysfs sur /sys et vérifier la présence du répertoire /sys/firmware/efi. Pas suffisant car efibootmgr a besoin d'accéder aux variables EFI (efivars) qui ne sont pas disponibles sur tous les systèmes UEFI et ne sont accessibles que si efivarfs est monté sur /sys/firmware/efi/efivars.
Installation de Debian (BIOS)
Format GPT : bon choix. Mais cela peut poser un problème pour l'amorçage avec certains firmwares BIOS (ou UEFI en mode legacy) défectueux qui refusent d'amorcer un disque si aucune entrée de la table de partition DOS du MBR n'a le drapeau "boot" activé. Or le MBR protecteur d'une table de partition GPT n'a pas de drapeau "boot" par défaut, ce qui empêchera l'amorçage avec ces firmwares. Pour l'éviter, il faut activer le drapeau boot de la partition de protection GPT du MBR, soit avec parted disk_set pmbr_boot on, soit avec fdisk -t dos. Je n'ai pas trouvé comment le faire avec gdisk. Attention : certains outils de partitionnement peuvent faire sauter ce drapeau, il faut donc revérifier sa présence après toute modification de la table de partition.
Par contre le choix de ne pas utiliser LVM est discutable avec un découpage aussi élaboré. L'utilisation de partitions manque de flexibilité.
L'argument "on peut également laisser de l'espace entre chaque partition dans le cas où l'on souhaiterait en agrandir certaine par la suite." est absurde : chacun de ces espaces est de fait réservé à l'agrandissement de la partition qui le précède et ne pourra servir à rien d'autre, donc autant créer des partitions plus grandes dès le départ.
Il faudra donc créer une partition spéciale « BIOS Boot » au début du disque pour permettre à GRUB de stocker des données sans risque d'écraser la table GPT.
Il n'y a aucun risque d'écraser la table de partition avec les versions actuelles de GRUB ; grub-install n'écrira pas sa core image à la suite du MBR s'il détecte une table de partition au format GPT. Simplement, en l'absence de partition "BIOS boot", il devra écrire sa core image en tant que fichier normal dans /boot/grub, ce qui n'est pas recommandé car considéré (à raison) comme peu fiable.
Les tailles proposées sont insuffisantes pour certains usages, notamment /var si on y stocke des bases de données volumineuses.
Une partition /boot de 200 Mo est trop petite pour un système Debian actuel. Pour pouvoir installer et mettre à jour les deux derniers noyaux il faut au minimum 3 fois la taille occupée par un noyau et son initramfs (~65 Mo) + la taille occupée par GRUB (~15 Mo). D'ailleurs les avantages de séparer /boot et /usr de la racine sont discutables alors que les inconvénients sont certains. Il n'est pas garanti qu'un /usr séparé continue à être supporté à l'avenir.
les fonctionnalités du système de fichiers Btrfs nous auraient par exemple éviter le partitionnement précédent grâce aux sous-volumes.
Pas vraiment car les sous-volumes Btrfs partagent le même espace de stockage du système de fichiers, donc ils ne protègent pas de la saturation.
On commence par définir les bons droits du dossier /tmp.
Ce n'est pas utile si le répertoire (et non "dossier") /tmp sert de point de montage pour un tmpfs. Les permissions du système de fichiers monté masqueront celles du point de montage.
Ça ne marche pas. Avec /32 aucune route directe permettant d'atteindre l'adresse du routeur n'est créé.
Systemd (...) est le premier processus démarré après le chargement du noyau
Rectification : le premier processus est le script /init situé à la racine de l'initramfs. C'est lui qui lance ensuite le programme /sbin/init (systemd ou autre gestionnaire d'init) après avoir monté la racine.
Installation de Debian (UEFI)
Monter la partition EFI sur /boot ne fonctionne pas avec les noyaux Debian. Lors de la mise à jour ou de la réinstallation d'un paquet, dpkg doit créer des liens physiques (hard links) des fichiers du paquet, ce qui provoquera un échec avec les fichiers du noyau installés dans /boot car le système de fichiers FAT ne supporte pas les liens physiques ou symboliques. D'autre part je n'en vois pas l'intérêt.
Étape 10 : Installation du noyau et du chargeur d'amorçage
il suffit juste de copier les fichiers vmlinuz et initrd.img dans la partition EFI puis de créer un script startup.nsh
Je viens de tester sur mes 3 PC UEFI et aucun ne prend en compte le fichier startup.nsh où que ce soit dans la partition EFI (à la racine, dans le répertoire EFI). Je soupçonne qu'il faut que le firmware UEFI soit doté d'un shell UEFI et que ce n'est pas toujours le cas. J'espère que la situation est meilleure avec les serveurs dédiés, VPS et autres hyperviseurs de machine virtuelle.
\EFI\Debian\vmlinuz root=/dev/sdb2 ro initrd=\EFI\Debian\initrd.img
Mettre en dur un nom de périphérique notoirement non persistant comme sdb2 dans le paramètre root du noyau est une mauvaise idée. lsblk montre que sda est la racine du mode secours, il est fort possible que ce disque ne soit pas présent lors d'un démarrage normal et le disque système deviendrait sda. Même si le disque du mode secours reste présent, rien ne garantit que le disque système sera toujours sdb. Il est donc préférable d'utiliser l'UUID, PARTUUID, LABEL ou PARTLABEL. Note : le problème ne se poserait pas avec LVM dont les noms de volumes logiques sont persistants.
Configuration des outils de base de Debian
Étape 1 (fac) : Durcissement du noyau
"A ce point", c'est bien le problème. Les modules chargés par l'initramfs ou par /etc/modules sont déjà chargés, mais rien ne garantit que les modules chargés dynamiquement par udev comme les pilotes de carte réseau sont déjà chargés. Sans parler du pilote vfat pour la partition EFI qui n'est pas montée automatiquement.
Tu as testé tout ce que tu as écrit, et ça marche ?
Il vaut mieux montrer que raconter.
Hors ligne