Cyril Brulebois a écrit 657 commentaires

Alors :

1. Côté logique, je ne sais pas trop quoi penser de LUKS + BTRFS avec RAID1. J'ai tendance à fuir BTRFS parce qu'il semble y avoir encore ± régulièrement des corruptions en fonction de comment il est utilisé. Indépendamment du choix de BTRFS, il est possible d'empiler LUKS et RAID dans un sens ou dans l'autre sans problème, puis de choisir le système de fichiers à mettre par dessus.
2. J'ai très peu joué avec du chiffrement sur plusieurs disques (les cas d'utilisation habituels étant laptop d'une part, et serveurs avec RAID pour obtenir un seul ensemble RAID sur lequels LUKS puis LVM sont empilés), donc je n'ai pas de réponse.
3. Debian Installer devrait te permettre de faire tout cela en mode Manuel, pas besoin de basculer sur une console.

Debian Consultant @ DEBAMAX

As-tu vérifié (netstat, ss, etc.) la bonne prise en compte de ce paramètre ?

Debian Consultant @ DEBAMAX

Merci à toi.

Je note que le tout début de cette citation (« Sauf dispositions statutaires ou stipulations contraires ») me semble inciter à employer des nuances plutôt que des affirmations péremptoires et définitives telles que celles de gUI.

Your {mileage,moinssage} may vary.

Debian Consultant @ DEBAMAX

[citation needed]

Debian Consultant @ DEBAMAX

Dans le désordre :

• Debian ≠ Ubuntu
• Quand on utilise une distribution binaire, on est en droit de s'attendre à avoir des choses qui fonctionnent par défaut, avec cette chose magique qu'on appelle des dépendances. Si ça n'est pas le cas, on a peut-être besoin d'apprendre ce que sont les Recommends, qu'on a peut-être désactivés sans savoir quelles seraient les conséquences. Auquel cas, quelques explications s'imposent.
• Renvoyer vers une recherche web plutôt que vers un gestionnaire de suivi de bogues (peut-être même vers un éventuel rapport de bogue pré-existant), ça n'est pas vraiment pertinent, en plus d'être hautain.
• Inviter à signaler le bogue au bon endroit (quitte à ce que ça soit fermé pour cause d'« erreur utilisateur »), c'est probablement la meilleure chose à faire, non ?

Enfin, les dépendances semblent plutôt raisonnables dans bionic :

kibi@armor:~$ chdist apt bionic show gufw
Package: gufw
Version: 18.04.0-0ubuntu1
Priority: optional
Section: universe/admin
Source: gui-ufw
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Python Applications Packaging Team <python-apps-team@lists.alioth.debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 3,517 kB
Depends: python3:any (>= 3.3.2-2~), ufw (>= 0.34~rc), gir1.2-gtk-3.0, policykit-1, gir1.2-webkit2-4.0, python3-gi
Homepage: http://gufw.org/
Task: ubuntu-mate-desktop
Supported: 3y
Download-Size: 855 kB
APT-Sources: http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
Description: graphical user interface for ufw
 gufw is an easy and intuitive way to manage your Linux firewall. It
 supports common tasks such as allowing or blocking pre-configured, common
 p2p, or individual port(s), and many others!

De loin, ça ressemble à un vrai problème.

Debian Consultant @ DEBAMAX

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