Cyril Brulebois a écrit 652 commentaires

Il y a un encart sur la page d'accueil qui envoie vers la page législation, je pense que la réponse à ta question s'y trouve ?

Debian Consultant @ DEBAMAX

Oh, j'avais loupé la distinction entre xenial-updates et xenial-proposed (no Ubuntu expert here).

kibi@armor:~$ rmadison -u ubuntu -s xenial-proposed shim shim-signed
 shim        | 13-0ubuntu2    | xenial-proposed | source, amd64
 shim-signed | 1.33.1~16.04.1 | xenial-proposed | source

Il y a donc bien les deux paquets qui sont faits pour aller ensemble (cette nouvelle version de shim a un Breaks sur les vieilles versions de shim-signed), seulement il n'y a pas de paquet binaire pour shim-signed. Et effectivement, en regardant amd64 build of shim-signed 1.33.1~16.04.1 in ubuntu xenial PROPOSED, on voit bien le statut Failed to build.

Tu n'as pas répondu sur le fait que tu utilisais juste le boot UEFI ou bien Secure Boot. Si ce dernier est activé, je te déconseille fortement de mettre à jour shim en virant shim-signed. Il n'y a pas de dépendance entre shim et shim-signed, mais sans ce dernier, Secure Boot risque de beaucoup moins bien fonctionner.

Debian Consultant @ DEBAMAX

La machine est un Zenbook Asus sur lequel Ubuntu 16.04 est installé en mode EFI […]

Ceci ne permet pas de savoir si Secure Boot est activé.

Pour info, description des paquets shim et shim-signed :

• shim : boot loader to chain-load signed boot loaders under Secure Boot
• shim-signed : Secure Boot chain-loading bootloader (Microsoft-signed binary)

Si Secure Boot est activé, j'ai du mal à voir comment ça pourrait booter sans shim-signed.

Quant aux paquets dans xenial-updates, étant donné que shim-signed (1.32~16.04.1+0.9+1474479173.6c180c6-1ubuntu1) dépend de shim (= 0.9+1474479173.6c180c6-1ubuntu1) (dixit packages.ubuntu.com), j'imagine qu'il faut mettre à jour les deux en même temps. Et peut-être que synaptic se mélange les pinceaux et n'arrive pas à trouver ça tout seul ?

Debian Consultant @ DEBAMAX

Tout à fait d'accord sur la pertinence. Peut-être qu'« honnête » aurait donné lieu à moins de controverses ?

Debian Consultant @ DEBAMAX

Effectivement, notre système de suivi de bogue est ultra-pénible. Pour s'assurer que tout le monde reçoive les réponses, une règle simple : reply-all, tout le temps. :-/

Debian Consultant @ DEBAMAX

L'idée serait plutôt d'enlever vga= qui force (ou essaie de forcer) une résolution donnée, et de laisser le noyau choisir ce qui lui semble le mieux. Mais bon, il est préférable de centraliser les suggestions sur le rapport de bogue que tu as ouvert chez Debian : #888513, et de continuer le débogage là-bas.

Debian Consultant @ DEBAMAX

C'est le composant base-installer du Debian Installer qui s'occupe de sélectionner le bon noyau. Cela se passe dans la fonction arch_get_kernel_flavour du fichier kernel/i386.sh, en s'appuyant sur les features exposées dans le fichier /proc/cpuinfo.

Debian Consultant @ DEBAMAX

Je pense que regarder les sources de hardlink était plus rapide que poser la question. La réponse est dans la fonction file_contents_equal. ;p

Debian Consultant @ DEBAMAX

Le SNR de la commande initiale me semble bien plus élevé que tout ce qui est proposé comme « meilleure solution » en commentaires. Quant au SNR des commentaires…

YMMV

Debian Consultant @ DEBAMAX

Pas d'accord pour needrestart. Exemple sur Debian 8 :

# DEBIAN_FRONTEND=readline needrestart
Scanning processes...                                                                                              
Scanning candidates...                                                                                             
Scanning kernel images...                                                                                          
Failed to retrieve available kernel versions.
Daemons using outdated libraries
--------------------------------


  1. atd.service            5. exim4.service       9. rpcbind.service   13. systemd-journald.service
  2. console-getty.service  6. getty@tty1.service  10. rsyslog.service  14. systemd-logind.service
  3. cron.service           7. lighttpd.service    11. ssh.service      15. systemd-udevd.service
  4. dbus.service           8. nfs-common.service  12. systemd manager  16. user@1002.service

(Enter the items you want to select, separated by spaces.)

Which services should be restarted? 1 2 3 5 7 8 9 10 11 12 14 15 16

Debian Consultant @ DEBAMAX

Hello,

wlan0 est le nom historique, mais il peut y avoir d'autres noms (surtout plus récemment). Pour avoir la liste des interfaces, on peut utiliser ip l, ce qui donne ici lo, eth0, wlan0.

Si le wifi est désactivé, ça peut être dû entre autres à rfkill (peut-être un bouton physique pour sortir d'un « mode avion » ou assimilé), un matériel non géré par le noyau utilisé, un microcode manquant (exemple classique : firmware-iwlwifi), etc. Mentionner les références du matériel en question pourrait accélérer les investigations.

Le wifi a-t-il déjà fonctionné sur cette machine avec ce système d'exploitation ? (Si la machine vient d'être installée, c'est un peu dommage de partir d'une version aussi vieille.)

Debian Consultant @ DEBAMAX

Les métadonnées citées me semblent plutôt correctes. En cherchant « systemd wait until a unit is ready », des fois qu'il y a des choses particulières à savoir qui ne seraient pas documentées dans man:systemd.unit, je suis tombé sur un rapport de bogue influx. ;)

Debian Consultant @ DEBAMAX

Un apt-get upgrade suffit si l'ensemble de paquets avant/après est le même. C'est usuellement le cas dans stable (mais coucou bind9 qui change ses SONAME régulièrement, et les noms de bibliothèques sont changés en conséquence).

Cependant, on a déjà vu des mises à jour de noyau qui changent l'ABI : cf. sortie de uname -r, c'est ce que l'on retrouve après linux-image- dans le nom du paquet binaire.

Ici, on passe de (linux-image-)4.9.0-4-amd64 à (linux-image-)4.9.0-5-amd64, donc la simple mise à jour du méta-paquet linux-image-amd64 ne suffit pas : il tire une nouvelle dépendance (la version en -5), il faut donc un dist-upgrade.

Debian Consultant @ DEBAMAX

Je m'étais dit initialement que le nom du serveur avait pu être « anonymisé » en serveur1.fr pour la question dans le forum… mais effectivement, il est impératif que les serveurs Let's Encrypt puissent résoudre le(s) nom(s) spécifié(s) et se connecter sur les ports qui vont bien.

Debian Consultant @ DEBAMAX

Pas besoin de redirection vers le bon service avec le bon certificat ? certbot a un mode standalone.

Du coup une redirection de 80/443 de la box vers la bonne machine, et certbot écoutera le temps qu'il faut pour faire le renouvellement, et l'écoute locale sur ces ports s'arrêtera juste après ? Conséquence : absolument aucun impact sur le serveur XMPP, qui ne voit pas passer de connexions « étranges ».

Debian Consultant @ DEBAMAX

Let's Encrypt permet de récupérer des certificats qui sont considérés de confiance par environ tout le monde. Il y a même une page côté Prosody pour faire le lien entre Let's Encrypt et Prosody.

Debian Consultant @ DEBAMAX

J'aurais imaginé une seule ouverture du fichier au tout début (ou des fichiers si plusieurs expressions avec -e sont spécifiées), et c'est ce que semble confirmer un petit strace.

Debian Consultant @ DEBAMAX

Je ne comprends pas pourquoi gérer des ACL serait plus dur (encore moins « impossible ») que n'importe quel autre mécanisme que tu pourrais mettre en place.

Si tu as des milliers de machines, tu utilises nécessairement un outil de configuration type ansible ou puppet donc il suffit de faire le travail une seule fois.

Pour les liens symboliques, citons la page de manuel de chmod :

chmod  never changes the permissions of symbolic links; the chmod system call cannot change their permis‐
sions.  This is not a problem since the permissions of symbolic links are never used.  However, for  each
symbolic  link listed on the command line, chmod changes the permissions of the pointed-to file.  In con‐
trast, chmod ignores symbolic links encountered during recursive directory traversals.

Debian Consultant @ DEBAMAX

Ce n'est probablement pas la première chose qu'on aperçoit avec cet outil, mais sed propose :

w filename

    Write the pattern space to filename.

Ça peut être une bonne idée de faire un tour de la liste des commandes disponibles dans GNU sed ; par ailleurs, w est spécifié dans POSIX.

Exemple de cours classique : partir de la sortie de seq et générer un fichier pairs et un fichier impairs.

Enjoy.

Debian Consultant @ DEBAMAX

(Bon, ma réponse s'est fait shooter plusieurs fois par LinuxFr, je refais en plus court.)

Non non, cf. sa page de manuel et surtout son code :

#!/bin/sh
set -e
exec grub-mkconfig -o /boot/grub/grub.cfg "$@"

Et je vois bien update-grub et update-grub2 dans le dernier paquet grub2-common disponible dans unstable.

Debian Consultant @ DEBAMAX

Concernant update-grub2, son but dans la vie est de générer un fichier de configuration pour GRUB, i.e. /boot/grub/grub.cfg (plus exactement, c'est c'est un wrapper pour grub-mkconfig, dont c'est le but). Si cette commande arrive à générer sans erreur le fichier en question, il n'y a pas de raison qu'elle retourne un code d'erreur non nul, ou qu'elle affiche des erreurs. Il convient de vérifier le contenu du fichier ainsi mis à jour en tenant compte des réglages spécifiés dans les différents fichiers (/etc/default/grub et /etc/grub.d/*) pour vérifier si cette commande a fait son boulot.

Pour le 2 en fin de commande, il y a eu une période où les paquets grub et grub2 ont cohabité dans Debian (possiblement Ubuntu aussi), avec chacun ses outils. Maintenant, la version 1 est oubliée, et on peut appeler indifféremment l'une ou l'autre des commandes (cf. lien symbolique mentionné dans une autre réponse).

Maintenant, pour le « résultat attendu », ce serait bien de détailler ce qui est affiché (menu ou non), combien de temps est attendu, etc. Personnellement, je découvre les variables GRUB_HIDDEN_TIMEOUT* ce jour. Je n'aurais pas pensé cela nécessaire pour ce type de manip. Sur Debian Stretch, j'ai juste besoin de changer le GRUB_TIMEOUT=5 en GRUB_TIMEOUT=0, puis update-grub, et plus d'attente.

Préciser la distribution et la version de GRUB serait une bonne idée, aussi.

Debian Consultant @ DEBAMAX

Précision : La sécurité est gérée au niveau du dépôt et non du paquet.

Pour chaque distribution, c'est le fichier Release qui est signé :

• signature détachée dans Release.gpg
• signature inline dans InRelease

et qui permet de vérifier les fichiers Packages et Sources pour chaque composant et architecture, qui à leur tour référencent les paquets individuels.

Debian Consultant @ DEBAMAX

Bonjour,

D'après la page Comparison of survey software, il y a au moins LimeSurvey qui est un logiciel de sondage sous licence libre. Peut-être que le CNLL pourrait pousser pour utiliser cela à la place de SurveyMonkey (qui ne me semble pas être un logiciel libre) ?

Dogfooding, cohérence, tout ça…

Debian Consultant @ DEBAMAX

Si j'ai bien suivi, on va progressivement vers des plateformes où les fournisseurs vont déposer leurs factures, auquel cas la plateforme joue un rôle d'intermédiaire technique/tiers de confiance.

En attendant, mes factures sont envoyées par mail, avec une signature GPG. Personne ne la vérifie (à ma connaissance), mais en cas de contestation/vérification, la signature apposée me semble garantir les propriétés que l'on souhaite (authenticité de l'origine et intégrité du contenu, cf. article 289-V du CGI).

Debian Consultant @ DEBAMAX

Je ne connais pas boot-repair, mais ceci devrait fonctionner :

• démarrer debian-installer en mode rescue
• répondre à quelques questions jusqu'à avoir accès aux partitions
• monter la partition racine et exécuter un shell dedans
• répondre oui quand il est proposé de monter /boot et /boot/efi
• réinstaller grub sur le MBR : grub-install /dev/le-bon-disque
• sortir du shell
• redémarrer

Je suppose que tu t'es retrouvé avec des morceaux différents de grub dans ton MBR et dans ton /boot, d'où ton souci initial. Cette manipulation devrait te mettre du grub-by-debian partout.

Debian Consultant @ DEBAMAX