Cyril Brulebois a écrit 652 commentaires

Hello,

kernel-package, fournissant la commande make-kpkg, est déprécié depuis fort longtemps.

Basculer sur make deb-pkg (ou make bindeb-pkg) est une très bonne idée, c'est maintenu upstream (cf. scripts/package/Makefile) et c'est adapté quand nécessaire pour que ça continue à fonctionner de version en version.

C'est également une recommandation côté debian-kernel, cf. le Debian Linux Kernel Handbook.

Je finirais par mentionner que générer un .deb est très utile pour un usage local (et pas forcément pour une autre machine) : cela permet d'obtenir un paquet intégré dans le gestionnaire de paquets (y compris les hooks initramfs-tools, grub* etc.), plutôt que d'avoir des fichiers en vrac qu'il faut maintenir (ou laisser pourrir) soi-même…

Debian Consultant @ DEBAMAX

Effectivement, j'ai déjà utilisé socat avec succès dans ce genre de contexte. Voir aussi l'option fork, qui peut être utile (mais faire attention, OpenSSL est géré de manière spécifique). Bref, une lecture de page de manuel s'impose. ;)

Debian Consultant @ DEBAMAX

Je pense que le morceau de code que je proposais contient bien un appel à losetup -f… ;)

Mon dernier commentaire avait juste pour but de mettre en évidence que la présence des différents /dev/loopN mentionnés est totalement normale.

Debian Consultant @ DEBAMAX

Je ne comprends pas trop pourquoi modinfo ne trouve pas le module loop pour en donner les détails, mais nous n'avons aucune information sur la distribution utilisée, ou sur comment le noyau a été installé (peut-être un depmod qui manque ?).

Le fait est qu'il y a déjà des loops en place pour des snaps (dixit le premier post), donc il me semble assez sûr que ce module est en fait fonctionnel…

Quant aux loops en trop, c'est un faux problème. Il y a en effet par défaut un certain nombre de périphériques prêts à être utilisés, et d'autres peuvent être créés à la volée…

Extrait de drivers/block/Kconfig :

config BLK_DEV_LOOP_MIN_COUNT
        int "Number of loop devices to pre-create at init time"
        depends on BLK_DEV_LOOP
        default 8
        help
          Static number of loop devices to be unconditionally pre-created
          at init time.

          This default value can be overwritten on the kernel command
          line or with module-parameter loop.max_loop.

          The historic default is 8. If a late 2011 version of losetup(8)
          is used, it can be set to 0, since needed loop devices can be
          dynamically allocated with the /dev/loop-control interface.

Debian Consultant @ DEBAMAX

Merci d'avoir mentionné cette option. Ça fait tellement longtemps que je joue avec losetup et kpartx que je n'ai pas relu les pages de manuel…

Pour info ça semble dater de :

commit 916bf85e621bb01d58279a014088376c80050a74
Author: Karel Zak <kzak@redhat.com>
Date:   Mon Jan 9 23:27:53 2012 +0100

    losetup: add --partscan option

    Signed-off-by: Karel Zak <kzak@redhat.com>

qui a été publié pour la première fois dans : v2.21-rc1.

Si on veut le faire à la main, exemple rapide, avec une image de disque contenant 3 partitions :

$ sudo losetup -f demo.img
$ sudo kpartx -avs /dev/loop0
add map loop0p1 (253:4): 0 2048 linear 7:0 2048
add map loop0p2 (253:5): 0 1024000 linear 7:0 4096
add map loop0p3 (253:6): 0 10440671 linear 7:0 1028096
$ sudo kpartx -dvs /dev/loop0
del devmap : loop0p3
del devmap : loop0p2
del devmap : loop0p1
$ sudo losetup -D demo.img

Quelques notes :

• losetup accepte l'option --show permet de demander l'affichage du périphérique utilisé, pratique pour les scripts.
• kpartx a besoin de -a / -d pour travailler, -v permet un affichage verbeux, -s le mode synchrone. À nouveau, pratique pour les scripts, ça évite de mettre un sleep ± long…
• j'ai édité la sortie dans mon exemple ci-dessus. On peut avoir des petites blagues, par exemple l'activation automatique d'un groupe de volumes LVM (VG).

Ce qui donnerait plutôt :

$ sudo kpartx -dvs /dev/loop0
device-mapper: remove ioctl on loop0p3 failed: Device or resource busy
del devmap : loop0p2
del devmap : loop0p1
$ sudo vgchange -an le-vg-parasite
  0 logical volume(s) in volume group "le-vg-parasite" now active
$ sudo kpartx -dvs /dev/loop0
del devmap : loop0p3
$ sudo losetup -D demo.img

Debian Consultant @ DEBAMAX

Ça me paraît audacieux de comparer un soft qui fonctionne (depuis quelques années) malgré des limites évidentes quand on le maltraite, avec un soft qui n'existe pas encore.

WireGuard tourne en espace noyau, le module n'est pas dans mainline, alors de là à avoir un noyau compatible côté serveur et côté clients…

Bref, tout n'est pas rose chez OpenVPN, mais au moins c'est utilisable. Aujourd'hui. (Et hier.)

Édition → J'ai failli oublier les mises en (wire)garde adressées par upstream :

About The Project

Work in Progress

WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. There are experimental snapshots tagged with "0.0.YYYYMMDD", but these should not be considered real releases and they may contain security vulnerabilities (which would not be eligible for CVEs, since this is pre-release snapshot software). If you are packaging WireGuard, you must keep up to date with the snapshots.

Debian Consultant @ DEBAMAX

J'ai utilisé OpenVPN dans plein de contextes différents et je n'ai pas l'impression que ça soit déprécié ?

Comme tu le mentionnes, il y a un plugin dans NetworkManager qui rend son utilisation plutôt agréable, que ça soit en cliquant dans l'applet ou via la CLI (nmcli c up Debamax pour monter la connexion VPN correspondante).

Au passage, je ne sais pas quel support Raspbian propose, mais rester sur une base oldstable (Jessie) qui n'est plus maintenue (que via l'initiative LTS) dans Debian, c'est potentiellement délicat comme point d'entrée sur ton infrastructure ?

Debian Consultant @ DEBAMAX

Aors je vais miser sur le fait que tu es avec la disposition de clavier fr, avec la variante latin9.

Problème caractéristique : quand on tape un peu vite altgr+| suivi d'espace, on peut avoir altgr encore enfoncée quand l'espace est tapée. Cela donne une espace insécable avec cette disposition, et on essaie donc de lancer la commande  dmtxwrite plutôt que dmtxwrite, ce qui donne l'erreur « commande introuvable ».

Pour éviter le souci, je privilégie la variante oss à la place de latin9, avec laquelle il faut taper altgr+shift+espace, ce qui limite les frappes involontaires (en plus de donner plein d'autres combinaisons/caractères).

Debian Consultant @ DEBAMAX

J'en profite pour détailler un peu comment cela fonctionne :

• on connaît les fameux r, w, x pour chaque utilisateur (u), groupe (g) et autre (o) ;
• il y a également le bit setuid, qui correspond à u+s ;
• mais aussi le bit setgid, qui correspond à g+s ;
• et enfin le bit sticky, qui correspond à o+t (ou +t).

Les trois derniers ont comme poids respectifs 4, 2 et 1, d'où le 2 en préfixe des permissions usuelles.

Le bit setgid, c'est ce que j'appelle le mode « collaboratif », et c'est ce qui permet de créer des fichiers/répertoires dans le même groupe que le répertoire parent plutôt que d'avoir le comportement par défaut, qui est de mettre les nouveaux items dans… le groupe principal de l'utilisateur en question.

Vu les besoins décrits, c'est effectivement probablement suffisant (modulo le problème d'umask). Alternativement, il est possible de positionner des ACL au niveau du système de fichiers (si les outils sont installés — paquet acl sous Debian — et si l'option est activée sur le système de fichiers — acl dans /etc/fstab) si on n'a pas la possibilité de régler le problème d'umask. Mais cela sous-entend de savoir reconnaître que des ACL sont positionnées, et comment les consulter/modifier (chacl, getfacl, setfacl). Flexibilité++ mais complexité++… ;)

Debian Consultant @ DEBAMAX

Erlingen c'est plutôt du côté de München. C'est Erlangen à côté de Nürnberg (confirmé sur le site de la conférence).

Debian Consultant @ DEBAMAX

Once upon a time nous avions besoin de spécifier des trucs très pointus dans /etc/X11/XF86Config-4. Plus récemment, c'est /etc/X11/xorg.conf qui l'a remplacé (suite au fork XFree86/X.Org). Mais depuis de nombreuses années, l'autoconfiguration fonctionne la plupart du temps, donc je ne vois pas trop pourquoi tu aurais besoin d'un tel fichier (malformé pour le moment). As-tu un outil qui l'a généré ? Je suggère de déplacer ce fichier ailleurs (ou bien de le supprimer complètement), de t'assurer que tu as bien les paquets suivants installés, puis de retenter ta chance :

• xorg
• xserver-xorg
• xserver-xorg-input-all
• xserver-xorg-video-all

Debian Consultant @ DEBAMAX

Au niveau du FS plutôt qu'au niveau du disque, mkfs.ext4 sait lire un rapport badblocks (avec -l foo) pour la création d'un système de fichiers qui évitent les trous.

Debian Consultant @ DEBAMAX

Merci pour la précision. Je viens de pinguer l'équipe noyau, peut-être que ça va accélérer les choses, d'avoir rappelé qu'un backport plus récent serait le bienvenu.

<shameless-plug>
Sur le même sujet, pour celles et ceux que ça pourrait intéresser, un petit état des lieux des réflexions en cours pour avoir un support officiel des backports dans l'installateur.
</shameless-plug>

Debian Consultant @ DEBAMAX

Ce serait intéressant de regarder s'il y a un log (journal) des modifications qui aurait été sauvegardé par cet outil, voire une copie de la table des partitions avant modification. Cela permettrait probablement de se faire une meilleure idée des conséquences du redimensionnement, et de peut-être conclure quant aux partitions d'à côté…

Debian Consultant @ DEBAMAX

Tu as une idée de quand ça date/de quelle version il s'agit ? Ça fait quelques années maintenant que je surveille ce que ça donne côté système d'installation, et je n'ai aucun souvenir de ça…

Debian Consultant @ DEBAMAX

Tout à fait d'accord. Si on n'est pas au courant du bogue, c'est difficile à deviner/détecter/corriger…

Au passage si quelqu'un pouvait modifier l'entrée initiale, il y a deux fois le lien vers stretch-backports au lieu de stretch-backports puis sid.

Debian Consultant @ DEBAMAX

Hello,

A priori il est possible de configurer les fichiers à essayer quand on arrive dans un « répertoire », par exemple avec une telle ligne :

index index.html index.html index.php

(Par défaut, chez Debian, et peut-être chez Ubuntu, il n'y a pas de tentative pour index.php…)

Si aucun de ces fichiers n'est trouvé, il peut y avoir un essai de listing automatique (directive autoindex).

Debian Consultant @ DEBAMAX

IFS, c'est un peu plus que \n uniquement. ;)

$ printf "$IFS"|hd
00000000  20 09 0a                                          | ..|
00000003

→ Espace, tabulation, et retour à la ligne.

Cela explique en partie pourquoi les scripts qui changent IFS pour une section de code plutôt que pour juste une commande comme tu le proposais… incluent presque tous une sauvegarde préalable dans une variable souvent nommée OLDIFS, pour recopie ultérieure dans IFS.

Debian Consultant @ DEBAMAX

Ce n'est pas pour rien que je posais la question de la taille du disque. Dans partman-partitioning, la taille du disque est vérifiée et si elle dépasse les 2G, on bascule automatiquement sur GPT. Il y a d'autres raisons d'effectuer cette bascule (être sur les sous-systèmes mac ou efi notamment), mais c'était le plus gros suspect.

Debian Consultant @ DEBAMAX

<toubonnais>Pour info, un emballage qui va bien pour jouer avec la tamponnisation : stdbuf des outils centraux.</toubonnais>

<frenglish>Pour info, un wrapper qui va bien pour jouer avec la bufferisation : stdbuf des coreutils.</frenglish>

Debian Consultant @ DEBAMAX

Hello,

J'imagine que tu es sur amd64, mais ça fait partie du genre d'informations qui peut être un peu importante. Quelle est la capacité du disque dur ? As-tu bien installé GRUB sur le disque à la fin du processus d'installation ? L'installation s'est-elle bien déroulée ? Si non, le processus d'installation aurait été interrompu ; si oui, je ne vois pas trop pourquoi relancer grub-install $DEVICE après coup poserait problème, sauf à ne pas avoir monté des systèmes de fichiers. Et surtout : quels sont les messages d'erreur ? (Une photo est facile à faire de nos jours.)

Enfin, un rapport de bogue peut être une bonne idée (cf. doc). Le fichier /var/log/installer/syslog devrait être plutôt intéressant.

Debian Consultant @ DEBAMAX

Hello,

J'ai regardé plusieurs versions différentes de nginx packagé dans Debian, mais je n'ai pas trouvé d'occurrence de robot dedans à part pour la gestion spécifique de robots.txt.

Ce serait donc bien de préciser la version exacte ainsi que comment elle a été installée (p. ex. via un paquet d'une distribution).

A priori, il suffirait d'une ligne de ce type pour positionner les valeurs qui t'intéressent ?

add_header X-Robots-Tag "valeur1, valeur2, ..., valeurN";

Debian Consultant @ DEBAMAX

Non non, on n'a pas encore l'intégration dans grub, c'est donc depuis l'initramfs que la phrase de passe est demandée.

(Désolé, j'avais tapé mais pas validé validé ma réponse un peu plus complète, qui se retrouve donc après ton commentaire.)

Pour en savoir plus là-dessus, chercher le mot-clé cryptodisk. Un jour quelqu'un travaillera sur l'intégration de ce genre de choses…

Debian Consultant @ DEBAMAX

Il y a quelques années (vers 2008-2009), sur des core 2 duo, on pouvait voir des différences avec/sans chiffrement. Je crois me souvenir de certains avançant des chiffres de l'ordre de 5 à 10 % de baisse de perf. J'avoue ne m'être pas trop posé la question de mesurer cela, les garanties apportées par le chiffrement me semblant bien plus importantes que d'éventuelles baisses de perf. Vu les SSD et les CPU qu'on a maintenant, ça me semble avoir encore plus gommé ce genre de différences.

Non, en l'état actuel des choses dans Debian, grub ne pose pas la question de la phrase de passe (on peut en définir plusieurs, au passage), c'est le composant cryptsetup embarqué dans l'initramfs (l'archive qui contient scripts, binaires, bibliothèques, modules, etc. aidant à démarrer) qui se charge de cela pour déverrouiller les périphériques de type bloc.

Je ne peux pas trop t'en dire plus pour la partie réinstallation. Je ne réinstalle jamais un système, donc je ne sais pas trop comment peut fonctionner la réutilisation d'un volume chiffré dans tel ou tel système d'installation.

Debian Consultant @ DEBAMAX

Hello,

Je vais répondre principalement sur la partie chiffrement du FS : Chiffrer les données personnelles uniquement ne me semble pas suffisant.

Côté Debian, l'installateur propose de chiffrer l'intégralité du système, avec un partitionnement automatique s'appuyant sur LVM. Cela apporte une assez grande flexibilité pour personnaliser les points de montage/partitions une fois le système installé. Note : Pour le moment, la partie /boot n'est pas chiffrée.

Je n'ai pas vu de problème particulier avec le chiffrement sur SSD, alors que j'utilise cela sur tous mes laptops depuis 10+ ans.

Maintenant, je ne connais pas trop les spécificités des installateurs Ubuntu/Linux Mint, mais c'est normalement full disk encryption que j'aurais tendance à chercher dans la doc. Mais j'ai l'impression que ça n'est pas forcément trivial à obtenir :

• https://help.ubuntu.com/community/ManualFullSystemEncryption
• https://help.ubuntu.com/community/FullDiskEncryptionHowto

Bonne continuation dans la recherche d'informations,
Cyril.

Debian Consultant @ DEBAMAX