Moonz a écrit 3657 commentaires

J’en ai rien à foutre d’emacs et des polices.

Maintenant ce que je vois c’est quelqu’un qui ne n’en fout pas s’est retroussé les manches, l’a implémenté pour le système qu’il utilise (OSX), l’a intégré. Puis a vu son travail être supprimé pour des raisons idéologiques (OSX pas libre bouh). Ça me semble être 100x plus décourageant que l’avis de 5 trolleurs sur DLFP, non ?

Je ne comprend pas.

Apparemment ta logique serait « L’électeur Green n’ayant pas voté pour Clinton, il a indirectement voté pour Trump ».

Pourquoi est-ce que ça ne marche pas dans l’autre sens ? « L’électeur Green n’ayant pas voté pour Trump, il a indirectement voté pour Clinton ».

Et ce d’autant plus que Trump a dit la même chose de Snowden.

Est-ce que tu votes non quand 1% des articles ne te plaisent pas? 10% Tout ça n'avait aucun sens.

C’est pourtant ce que tu es censé faire quand tu votes à la présidentielle sur la base d’un programme complet.

La difference c'est que bush etait du genre a rien faire

Bush n’a rien fait au moyen orient ?

Mon idée première était d'avoir le reverse proxy qui écouterait en HTTPS avec le certificat qui va bien, pour distribuer les échanges vers les bons conteneurs (wallabag, mais aussi les autres) directement en HTTP (ce serait local au nas, pas de pb de sécurité).

Oui

Chaque conteneur (=service) doit donc avoir son propre certificat

Ben non, puisque le conteneur n’a aucune idée qu’il est en HTTPS. C’est le frontal nginx qui aura un certificat différent pour chaque conteneur, mais en pratique ça veut dire deux lignes (ssl_certificate/ssl_certificate_key) différentes par vhost.

Tu mets la config globale (ssl_protocols/ssl_ciphers/... [1], proxy_set_header/proxy_http_version) dans la section http (donc commune à tous les vhosts). Ensuite dans chaque vhost tu auras (par exemple) :

server {
        server_name wallabag.romu.fr;

        listen 443 ssl;
        ssl_certificate /var/lib/acme/live/wallabag.romu.fr/fullchain;
        ssl_certificate_key /var/lib/acme/live/wallabag.romu.fr/privkey;
        ssl_trusted_certificate /var/lib/acme/live/wallabag.romu.fr/chain;

        location / {
                proxy_pass http://localhost:4000;
        }
}

(ces chemins pour le certificat/clé sont ceux de l’outil acmetool. Un autre outil pourrait en avoir d’autres)

Pour l’obtention des certificats, ça dépend de l’outil. Avec acmetool, il suffit d’ajouter à tous tes vhosts :

        location /.well-known/acme-challenge {
                allow all;
                default_type text/plain;
                root /var/www;
        }

(/var/www dépend de la configuration d’acmetool)

puis de faire un acmetool want wallabag.romu.fr.

[1] Aide toi de ça pour configurer correctement SSL.

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

If the proxy_pass directive is specified with a URI, then when a request is passed to the server, the part of a normalized request URI matching the location is replaced by a URI specified in the directive:

    location /name/ {
        proxy_pass http://127.0.0.1/remote/;
    }

If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI:

    location /some/path/ {
        proxy_pass http://127.0.0.1;
    }

Dans le premier cas, romu.fr/toto est passé à ton wallabag: localhost:4000/toto, ce qui fonctionne (si /toto est reconnu par wallabag, évidemment)

Dans le second cas, romu.fr/wallabag/toto est passé ainsi: localhost:4000/wallabag/toto.

Deux solutions :

• soit wallabag a une option pour reconnaître qu’il est à l’intérieur d’un namespace (/wallabag), et tu dois le configurer
• soit tu dis à nginx de transformer romu.fr/wallabag/toto en localhost:4000/toto. Ajouter juste un / à la fin de l’adresse du reverse proxy dans proxy_pass devrait suffire. Problème : si wallabag utilise des URL absolues (type <a href="/tata">), alors tous les liens vont péter, puisqu’au premier lien tu seras redirigé vers romu.fr/tata, qui ne sera pas reconnu comme faisant partie du namespace wallabag. Pour cette raison, faire du reverse proxying dans un namespace est considéré comme une mauvaise idée.

À ta place je m’emmerderai pas et je prendrai un certificat letsencrypt pour wallabag.romu.fr.

Par ici

Tout à fait. Si on remonte dans les archives, on voit bien qu’à une époque les news de deux lignes qui seraient aujourd’hui critiquées dans les journaux comme étant « de simples journal-bookmark » étaient monnaie courante. Personnellement j’appréciais.

Ce qui confirme ce que je dis : même quand par un miraculeux alignement des planètes un « indépendant » (i.e. hors des deux grands partis) arrive au second tour il n’a aucune chance au dernier. US, France, même combat sur ce point.

les independants n'ont absolument aucune chance, zip nada, que dalle. Ils sont totalement inutiles et c'est pour la galerie leur candidature

Ben un peu comme en France quoi.

voire de chercher à provoquer la fin de mon rêve.

Compte tes doigts.

Si on met de côté la virulence de son propos, les insultes et l'agressivité

Je suis totalement d’accord, espèce de gros enfoiré de merde.

(je ne pense évidemment pas ces insultes, mais c’était pour illustrer l’idée :))

Je vois pas ce qu'il y'a de délirant a tuer les process lancés manuellement par un utilisateur quand il se délogge.

Parce qu’un utilisateur peut très bien avoir de bonnes raisons pour vouloir avoir des processus sans avoir de session (liste non exhaustive) :

• screen/tmux
• un job long terme (encodage d’une video par exemple)
• download/seed d’un client bittorrent
• programme type seti@home

Sinon non, ça n’a rien de délirant tant qu’une alternative crédible est proposée pour permettre les mêmes fonctionnalités. Je n’en vois pas. Sur le principe, ce serait certainement une bonne idée de faire ça si on créait un système de novo, sans historique à gérer. Scoop : ce n’est pas le cas de Linux.

Si tu veux que ca tourne en tache de fond, fais en un vrai service

1. La méthode idiomatique pour se faire depuis des décennies c’est de faire une tâche de fond de ce type un orphelin. Pourquoi vouloir à ce point casser une convention qui marche somme toute pas trop mal (pas parfait on est d’accord, mais c’est pas comme si la solution systemd était parfaite elle) ?

2. systemd ne fournit aucune alternative accessible à l’utilisateur (systemd-run nécessite les droits root, créer un service systemd nécessite les droits root)

3. systemd ne fournit aucune alternative interopérable

Quel rapport avec les zombies ?

Les zombies orphelins sont nettoyés par init depuis la nuit des temps, c’est pas une nouveauté de systemd. Les zombies non orphelins n’ont pas à être nettoyés puisque leur père peut très bien vouloir récupérer leur code retour plus tard (et systemd ne les nettoie pas).

Si t'as un workflow digne de Windows 98, ca ne regarde que toi.

Quitte à troller, je dirai que le workflow digne de Windows 98, ce serait bien de se dire « je laisse ma session ouverte parce que si je la ferme apache.exe de mon WAMP va se faire tuer ».

La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).

Si si, il y a bien un IV dans CTR : https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_.28CTR.29

Ça évite en prime de voir l’intégralité des messages qui tombent en cas de compromission de la clef unique (d’autant plus si l’IV est public).

Je vois pas ce que ça change. Dans ton schéma plus haut, si MK tombe tes clés uniques tombent aussi.

Tu peux faire de la crypto en js sur les navigateurs récents : https://developer.mozilla.org/en/docs/Web/API/SubtleCrypto

Réutiliser une clef de chiffrement est une erreur grave en crypto

Huh… source ? De mémoire de mes cours de crypto, c’est le couple (clé, IV) qui ne doit pas être réutilisé.

Edit : stackoverflow confirme mes souvenirs : http://crypto.stackexchange.com/questions/33751/aes-key-reuse-and-guessing-the-key/33757

To simplify, you can reuse a private key as often as you want as long as you can generate new initialization vector for each message.

Ça commence à faire une jolie combinaison de trucs foireux, non ?

1. Le fond de mon commentaire est que dans la vie réelle les trucs foireux arrivent. « On s’en fout de X, ça ne pose problème que dans les situations foireuses » n’est pas une défense acceptable. Un truc robuste c’est un truc robuste y compris dans les situations foireuses, pas un truc « robuste si tout se passe comme sur des roulettes ». Il n’y a pas grand mérite à être « robuste » quand il n’y a aucun souci par ailleurs.

2. Comme remarqué plus haut, en prod/preprod et en temps normal on ouvre pas de session utilisateur. Ergo, tu ne verras jamais en preprod que systemd a tout chamboulé les règles concernant les sessions utilisateurs sur une mise à jour (sauf si tu y penses, mais honnêtement, avant ce journal ou d’y être confronté, qui peut penser au cas « haha la mise à jour systemd va rien casser dans ma prod sauf dans le cas complètement anormal où j’y ouvre une session utilisateur » ?) puisque la question ne se pose pas en temps normal. 3 mois plus tard, urgence en prod, et paf les ressources IPC postgres.

3. Il n’y a pas que des serveurs dans la vie, et on a toujours pas répondu à ma question : pourquoi présupposer qu’un utilisateur ne puisse pas avoir de démon ?

Des développeurs peuvent aussi avoir une base de données locale sur le poste de développement. En Oracle je sais pas, mais avec postgres/mysql c’est une solution toute aussi viable qu’un serveur de dev centralisé.

Whaou y'a encore des gens qui ont pour bonne pratique de se connecter à une machine pour faire des trucs à la mano, non reproductibles, non testés et idéalement sans rien dire à personne pour être sur de prendre un KO à la prochaine mise à jour ?

1. Pour faire des tests en dev, oui, ça me paraît une pratique acceptable
2. Malheureusement, dans la vie réelle, même si on connaît et applique généralement les bonnes pratiques, il y a toujours x% de situations merdiques où il faut se connecter en root@prod à l’arrache pour mettre quelques bouts de sparadraps en urgence (x variant de 0 à 100 selon la qualité de l’équipe d’admin, 0 et 100 étant irréalistes). Ce serait bien que dans cette situation d’urgence on ait pas à gérer la surprise « bon, quel comportement qui fonctionnait depuis 15 ans systemd va nous faire exploser à la figure aujourd’hui ? »

Ca me parait logique de "tuer" tout ce qui est lié à un utilisateur quand il se déloggue (car il… se déloggue).

Pourquoi diable exclure d’office l’idée que l’utilisateur puisse avoir un démon ?

En 2000, RMS ne voyait pas l’intérêt de l'art libre

Et alors ? Moi non plus je ne vois pas l’intérêt de l’art libre, mais ce n’est pas pour autant que je vais me mettre à appeler « art libre » de l’art qui ne respecte pas les 4 libertés fondamentales.

Donc, ils faisait la différence entre l'usage d'un outil pour faire une bombe, et l'expression d'une personne ou d'un groupe.

Si tu veux un exemple qui n’implique pas de bombe :

Je doute que les devs apache/nginx soient fan de l’utilisation qui est faite de leur code pour distribuer de la pédopornographie, ou de la propagande de groupes terroristes (par exemple). Devrait-ils ajouter une clause contre certaines expressions ?

Les débats libre vs open source ont donné lieu à la définition du libre selon la FSF, définition selon laquelle -NC n’est pas libre, et la définition de l’open-source selon l’OSI, définition selon laquelle -NC n’est pas plus open source que ce n’est libre. Et quelques autres initiatives comme les DFSG… qui n’accepte pas non plus le -NC.

J’aimerais bien que tu me cites ces gens qui en 1998 étaient d’accord pour considérer que le -NC était acceptable d’un point de vue libre. À part le Shared Source de Microsoft, s’entend.

mailpile stocke ses données, métadonnées et indexs de manière chiffrée (sans aller taper dans le chiffrement homomorphique). Peut-être regarder de ce côté là.

Vous avez une timeline grossière ?

La technologie a un peu évolué depuis les disquettes. Et pas que quantitativement.

https://aws.amazon.com/glacier/faqs/

Q: How durable is Amazon Glacier?

Amazon Glacier is designed to provide average annual durability of 99.999999999% for an archive. The service redundantly stores data in multiple facilities and on multiple devices within each facility. To increase durability, Amazon Glacier synchronously stores your data across multiple facilities before returning SUCCESS on uploading archives. Glacier performs regular, systematic data integrity checks and is built to be automatically self-healing.

Pour le format, ça ne changera pas du jour au lendemain. Il y aura toujours une période de transition pour passer les archives d’un ancien format au niveau. Et ça aussi ça devient de plus en plus facile technologiquement : passer d’un film photographique argentique à un format numérique c’est dur et cher, passer d’un format numérique à un autre c’est facile et (relativement) pas cher.