Adrien Dorsaz a écrit 943 commentaires

En théorie, la recherche non-sensible aux accents ni à la casse dépend du contexte de la langue utilisée pour la recherche. Cette théorie est définie par Unicode.

J'imagine que Gnome Shell et Nautlius utilisent pour la recherche la langue configurée par l'utilisateur.

Est-ce que tu peux vérifier que la langue de ta session est bien le français ?

Qu'est-ce que tu as comme résultat quand tu liste tes variables d’environnements avec la commande suivante ?

env | sort | grep -E "^(LC_|LANG)"

Moi, pour l'instant avec OpenSuse Tumbleweed, je n'ai que LANG=fr_FR.UTF-8 et Nautilus n'arrive pas non plus à trouver de résultat quand la recherche est sans accent.

Merci pour l'info, je ne savais pas que les images pouvaient être signées avec Docker.

C'est assez chouette, parce que ça permettrait d'avoir la même confiance que pour l'ajout du repository apt externe et ce sans avoir à donner les droits root.

Pour le point des tags "latest", c'est très juste, il faut que je corrige ça.

Merci pour les idées!

J'ai oublié de mettre le fichier service généré par podman (j'ai juste ajouté la ligne OnFailure):

# container-grafana.service
# autogenerated by Podman 3.0.1
# Thu Apr 28 23:09:17 CEST 2022

[Unit]
Description=Podman container-grafana.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
OnFailure=notify-admin@%n

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/bin/rm -f %t/container-grafana.pid %t/container-grafana.ctr-id
ExecStart=/usr/bin/podman run --conmon-pidfile %t/container-grafana.pid --cidfile %t/container-grafana.ctr-id --cgroups=no-conmon -d --replace --name=grafana -p 3000:3000 --env-file /home/grafana/grafana.env --volume /home/grafana/grafana:/grafana --net slirp4netns:allow_host_loopback=true docker.io/grafana/grafana-oss
ExecStop=/usr/bin/podman stop --ignore --cidfile %t/container-grafana.ctr-id -t 10
ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/container-grafana.ctr-id
PIDFile=%t/container-grafana.pid
Type=forking

[Install]
WantedBy=multi-user.target default.target

Pour tes idées, je commence par la deuxième qui repose sur celle proposée par la génération automatique de podman.

Utiliser l'option --log-driver=journald (mais je ne sais pas si c'est déjà supporté par la version de podman proposée par debian).

J'avais essayé ça, mais j'ai eu l'impression que ça ne marchait pas.

En gardant le fichier tel que généré et en ajoutant les arguments --log-driver=journald --log-opt tag=grafana, les logs existent bien, mais ils apparaissent dans le journal système et ils sont préfixés par conmon.

Ça m'a vraiment surpris que ça apparaissent dans le journal --system. C'est parce que journald détecte que l'utilisateur grafana est un utilisateur système (avec un UID < 1000) et il redirige ses logs directement dans les logs systèmes.

Donc, malgré moi, lors de la création de l'utilisateur, j'avais pris le bon choix de demander d'en faire un utilisateur système car ça me centralise les logs (ce que je cherchais à faire justement :)).

Pour le problème du préfixe conmon, il faudrait que j'essaie l'option --log-opt tag=grafana, mais avec podman 4, d'après ce bug (Debian a un podman en version 3.1).

Pour l'instant, je vais essayer ta première idée, car je vais pouvoir changer le tag syslog avec ça.

Deux méthode: fournir ta propre unit file pour le service au lieu d'utiliser podman generate et démarrer le pod comme s'il était lancé en interactif, non détaché.

Je n'y avais pas pensé, merci.

J'ai essayé et ça semble bien fonctionner, même si ce n'est pas la solution officielle.

Pour le faire, j'ai enlever l'argument -d de la commande podman run, j'ai passé le Type en simple. En plus, j'ai ajouté l'option SyslogIdentifier=%N pour éviter de voir toujours écrit podman dans les logs.

Pour gedit, le mainteneur a demandé de retirer son projet du cœur de GNOME.

Or le projet GNOME considère important de proposer un éditeur de texte a ses utilisateurs.

Le nouveau projet leur permet d'en créer un qui suit les recommandations de l'équipe design.

Et puis j'ai découvert l'existence openSUSE Tumbleweed : une rolling release qui promet d'être bien peaufinée et stable / robuste.

C'est très alléchant présenté comme ça :)

Si je me rappelle bien, il y a quelques années, ils essayaient de mettre en place en plus un système de backups / restore automatique avec les snapshots de BTRFS.

En gros si la dernière mise à jour ne te plait pas, tu dois pouvoir revenir à l'état précédent grâce au menu GRUB (et pas juste le kernel, mais le système entier).

Si c'est bien en place, c'est encore un atout en plus pour leur rolling release :)

Un peu réticent au départ parce que c'est une distribution RPM (habitué à APT depuis des années), je me suis malgré tout dit pourquoi pas essayer,

J'ai essayé juste 1-2 jours il y a 2-3 ans, je voulais justement voir ce que permettait les snapshots BTRFS.

Je ne me souviens plus exactement pourquoi j'ai réinstallé Debian après ces tests.

J'avais juste une appréhension sur YaST. Est-ce que ça te dérange pour configurer tes logiciels ? Son utilisation est-elle obligatoire pour configurer son système ?

J'ai l'impression que c'est une couche d'abstraction des configurations en plus et j'appréhende de ne plus savoir comment faire pour configurer les logiciels (par exemple sssd, apache, nftables…).

Pour le CR/LF, il faudrait que je vérifie avec un bon éditeur de texte (je n'en ai pas sur mon téléphone), mais je suis quasiment sûr que ce n'est que du LF (il est par contre peut-être doublé), car il n'y a pas de Windows pour servir LinuxFr.

J'ai vérifié avec vim et oui, tu as raison, il y a des CR qui trainent dans la seconde partie. C'est vraiment étrange 🤔

L'entête n'est pas du yaml, simplement du texte pour les humains :)

Pour le CR/LF, il faudrait que je vérifie avec un bon éditeur de texte (je n'en ai pas sur mon téléphone), mais je suis quasiment sûr que ce n'est que du LF (il est par contre peut-être doublé), car il n'y a pas de Windows pour servir LinuxFr.

le contenu est bien adapté et les 600px ne semblent s'appliquer qu'aux ordis (pour lesquels le minimum attendu en mode graphique est 800*600 justement ?)

Si on affiche le navigateur en plein écran, oui. Mais ce n'est pas toujours le cas, tu peux le faire afficher que sur la moitié, un quart ou n'importe quelle dimension grâce à ton gestionnaire de fenêtre préféré 🙂

Par contre, ce n'est pas évident d'être utilisable / lisible pour n'importe quelle dimension…

Je viens de voir que cette idée vient de la difficulté de lire les tableaux dans ce journal.

Un code complet CSS pour tester, c'est:

table {
  border-collapse: collapse;
}
table td {
  padding: 5px;
}
table tr {
  border-bottom: thin solid;
  border-top: thin solid;
}
table tr:hover {
  background: #f1f1f1;
}

J'ai dû ajouter la règle border-collapse sur table, si non, la règle sur les border de tr n'avait aucun effet.

Quand j'ajoute cette règle, on perd l'espacement qui existait entre les cellules, c'est pour ça que j'ai rajouté aussi un padding sur les td.

Je trouve que ça donne bien dans le journal cité plus haut.

Il faut que je prenne le temps de tester cette idée sur plus de contenu.

En particulier celui du "hack" des tableaux pour afficher les logos des éditions dans les journaux des contenus LinuxFr récompensés par des livres.

comment finaliser les dépêches qui traînent en rédaction ? Plus d'humain avec plus d'animateurs de rédaction pour veiller à l'état de fraîcheur des dépêches ? Plus de technique pour aider avec des relances/rappels/alertes ?

Suite au récent journal Les dernières nouvelles du nettoyage de l'espace de rédaction, je continue de penser qu'il vaut mieux compter sur les moyens techniques pour garder un espace de rédaction conviviale à tous.

En effet, dans ce journal, tisaac montre bien qu'il y a quand même pas mal de sentiments en jeu pour les animateurs (traumatisme, désespérant…). Alors que pour un robot, c'est fait sans appréhension.

Je ne pense pas qu'il y ait besoin de tant de sentiments, car l'auteur qui a lancé la dépêche l'a certainement oublié et est passé à autre chose. Le robot enverra un rappel quelques jours avant la suppression et si aucun n'espoir n'est donné à la dépêche, elle sera supprimée (enfin "cachée dans la base de donnée", rien n'est vraiment supprimé sur LinuxFr).

Un autre arguement est que pas mal d'autres communautés font le même genre de système automatique: je vois de plus en plus souvent des robots fermer automatiquement des Pull Request sur Github après x jours (les animateurs sont un peu les "mainteneur de l'espace de rédaction") ou encore des Discourse qui ferment les commentaires après 15 jours sans activité (là, il y a bien la communauté qui anime).

Dans le journal on voit également:

En dehors des valeurs sûres, il n’y a que deux dépêches qui ont été entamées avant le 1er janvier 2021. Seules trois dépêches n’ont pas donné signe de vie sur les 6 derniers mois. Je ne vais pas dire que les autres sont toutes hyper actives mais bon, en termes de sédimentation, c’est vachement moins important que quand j’ai commencé mon œuvre.

Le robot aurait donc supprimer 5 dépêches si on le règle pour 6 mois d'inactivités.

Ça ne sera pas non plus une hécatombe ;-)

En effet, quelqu’un a osé indiquer au fronton d’une dépêche dans l’espace de rédaction : Merci de ne pas contribuer ni rien traduire. Pour l'instant, ce sont mes notes et points de repères dans des docs. J’en vois dans le fond déjà chercher des excuses à ce malheureux en avançant que cela peut être utile pour construire dans un premier temps une structure un peu correcte de la dépêche.

Là, je trouve que c'est un abus de l'espace publique proposé pour la communauté LinuxFr, on pourrait même imaginer une intervention à la main pour supprimer cette dépêche.

Pour ça, il y l'autre entrée de suivi qui propose d'améliorer l'interface pour les animateurs.

Merci pour le retour, j'ai ajouté un commit au PR pour refuser de proposer en dépêche un journal qui n'a pas coché la license CC-BY-SA 4.0.

C'est effectivement plus simple, puisque rien n'est sûr si la case n'a pas été cochée.

Ou bien est-ce que tu veux pouvoir commenter directement sur la page du contenu ? Par exemple, tu cliques sur le bouton "Répondre" et il affiche directement le formulaire dans la page sans la changer.

C'est ce qui se fait partout ailleurs :-) donc oui, ça. Ça permet, en restant sur la page, de voir ce qu'il y au dessus (donc tout).

En fait, ce qui est compliqué avec LinuxFr, c'est que l'utilisateur peut répondre à n'importe quel commentaire et, ça, ça ne se fait pas "partout ailleurs" ;-)

Je connais 2 sites qui permettent de faire ces réponses en fil: reddit et slash dot.

Sous chaque commentaire, ils ajoutent un texte/bouton "Répondre" qui affiche le formulaire pour créer le commentaire.

Ça fera pas mal de travail pour adapter LinuxFr, mais c'est un challenge intéressant, car l'essentiel des fonctionnalités est là, mais il faut les adapter :)

Si je devais faire un plan d'attaque, j'essaierai dans l'ordre:

1. Fusionner la partie "Écrire le commentaire" et la partie "Prévisualiser" quand on crée le commentaire. Par exemple sur Github/Gitlab, il y a des onglets "Write" et "Preview" pour faire ça.
   • Là il faudra déjà utiliser JavaScript pour demander au serveur de faire la prévisualisation et faire du CSS pour avoir de jolis onglets (il y a déjà un système d'onglet disponible pour l'espace de rédaction)
2. Modifier le texte "Répondre" dans chaque commentaire pour faire afficher ce formulaire lors du clique
3. Faire de même pour la création d'un nouveau fil de commentaire.

Je veux pouvoir avoir tout le contenu et les autres commentaires sous les yeux quand je commente

C'est ça que je ne comprend pas. Est-ce que c'est une demande pour améliorer le système actuel ou pour le remplacer complètement par autre chose ?

Autrement dit:

Est-ce que tu veux garder le système actuel, mais ajouter de l'information en plus autour du formulaire de création de commentaire ?

Ou bien est-ce que tu veux pouvoir commenter directement sur la page du contenu ? Par exemple, tu cliques sur le bouton "Répondre" et il affiche directement le formulaire dans la page sans la changer.

Je te comprend et je ne sais pas ce qui est possible de faire pour aider Benoît et les administrateurs systèmes à ce sujet.

J'ai été ajouté comme membre de l'organisation sur Github, mais je ne sais pas ce qui se passe quand on applique les PR. Est-ce que les serveur se synchronisent directement avec la branche master ? Est-ce que seul l'environnement alpha le fait ?

En fait, en tant que développeur, je sais que pour aider à fusionner les PR, il faut ajouter des tests exécutés automatiquement (au moins voir si le site démarre et répond). Seulement, ça demande encore de faire des PRs et donc d'en ajouter encore dans la pile déjà assez grande.

Un autre moyen d'aider serait de pouvoir aider à installer et tester les différents PRs, mais, comme dit plus haut, je ne connais pas du tout la procédure d'installation sur alpha et la production.

Je n'arrive pas à bien comprendre la demande.

Est-ce que tu voudrais pouvoir ajouter un commentaire directement dans le fil de discussion sans changer de page ?

Si c'est le cas, je pense qu'il il y aura besoin de JavaScript.

Le site a été développé en 2009 pour pouvoir travailler quasiment sans nécessiter JavaScript, ce qui explique le comportement actuel à mon avis.

La seule partie où JavaScript est vraiment nécessaire, c'est l'espace collaboratif de rédaction des dépêches et les tribunes.

Plus de 12 ans plus tard, on pourrait remettre en question ce choix d'être fonctionnel sans JavaScript. C'était plutôt pratique à l'époque, car Internet Explorer ne savait pas tout faire, mais de nos jours ce navigateur n'est même plus mis à jour par Microsoft.

Personnellement, ça ne me dérangerait pas d'utiliser JavaScript, car il est possible de faire beaucoup de choses propres avec les standards plus ou moins récent.

Si on décide d'utiliser un peu plus intensivement JavaScript, il faudra aussi se poser la question de quelle version nous souhaitons utiliser. Par exemple, on pourrait décider d'utiliser la version 6 publiée en 2015.

Le correctif est proposé dans le PR #320.

Il me semble que j'ai remarqué ce même comportement également sur les entrées de suivis.

Il faudrait que le tableau de bord notifie l'auteur d'un contenu quand un nouveau fil de commentaire est crée.

Je vois que dans le tableau de bord, nous avons les sections "Vos derniers messages dans les forums" et "Vos dernières entrées dans le suivi" qui devraient recevoir le symbole de notification dans ce genre.

Je comprend tout à fait le problème de la gestion de réputation d'un serveur email. C'est un réel problème et ce même pour l'hébergement professionnel et privatif.

Comme nous avons déjà les flux RSS pour les commentaires pour chaque contenu (forum, journal, dépêche, entrée de suivi…), ça serait bien de proposer à l'auteur du contenu de s'inscrire au flux RSS.

En plus, j'ai entendu parler d'outils qui permettent de transformer un flux RSS en flux d'email (côté utilisateur) sans avoir besoin d'employer le serveur de mail de LinuxFr.

Je trouverais ça chouette d'avoir un message du genre:

Votre journal/post de forum/lien a bien été publié.

Pour suivre les commentaires, inscrivez-vous à son flux RSS

Si vous n'avez pas de lecteur RSS, vous pouvez utiliser "rss2email" pour recevoir les commentaires dans votre boîte email.

J'ai mis "rss2email" car c'est le premier nom qui m'est apparu en cherchant "rss to email open source". Il faudrait trouver l'outil/service le plus ergonomique pour les néophites des flux RSS.

Pour référence, le même genre de problème a été soulevé dans ce commentaire: https://linuxfr.org/forums/linux-debian-ubuntu/posts/pour-utilisation-d-une-cle#comment-1872522

Notamment, les réponses d'Ysabeau:

Tu noteras la réponse de Bruno Michel à la deuxième entrée de suivi et celle de Benoît Sibaud sur la troisième.

Personnellement, j'y suis favorable et je pense qu'il y a un besoin. Après je ne sais pas trop comment ça fonctionne, désolée. Je vais signaler ton commentaire à la modération afin que les administrateurs le lisent et je te suggère de répondre à cette entrée de suivi.

Merci de ta proposition.

Sinon, je ne pense pas qu'il s'agisse d'un manque de volonté, mais plus d'un manque de mains pour faire le boulot. On manque de gens pour le développement du site en fait.

Et la réponse de Benoît:

Il n'y a pas de volonté de ne pas le faire. La seule contrainte me semble être la volumétrie de courriels et les règles semi-aléatoires de certains serveurs pour accepter ou non les courriels (ie. peut-être des soucis de fiabilité et/ou un plus gros risque de classement en spammeur de notre serveur de courriel). Mais ça ne devrait pas nous décider de mettre en place de la notification par courriel (ou autre).

Quand tu "run une image" pour reprendre tes mots[…]

Hum https://docs.docker.com/engine/reference/run/

$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG…]

Et quand tu lis la documentation qui est juste avant:

Docker run reference

Docker runs processes in isolated containers. A container is a process which runs on a host.

Puis, tu lis la documentation juste après:

The docker run command must specify an IMAGE to derive the container from.

Je suis d'accord que la syntaxe donne l'impression de "run une image", mais en réalité tu run un container.

Ce n'est pas de la drosophilie avancée, c'est très important pour comprendre comment Docker fonctionne et comment il faut l'utiliser.

Le principe est qu'une image devrait toujours pouvoir être complètement détruite et, quand tu la rebuild avec un Dockerfile, tu retrouves le même résultat à peu près ("à peu près", car ça dépend des commandes exécutées pendant le build).

Le container par contre utilise l'image pour exécuter une commande et il n'y a plus de garantie sur l'état du système de fichier du container.

Ça permet aussi de garder un même volume entre plusieurs démarrages de container.

Je me suis même reposé la question et c'est pour ça que j'ai voulu précisé. Je me suis dis que si moi qui utilise docker régulièrement avait mal compris d'autres pourraient mal comprendre.

Ok, cette formulation n'était pas très précise.

Le but était surtout de préciser qu'un volume "nommé" a un nom fixe, qu'il peut être facilement identifiable sur la machine hôte.

En plus, comme son nom est fixe, il peut aussi facilement être réutilisé après avoir détruit son container. Il peut aussi être lié à d'autres containers (comme proposé par Psychofox pour les backups), mais dans ce cas, il faut faire très attention aux accès concurrents aux fichiers.

Non, non, une image est juste le résultat soit de:

• la fin d'un build de fichier Dockerfile
• un commit du système de fichier d'un container

L'image peut être vu comme un snapshot d'un système de fichier en lecture seule.

Quand tu "run une image" pour reprendre tes mots, en réalité tu fais ça :

• tu copies le système de fichier de l'image pour le passer en lecture/écriture pour le container (c'est le container niveau file system)
• tu attaches les volumes éventuels définis dans la commande "run" (ils sont créés s'ils n'existent pas déjà)
• tu lies les ports TCP de l'hôte sur ceux du container (si définis)
• … et d'autres liens entre le namespace du container et l'hôte, je ne connais pas toutes les options…
• enfin, dernière étape, dans le container une commande est exécutée. Soit celle définie dans la commande "run", soit la ligne CMD du Dockerfile, soit l'ENTRYPOINT de la commande ou du Dockerfile

Pour le point "copier le système de fichier de l'image", Docker utilise des systèmes de fichiers spécialisés qui ne nécessitent pas de faire une copie réelle, comme BTRFS et OverlayFS.

Si tu supprimes ton container sans avoir fait un "commit" de son système de fichier (c'est à dire créé une image depuis un système mouvant, c'est une mauvaise idée !) ni avoir mis les données dans un volume, alors tu perds ces données.

Si tu penses "redémarrer" comme uniquement "stop" et "start", alors oui, les données sont conservées. Mais ce n'est pas le cas intéressant de Docker.

Une image Docker ne démarre jamais ;-)

Le volume est attaché au container au moment où tu créés le container.

Avec un volume nommé, tu peux le réutiliser, même après avoir détruit le container original.

De même, comme l'a dit PsychoFox plus bas, tu peux l'attacher à plusieurs container en même temps (mais attention à la concurrence d'accès aux fichiers !).

Si jamais, on peut donner des noms aux volumes et tu retrouveras le dossier avec le nom correspondant sur l'hôte.

Ça permet aussi de garder un même volume entre plusieurs démarrages de container.

Bon pour vérifier la théorie, j'ai fais un rapide exemple avec un client JavaScript: https://projects.adorsaz.ch/adrien/example-refresh-token-for-linuxfr.org/-/blob/main/src/app.js

Ce client est vraiment stupide: il récupère l'access_token et le refresh_token et, tout de suite après, il essaie de rafraîchir l'access_token et il affiche tout ça dans le log du serveur.

Un exemple d'exécution sur ma machine me donne:

GET / - - 
code found:  ff48b...
Access token response (status: 200):  {
  access_token: '255367...',
  token_type: 'Bearer',
  expires_in: 86400,
  refresh_token: '140a2c...',
  scope: 'account',
  created_at: 1635286565
}
Refresh token response (status: 200):  {
  access_token: '40dd64...',
  token_type: 'Bearer',
  expires_in: 86400,
  refresh_token: '41566c....',
  scope: 'account',
  created_at: 1635286565
}
GET /?code=ff48b... - - 

Bien sûr, j'ai retiré mes token de l'exemple, mais je t'ai laissé les 6 premiers caractères pour que tu voies qu'ils ont bien changé.

Edit: Comme tu le vois dans le code, il faut faire attention à ce que le POST sur /token utilise le format x-www-form-urlencoded et non pas du JSON directement. C'est pour ça que j'utilise l'API URLSearchParams: https://github.com/node-fetch/node-fetch#post-with-form-parameters

Comme indiqué sur la page https://linuxfr.org/developpeur , en théorie Doorkeeper te permet de rafraîchir ton access_token grâce au refresh_token récupéré à la connexion de l'utilisateur.

Voir le chapitre Renewing the access token de la documentation de Doorkeeper.

Donc, en théorie un POST sur https://linuxfr.org/api/oauth/token avec ces informations devraient suffire:

{
"client_id": "l'identifiant publique de ton client",
"client_secret": "le secret de ton client",
"redirect_uri": "l'url que ton client écoute pour la redirection",
"grant_type": "refresh_token",
"refresh_token": "Le refresh_token reçu en même temps que ton premier access_token"
}

Mais je n'ai jamais utilisé l'API donc ça me sera difficile de t'en dire plus.

Est-ce que tu utilises une bibliothèque pour gérer OAuth ?