Benoît Sibaud a écrit 9928 commentaires

Wildcard ou pas, ça n'aurait rien changé dans ce cas, c'est juste un autre bloc de config pour le www. pour une redirection, il est caché tout en bas d'un long fichier, et il pointait encore vers l'ancien certificat. Le nouveau certificat était déjà prévu pour linuxfr.org www.linuxfr.org prod.linuxfr.org img.linuxfr.org. Écraser l'ancien certificat avec le nouveau aurait pu éviter le souci par contre (mais dehydrated préfère sans doute avoir son propre répertoire).

Sinon sur la question du wildcard, c'est mieux de ne pas partager un certificat magique entre tous les serveurs (*), et quitte à avoir un certificat différent par serveur, ce n'est pas plus compliqué de préciser les domaines et d'éviter le wildcard.

(*) pour au moins deux raisons, la sécurité, et aussi le fait qu'ils vont tous expirer en même temps, comme un dimanche 3 juin par exemple.

La correction du www.linuxfr.org a été faite le 4 juin à 22:52 (Paris). (Cette conf un peu inutile du www n'existe pas sur le serveur de dev, et il est facile de l'oublier).

La correction sur la partie messagerie électronique (postfix/sympa) a été faite le 5 juin à 00:29 (Paris).

Dix certificats sur quatorze (smtp et https pour les différents domaines) sont à jour actuellement, les quatre derniers étant invisibles de l'extérieur. Et il reste encore un peu de taf pour finaliser l'automatisation de l'installation et du renouvellement (crontab, script ansible, mise à jour de la doc, mise à jour de la FAQ, etc.).

Le certificat pour www.linuxfr.org n'a été remplacé qu'hier soir. (Cette conf un peu inutile du www n'existe pas sur le serveur de dev, et il est facile de l'oublier). Dix certificats sur quatorze (smtp et https pour les différents domaines) sont à jour actuellement, les quatre derniers étant invisibles de l'extérieur. Et encore un peu de taf pour finaliser l'automatisation de l'installation et du renouvellement.

Encore ces nantis d'OpenBSD !

 __________________________________
/ Do you really want to clone this \
\ project?                         /
 ----------------------------------
 \
  \
     __
    /  \
    |  |
    @  @
    |  |
    || |/
    || ||
    |\_/|
    \___/

(ou Clone Wars « je suis ton père » ?)

Corrigé, merci.

Corrigé, merci.

Corrigé, merci.

Pour Debian Stretch actuellement, les architectures prises en charge :

• 52.8.0esr-1~deb9u1 : amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x

Pour Debian Sid actuellement :

• 60.0.1-5: amd64 arm64 armel armhf i386 ppc64el
• 52.0.2-1: hppa mips mips64el mipsel powerpc ppc64 s390x // donc au moins 5 archi non encore dispo en 60.0 pour Stretch
• 50.1.0-1 [debports]: m68k sparc64
• 48.0-1: kfreebsd-i386
• 47.0.1-1: kfreebsd-amd64

Pour Debian experimental :

• 61.0~b8-1: amd64 arm64 armel armhf i386 ppc64el

Bref il manque encore quelques paquets pour cela (cf source).

Corrigé, merci. (même si la version de la demande est malvenue)

Ça mériterait un tooltip ou une info plus visible sur la barre d'outils (ou ailleurs je ne sais pas trop).

On parle bien des raccourcis clavier ?

Corrigé, merci.

Précision ajoutée dans la dépêche.

Corrigé, merci.

Corrigé, merci.

Du coup, tu as déduit une formule du type consommation structurelle = taille fixe + pourcentage du volume * taille du volume ? (le tout en fonction de la taille des blocs ?).

Ouais ben de mon temps on faisait du pixel art sur Amstrad CPC en redéfinissant les fontes 8x8 en binaire dans du Basic après avoir dessiné sur du papier millimétré… Espèce de jeunes assistés ! (enfin assisté·e·s)

(tiré de man mke2efs)

       -m pourcentage_blocs_réservés
              Indiquer le pourcentage de blocs du système de fichiers réservés pour le superutilisateur. Cela permet d'éviter la fragmentation et permet aux démons lancés  par le  superutilisateur,  comme syslogd(8), de continuer à fonctionner correctement après que les processus non privilégiés ne soient plus autorisés à écrire sur le système de fichiers. La valeur par défaut est de 5 %.

Étrangement ma question en lisant l'article était de trouver des applications au fait de réserver 100% à root…

Cette conclusion est des plus classiques/banales. La plupart des gens s'exprime sur des sujets sans en maîtriser les tenants et les aboutissants (forcément on n'est pas experts spécialisés en tout) : la plupart des personnes qui s'exprime sur le karma, la modération ou les fonctionnalités de LinuxFr.org (pour prendre un exemple que je connais bien) ne connaisse pas les détails techniques, l'historique ou les raisons des choix, mais ont des avis tranchés en général. On ne doit pas leur dire de ne pas s'exprimer, c'est même souhaitable qu'elles s'expriment pour dire ce qui leur plaît, ne leur plaît pas, leurs suggestions, etc. Tout au plus peut-on espérer un peu de pondération/modération dans les propos pour convertir un « Votre xxxx c'est de la merde » ou « Bordel pourquoi vous n'avez pas encore fait ça ? » en « Votre xxx est améliorable pour telle ou telle raison et par tel ou tel moyen » ou « Pourquoi votre xxx fait-il cela ? ». C'est moins présomptueux, plus empathique, moins inflammatoire, plus respectueux, plus intéressant pour les deux parties (le demandeur réfléchit un peu plus aux raisons, et de fait le répondant aussi, tâchant de se rappeler pourquoi c'est comme ça et si ça ne devrait pas être documenté quelque part), et ça rend le poil soyeux et guérit la faim de la guerre des cancers du monde.

C'est dommage de réduire ces sujets à un simple lien je trouve. Il y aurait plus à dire sur RGPD et infrastructures informatiques (ICANN & DNS, GPG, blockchain, etc.).

Tentative de résumé des échanges sur la liste gnupg-devel :

• les serveurs de clé peuvent partager des noms/prénoms/courriels (voire des photos) associés aux clés
• cela se fait sans permettre la suppression et rentrerait en conflit avec le droit à l'oubli
• cela fait partie du fonctionnement (la collecte n'est pas abusive)
• demander des confirmations/informer l'utilisateur à chaque envoi serait contre-productif en termes d'interface utilisateur et de diffusion de la crypto
• un tiers peut collecter les données partagées de toute façon, sans accord utilisateur ou sans respect de la loi (spammeur par exemple)
• techniquement, il n'est pas actuellement possible de marquer « privée »/non diffusable une clé publique (ou de la supprimer). Il faudrait au moins permettre la suppression de la clé (ou au moins de la partie UID nom/prénom/courriel/photo) par le propriétaire de la clé.
• les serveurs SKS ne seraient pas compatibles RGPD, mais d'autres serveurs de clé (celui de Mailvelope est cité) le seraient.
• plusieurs positions plus rassurantes sur l'objectif du RGPD et la position des autorités nationales, comme le fait que ce n'est pas leur but ou le fait qu'elles utilisent aussi GPG
• il est de toute façon utile d'ajouter une politique sur les données sur son serveur de clé (il existe des générateurs)

Précisé, merci.

Une solution est d'utiliser %S, qui marche sur mobile et desktop dans ce cas.

Corrigé, merci.

Corrigé, merci.