TeDomum Write

Reader

Read the latest posts from TeDomum Write.

from Argeveller

Habituellement j'aime bien les vendredi. Ils appellent les ami⋅e⋅s, signifient l'arrivée d'un droit à la paresse, ils sont comme habités d'une atmosphère joviale dans les rues que je fréquente.

J'aurais dû me méfier de cette amicalité avec les vendredis.

L'origine de la méfiance

Tout récemment il y eut ce vendredi 13 mars 2020, dans lequel j'aidais à organiser une soirée « Débat sur la technopolice à Rennes ». Je ne suis pas superstitieux, pourtant l'accumulation de signes et de symboles était si bonne que j'en rigolais : Vendredi 13, Boulevard de la Liberté, arrivée en France de la pandémie du coronavirus…

Puis le 20 mars, vendredi durant lequel nous avions dû prendre la pénible décision de suspendre nos permanences d'accueil et d'aide aux personnes étrangères sans papiers.

Le 27 mars, alors que je bossais sur une signature par « Chaos Game Representation of a genetic sequence » du petit vilain virus et ses versions mutées, mon ordinateur passa à trépas. La perte de ce fidèle compagnon de plus de 10 ans de vadrouilles et vagabondages était chargée de conséquences possiblement dramatiques pour moi. j'ai donc criée mon désespoir dans le minitel du Fediverse des Internets. Oui ma précarité chevillée à ma condition sociale ne fait de moi un flocon de neige unique qui faudrait à tout prix sauver de la disparition. Je suis tout au plus un saltimbanque qui déchaîne les vendredi, un pauvre ordinaire comme des dizaines de millions d'autres personnes juste pour ce pays nommé France.

Les routes de la confiance

Dans mes peurs et mon cafard j'ai ressenti à nouveau le parfum de vendredi de convivialité, un air de « le plaisir de vivre ensemble, de chercher des équilibres » ( Jean Anthelme Brillat-Savarin − 1825), des épices de quelque chose de « déterminée » (Illitch − 1973) dans un chaos du monde que je me perds parfois à comprendre.

Des personnes du Fediverse, dont certaines que je n'ai rencontrée que leur être des internets, ont proposé de m'aider, de s'organiser pour ne pas me laisser glisser vers plus de pauvreté. J'étais dans le luxe de respirer à plein poumon les effluves des élans de solidarité, des pollens de convivialité. Solidaryverse¹…

Je voudrais vous écrire explicitement mes profonds remerciements et partager un une foule les sentiments de papillonnement tout en couleur et saveurs que vous m'avez mis dans les tripes. Vous êtes des géant⋅e⋅s aux doigts magiques.

Une reine des Elfes et une Airbird (si, si je vous jure) m'a aidé. Rien qu'avec cela je pourrais affronter tous les vendredi maléfiques qui adviendraient.

Mon avenir sans outils de travail, sans mon ordinateur de gagne miette de pain, semblait moins pénible, pourtant pas encore au soleil. J'aurais pu vivre pire dans une République en Marche, on aurait pu me proposer un numéro de téléphone et site web d'urgence tout frais du matin pour m'aider à traverser la rue de ma misère. Heureusement pour moi, en lieu et place des petits arnaqueurs du dimanche, je suis attrapé par un Héros du vendredi.

Les voiles de générosité

Une personne qui souhaite conserver une forme d'anonymisation de son geste m'offrait un ordinateur portable tout neuf et de très bonnes qualités. À des centaines de kilomètres de moi, dans une période de pandémie mondiale, simplement et presque timidement une personne que je ne fréquente que via les internets vient au chevet de ma situation pour y déposer toute cette immense anticyclone de générosité.

Je voudrais ici et maintenant précis et concis. Il n'y a pas de mot assez fort, pas un merci assez grand écrit, pour exprimer ce que j'ai ressenti.

<3 <3 <3 <3 <3 <3

J'ai inspiré profondément, expiré longuement, répété cela plusieurs fois, pendant plusieurs jours. Puis quelques coups de pinceaux plus tard…

Mon nouvel outil de vadrouille depuis lequel je vous écris

Les invisibles qui nous relient et nous sauvent

Il y a des héroïnes et des héros dans mon histoire, des géants, une Reine des Elfes. mon histoire est vraie puisque je l'ai vécue et aussi elle racine sa factualité dans ces lignes que je vous écris.

Cette histoire s'est déroulé dans une société qui est orientée par des choix politiques qui sont mis en œuvre à l'aide d'architecture et de configuration.

« Cette “crise” de plus fait office de révélateur des structures sous-jacentes mais invisibles de nos sociétés ... et le ridicule qui va avec. L'opportunisme et le colonialisme se lâchent sous prétexte de crise, alors même que ces modèles devraient changer pour éviter la prochaine ... ne pas réagir mais structurer et prévenir » Olm_e

Les protagonistes de cette histoire, de notre histoire puisque composées à plusieurs, ont ouvert couloir d'air vers des champs de liminarité. Elles et ils m'ont offert l'immense privilège de bénéficier de celui-ci.

Cette histoire n'aurait jamais été autre chose qu'un accident confiné, enfermé, cris et peines étouffées entre quatre murs, sans les interventions des invisibles qui tissent et maintiennent les conditions d'existences de mondes.

Les personnes du service postale, les caissières du supermarché la buraliste de ma rue, toutes les personnes de la santé et des hôpitaux, les profs qui ont eu à l'école toutes ces personnes, les éboueurs, les devs de liberapay, les admins des instances du Fediverse, Tedomum team, les pseudonymes des internets, et tellement d'autres… C'est avec vous que l'on écrira les conditions « transfrontalières et transliminaires » (Léna Dormeau 2020). Nous n'oublions et n'oublieront pas celles et ceux qui nous assujettissent à l'invisible et aux souffrances forcées.

Notes

 
En savoir plus...

from TeDomum

Bonjour à tous nos utilisateurs, utilisatrices, et soutiens,

Vous avez probablement remarqué un bon nombre de changements récemment : nous avons interrompu nos services à plusieurs reprises, notamment pour déployer une authentification centralisée Hiboo mais également pour migrer vers de nouveaux serveurs.

Aujourd'hui, nous sommes fiers de vous annoncer que nos demandes de partenariat depuis l'assemblée générale 2019 n'ont pas été vaines !

Ce matin, à 8h37, nous avons reçu une confirmation bien matinale de Microsoft Azure concernant le tarif partenarial pour l'utilisation de leur Cloud, en vue de fournir des services à titre gracieux. Nous avons dorénavant accès a une infrastructure moins coûteuse et plus perfomante que celle utilisée actuellement. Nous explorons l'hébergement Azure depuis le mois de décembre, avec notamment un grand intérêt pour les capacités compatibles Kubernetes, et sommes particulièrement enthousiastes à l'idée de voir aboutir ce projet.

Ce changement s'inscrit dans une démarche plus globale de limitation des coûts afin d'assurer la rentabilité de l'association, mais aussi de limiter l'impact écologique de l'hébergement associatif conformément aux directives des CHATONS verts. En outre, la compatibilié Kubernetes, les capacités de passage à l'échelle et de sauvegarde automatiques de Azure permettront une gestion plus simple de notre infrastructure, une meilleure délégation des ressources, et une plus grande sécurité pour les données de tous nos utilisatrices et utilisateurs. Enfin, nous avons obtenu garantie que nos services demeureraient hébergés en Europe.

Etant donné les pics d'utilisation actuels liés à la quasi-généralisation du télétravail, et comme cette infrastructure est bien plus performante que les machines que nous utilisons actuellement, nous prévoyons de migrer les services progressivement, mais rapidement ; des coupures momentanées sont a prévoir (plus d'informations et suivi des migrations sur notre page Facebook). Une fois la migration achevée, nous envisageons un coût de compute d'environ 20€ par mois, et un coût de stockage à date d'environ 25€ par mois, avec une prévision à 35€ mensuels d'ici fin 2020. Les objectifs en termes de dons pourront être mis à jour progressivement lorsque nos besoins en stockage grandiront, nous publierons ainsi prochainement une prévision de budget consolidée pour l'année à venir, qui sera mise à jour chaque année à la suite de notre assemblée générale.

Microsoft nous met à disposition nativement des outils performants pour la communication et la collaboration en ligne, deux principaux thèmes des services fournis par TeDomum. Afin de limiter les doublons et la surconsommation de ressources associée, nous proposerons d'abord des services Azure en complément de nos services natifs et faciliterons la migration, conformément à la charte CHATONS : Matrix sera complété par Teams, Jitsi Meet par Skype, Nextcloud par OneDrive, et OnlyOffice par Office Online (d'autres migrations sont a prévoir afin d'éviter de proposer des services déja hébergés par Microsoft). Nous n'excluons pas de fermer à terme les services en doublon lorsqu'une majorité d'utilisatrices et utilisateurs aura migré, afin de nous concentrer sur les services différenciants tels que les Pads, l'hébergement vidéo, d'images et le stockage sécurisé de mots de passe.

Les services Nitter et Maps ont déja été migrés vers la nouvelle infrastructure a titre de test, vous pouvez dès ce matin constater de meilleures performances sur nitter.tedomum.net par exemple. Les prochains services migrés seront les Pads et les blogs WriteFreely.

Si vous avez des questions ou rencontrez des difficultées durant le mois de migration, n'hésitez surtout pas a nous en faire part sur notre page Facebook. Nous serons particulièrement à l'écoute pendant le mois de migration à venir.

Plus sérieusement

Avec un peu plus de sérieux : oui, nous allons migrer nos services, mais certainement pas vers Microsoft. Les principales raisons qui nous poussent à migrer sont :

  • le cycle de vie de nos machines physiques actuelles, que nous tâchons de ne pas renouveler trop souvent mais qui arrivent en fin d'emploi aujourd'hui (après 4 ans de production) ;
  • la simplification de notre budget, afin de limiter nos coûts en infrastructure en louant des machines moins performantes et donc moins coûteuses, et d'atteindre l'équilibre à base exclusivement de dons réguliers ;
  • la réduction de notre impact énergétique et écologique en limitant dans un premier temps le nombre et la consommation de nos équipements.

Pour cela, nous visons vers le bas, et non vers le haut : nombre de nos travaux récents vont vers la rationalisation, non pas en fusionnant avec Microsoft Azure, mais en limitant la consommation CPU et mémoire là où elle est superflue, en décommissionnant les projets qui n'ont pas abouti et ne sont pas utilisés au quotidien. Aussi, étant donné la sur-utilisation de plusieurs de nos services ces derniers jours et pour les semaines à venir, nous conserverons nos serveurs actuels en complément pour encaisser la charge et proposer une instance Jitsi Meet la plus performante possible.

Nous devrions atteindre l'équilibre financier à base exclusivement de dons réguliers courant 2020. Cet équilibre consolidera la pérennité de nos services, qui dépendait jusqu'alors de dons ponctuels particulièrement bienvenus mais plus délicats à anticiper et à intégrer à notre budget.

Enfin, sur décision de notre assemblée générale 2019, nous prévoyons de migrer progressivement en dehors des datacenters (nous sommes aujourd'hui hébergés chez Scaleway, prochainement chez OVH) afin d'exploiter des ressources hébergées directement chez nos membres et par de petites structures associatives respectueuses des libertés individuelles. Nous détaillerons dans un prochain billet les objectifs et les expérimentations de l'initiative ACIDES sur ce point lorsque les premières preuves de concept concrétiseront ces efforts.

 
Read more...

from Argeveller

Un endroit ydillique en Bretagne, sur le côte aux granits roses, des hackeuses, hackers, designeuses, designers, écologues, linguistes, architectes, militant⋅e⋅s, programmeuses et programmeurs, ingé⋅e⋅s, queers, se réunissent.

Des bords bords du Jaudy, sur épéron de roches et de terres face à la mer, elles et ils pensent que leurs utopies peuvent panser un peu le monde.

Dès le premier jour, à l’abri des pins, les WC et la douche rompent leur assignation à évacuation des matières. Leur espoir de deux semaines estivales florissantes sont menacés, leur hygiène est compromise. Un enfant de moins de dix ans est privé de commodités élémentaires dites modernes. Manger devenait compliqué car la vaisselle difficile à réaliser sans rejeter d’eau.

Les WC se bouchent, la douche refoule, l’odeur de putréfaction colle à leur système de conceptions idéalistes, l’odeur se répand dans le paysage. Même la vase de l’embouchure de la rivière ne rivalise pas avec ce spectre et son suaire olfactif.

Elles et ils pensent les liens, les techniques, les cultures, les systèmes et infrastructures. Elles et ils tissent des étoles de promesses et de devenirs. Pourtant cette panne les paralysait, au point critique que personnes n’agissait.

Il n’y a pas de “How To”, de “write up”, de “post mortem”, de page wiki pour ces situations. Seule les manches retroussées de rares personnes qui acceptent la responsabilité de l’investigation dans le dur, qui se chargent de patauger et de remuer les défécations d’un groupe social, ici concentré comme rarement sur cette zone, sont les agentes et agents de persistances d’une continuité de qualité de vie moderne faisant face à l’obligation physiologique.

Nous étions face à une esthétique, tout autant face à une métaphore, d'imbrications de construits dont nous héritons sans avoir choisi ce lègue, confronté·e·s à l'injonction de nous en responsabiliser. Nous entrions en profondeur « négociation tacite » avec les systèmes dont nous étions surgeonnes et surgeons.

Deux, nous avions été deux à prendre une pioche partagée pour fendre le puissant granit dans l’attente de libérer une hypothétique fausse ; à s’acharner à découvrir les drains bouchés par les temps et les rejets des humains. Chaque coup de boutoir n’enlevait que quelques éclats de roche, faisant raisonner notre squelette comme un simple tube métallique. En revanche de notre opiniâtreté nous recevions des jaillissements de liquide chargé de matières molles dont nous refusions la composition bien qu’étant obligés d’en avoir les odeurs.

Sueurs d’août, eau croupie, excréments, éclats de granit rose, finissaient par former un nouveau film, part de nous et de notre labeur, à même notre peau et faible quantité de vêtements.

La fausse fut découverte après une journée de bagnards. Il fallut ensuite y plonger seau et mains pour purger de mix de matières et de liquides afin d’envisager à la racine le problème. Pas non plus rejeter n’importe comment, ni n’importe où, ces reliquats de notre humanité que le temps de la nature et les technologies n’avaient pas encore eu le plaisir de traiter et digérer. Un ydillique cap rose ne mérite pas notre infection.

Le groupe, lui comment il fonctionnait ? Dans l’indigence, dans la mécanique sociale cassée, tout du moins arrêtée jusqu’à l’extrême capacité à retenir des besoins du corps. Certaines personnes encourageaient, d’autres regardaient par la fenêtre, d’autres encore s’échappait à la situation. Une forme de socialité chargée se constituait ; deux creusaient.

Ces personnes, pouvant être vues et lues comme « en capacité », sachantes, ou performantes, étaient ici dans une épaisse panne qui les gênait. Revelant aux passage beaucoup de l’intime et du fonctionnement de leur prédéceseuses et prédécesseurs, exposant à l’œil et au nez un envers du décors de nos communautés.

Nous avions pioché et curé plus d’une journée et demi. La pioche en étant usée, même rabougrie dans son profil. Déboucher, re-tuayauter, puis retapisser de sols, n’auront été que des épiphénomènes, tant ils furent faciles physiquement, tant la tension n’existait que dans la panne non-résolue du fonctionnement sanitaire.

Le camp des utopistes, des commonistes, pouvait reprendre le chemin du fonctionnement qui lui était promis. Là dans ce coin de paradis qui jadis fut et aujourd’hui est le théâtre de pirateries dont on ne sait jamais vraiment si elles furent fictionnées ou perpétrées.

Aux ami⋅e⋅s, à Kerbors.

 
En savoir plus...

from rinnai

암호화폐라는 명칭은 “자금결제에 관한 법률”에 근거가 있는 것이므로, 변경에는 법률 개정이라는 대규모 절차가 필요함을 고려할 때 보고서가 굳이 명칭을 암호 자산으로 변경하도록 제언하는 이유로는 단순히 해외에서 암호 자산이라는 표현이 정착되고 있는 것만이 아니라, 암호화폐의 통화로서의 지위에 대해 부정적인 견해를 표명하기에 이른 것이라고 해도 좋을 것입니다.

배경으로서는 통화의 결제수단으로서의 기능을 생각할 때 이른바 캐시리스화가 급속히 정책과제로까지 부상하고 있는 가운데 법정통화의 디지털화가 진전되고 있는 것입니다만, 이들은 일본의 법률 하에서는 '통화표시자산'이나 '선불식 지불수단' 등에 해당되어 표시된 법정화폐와 같은 가치를 갖는 것에 지나지 않으므로 암호화폐라는 신개념을 전혀 필요로 하지 않을 것입니다.

또한 가치의 저장수단으로서의 기능에 대해서도 암호화폐의 현재 상황에서는 그 고유의 독자적인 경제권이 성립되지 않는 가운데 법정화폐와의 대비에서 상대가치를 합리적으로 평가측정하는 수법을 상정할 수 없고, 순전한 투기대상으로서의 존재 의의 밖에 인정할 수 없는 실정입니다.통화는 FX에서 보듯이 투기 대상이 될 수 있지만, 반대로, 투기 대상이 될 수 있기 때문에 암호화폐가 통화라고 할 수 없는 것입니다.

그래서 종합적으로 판단하면 가상화폐는 적어도 현재 상황에서 통화로서의 기능이 없어 단순한 투기대상일 뿐이라고 생각할 수밖에 없지만, 동시에 법정화폐로 교환 가능한 한 자산성이 있다는 것도 부정할 수 없으며, 결국 암호자산당 명칭이 타당한 명칭이 될 것입니다.

암호화폐의 통화로서의 조건

그럼 암호화폐가 통화가 될 수 있다고 한다면 그 조건은 무엇일까요.가상화폐는 법정화폐와 대등한 것이어야 하며, 특정 법정화폐에 종속되는 것이 아닌 단순 법정화폐의 디지털화 혹은 암호화가 아니라는 것입니다.또 그것이 법정 통화가 아니라는 것은 배후에 법을, 즉 정치권력을 갖지 않는다는 것입니다.

가상화폐가 배후에 정치권력을 가지지 않는다면 발행체는 없는 것이 될 수밖에 없습니다. 왜냐하면 발행체를 갖는다면 그 발행체의 배후에 정치권력을 상정할 수밖에 없고, 일본의 법률 하에서는 '통화건 자산', '선불식 지불 수단', 금융상품의 어느 하나에 해당될 것이 틀림없기 때문입니다.

따라서 암호화폐는 상식적으로는 관념 불능이지만 정보기술의 고도화에 따라 디지털 공간상에 자율적으로 존재하는 것으로 실현될 수 있다는 주장에 대해서는 그것이 상식을 초월한다고 해도 부정할 수 없는 현 상황이 있는 것입니다.

그래서 암호화폐는 통화로서 존재할 수 있기 위해서는 발행체, 즉 특정 관리자를 가지지 않고 정보기술적으로 자율성을 갖춘 질서를 형성하고 있을 것, 복제, 개찬, 유출 등의 불가능성을 기술적으로 보증할 수 있는 것 등 고도의 기술적 요건을 충족해야 하는데, 현재 그러한 요건을 충족하는 것이 여러 개 존재한다고 되어 있는 것 같습니다.

그러나, 기술적 요건만으로는, 통화로서의 실질적인 기능을 충족하는 것은 아닙니다.법정화폐는 배후에 국가를 갖는 것인데, 국가는 정치적인 결합일 뿐 아니라 경제적 결합, 즉 자율적인 경제권이기도 하고, 통화는 경제권이 있어야 의미가 있으며, 반대로 경제권을 조직하는 것이어야 의미가 있습니다.그런데 가상화폐에 대해 말하자면 기술적 요건을 충족하고 있는 것도 그 배후에 경제권의 성립을 인정하는 것은 불가능한 것이 현실입니다.

단순 투기대상 가상화폐

투기 대상이라고 해도 가상화폐는 법정화폐와 달리 순수 투기대상이 돼 버린 것이 큰 문제죠. 즉 FX처럼 법정화폐도 투기대상이 되는데, 법정화폐에는 한편으로 무역이나 자본거래에 따른 거액 실수거래가 있기 때문에 다른 쪽에서 활발한 투기를 하는 것은 시장에 유동성을 공급한다는 중요한 사회적 의의를 갖는 반면 가상화폐의 경우에는 배후에 경제권이 있는 것이 아니기 때문에 실수요를 예상하지 못하고 순전한 투기가 되어버린다는 것입니다.

투기는, 요점은 도박입니다만, 형법상 범죄에 해당하는 도박조차, 복권이나 경마와 같이 특별법으로 합법화되어 있는 것은, 지방 자치체의 자금 조달에의 공헌 등, 일정한 사회적 의의를 인정받고 있습니다.법정화폐의 투기에도 그런 사회적 의의가 있지만 가상화폐의 경우에는 그런 의의를 인정할 여지가 전혀 없습니다.

아마 규제당국의 입장에서 보면 당초에는 암호화폐의 미래 가능성을 호의적으로 인정하여 '자금결제에 관한 법률'에서의 명칭도 암호화폐로 하였겠지만 현실적으로는 통화로서의 발전이 없는 가운데 법률상의 수당이 있는 만큼 오히려 도박장 개장을 합법적으로 허용한 셈이 되고 있는 현상에 대해 규제색을 강화하고 있는 것 같습니다.그것이 암호자산이라는 명칭으로의 변경으로 나타나고 있는 것이라고 생각됩니다.

규제의 잠탈로서의 ICO

ICO에 대해서는 어떻습니까?투기 도구로 자금 조달이라고 하는 것은 과연 어떤 것일까요.ICO 즉 이니셜 코인 오퍼링이란 코인 혹은 토큰이라 불리는 암호화폐를 발행하여 자금을 조달하는 것으로 이니셜 토큰 세일이라고도 합니다.

여기서 분명한 문제는 ICO는 발행체가 있고 그 자금 조달로 발행되는 것이기 때문에 처음부터 암호화폐의 본래 취지에 반한다는 것입니다.물론, 이 점은 의식되고 있고, ICO는 어떤 가치를 공유하는 것이 발기인이 되어 그것에 찬동하는 것을 모집하는 형태를 가장하고 있어, 그 가치 공동체가 경제권을 형성한다고 하는 상정하에 이루어지는 것이 보통으로, 그 경제권은 토큰 이코노미 등으로 불리고 있습니다.

하지만 경제권을 창출하기에 이른 ICO의 실례가 없어 누구나 상상하듯 사기 사안으로 여겨지는 것도 적지 않은 것이 현실입니다.따라서 규제당국 입장에서 보면 ICO에서 발행되는 것이 법률상의 암호화폐 요건을 형식적으로 충족하게 되면 경제권 창출이라는 실질적 요건을 갖추지 못하더라도 ICO에 의한 자금조달이 가능해지는 것에 대해 큰 우려를 갖지 않을 수 없을 것입니다.

특히 규제상의 결정적인 난점은 암호화폐로서의 형식적인 요건을 충족시켜 버리면 자금조달임에도 불구하고 이를 규제하는 '금융상품거래법' 적용을 피해 버린다는 점입니다.실제로 ICO를 검토하는 동기로서'금융상품거래법'을 회피하고 자금을 조달할 수 있는 데 이점을 찾아내는 사안도 적지 않은 것 같습니다.규제 당국 입장에서 보면 우려할 만한 사태가 아닐 수 없습니다.

투기 대상에도 규제 필요

옛날 네덜란드에는 튤립 구근을 대상으로 한 투기로 인한 거품이 있었다고 하는데, 튤립은 원예의 취미 대상이었기에 투기의 대상이 될 수 있었겠지요.모든 것이 투기의 대상이 되는 것은 아니고, 일정한 가치가 뒷받침되지 않으면 투기 대상조차 될 수 없다는 것은 암호자산도 마찬가지라고 생각합니다.

그리고 암호 자산은 단순한 투기 대상에 지나지 않는다고 해도 법률상의 수당이 이루어지고 있는 이상 거래 참여자의 이익은 보호되어야 합니다.특히 기술적 측면에서 복제, 개찬, 유출 등의 위험에 대해 충분히 대응할 필요가 있으므로 규제당국으로서는 기술적 요건에 관한 규제를 강화함으로써 기술의 고도화를 촉진함과 동시에 업자의 진입장벽을 높게 하여 투기나 부정한 ICO를 억제하는 목적도 있을 것입니다.

규제당국으로서는 부정한 원인으로 형성된 자금에 의해 어떤 자산을 취득하고 이를 재매각해 법정화폐로 하면 부정한 기원으로 소급할 수 없게 되는 점, 이것이 자금세탁, 즉 불법자금 세탁인데 암호자산이 자금세탁의 편리한 도구가 될 수 있다는 점은 지극히 심각한 문제입니다.여기에도 암호자산에 관한 규제강화의 불가피한 흐름의 원인이 있습니다.

암호화폐의 가능성

마지막으로, 암호 자산에 통화로서의 미래의 가능성은 있는 것일까요. 암호자산으로의 명칭변경에 따라 현재의 암호화폐는 단순히 파칭코와 유사한 도박판의 개장에 지나지 않는 것으로서 사회 일각에 봉해지게 되겠지만, 그것은 반대로 암호자산이 진정한 통화, 아마도 암호화폐라고 불리겠지만, 그 암호화폐가 될 수 있기 위한 조건에 대해 새로운 생각을 개시시키는 계기가 될 것입니다.

예를 들면, 아마존이 암호 화폐를 찍어내는 암호 돈으로 교환에 전 주식을 취득하고 비공개화하면 100조 엔이라는 거대한 암호 통화에 따른 경제권이 창출된다, 그렇게 되면 실물 경제의 뒷받침을 가진 진정한 암호 통화가 탄생하게 되고, 그렇게 보는 것은 공상이나 망상도 아니고 가까운 미래를 전망되는 것은 아니겠죠?

 
Read more...

from theabbie

How to mind your own business?

I was walking past the mental hospital the other day, and all the patients were shouting, ’13….13….13.’

The fence was too high to see over, but I saw a little gap in the planks, so I looked through to see what was going on.

Some idiot poked me in the eye with a stick!

Then they all started shouting, ’14….14….14.’

 
Read more...

from rinnai

결혼이란 파트너에게 사랑과 존경과 헌신과 성실함을 맹세하는 것. 하지만 세상에는 유감스럽게도 상대방에게 말도 안 되는 숨긴 채 이혼에 이른 커플도 여럿 있는 듯 하다.

이에 미국 코스모폴리탄의 인터넷 사이트에 실린, 믿기 힘든 이혼 에피소드 몇가지를 소개한다.

1. 막대한 사유재산

“내가 아는 사람들은 전처에게 빌딩 2개, 고급 지대에 있는 바다를 따라 1개의 펜션, 그리고 2개의 회사가 사용하는 석유 플랫폼 소유주라는 것을 숨겼다고 합니다.”

약 20년 후,그 남자가 돌아가고 두 아들에게 상속되었을 때 처음으로 가족은 그 존재를 알았을까?

2. 엄청난 돈과 다른 가족

“그 남자는 연봉 150만 달러가 있는 사람이었고, 10회에 걸쳐 외도를 반복하고 있었습니다. 이혼 중재의 막바지에서 그는 시애틀에 또 다른 가족이 있다는 사실과 더불어 다른 업계에서도 1400만 달러의 수익을 올리고 있는 것으로 드러났으며, 두 번째 명의로 소유한 주식 옵션(자사주 매입권)의 가치는 약 2억1400만 달러 상당에 달했다고 합니다.”

이 정도면 그야말로 혀를 내두르지 않을 수 없는 수준이다.

3.말도 안 되는 액수의 청구서

“한 부부가 1972년 가스 사용 계약을 마치고 살기 시작한 집에서의 일. 가스회사의 문제로 계약서류가 제대로 처리되지 않았고, 한 번도 청구서가 보내져 오지 않았다고 합니다. 하지만 가스 마개는 열려 있었고, 그 부부는 계속해서 무료로 가스를 사용했습니다. 그 후 두 사람은 이혼했고, 남편은 그 집의 소유주였습니다. 2014년에야 가스 회사가 이 문제를 알아차리게 되었는데, 법률상 지난 몇 년치 청구가 가능했기 때문에 남편에게 상당한 금액의 청구서를 보냈지만 남편은 아내에게 청구서를 보내라고 말했습니다.”

알고보니, 남편이 이혼할 때 가스 회사가 과거의 가스 대금을 청구할 수 있다면 아내가 전액 부담한다는 항목을 몰래 이혼협의서에 명시해 놓았다고 한다;;

 
Read more...

from Erin Carson

Posted by Erin Carson October 20, 2019 at WordPress.com Posted in News

An incomplete list of places I go for news.
(Note: This list changes)

General News

U.S. News

News Aggregators & Wire Services

Internet News

Memes
Video Games

Technology

 
Read more...

from TeDomum

... sans en avoir trop honte !

Ces derniers mois l'idée a mûri et il est grand temps que ce blog s'en fasse le relais puisque nous expérimenterons dès ce week-end sur de premiers services en production : Hiboo, notre nouvelle usine à gaz.

Si Hiboo est tout ce qui vous intéresse plutôt que l'historique, vous pouvez avancer directement à la section « Que s'apeleriá Hiboo »

Un problème avec l'authentification

L'authentification d'utilisateurs sur un service distant n'est pas un sujet neuf, et une successions de philosophies, chacune accompagnée de sa pile de protocoles et d'outils, fournit aujourd'hui un beau panel de possibles. Résumons chronologiquement.

Au commencement était la base d'utilisateurs, locale sur chaque machine. Cette base, que certains ont matérialisée dans un /etc/passwd, d'autres dans les tables SQL de leur application Web, détenait la vérité sur les utilisateurs, leur mot de passe et leur profil.

Le problème est rapidement devenu évident : chaque administrateur connaissait les mots de passe de tous ses utilisateurs. Pour peu – suivez mon regard – que les utilisateurs ré-employassent leur mot de passe sur plusieurs systèmes, chaque administrateur détenait en réalité les clés de leur vie numérique.

Bien entendu et même si les paragraphes sont rédigés au passé (y compris du subjonctif !) : cette époque n'est pas révolue. Quelques mécanismes ont été mis en place pour limiter les dégâts lorque les informations fuitaient : utilisation de hachage cryptographique à l'état de l'art pour rendre plus difficile la récupération du mot de passe réel de l'utilisateur par exemple. Ceci n'empêche que la majorité des applications emploie toujours ce modèle en 2019 ; et que la majorité des administrateurs ont, sur chaque service, une copie de nos mots de passe.

Plus tard on a suggéré que centraliser ce stockage le rendrait plus difficilement accessible à un attaquant, mais aussi plus facilement maintenable. L'IT d'entreprise a ainsi adoubé LDAP et ses concurrents, pour que chaque application interroge le stockage central des authentifiants. Malheureusement dans ce modèle, les applications connaissent toujours le mot de passe de chaque utilisateur qui se connecte.

Les années 80, 90, enfin les années 2000 et plus récentes ont vu fleurir la notion de tiers authentifiant. D'abord Kerberos, puis SAML, SAML2, OAuth, enfin OAuth2 et son cousin OpenID Connect offrent la possibilité de centraliser l'authentification sans que l'application ait accès au mot de passe. Comment ? grâce à la magie de la cryptographie essentiellement ; nous vous renvoyons à la documentation de chacun de ces standards pour les détails plus ou moins gores.

TeDomum dans tout ça

Où en est-on chez TeDomum aujourd'hui ? Au triste niveau de la base d'authentifiants gérée par chaque service. C'est un choix que nous avons fait il y a plusieurs années selon le raisonnement suivant.

La plupart des applications que l'on déployait à l'époque supportait soit LDAP, soit un stockage local. L'alternative LDAP posait un risque supplémentaire : non seulement les applications continueraient d'accéder au mot de passe utilisateur, mais en prime l'utilisateur n'aurait plus le choix que d'utiliser le même pour tous nos services. On n'aurait rien apporté à un utilisateur peu consciencieux, et on aurait pénalisé les internautes motivés qui configuraient déjà un mot de passe différent par application. Nous avions donc opté pour le moindre mal : ne rien changer.

Notre objectif dorénavant : fournir enfin une authentification unique pour nos services, mais sans révéler le mot de passe à chaque application, et en proposant des mécanismes modernes, multi-facteurs, adaptés.

Que s'apeleriá Hiboo

Le bon sens voulut que nous options pour une solution du marché (Gluu et Keycloak ne sont que deux exemples de qualité dans un écosystème assez bien fourni), mais la lourdeur et le manque de souplesse de ces implémentations nous ont freinés. Aussi, contre toute raison, et comme nous l'avions fait en 2014 en débutant le développement de Mailu, nous nous sommes lancés from scratch.

L'objectif d'authentification centralisée a guidé la réflexion, mais il est loin d'être le seul besoin : plusieurs se sont par exemple présentés en réfléchissant aux manières d'implémenter SAML2 et OpenID Connect, les protocoles retenus pour migrer notre authentification.

C'est ainsi qu'est né le projet Hiboo, où nous souhaitons développer notre capacité à gérer sur le plan technique la communauté d'utilisateurs et de services de l'association de façon unifiée et sécurisée.

Page principale de Hiboo

Métadonnées des utilisateurs

La gestion des métadonnées nous pose conceptuellement problème dans les solutions standard d'authentification : en général, le fournisseur d'identité détient le profil de l'utilisateur et autorise les applications à y accéder. Hors, nous ne souhaitons pas que chaque application stocke à sa guise des copies des informations privées de nos utilisateurs, à commencer par leur adresse e-mail.

En attaquant le problème par l'e-mail (nous avons bien d'autres fronts à couvrir), nous proposons une solution où l'utilisateur peut recevoir des notifications sans communiquer ses coordonnées directement à l'application.

Mon profile Grafana avec une adresse e-mail pseudonymisée

Hiboo pseudonymise ainsi l'adresse de contact et joue le rôle de relai. A terme, nous devrions même pouvoir relayer ces messages, après filtrage par l'utilisateur, sur une messagerie au choix. Qui n'a jamais rêvé de recevoir ses notifications applicatives sur Matrix ?

Gestion multi-profils

Au sein de l'équipe TeDomum, nous avons chacun plusieurs profils sur nos services, pour tester, pour administrer, pour notre usage personnel quotidien. Devoir gérer les mots de passe de tous ces profils est coûteux et sujet à erreurs. Nous souhaitions faciliter ces manipulations.

Aussi, nous avons été témoins de quelques cas de harcèlement où malheureusement, malgré les mesures prises pour désarmer l'agresseur et les moyens à disposition pour bloquer ou ignorer ses messages, la victime n'avait plus d'autre choix que de créer de nouveaux comptes pour changer de visage numérique et y échapper. Il nous paraissait primordial d'accompagner ces changements, voire de les rendre faciles et autonomes.

Ainsi, Hiboo décorrèle le compte utilisé pour s'authentifier des profils exposés aux applications. Je peux m'authentifier sur mon unique compte « john » et me connecter à Mastodon en tant que « alice » le matin et « bob » l'après-midi, de même que je peux me connecter à Pixelfed en tant que « john » ou « charlie » quand je le souhaite.

Interface de sélection de profil pour une authentification

L'adresse e-mail fournie étant la seule métadonnée et comme elle est pseudonymisée, l'application ne peut pas relier mes différents profils entre eux (nos applications n'accèdent par ailleurs pas à l'adresse IP source, même s'il nous reste un peu de travail pour masquer le user agent). Mieux : nous avons prévu que le modérateur lui-même ne puisse pas nativement lier ces profils entre eux (nous réfléchissons aux outils pour aider la modération sans compromettre la vie privée des utilisateurs).

Chaque application a son quota de profils pour éviter les débordements, pour certaines les profils supplémentaires sont soumis à validation du modérateur, pour d'autres les profils ne peuvent être créés que par un administrateur, etc.

Liste de profils sur un compte Hiboo

Gestion de la migration

La part la plus difficile de ce nouveau type de composant reste classiquement la migration. Chaque utilisateur de nos services a aujourd'hui son compte sur une, deux, voire plus d'applications que nous hébergeons. Quelque fois ces comptes ont le même nom, parfois ce n'est pas le cas, voire souvent un même nom employé sur une application est en réalité détenu par un autre utilisateur sur une autre application. Comment gérer alors la reprise des milliers de comptes existant sans cafouillage et des mois de préparation ?

C'est là encore que décorréler comptes d'authentification et profils applicatifs nous a rendu service. Chacun est libre de créer le compte d'authentification qu'il souhaite sur Hiboo. Seules quelques rares applications (essentiellement les services d'administration internes à TeDomum) utilisent ce nom de compte pour authentifier l'utilisateur.

Puis, nous importons par application la liste des profils déjà réservés car appartenant historiquement à un utilisateur de l'application. Ces profils sont « récupérables » dans Hiboo en fournissant le mot de passe du compte original ; ils sont alors importés dans le compte Hiboo et utilisables directement (dans la limite du nombre de profils autorisés).

Récupération de profil sur un compte Hiboo

Où en sommes-nous ?

Hiboo n'est plus une chimère, nous le testons depuis quelques semaines et le code est public sur notre forge : https://forge.tedomum.net/acides/hiboo.

Il s'agit d'un développement Python Flask et SQLAlchemy pour le stockage. La gestion des comptes et profils est développée sur mesure, tandis que OpenID Connect et SAML2 sont respectivement implémentés par Authlib et pySAML2, deux excellentes bibliothèques.

A l'heure où nous publions cet article, nous importons les comptes de notre instance Mastodon dans notre serveur Hiboo de production, afin d'ouvrir dans les heures ou jours qui viennent le service pour l'authentification sur Mastodon. Si tout se déroule sans accroc, nous poursuivrons avec l'ensemble des applications supportant SAML2 ou OpenID Connect (soit l'essentiel de nos services).

Perspectives pour Hiboo

Nous ne plaisantons pas en décrivant Hiboo comme notre nouvelle usine à gaz : il reste une montagne de fonctionnalités à ajouter pour en faire notre premier outil de gestion technique de communauté. Mais nous prêterons attention à ce qu'il demeure simple de conception, maintenable et auditable.

D'abord, l'anti-spam. Nous avons travaillé ces derniers mois à la conception de CAPTCHA pour limiter le spam sur nos services. Nous avons espoir que le déport d'authentification calme les robots mais il n'arrêtera pas les spammeurs motivés. Pour cela nous planifions d'intégrer rapidement un système de CAPTCHA modulaire, utilisable par Hiboo lui-même mais également par les applications tierces. Les premiers modules reprendront des CAPTCHA sur étagère (dont le décrié reCAPATCHA, en limitant au maximum le tracking Google associé).

Ensuite, l'authentification forte : nous projetons d'intégrer des bibliothèques d'authentification multi-facteurs, avec en premier lieu du TOTP. Plus généralement, nous souhaitons un modèle d'authentification générique pour Hiboo, où chacun peut choisir son mode d'accès : mot-de-passe, certificat client, voire qui-sait un compte sur un service tiers ? (on pense bien entendu à Facebook et Google, mais nous imaginons plutôt une fédération d'identité « à la » Fediverse, où chacun pourrait employer son compte d'une autre instance Hiboo, comme le suggérait à sa conception le standard OpenID).

Pour terminer, nous envisageons d'y intégrer nos outils de modération assez largement : gestion des comptes, blocage temporaire, suivi des rappels à l'odre, prise en compte des requêtes externes (administratives et judiciaires principalement), blocage rapide d'URL, etc.

Une chose est certaine : nous ne manquons pas de travail. Aujourd'hui une poignée à contribuer, nous espérons que les concepts proposés dans Hiboo séduiront d'autres hébergeurs associatifs. Ce sont les retours de la communauté, et idéalement les contributions à la conception et au code, qui décideront du succès de Hiboo.

 
Read more...

from Erin Carson

I may receive compensation for some referrals to these services.

Where You Can Find My Terrible Opinions In Other Forms
Minds (Referral Link) – TwitterSaiditMemes Page

RSS: BlogRedditYouTubeTwitch

Less Used – Give me a follow if you are already there
Micro Blog: FreeSpeachExtremistTelegramGab Social
Blog: WordPressMindsTedomum
Images: PinterestimgurInstagramFlickr
Video: BitChute (Referral) – YouTubeTwitch Forum: RedditQuoraUnsilenced Voice Other: LinkedInAbout MeFrendica op V M

Backup lists of links: LinktreeWall of Me
Experiments:
Suspended, Banned, Blocked, Locked: Yay!

 
Read more...

from TeDomum

Docker et les journaux

Nous sommes en 2019 et l'on raffole de Docker. En particulier chez TeDomum, nous l'employons pour rationaliser nos travaux de déploiement et de configuration, pour faciliter le partage. Par exemple, l'ensemble de nos services, y compris les services d'infrastructure (sauvegardes, journalisation, statistiques, etc.) est déployé sous forme d'images Docker disponibles à tous et de projets Compose accessibles publiquement, ce qui assure que créer un hébergeur identique est l'affaire de quelques heures, et qu'on bénéficie de facto des mises à jour.

Les écoles varient, mais l'un des patterns usuels de gestion des journaux sous Docker consiste à employer exclusivement la sortie d'erreur et la sortie standard, puis confier à Docker le routage des messages. Cette approche est critiquable par beaucoup d'aspects, surtout son manque de souplesse, mais compense en simplicité et fait presque aujourd'hui l'unanimité. Elle a cela aussi d'avantageux que les choses fonctionnent bien, sans trop de complexité initiale, par exemple pour afficher les journaux du service app d'un projet Compose :

docker-compose logs --tail=100 app

Centraliser les journaux

Lorsqu'on commence à gérer des dizaines de projets Compose sur plusieurs serveurs, même plus généralement quand on multiplie les équipements et les services, il est de bon goût de centraliser rapidement les journaux. Cela permet non seulement de faciliter la détection de défaut avec des jeux d'alertes, mais c'est aussi bénéfique pour la gestion de la vie privée et des libertés : un point unique où les journaux peuvent être systématiquement nettoyés de leurs adresses IP, logins, autres informations personnelles ; un point unique où la rétention peut être limitée conformément à la jurisprudence européenne.

Plusieurs outils et standards pour ça : – syslog, historique mais très robuste, supporte chiffrement et signature des messages ; – Elastic, en appelant directement les endpoints d'un ElasticSearch pour y injecter des objets formattés JSON ; – Splunk, propriétaire et assimilable à une API HTTP ; – GELF, transporté en TCP, UDP ou HTTP, formalisé par Graylog et spécialisé pour le transport de journaux.

Historiquement, TeDomum utilisait Graylog pour la gestion de ses journaux, et nous avions donc favorisé GELF pour les transporter directement depuis le démon Docker. La configuration est simple (extrait de notre daemon.json de configuration Docker :

{
    "log-driver": "gelf",
    "log-opts": {"gelf-address":"udp://logs.server.hostname:12201"}
}

C'est une architecture simplissime, qu'on recommande vivement à quiconque gère une petite infrastructure à base de Docker. Attention toutefois à ce que les communications soient bien protégées (réseau privé) entre les hôtes et le serveur de journaux, de sorte que les traces ne soient pas interceptées.

Ses principaux défauts :

  • la consommation de stockage (qu'on se le dise, un index Graylog doublé de son ElasticSearch pour la recheche, cela consomme plus de 5 fois le volume des journaux ingérés ; TeDomum le payait de 50Go assignés au journaux pour une semaine de rétention environ) ;
  • la consommation en RAM (de même, pour un moteur applicatif sur OpenJDK accompagné d'un ElasticSearch, compter au minimum 3Go) ;
  • on ne collecte que Docker en l'état.

Fluentd pour plus de souplesse

S'agissant de collecter les journaux système, nous employons actuellement journald sur tous nos hôtes car déployé nativement sous notre distribution, Debian Buster.

Malheureusement, journald n'implémente pas de transmission de journaux au format GELF, un agent intermédiaire est donc nécessaire. Les principales technologies sont à ce titre :

  • rsyslog, originalement orienté syslog mais aujourd'hui très généraliste pour router des messages, sa configuration est malheureusement complexe ;
  • Logstash, très accessible et composant essentiel de ELK, gourmand en ressources toutefois ;
  • Fluentd et son petit frère FluentBit bien plus légers et toujours accessibles.

Par principe conservateur, nous avons opté pour Fluentd en attendant un support plus large de la communauté de FluentBit. Déjà franchement léger (compter quelques dizaines de Mo, au pire 200Mo pour une instance), l'agent est capable de traiter de nombreux types d'entrée et de les router vers la même variété de destinations (ElasticSearch, Mongo, fichiers plats, tout y passe, et les modules existent pour étendre). En prime, Docker supporte officiellement le format d'entrée natif, et il existe un module natif pour journald, impeccable !

Nous avons donc imaginé une infrastructure simple, reposant sur Fluentd déployé localement sur chaque hôte ; il peut même y effectuer des pré-nettoyages et pré-traitements. Chaque Fluentd rappatrie ses journaux collectés de Docker et de journald vers un serveur central assurant le processing et le stockage.

Loki, petit nouveau très complet

TeDomum emploie déjà Prometheus pour collecter l'ensemble de ses métriques. Même notre robot de supervision Anna publie des métriques Prometheus sur la supervision des services (combien de temps met un message pour être délivré de chez nous à tel ou tel fournisseur de mails, etc.) Nous consultons ces métriques collectées via Grafana, leader libre de la visualisation de métriques. Grafana est très complet et nous sert dans de nombreux cas d'investigation ; il était auparavant employé aux côtés de Graylog pour la consultation.

Il y a quelques mois, Grafana annonçait la sortie de Loki, une solution de centralisation de journaux façon Prometheus : légère, reposant sur des principes simples mais performants, et surtout complètement intégrée à Grafana. Il faut l'avouer : pouvoir afficher côte à côte les statistiques d'accès à un service et les journaux de ce service, difficile de refuser.

Nous avons donc expérimenté avec Loki, et avons abouti à une configuration plutôt simple mais solide. Nous pouvons aujourd'hui en une seule requête : {"app": "mastodon"} ou {"service": "db"} cibler les statistiques et les journaux d'un type de service, d'une application entière et les affichers sur une même fenêtre.

Loki et Prometheus

Nous avons donc orienté notre configuration Fluentd pour employer Loki en moteur de stockage, ce qui s'avère plutôt aisé avec un plugin développé officiellement par Grafana.

Un déploiement sans encombre

Après une phase de laboratoire, quelques jours d'expérimentation sur une fraction de notre production, la décision était prise jeudi 9 de profiter d'un redémarrage – mise à jour oblige – pour basculer le premier de nos serveurs entièrement sous Fluentd et Loki côté journalisation.

Pour l'occasion, nous avons déployé Fluentd dans un conteneur local, qui écoute sur un socket unix :


<source>
  @type unix
  @id in_docker
  @label docker

  path /var/log/fluentd.socket
</source>

Et Docker qui pointe ses journaux vers le socket :

{
    "log-driver": "fluentd",
    "log-opts": {
        "fluentd-address": "unix:///var/log/fluentd.socket",
        "fluentd-async-connect": "true",
        "fluentd-retry-wait": "30s"
    }
}

Le choix de la connexion asynchrone est nécessaire, puisque Fluentd étant lui-même conteneurisé, Docker ne parvient à lancer aucun conteneur tant que le service n'est pas disponible sur le socket.

Après un premier déploiement réussi, la même configuration est appliquée partout. Rapidement l'ensemble des journaux remonte vers Loki : un bonheur.

Et les ennuis commencent...

C'est jeudi soir que les premiers ennuis se font sentir. Le symptôme est simple, plus aucun service n'est accessible sur l'un de nos serveurs : joke. Naturellement on fait le lien avec le nouveau déploiement, mais comme plusieurs mises à jour ont également été appliquées, rien n'est évident.

Un diagnostic rapide montre que les services eux-mêmes ne sont pas en défaut, mais que le frontal traefik ne répond plus aux requêtes (il n'accepte même plus de connexion TCP). Qu'à cela ne tienne, avant d'investiguer, on le redémarre pour rétablir le service :

docker-compose restart traefik                                                                                         
Restarting front_traefik_1 ...                                                                                                                                                                                                                                                                   
ERROR: for front_traefik_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)                                
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.                                               
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60). 

Le stress grimpe un petit peu, et pour rétablir les choses assurément, on redémarre le démon Docker et l'ensemble des services. Tout rentre dans l'ordre, un « glitch » passager tente-t-on de se rassurer. Le diagnostic matériel ne donne par ailleurs aucune information, rien non plus dans les journaux système ou noyau.

Un « glitch » passager

S'il y a une chose acquise depuis qu'on administre un hébergeur, c'est qu'un « glitch » passager n'existe pas. On s'en rassure, mais il y a toujours une cause derrière chaque défaut, et souvent elle revient à la charge.

Vendredi, ce n'est pas un mais trois plantages du même serveur, joke, auxquels nous avons fait face. Très difficile à vivre pour un hébergeur habitué à quelques défauts mais rarement de panne générale. Aussi, en fin d'après midi, pas enclins à passer la nuit à surveiller les compteurs, on décide de rappatrier sur une autre machine nos services les plus délicats.

En parallèle, on investigue rapidement. Le défaut semble lié à un gros volume de journaux comme en témoigne les statistiques (en octets par seconde reçus par Loki). On distingue parfaitement les horaires des trois dénis de service :

Stats logs

Ces statistiques sont effectivement corrélées avec l'émission réseau par le conteneur Fluentd sur joke :

Stats fluentd

Malheureusement, il ne semble pas qu'un seul de ces journaux reçus apparaisse dans Loki ; on ne sait donc pas qui les génère ni pourquoi ils empêchent Fluentd ou traefik de fonctionner. Les statistiques CPU laissent tout de même entendre que PeerTube est particulièrement actif au moins sur l'un des défauts :

Stats CPU Peertube

On décide de conserver PeerTube sur joke pour ne pas risquer d'impacter les autres hôtes et on projette d'investiguer pendant le week-end.

Vers un début de solution

A notre surprise samedi, c'est l'hôte où l'on a justement migré les services qui fait défaut. Une fois, puis deux. On s'apprête à conclure que c'est l'un des services migrés qui déclenche le bug lorsque joke tombe à nouveau : nos certitudes s'effondrent.

Toutes nos hypothèses à l'eau, on profite du défaut de joke sans service critique pour investiguer plus tranquillement. D'abord, on confirme le volume de journaux importants à chaque plantage ; ils n'apparaissent toujours pas dans Loki pour une raison qu'on ignore – un défaut de parsing suppose-t-on – aussi on active une copie locale dans un fichier.

<match **>
  @type copy

  <store>
    @type loki
    ...
  </store>
  <store>
    @type file
    path /logs/fluentd.log
  </store>
</match>

Egalement, en tentant d'isoler le défaut de Docker on constate que seul le conteneur traefik est impacté. Le reste fonctionne impeccablement, et aucun autre timeout n'est constaté. Dernier pas en avant (et pas des moindres) dans notre réflexion, redémarrer le conteneur Fluentd résoud le problème.

Non seulement cela nous offre une solution meilleur marché que redémarrer l'ensemble des services si le défaut se reproduit, mais cela confirme une chose : le lien clair avec Fluentd. Notre hypothèse à ce stade : quelque chose déclenche le traitement d'un gros volume de journaux dans Fluentd ; puis soit la forme soit le seul volume de ces journaux rend Fluend inopérant, y compris sur son socket (ce qui est normalement impossible grâce au mécanismes internes de buffer de Fluentd) ; Docker, ne pouvant écrire sur le socket de logs, refuse de traiter la sortie standard et la sortie d'erreur des conteneurs ; traefik est bloquant dans son écriture de journaux et se retrouve donc inopérant.

On laisse l'infrastructure en l'état en espérérant que les traces générées par un plantage prochain offriront quelques éclairages.

Le déni de service auto-infligé

Les traces n'ont pas tardé à tomber ce dimanche, nous n'avons pu les analyser que ce matin.

-rw-r--r--   1 root  root    244M May 12 13:01 fluent.log.20190512_0.log
-rw-r--r--   1 root  root    244M May 12 21:19 fluent.log.20190512_1.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_2.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_3.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_4.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_5.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_6.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_7.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_8.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_9.log
-rw-r--r--   1 root  root    212M May 13 02:46 fluent.log.20190512_10.log
-rw-r--r--   1 root  root    244M May 13 09:36 fluent.log.20190513_0.log
-rw-r--r--   1 root  root    244M May 13 09:36 fluent.log.20190513_1.log
-rw-r--r--   1 root  root    244M May 13 09:36 fluent.log.20190513_2.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_3.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_4.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_5.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_6.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_7.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_8.log

À 22h18 dimanche, puis à 9h37 ce matin, les horaires des derniers sursauts du serveur correspondent parfaitement à une flanquée de journaux écrits par Fluentd, comme nous l'attendions ! Pour ne pas tomber dans le défaut de parsing on les analyse avec des moyens simples : grep, awk et sort font l'affaire.

D'abord on confirme que PeerTube est à l'origine du plantage dans chacun des cas. Clin d'œil à l'ami virtualab qui a dû faire la publicité de son blog tout récemment, et quelques visiteurs parcourent ses pages où une vidéo PeerTube est intégrée, le client PeerTube générant beaucoup de requêtes pour charger la vidéo par morceaux. Il n'empêche que ces quelques 1000 requêtes par seconde consomment un petit peu de CPU sur les frontaux et PeerTube lui-même, mais ne devraient certainement pas inquiéter Fluentd, par ailleurs habitué à traiter des millions de lignes de journaux par seconde.

On se concentre donc sur les traces de Fluentd lui-même et la réponse n'est pas bien loin :

2019-05-12T20:17:13+00:00       dad34f22107c    {"container_id":"xxx","container_name":"/agents_fluentd_1","source":"stdout","log":"2019-05-12 20:17:13 +0000 [info]: #0 sending 5714975 bytes","app":"agents","service":"fluentd","tag":"agents.fluentd","instance":"joke"}
2019-05-12T20:17:14+00:00       dad34f22107c    {"container_name":"/agents_fluentd_1","source":"stdout","log":"2019-05-12 20:17:14 +0000 [warn]: #0 failed to POST http://logs.hostname:3100/api/prom/push (500 Internal Server Error rpc error: code = ResourceExhausted desc = grpc: received message larger than max (5186961 vs. 4194304)","container_id":"xxx","app":"agents","service":"fluentd","tag":"agents.fluentd","instance":"joke"}

Suivi d'une description précise des messages qui n'ont pas pu être émis :

2019-05-12T20:17:14+00:00       xxx    {"log":"2019-05-12 20:17:14 +0000 [warn]: #0 {\"streams\":[{\"labels\":\"{app=\\\"video\\\",service=\\\"peertube\\\",tag=\\\"video.peertube\\\",instance=\\\"joke\\\"}\",\"entries\":[{\"ts\":\"2019-05-12T20:17:03.644103Z\",\"line\":\"container_id=\\\"xxx\\\" container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\" log=\\\"[video.tedomum.net:443] 2019-05-12 20:17:03.643 \\u001B[32minfo\\u001B[39m: 2a01:: - - [12/May/2019:20:17:03 +0000] \\\"GET /static/webseed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32-360.mp4 HTTP/1.1\\\" 206 16384 \\\"https://video.tedomum.net/videos/embed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32\\\" \\\"Other\\\"\\\"\"},{\"ts\":\"2019-05-12T20:17:03.784652Z\",\"line\":\"container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\" log=\\\"\\\" container_id=\\\"xxx\\\"\"},{\"ts\":\"2019-05-12T20:17:03.786381Z\",\"line\":\"log=\\\"[video.tedomum.net:443] 2019-05-12 20:17:03.644 \\u001B[32minfo\\u001B[39m: 2a01:: - - [12/May/2019:20:17:03 +0000] \\\"GET /static/webseed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32-360.mp4 HTTP/1.1\\\" 206 16384 \\\"https://video.tedomum.net/videos/embed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32\\\" \\\"Other\\\"\\\" container_id=\\\"xxx\\\" container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\"\"},{\"ts\":\"2019-05-12T20:17:03.786593Z\",\"line\":\"container_id=\\\"xxx\\\" container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\" log=\\\"\\\"\"},{\"ts\":\"2019-05-12T20:17:03.786793Z\",\[... suivi de 5Mo de logs non émis]

Fluentd, non content de n'avoir pu émettre un bloc de 5Mo de journaux (qui correspondent à 10s de trafic intense sur PeerTube) comme cette taille dépasse le maximum accepté par Loki, journalise cette erreur en incluant le contenu... des journaux qui n'ont pas été émis. Vous connaissez la suite : Fluentd lui-même est journalisé par Docker, ces quelques 5Mo, gonflés par une batterie d'anti-slash d'échappement, sont rapidement réinjectés dans la boucle, et le tout dépasse à nouveau 5Mo en générant une erreur du même accabit. Effet Larsen.

Comme tout se déroule localement, les choses vont vite. Très vite. Après quelques millisecondes, les journaux internes de Fluentd ressemblent plutôt à :

log":"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\[... quelques Mo d'anti-slashs]

Au bout d'une seconde environ, Fluentd ne peut plus conserver ces journaux dans ses buffers et s'effondre en bon guerrier.

On trouve rapidement une solution et l'on patch, en limitant la taille des blocs envoyés à Loki d'une part pour ne plus générer cette erreur, mais également en configurant Fluentd pour ne passer par... Fluentd :

On avait pourtant testé !

Et c'est vrai. Certes pas pendant des mois, mais une petite semaine a vu les journaux de production de pas mal de conteneurs, dont traefik, pointer vers un Fluentd de test afin d'évaluer le bon fonctionnement. Comment se fait-il donc que le défaut n'ait pas été identifié avant un déploiement global ?

C'est que les conditions de tests ont consisté à rediriger spécifiquement chaque conteneur testé vers Fluentd, et jamais Fluentd lui-même. Egalement, les quelques heures de tests en production sur le premier serveur déployé n'ont pas été suffisantes pour déclencher le bug qui dépend grandement du trafic entrant (il est rare en temps normal de générer plus de 1Mo ou 2Mo de journaux toutes les 10 secondes).

Une bonne leçon pour ne pas oublier de tester et de qualifier en conditions au plus près de la production. Avec le recul, ce fut l'un des bugs les moins évidents à investiguer depuis qu'on administre TeDomum.

 
Read more...

from ACCEL

Arizona Centers for Comprehensive Education and Life Skills

ACCEL has provided a continuum of special needs services since 1980, now serving 450 clients each year through our three major service offerings: our BISTA Applied Behavioral Analytics (ABA) therapeutic program for early intervention, our private nonprofit school system serving students from age 5-22 and our Adult Services Program that gives adults with disabilities a place to learn and grow. We specialize in providing a safe and encouraging learning environment so individuals can maximize their potential as they lead lives of dignity and self-worth.

 
Read more...

from TeDomum

Pour protéger les données, la vie privée, et les libertés de nos utilisateurs, nous croyons en une solution par l'hébergement distribué – acentré – où ni les risques ni les pouvoirs ne sont concentrés. Aussi, TeDomum est le fruit de travaux sur ce thème débutés bien avant la déclaration de l'association. Les prémisses remontent à 2005 ; Google était surtout un moteur de recherche, Facebook n'était que l'embryon du géant que nous connaissons, l'iPhone n'existait pas et Apple était presque un acteur de niche. Pourtant déjà les vieux avaient flairé la réalité à venir. Derrière l'Internet tel qu'il avait débuté, Multimania, iFrance et quelques publicitaires élaboraient des modèles commerciaux basés sur la centralisation et l'enfermement : devenir principal hébergeur de sites Web – la principale source de contenu à l'époque – c'était s'assurer une visibilité en tant que régie, donc un revenu.

2005, c'était aussi les premiers pas de la LCEN. Le souvenir du procès Altern encore chaud, le législateur venait de déresponsabiliser largement les hébergeurs. Cela profitait évidemment aux quelques gros en devenir, mais aussi aux fournisseurs modestes proposant de publier un site Web pour pas grand chose et sans restriction à ceux qui ne disposait pas de la connexion nécessaire pour le faire chez soi. Dans le texte, un chapitre complet consacré aux prestataires techniques définit précisément le rôle et les responsabilités des intermédiaires sur l'Internet ; l'article 6 s'attaque à la position des hébergeurs de contenu, qui ne sont donc pas auteurs ou publicateurs du contenu qu'ils diffusent pourtant techniquement :

(2) Les personnes physiques ou morales qui assurent, même à titre gratuit, pour mise à disposition du public par des services de communication au public en ligne, le stockage de signaux, d'écrits, d'images, de sons ou de messages de toute nature fournis par des destinataires de ces services ne peuvent pas voir leur responsabilité civile engagée du fait des activités ou des informations stockées à la demande d'un destinataire de ces services si elles n'avaient pas effectivement connaissance de leur caractère illicite ou de faits et circonstances faisant apparaître ce caractère ou si, dès le moment où elles en ont eu cette connaissance, elles ont agi promptement pour retirer ces données ou en rendre l'accès impossible.

La voie était ouverte ; les textes, certes un peu flous mais appuyés par une jurisprudence, permettaient une plus grande latitude dans le rôle d'hébergeur. Cette latitude était balancée par l'obligation de rétention des données de connexion afin que l'auteur d'un contenu puisse être identifié et poursuivi en cas d'infraction. En particulier, les petits hébergeurs n'avaient plus à craindre de devoir contrôler tout le contenu de leurs utilisateurs : la responsabilité ne leur incombait pas tant qu'ils n'étaient pas mis au courant. Une route toute tracée vers un Internet bien acentré, le succès d'intiatives comme le RHIEN, le tout dans la neutralité et le respect des libertés individuelles, non ? Non.

Les faits sont simples : dans les années 2000, tous les passionnés et la moitié des intéressés se retroussaient les manches pour assembler une page Web, les plus aguerris administraient des services en tous genre, et l'ensemble n'était pas systématiquement hébergé chez Amen. Dans les années 2010, tous les Internautes se font guider pour créer une page Facebook et les entrepeneurs un site Wix, des services privés (et privateurs) disposent d'un monopole sur les technologies pourtant intrinsèquement ouvertes. Ce monopole s'inscrit dans la simple continuité du modèle économique d'enfermement avancé par feu-Multimania : il est nécessaire de concentrer l'audience chez quelques acteurs pour la rentabiliser en tant que régie – et nouveau marché obligeant, pour collecter et revendre un maximum de données personnelles.

Le régime plus souple a profité aux plus gros, également nourris par la nouvelle ère du commerce de la surveillance. Et c'est soudain en Europe, alors que le RGPD peine justement à responsabiliser les internautes et les fournisseurs à la protection des données personnelles, que fleurit le débat sur la « directive copyright », portant largement sur les mesures de protection du droit d'auteur sur Internet. L'objet n'est pas ici d'en commenter trop en détails le contenu, car bonne nouvelle : pour une fois, le texte est digeste, loin des 200 considérants du RGPD, le tout tien en moins de 50 pages et est disponible sur le site de l'union (la version consolidée n'est pas encore mise en forme à notre connaissance, nous mettrons le lien à jour au besoin, en attendant l'amendement 271 est disponible en PDF). Il n'est pas non plus question d'aborder la pertinence du sujet de la directive ou des moyens déployés, la Quadrature a par exemple développé le très bon argument de la soumission au marché de la surveillance de masse. Plutôt très égoïstement, nous abordons la principale nouveauté pour un acteur comme TeDomum, le fameux article 13 : contrairement à la déresponsabilisation apportée par la LCEN, l'hébergeur devient responsable sous certaines conditions et se voit attribuer une obligation de moyens pour lutter contre les infractions au droit d'auteur.

Principal moyen rendu obligatoire par le texte maintenant validé : la coopération avec les titulaires des droits pour tout ce qui concerne la mise à disposition de contenu au public. Suggérée également, la mise en place de dispositifs automatiques et systématiques pour forcer l'application des conventions que nous aurions établies en coopérant avec les titulaires. Autrement dit : petit hébergeur, nous devrions engager des moyens administratifs pour décider en accord avec les ayants droits d'une posture et d'un régime quant à la publication d'œuvres sur notre plateforme. Avant même de réflechir à mettre en place techniquement les dispositions convenues, l'idée même que nous soyons reçus pour échanger d'égal à égal avec les ayants droits est surréaliste – même en dépêchant les représentants d'un collectif de petits hébergeurs –, l'application de la directive est donc irréalisable à notre échelle.

Seulement les dernières versions du texte ont complexifié les règles, et un paquet d'analyses publiées (par exemple par Arte, ou des YouTubers) sont rassurantes quant à l'avenir des plateformes de diffusion de contenu. Il faut modérer. Ce qui a changé d'abord (pour rappel la version originale du texte, l'article 13 étant renuméroté en 17) :

  • le paragraphe 4. est découpé en trois obligations, celle d'obligation de moyens pour obtenir une autorisation des ayants droits (a priori, de tous les ayants droits), celle d'obligation de moyens pour empêcher les infractions à l'autorisation – ou en l'absence les infractions au droit d'auteur en général –, et une obligation de résultats en cas d'infraction pour oter le contenu du site ;
  • le paragraphe 5. indique que les obligations de moyens et résultats doivent être appréciées en fonction du type, de la taille et de l'audience, ainsi que des moyens de la plateforme ;
  • le paragraphe 6. crée une exception pour les entités de moins de 3 ans, moins de 10M€ de chiffre d'affaire, et une contre-expception pour le sites cumulant plus de de 5M visiteurs par an ;
  • le paragraphe 7 rappelle et confirme que les exceptions au droit d'auteur continuent de courir, en particulier concernant la citation et la caricature.

Il va sans discuter qu'une partie des précisions apportées est rassurante. Celle qui a essuyé la sueur de la plupart des critiques : le maintien de l'exception pour caricature ou critique, qui sauve le modèle des principales plateformes où bloggeurs et chroniqueurs postent leurs productions. Sauvés pour autant ? pas encore. Les précisions protègent :

  • les principales plateformes qui appliquent déjà des filtres automatiques et disposent d'une armée d'avocats, mais ne peuvent se permettre de perdre l'auditoire des chroniqueurs vidéos qui commentent sur – insérer au choix sorties cinéma, séries, livres, jeux, etc. ;
  • les startups qui chercheraient à les concurrencer mais ne seraient pas immédiatement rentables ou populaires ;
  • les plateformes touchant à l'éduction et l'enseignement, bien que pas explicitement inquiétées.

Ce qui nous tire a priori de l'embaras tient plutôt dans les modifications de l'article 2 portant définitions pour le texte et dans l'ajout du considérant 62.

(62) Certains services de la société de l’information sont, dans le cadre de leur utilisation normale, conçus pour donner au public l’accès aux contenus ou autres objets protégés par le droit d’auteur que leurs utilisateurs téléversés. La définition de fournisseur de services de partage de contenus en ligne prévue par la présente directive ne devrait cibler que les services en ligne qui jouent un rôle important sur le marché des contenus en ligne en étant en concurrence pour les mêmes publics avec d’autres services de contenus en ligne, comme les services de diffusion audio et vidéo en flux continu. Les services couverts par la présente directive sont les services dont l’objectif principal ou l’un des objectifs principaux est de stocker et de permettre aux utilisateurs de téléverser et de partager une quantité importante de contenus protégés par le droit d'auteur en vue d’en tirer un profit, directement ou indirectement, en organisant et en promouvant ces contenus afin d’attirer un public plus large, y compris en les classant et en faisant une promotion ciblée parmi ceux-ci. Ces services ne devraient pas inclure les services qui ont un objectif principal autre que celui de permettre aux utilisateurs de téléverseret de partager une grande quantité de contenus protégés par le droit d’auteur en vue de tirer profit de cette activité.

[...]

Article 2 – 5. « fournisseur de services de partage de contenus en ligne », le fournisseur d’un service de la société de l’information dont l’objectif principal ou l’un des objectifs principaux est de stocker et de donner au public l’accès à une quantité importante d’œuvres protégées par le droit d’auteur ou d’autres objets protégés qui ont été téléversés par ses utilisateurs, qu’il organise et promeut à des fins lucratives.

S'il semble à première lecture que nous ne cochions pas la case de la fin lucrative, une partie de nos services répond sans conteste au reste de la définition. La subtilité est illustrée dans la Directive par les encyclopédies en ligne ou les plateformes de partage de code, mais rien ne fait référence aux outils de l'expression libre que nous contribuons à mettre en place, tels que Mastodon, PeerTube ou Pixelfed ; c'est probablement que le cas des hébergeurs de notre taille n'était pas à l'esprit du groupe de travail qui a rédigé l'amendement. Vu la délicate question de la modération sur le Fédiverse, la position des lobbies et d'une partie de la classe politique française sur le droit d'auteur, nous craignons évidemment que la nuance soit effacée dans la traduction en droit national et que malgré l'exception pour Wikipedia et autres encyclopédies, les petits hébergeurs deviennent vulnérables légalement, annulant les dispositions protectrices de 2004.

L'idée était séduisante que d'attaquer légalement les monopoles de la diffusion de contenu sur Internet. Après tout, c'est à cela que tient aujourd'hui notre liberté d'expression. Mais en les attaquant pour de mauvaises raisons (satisfaire financièrement les quelques bénéficiaires du droit d'auteur, et non protéger les créateurs ou la liberté d'expression – tirer profit des monopoles plutôt que de limiter leur pouvoir) et avec de mauvais outils (en contraignant tout le monde – y compris la concurrence – plutôt qu'en favorisant des alternatives), le résultat nous effraie en tant que petit hébergeur. Enfin, même si elle nous concerne peu, la Directive crée de la complexité. Le démêlement du corpus légal qui entoure l'activité d'hébergement, où le régime général de responsabilité limité de 2004 cède progressivement la place à des régimes spécifiques – sur le droit d'auteur ici, la lutte anti-terroriste là- rend l'aventure plus difficile et plus risquée pour les acteurs de la décentralisation.

Plus délicat encore, si la directive copyright traite exclusivement du droit d'auteur, la question de la responsabilité quant à la mise à disposition du public de contenus illicites en général promet un débat d'autant plus guidé par l'émotion que seront abordés les cas de l'incitation à la haine, de l'apologie du terrorisme, ou de la pédo-pornographie. Mais restons positifs, car indépendamment de l'hypothétique législation que nous ne pourrions de toute façon pas appliquer, chaque nouvel utilisateur de nos services et chaque nouvel hébergeur que nous inspirons ou aidons est un progrès concret vers plus de sécurité, de libertés, et un meilleur respect de la vie privée.

 
Read more...