Attention, bs=512 signifie une taille de bloc de 512 octets.
Cela peut être vérifié dans la page info :
‘bs=BYTES’
Set both input and output block sizes to BYTES. This makes ‘dd’
read and write BYTES per block, overriding any ‘ibs’ and ‘obs’
settings. In addition, if no data-transforming ‘conv’ operand is
specified, input is copied to the output as soon as it’s read, even
if it is smaller than the block size.
La page de manuel précise la taille par défaut :
bs=BYTES
read and write up to BYTES bytes at a time (default: 512); overrides ibs and obs
(Pour la petite histoire, un bloc UNIX signifie 512 octets, alors que sous Linux, c'est plutôt 1024. Cf. la variable d'environnement POSIXLY_CORRECT, prise en compte par différents utilitaires classiques.)
Cela fait des mois, peut-être années en fait, que je trouve Firefox ultra pénible pour ce qui est sélection de périphériques. C'est le cas pour le microphone mais aussi pour la webcam (casque Bluetooth, caméra USB en haut de l'écran externe). Le ressenti (je n'ai pas cherché à déboguer), c'est que la gestion du branchement à chaud est soit inexistante soit boguée. D'où mon utilisation systématique de Chromium pour toute visio : j'ai toujours le choix parmi les différents périphériques (c'est moins pénible de démarrer un Chromium pour quelques dizaines de minutes que redémarrer mon navigateur principal.)
Écrire les locales demandées via /etc/locale.gen permet d'éviter à gérer les interactions qui seraient provoquées via dpkg-reconfigure locales mais cela permet bien d'activer ce qui est voulu, plutôt que de désactiver tout ce qui ne l'est pas.
$ sed -n '/^NAME.*netdb/,/^$/p' src/cf.data.pre
NAME: netdb_filename
TYPE: string
DEFAULT: stdio:@DEFAULT_NETDB_FILE@
LOC: Config.netdbFilename
IFDEF: USE_ICMP
DOC_START
Where Squid stores it's netdb journal.
When enabled this journal preserves netdb state between restarts.
NAME: netdb_low
TYPE: int
DEFAULT: 900
LOC: Config.Netdb.low
DOC_START
The low water mark for the ICMP measurement database.
NAME: netdb_high
TYPE: int
DEFAULT: 1000
LOC: Config.Netdb.high
DOC_START
The high water mark for the ICMP measurement database.
NAME: netdb_ping_period
TYPE: time_t
LOC: Config.Netdb.period
DEFAULT: 5 minutes
DOC_START
The minimum period for measuring a site. There will be at
least this much delay between successive pings to the same
network. The default is five minutes.
DOC_END
Si ça peut donner un point de comparaison, j'utilise Ungoogled Chromium via Flatpak sur Debian 11 (pour Teams…), et j'ai bien accès aux deux webcams (interne et externe), et à toutes les entrées/sorties son (dont l'enceinte Bluetooth et la connectique jack 3.5 mm).
Ce que tu décris est plutôt vrai en général mais ça ne s'applique pas au cas d'apache2 :
En août, Debian 11.0 est sortie avec la version 2.4.48-3.1.
Le 8 octobre, c'est la version 2.4.51-1~deb11u1 qui est incorporée via bullseye-security.
Concernant le security-tracker, l'info n'est pas présente à l'heure actuelle, mais un verdict classique est « no-dsa » dans les notes, pour les bogues ne nécessitant pas une correction via une suite de sécurité, avec l'annonce de sécurité correspondante. Dans ce cas, c'est souvent via proposed-updates que le paquet est incorporé, avant intégration lors d'une point release ultérieure.
Comme le mentionne Gil, le système d'installation suit tes instructions, donc tu peux très bien réutiliser la partition existante, lui attribuer le point de montage /boot, et la formater ou non.
Je n'ai pas de réponse définitive pour ta question initiale (cohabitation de la même partition pour deux systèmes), mais j'aurais tendance à penser que ça peut amener des soucis : versions de GRUB différentes, config différente, et probable « le dernier qui lance update-grub gagne ».
Pour ton besoin spécifique, je pense que je garderai une copie de la partition à portée de main (à remettre en place via un système live au besoin), et je partirais d'une partition formatée.
Une autre question est : installation BIOS ou UEFI ? Dans le second cas, la partition ESP ne devrait pas poser problème, puisqu'il y a un répertoire vendor qui permet de faire cohabiter tout le monde (ici, j'ai typiquement EFI/debian dedans), mais il faudra bien penser à déclarer une partition ESP, sans la formater.
debian-installer va très fortement inciter à mettre en place ce genre de choses (/boot séparé, en clair), mais GRUB sait déverrouiller un espace LUKS depuis longtemps (fonctionnalité dite « cryptodisk »). Avec l'arrivée du format LUKS2, ça n'était à nouveau plus vrai… J'avais donné une présentation aux mini-DebConf Marseille et Hambourg 2019 à ce sujet, dans laquelle je brossais un panorama rapide des petits challenges à résoudre. J'ai été occupé à d'autres choses après ces deux présentations, mais quelqu'un d'autre a travaillé dessus… Je n'ai pas encore essayé de mon côté.
Bref, il y avait (pour LUKS) et il devrait y avoir (pour LUKS2) ce qu'il faut dans GRUB pour déverrouiller des espaces de stockage LUKS, qui peuvent à leur tour contenir du LVM, etc., et c'est un manque d'intégration côté debian-installer qui explique cette impression d'obligation d'avoir un /boot séparé, en clair.
Pour le chargeur de démarrage qui « voit » les autres systèmes, ça dépend très probablement des choix faits au niveau de la distribution et/ou de l'administrateur local. Par exemple sous Debian, il faut que le paquet os-prober soit installé pour que les autres OS soient visibles.
Enfin, pour les 4 partitions primaires, c'est une limitation historique, mais seulement si le partitionnement est de type msdos (aka. MBR). Si GPT est utilisé, il y a largement de la place pour numéroter plein de partitions. :)
J'envisageais de faire une petite rétrospective “d-i vs. Debian 11” sur le blog de ma boîte, comme je travaille trop et ne rédige pas assez, c'est encore sur une todo-list… → C'est parti pour quelques réponses en commentaire sur cette dépêche, en te remerciant pour les questions.
Tu peux jeter un œil aux annonces publiées sur la liste debian-devel-announce@, à savoir une annonce par version publiée (Alpha ou RC). Dans chacune, j'essaie de reprendre les changements dans les composants individuels qui peuvent être impactants pour les utilisateurs (plus rarement les développeurs) du système d'installation, et de les résumer à destination des utilisateurs avancés.
Par exemple, pour le cycle de publication de Debian 11 :
C'est donc le debian-installer de la RC 3 qui est utilisé pour Debian 11.0, puisque nos développements de dernière minute n'ont pas explosé en vol.
C'est principalement de la maintenance corrective, ou ce qui semble maintenant s'appeler du « maintien en condition opérationnelle ». La base de code n'est pas toute récente, elle pourrait bénéficier de simplifications, réécritures, etc. (notamment en ce qui concerne la gestion des différentes architectures) mais globalement le système d'installation actuel a une certaine flexibilité (mode texte, mode graphique, installation par SSH ou console série, démarrage par le réseau, etc.), et les investissements en temps/énergie pour le maintenir en état sont relativement raisonnables. À titre personnel, j'aurais aimé avoir plus de temps à y consacrer pendant ce cycle de publication, et les évolutions pour la gestion des micrologiciels sont arrivées bien tard (cf. introduction de l'annonce D-I Bullseye RC 3), mais elles ont fini par arriver…
Cela étant dit, il ne s'agit pas que de corriger les problèmes quand ils apparaissent. Comme cela peut être constaté en parcourant les annonces mentionnées ci-dessus, il y a régulièrement de petites améliorations à gauche à droite dans tel ou tel composant, à la demande d'utilisateur, ou parce que telle technologie de stockage/réseau/autre propose des options supplémentaires, etc.
Dans les évolutions nécessaires durant le nouveau cycle de publication (Debian 12), il y a le passage de GTK 2 à GTK 3 ou 4. Les premiers paquets GTK 3 n'étaient pas utilisables directement dans le contexte du système d'installation, donc cela a traîné. Simon McVittie a indiqué que le passage à GTK 3+ supposera de revoir l'architecture. Nous ne sommes pas passés loin de la catastrophe à forcer de rester sur GTK 2, d'où mes chaleureux remerciements en introduction de l'annonce D-I Bullseye RC 2 (cf. les entrées cdebconf et gtk+2.0 pour plus de détails).
J'ai également des patches qui traînent depuis des années pour proposer, par exemple à mi-chemin du cycle de publication, des images d'installation de stable qui utiliseraient le noyau de stable-backports afin de simplifier l'installation sur du matériel tout récent, mais il faudrait changer quelques composants (comme base-installer) pour avoir une intégration propre. J'espère que Steve McIntyre (debian-cd) et moi (debian-boot) arriverons à trouver le temps d'intégrer cela dans les mois qui viennent. Note : Il s'agit des noms historiques, debian-cd s'occupe « bien évidemment » de produire les images d'installation pendant que debian-boot s'occupe de produire le système d'installation à intégrer dans lesdites images.
Peut-être aurons-nous aussi un jour une nouvelle résolution générale concernant les micrologiciels, et peut-être pourrons-nous proposer des images qui ne soient plus marquées au fer rouge de l'aspect unofficial. Cela étant, je ne considère pas qu'une telle évolution relève des prérogatives de l'équipe du système d'installation (debian-boot) ou de celle qui gère les images d'installation (debian-cd), et Steve semble d'accord sur ce point : c'est au niveau du projet tout entier que cela devrait être discuté, et validé. Cf. mon premier message sur le rapport de bogue #989863.
Il y a plus ou moins régulièrement des personnes qui veulent révolutionner le système d'installation. Elles sont libres de proposer des alternatives, et c'est ensuite au projet Debian en général et à l'équipe qui gère le site web, etc. de voir ce qui est mis en avant et comment. Je note qu'un certain nombre de telles propositions reposent sur des images autonomes (« live ») que nous avons déjà du mal à produire… Nous avons d'ailleurs déjà une alternative à D-I (Calamares).
Pour ma part, je contribue à maintenir l'existant depuis bientôt 10 ans (mon tout premier message sur debian-devel-announce@ date de mai 2012), et bien qu'imparfait, cela permet d'installer Debian de versions majeures en versions majeures… Ce n'est pas forcément fascinant côté utilisateur, mais il me semble que cette constance colle plutôt à la réputation de stabilité de Debian.
Je pensais plutôt aux logs du système avant/après la mise à jour, à comparer avant et après correction.
Je vois typiquement ceci ici (installation Debian 11 standard, pas de migration) dans /var/log/{kern,syslog}* et/ou dmesg (en fonction de l'uptime/du logrotate) :
Aug 17 14:45:15 tokyo kernel: [ 1.640746] e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) a0:8c:fd:2a:bd:8a
Aug 17 14:45:15 tokyo kernel: [ 1.640748] e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection
Aug 17 14:45:15 tokyo kernel: [ 1.640797] e1000e 0000:00:1f.6 eth0: MAC: 12, PHY: 12, PBA No: FFFFFF-0FF
Aug 17 14:45:15 tokyo kernel: [ 1.641487] e1000e 0000:00:1f.6 enp0s31f6: renamed from eth0
ou bien (installation Debian 10 standard, pas de migration) :
Ça fait des années que certaines configurations globales sont déployées sous /usr. Quelques exemples :
/usr/share/fontconfig/conf.avail/10-autohint.conf
/usr/share/X11/xorg.conf.d/40-libinput.conf
/usr/share/X11/xorg.conf.d/70-wacom.conf
Et il est possible de changer du comportement par défaut en créant/modifiant/adaptant ces fichiers sous /etc en tant qu'admin local.
C'est exactement la même chose avec les configurations systemd et udev, les règles par défaut sont catapultées sous (/usr)/lib/{systemd,udev} et les admins locaux peuvent adapter sous /etc.
Pour l'aspect « textuel » d'/etc, je vois des zip, des clés publiques/privées (SSH, X.509), des trousseaux GPG, et des choses vraiment binaires comme /etc/ld.so.cache ou du Berkeley DB pour les fichiers de postfix. J'ai un peu la flemme de sortir les vieilles sources d'UNIX pour voir à quel point ce « Editable Text Configuration » est un backronym, mais au moins la page wikipedia FHS suggère qu'il y a débat… :)
Vu d'ici, la différence i386 vs. amd64 devrait être absolument sans rapport.
Je soupçonne plutôt l'existence ou l'absence d'un fichier, lien, autre, quelque part, que ça soit une vieille règle udev ou quelque chose de similaire, qui a pu provoquer ce souci. Vu le nommage « moderne » que tu avais avant la mise à jour, j'imagine que tu n'avais pas de net.ifnames qui traîne…
En regardant la page de wiki NetworkInterfaceNames j'imagine que tu as pu avoir un 70-persistent-net.rules… mais si c'est bien ça, pourquoi est-il ignoré avant la mise à jour ?
Tu aurais les logs de la mise à jour ? Typiquement, sous /var/log/apt/, fichiers term.log*.
J'ai du mal à voir comment l'installation d'un noyau a pu « oublier » de déployer vmlinuz& friends dans /boot, surtout sans laisser de message d'erreur explicite, et un statut « pas content » au niveau dpkg… ENOSPC chemin faisant ?
Note que les deux commandes apt-get et apt gère la commande reinstall (pour install --reins(in)tall). ;)
À tout hasard, la pagination (via more, less, most, etc. ou bien un pager interne à systemctl) a été activée pour une raison ou pour une autre, et il suffit de faire q (ou équivalent en fonction de l'outil) pour en sortir ?
Mon premier réflexe serait de vérifier si la box-bidule propose des baux statiques. 1 MAC = 1 IP (× 2) et hop ? C'est le genre de réglage qui ne devrait pas facilement sauter lors d'une mise à jour future de la box, ça ferait une manip one-shot ?
Tu as des mécanismes en place pour empêcher les pisteurs de remonter tout plein d'infos sur ton téléphone, ta navigation, etc. chez les data brokers ? Tu peux choisir d'interdire la localisation précise, l'accès à tes contacts, le fait de passer un coup de fil, etc. et l'application fonctionne quand même ?
Ça se passe comment dans cet environnement, pour tout ce qui est pisteurs/permissions ?
Le rapport d'Exodus Privacy m'inciterait bien à ne jamais songer à installer une telle application sur mon téléphone, quel que soit l'environnement. (J'ai fait le tour des applis des grands groupes bancaires français il y a quelques temps, c'est le même niveau d'indécence environ partout.)
C'est comme les rapports de bogue, c'est plus simple si on est complet dès le début… préciser la banque ne coûterait pas trop cher et ça éviterait de jouer aux devinettes.
Je serais toi, je me renseignerais sur le lecteur CAP qui est probablement un lecteur de carte à puce (chez CE) ou le lecteur PASS CyberPlus (chez BP). Chez CM/CIC j'ai opté pour le boîtier DIGIPASS pour éviter d'avoir à utiliser la moindre application (modulo 29 € à l'acquisition).
Pour commencer, à propos du « si c'est possible » : À ma connaissance, sur architecture PC, une machine estampillée Windows 8 doit pouvoir laisser la possibilité de désactiver Secure Boot et/ou d'enrôler une MOK (Machine Owner Key).
Quant à « OS signé par Microsoft » c'est un beaucoup trop gros raccourci. Il faut que le chargeur de démarrage soit signé par une autorité de confiance, c'est très différent d'un système d'exploitation complet. On trouve souvent le composant shim qui fait effectivement un tour pour se faire tamponner cryptographiquement, mais le reste peut être signé par d'autres clés (par exemple Debian Secure Boot CA). Cela inclut (mais n'est pas limité à) : GRUB, le noyau Linux, fwupd, etc. Des modules complémentaires (module patché, module propriétaire nvidia, etc.) peuvent être signés par l'administrateur local grâce à la MOK, qu'il conviendra d'enrôler dans le firmware (cf. mokutil).
Sur tout un tas de distributions, dont je pense Kubuntu, Secure Boot ne devrait pas poser de problème, tu peux donc le laisser activé.
Si tu démarres avec Secure Boot activé, ça sous-entend démarrer en mode UEFI (plutôt que BIOS = Legacy = CSM…), et ça veut dire avoir une partition ESP (EFI System Partition) sur le système déployé. Le système d'installation de ta distribution devrait faire le boulot pour toi.
maxsize size
Log files are rotated when they grow bigger than size bytes even
before the additionally specified time interval (daily, weekly,
monthly, or yearly). The related size option is similar except
that it is mutually exclusive with the time interval options,
and it causes log files to be rotated without regard for the
last rotation time, if specified after the time criteria (the
last specified option takes the precedence). When maxsize is
used, both the size and timestamp of a log file are considered.
[^] # Re: besoin précision supplémentaire
Posté par Cyril Brulebois (site web personnel) . En réponse au message commande dd spécifique. Évalué à 3.
Attention,
bs=512signifie une taille de bloc de 512 octets.Cela peut être vérifié dans la page info :
La page de manuel précise la taille par défaut :
(Pour la petite histoire, un bloc UNIX signifie 512 octets, alors que sous Linux, c'est plutôt 1024. Cf. la variable d'environnement
POSIXLY_CORRECT, prise en compte par différents utilitaires classiques.)Debian Consultant @ DEBAMAX
[^] # Re: Solution
Posté par Cyril Brulebois (site web personnel) . En réponse au message Firefox 98 ou 99 et l'accès au microphone sous Debian 11 [résolu semble-t-il]. Évalué à 3.
Cela fait des mois, peut-être années en fait, que je trouve Firefox ultra pénible pour ce qui est sélection de périphériques. C'est le cas pour le microphone mais aussi pour la webcam (casque Bluetooth, caméra USB en haut de l'écran externe). Le ressenti (je n'ai pas cherché à déboguer), c'est que la gestion du branchement à chaud est soit inexistante soit boguée. D'où mon utilisation systématique de Chromium pour toute visio : j'ai toujours le choix parmi les différents périphériques (c'est moins pénible de démarrer un Chromium pour quelques dizaines de minutes que redémarrer mon navigateur principal.)
Debian Consultant @ DEBAMAX
# --verbose
Posté par Cyril Brulebois (site web personnel) . En réponse au message demande aide anacron sur instance Gandi. Évalué à 4.
À quoi ressemblent ton entrée de crontab et ton script ?
Debian Consultant @ DEBAMAX
# C'est exactement ça sauf que c'est l'inverse
Posté par Cyril Brulebois (site web personnel) . En réponse au message Question sur locales. Évalué à 4.
Tu peux regarder la grosse différence entre les paquets
localesetlocales-all:Écrire les locales demandées via
/etc/locale.genpermet d'éviter à gérer les interactions qui seraient provoquées viadpkg-reconfigure localesmais cela permet bien d'activer ce qui est voulu, plutôt que de désactiver tout ce qui ne l'est pas.Debian Consultant @ DEBAMAX
# netdb ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message Debian 11 / Squid / Ping du serveur. Évalué à 6.
Un grep rapide dans les sources suggère cette option sous
cache_peer:inspiré par :
Debian Consultant @ DEBAMAX
[^] # Re: chance ou pas chance?
Posté par Cyril Brulebois (site web personnel) . En réponse au message Webcam externe ne fonctionne pas et entretien d'embauche ><. Évalué à 3.
Si ça peut donner un point de comparaison, j'utilise Ungoogled Chromium via Flatpak sur Debian 11 (pour Teams…), et j'ai bien accès aux deux webcams (interne et externe), et à toutes les entrées/sorties son (dont l'enceinte Bluetooth et la connectique jack 3.5 mm).
Debian Consultant @ DEBAMAX
[^] # Re: Security tracker
Posté par Cyril Brulebois (site web personnel) . En réponse au message CVE-2021-44790 bullseye. Évalué à 5.
Ce que tu décris est plutôt vrai en général mais ça ne s'applique pas au cas d'
apache2:bullseye-security.Concernant le security-tracker, l'info n'est pas présente à l'heure actuelle, mais un verdict classique est « no-dsa » dans les notes, pour les bogues ne nécessitant pas une correction via une suite de sécurité, avec l'annonce de sécurité correspondante. Dans ce cas, c'est souvent via
proposed-updatesque le paquet est incorporé, avant intégration lors d'une point release ultérieure.Debian Consultant @ DEBAMAX
[^] # Re: Debian
Posté par Cyril Brulebois (site web personnel) . En réponse au message Migration Fedora → Debian. Évalué à 3.
Comme le mentionne Gil, le système d'installation suit tes instructions, donc tu peux très bien réutiliser la partition existante, lui attribuer le point de montage
/boot, et la formater ou non.Je n'ai pas de réponse définitive pour ta question initiale (cohabitation de la même partition pour deux systèmes), mais j'aurais tendance à penser que ça peut amener des soucis : versions de GRUB différentes, config différente, et probable « le dernier qui lance
update-grubgagne ».Pour ton besoin spécifique, je pense que je garderai une copie de la partition à portée de main (à remettre en place via un système live au besoin), et je partirais d'une partition formatée.
Une autre question est : installation BIOS ou UEFI ? Dans le second cas, la partition ESP ne devrait pas poser problème, puisqu'il y a un répertoire vendor qui permet de faire cohabiter tout le monde (ici, j'ai typiquement
EFI/debiandedans), mais il faudra bien penser à déclarer une partition ESP, sans la formater.Debian Consultant @ DEBAMAX
[^] # Re: Debian
Posté par Cyril Brulebois (site web personnel) . En réponse au message Migration Fedora → Debian. Évalué à 3.
Au moins pour Secure Boot, la chaîne de démarrage supportée est : firmware UEFI → shim → GRUB → Linux.
Je ne vois pas trop ce qu'apporterait le fait de virer GRUB de l'équation, Secure Boot ou non.
Debian Consultant @ DEBAMAX
[^] # Re: Debian
Posté par Cyril Brulebois (site web personnel) . En réponse au message Migration Fedora → Debian. Évalué à 7.
Oui et non.
debian-installerva très fortement inciter à mettre en place ce genre de choses (/bootséparé, en clair), mais GRUB sait déverrouiller un espace LUKS depuis longtemps (fonctionnalité dite « cryptodisk »). Avec l'arrivée du format LUKS2, ça n'était à nouveau plus vrai… J'avais donné une présentation aux mini-DebConf Marseille et Hambourg 2019 à ce sujet, dans laquelle je brossais un panorama rapide des petits challenges à résoudre. J'ai été occupé à d'autres choses après ces deux présentations, mais quelqu'un d'autre a travaillé dessus… Je n'ai pas encore essayé de mon côté.Au passage, suite à discussion avec le mainteneur de
cryptsetupà Hambourg, cette documentation est née :Full disk encryption, including /boot: Unlocking LUKS devices from GRUB.
Bref, il y avait (pour LUKS) et il devrait y avoir (pour LUKS2) ce qu'il faut dans GRUB pour déverrouiller des espaces de stockage LUKS, qui peuvent à leur tour contenir du LVM, etc., et c'est un manque d'intégration côté
debian-installerqui explique cette impression d'obligation d'avoir un/bootséparé, en clair.Debian Consultant @ DEBAMAX
[^] # Re: Debian
Posté par Cyril Brulebois (site web personnel) . En réponse au message Migration Fedora → Debian. Évalué à 4.
GRUB supporte tout de même plein de systèmes de fichiers (dont XFS)…
Pour le chargeur de démarrage qui « voit » les autres systèmes, ça dépend très probablement des choix faits au niveau de la distribution et/ou de l'administrateur local. Par exemple sous Debian, il faut que le paquet
os-probersoit installé pour que les autres OS soient visibles.Pour LVM, oui, GRUB sait faire tout seul :
Enfin, pour les 4 partitions primaires, c'est une limitation historique, mais seulement si le partitionnement est de type
msdos(aka. MBR). Si GPT est utilisé, il y a largement de la place pour numéroter plein de partitions.:)Debian Consultant @ DEBAMAX
[^] # Re: Évolutions de l'installeur
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 10.
J'envisageais de faire une petite rétrospective “d-i vs. Debian 11” sur le blog de ma boîte, comme je travaille trop et ne rédige pas assez, c'est encore sur une todo-list… → C'est parti pour quelques réponses en commentaire sur cette dépêche, en te remerciant pour les questions.
Tu peux jeter un œil aux annonces publiées sur la liste
debian-devel-announce@, à savoir une annonce par version publiée (Alpha ou RC). Dans chacune, j'essaie de reprendre les changements dans les composants individuels qui peuvent être impactants pour les utilisateurs (plus rarement les développeurs) du système d'installation, et de les résumer à destination des utilisateurs avancés.Par exemple, pour le cycle de publication de Debian 11 :
C'est donc le
debian-installerde la RC 3 qui est utilisé pour Debian 11.0, puisque nos développements de dernière minute n'ont pas explosé en vol.C'est principalement de la maintenance corrective, ou ce qui semble maintenant s'appeler du « maintien en condition opérationnelle ». La base de code n'est pas toute récente, elle pourrait bénéficier de simplifications, réécritures, etc. (notamment en ce qui concerne la gestion des différentes architectures) mais globalement le système d'installation actuel a une certaine flexibilité (mode texte, mode graphique, installation par SSH ou console série, démarrage par le réseau, etc.), et les investissements en temps/énergie pour le maintenir en état sont relativement raisonnables. À titre personnel, j'aurais aimé avoir plus de temps à y consacrer pendant ce cycle de publication, et les évolutions pour la gestion des micrologiciels sont arrivées bien tard (cf. introduction de l'annonce D-I Bullseye RC 3), mais elles ont fini par arriver…
Cela étant dit, il ne s'agit pas que de corriger les problèmes quand ils apparaissent. Comme cela peut être constaté en parcourant les annonces mentionnées ci-dessus, il y a régulièrement de petites améliorations à gauche à droite dans tel ou tel composant, à la demande d'utilisateur, ou parce que telle technologie de stockage/réseau/autre propose des options supplémentaires, etc.
Dans les évolutions nécessaires durant le nouveau cycle de publication (Debian 12), il y a le passage de GTK 2 à GTK 3 ou 4. Les premiers paquets GTK 3 n'étaient pas utilisables directement dans le contexte du système d'installation, donc cela a traîné. Simon McVittie a indiqué que le passage à GTK 3+ supposera de revoir l'architecture. Nous ne sommes pas passés loin de la catastrophe à forcer de rester sur GTK 2, d'où mes chaleureux remerciements en introduction de l'annonce D-I Bullseye RC 2 (cf. les entrées
cdebconfetgtk+2.0pour plus de détails).J'ai également des patches qui traînent depuis des années pour proposer, par exemple à mi-chemin du cycle de publication, des images d'installation de
stablequi utiliseraient le noyau destable-backportsafin de simplifier l'installation sur du matériel tout récent, mais il faudrait changer quelques composants (commebase-installer) pour avoir une intégration propre. J'espère que Steve McIntyre (debian-cd) et moi (debian-boot) arriverons à trouver le temps d'intégrer cela dans les mois qui viennent. Note : Il s'agit des noms historiques,debian-cds'occupe « bien évidemment » de produire les images d'installation pendant quedebian-boots'occupe de produire le système d'installation à intégrer dans lesdites images.Peut-être aurons-nous aussi un jour une nouvelle résolution générale concernant les micrologiciels, et peut-être pourrons-nous proposer des images qui ne soient plus marquées au fer rouge de l'aspect unofficial. Cela étant, je ne considère pas qu'une telle évolution relève des prérogatives de l'équipe du système d'installation (
debian-boot) ou de celle qui gère les images d'installation (debian-cd), et Steve semble d'accord sur ce point : c'est au niveau du projet tout entier que cela devrait être discuté, et validé. Cf. mon premier message sur le rapport de bogue #989863.Il y a plus ou moins régulièrement des personnes qui veulent révolutionner le système d'installation. Elles sont libres de proposer des alternatives, et c'est ensuite au projet Debian en général et à l'équipe qui gère le site web, etc. de voir ce qui est mis en avant et comment. Je note qu'un certain nombre de telles propositions reposent sur des images autonomes (« live ») que nous avons déjà du mal à produire… Nous avons d'ailleurs déjà une alternative à D-I (Calamares).
Pour ma part, je contribue à maintenir l'existant depuis bientôt 10 ans (mon tout premier message sur
debian-devel-announce@date de mai 2012), et bien qu'imparfait, cela permet d'installer Debian de versions majeures en versions majeures… Ce n'est pas forcément fascinant côté utilisateur, mais il me semble que cette constance colle plutôt à la réputation de stabilité de Debian.Debian Consultant @ DEBAMAX
[^] # Re: Surprise, retour à eth0
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 2.
Je pensais plutôt aux logs du système avant/après la mise à jour, à comparer avant et après correction.
Je vois typiquement ceci ici (installation Debian 11 standard, pas de migration) dans
/var/log/{kern,syslog}*et/oudmesg(en fonction de l'uptime/du logrotate) :ou bien (installation Debian 10 standard, pas de migration) :
(Ici j'ai cherché le
eth0historique qui se retrouve renommé en autre chose, mais je t'invite à chercher les deux noms dans les logs en question.)Debian Consultant @ DEBAMAX
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 10.
Ça fait des années que certaines configurations globales sont déployées sous
/usr. Quelques exemples :/usr/share/fontconfig/conf.avail/10-autohint.conf/usr/share/X11/xorg.conf.d/40-libinput.conf/usr/share/X11/xorg.conf.d/70-wacom.confEt il est possible de changer du comportement par défaut en créant/modifiant/adaptant ces fichiers sous
/etcen tant qu'admin local.C'est exactement la même chose avec les configurations
systemdetudev, les règles par défaut sont catapultées sous(/usr)/lib/{systemd,udev}et les admins locaux peuvent adapter sous/etc.Pour l'aspect « textuel » d'
/etc, je vois des zip, des clés publiques/privées (SSH, X.509), des trousseaux GPG, et des choses vraiment binaires comme/etc/ld.so.cacheou du Berkeley DB pour les fichiers de postfix. J'ai un peu la flemme de sortir les vieilles sources d'UNIX pour voir à quel point ce « Editable Text Configuration » est un backronym, mais au moins la page wikipedia FHS suggère qu'il y a débat… :)Debian Consultant @ DEBAMAX
[^] # Re: Surprise, retour à eth0
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 7.
Vu d'ici, la différence
i386vs.amd64devrait être absolument sans rapport.Je soupçonne plutôt l'existence ou l'absence d'un fichier, lien, autre, quelque part, que ça soit une vieille règle
udevou quelque chose de similaire, qui a pu provoquer ce souci. Vu le nommage « moderne » que tu avais avant la mise à jour, j'imagine que tu n'avais pas denet.ifnamesqui traîne…En regardant la page de wiki NetworkInterfaceNames j'imagine que tu as pu avoir un
70-persistent-net.rules… mais si c'est bien ça, pourquoi est-il ignoré avant la mise à jour ?Il y a peut-être la réponse dans tes logs.
:)Debian Consultant @ DEBAMAX
[^] # Re: Souci de dispo du nouveau noyau
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 4.
Tu aurais les logs de la mise à jour ? Typiquement, sous
/var/log/apt/, fichiersterm.log*.J'ai du mal à voir comment l'installation d'un noyau a pu « oublier » de déployer
vmlinuz& friends dans/boot, surtout sans laisser de message d'erreur explicite, et un statut « pas content » au niveau dpkg…ENOSPCchemin faisant ?Note que les deux commandes
apt-getetaptgère la commandereinstall(pourinstall --reins(in)tall).;)Debian Consultant @ DEBAMAX
[^] # Re: ne pas utiliser ALL
Posté par Cyril Brulebois (site web personnel) . En réponse au message sudoers. Évalué à 2.
Au passage, attention à
/proc/sysrq-trigger.Debian Consultant @ DEBAMAX
# Pager ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message [RESOLU] Et aprés je fais quoi ?. Évalué à 4.
À tout hasard, la pagination (via
more,less,most, etc. ou bien un pager interne àsystemctl) a été activée pour une raison ou pour une autre, et il suffit de faireq(ou équivalent en fonction de l'outil) pour en sortir ?Debian Consultant @ DEBAMAX
# Baux statiques
Posté par Cyril Brulebois (site web personnel) . En réponse au message Dossier partagé entre deux GNU/Linux, simple et efficace ?. Évalué à 2.
Mon premier réflexe serait de vérifier si la box-bidule propose des baux statiques. 1 MAC = 1 IP (× 2) et hop ? C'est le genre de réglage qui ne devrait pas facilement sauter lors d'une mise à jour future de la box, ça ferait une manip one-shot ?
Debian Consultant @ DEBAMAX
[^] # Re: Ça passe
Posté par Cyril Brulebois (site web personnel) . En réponse au message Secur'pass ?. Évalué à 1.
Tu as des mécanismes en place pour empêcher les pisteurs de remonter tout plein d'infos sur ton téléphone, ta navigation, etc. chez les data brokers ? Tu peux choisir d'interdire la localisation précise, l'accès à tes contacts, le fait de passer un coup de fil, etc. et l'application fonctionne quand même ?
Debian Consultant @ DEBAMAX
[^] # Re: Ça passe
Posté par Cyril Brulebois (site web personnel) . En réponse au message Secur'pass ?. Évalué à 7.
Ça se passe comment dans cet environnement, pour tout ce qui est pisteurs/permissions ?
Le rapport d'Exodus Privacy m'inciterait bien à ne jamais songer à installer une telle application sur mon téléphone, quel que soit l'environnement. (J'ai fait le tour des applis des grands groupes bancaires français il y a quelques temps, c'est le même niveau d'indécence environ partout.)
Debian Consultant @ DEBAMAX
# Groupe BPCE ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message Secur'pass ?. Évalué à 8.
C'est comme les rapports de bogue, c'est plus simple si on est complet dès le début… préciser la banque ne coûterait pas trop cher et ça éviterait de jouer aux devinettes.
Je serais toi, je me renseignerais sur le lecteur CAP qui est probablement un lecteur de carte à puce (chez CE) ou le lecteur PASS CyberPlus (chez BP). Chez CM/CIC j'ai opté pour le boîtier DIGIPASS pour éviter d'avoir à utiliser la moindre application (modulo 29 € à l'acquisition).
Debian Consultant @ DEBAMAX
[^] # Re: SB → UEFI
Posté par Cyril Brulebois (site web personnel) . En réponse au message que faire du secure boot en 2021 avec Linux seul ?. Évalué à 4.
J'ai l'impression qu'il y a une grosse confusion.
Pour commencer, à propos du « si c'est possible » : À ma connaissance, sur architecture PC, une machine estampillée Windows 8 doit pouvoir laisser la possibilité de désactiver Secure Boot et/ou d'enrôler une MOK (Machine Owner Key).
Quant à « OS signé par Microsoft » c'est un beaucoup trop gros raccourci. Il faut que le chargeur de démarrage soit signé par une autorité de confiance, c'est très différent d'un système d'exploitation complet. On trouve souvent le composant
shimqui fait effectivement un tour pour se faire tamponner cryptographiquement, mais le reste peut être signé par d'autres clés (par exempleDebian Secure Boot CA). Cela inclut (mais n'est pas limité à) : GRUB, le noyau Linux, fwupd, etc. Des modules complémentaires (module patché, module propriétaire nvidia, etc.) peuvent être signés par l'administrateur local grâce à la MOK, qu'il conviendra d'enrôler dans le firmware (cf.mokutil).Debian Consultant @ DEBAMAX
# SB → UEFI
Posté par Cyril Brulebois (site web personnel) . En réponse au message que faire du secure boot en 2021 avec Linux seul ?. Évalué à 3.
Sur tout un tas de distributions, dont je pense Kubuntu, Secure Boot ne devrait pas poser de problème, tu peux donc le laisser activé.
Si tu démarres avec Secure Boot activé, ça sous-entend démarrer en mode UEFI (plutôt que BIOS = Legacy = CSM…), et ça veut dire avoir une partition ESP (EFI System Partition) sur le système déployé. Le système d'installation de ta distribution devrait faire le boulot pour toi.
Debian Consultant @ DEBAMAX
# maxsize
Posté par Cyril Brulebois (site web personnel) . En réponse au message Cache log de squid ne tourne pas . Évalué à 2.
Cf. logrotate(8) :
Debian Consultant @ DEBAMAX