Pourquoi un compte de secours ?

Le nouveau réseau social Mastodon offre grâce à sa nature décentralisée une bonne résistance contre les attaques ou problèmes survenant sur le réseau d’ordinateurs qui le constitue.

Ces ordinateurs, qu’on appelle individuellement des instances dans le vocabulaire de Mastodon, peuvent avoir un problème technique, temporaire ou définitif, un problème légal ou subir des attaques les affectant encore une fois temporairement ou définitivement.

Votre compte utilisateur est hébergé sur l’un de ces ordinateurs. Cela signifie que si cet ordinateur disparaît, votre compte disparaît. Heureusement, la nature fédérée de Mastodon vous permet de créer un compte avec à peu près le même nom sur une autre instance et de recommencer à vous exprimer rapidement.

Mais créer un compte sur une nouvelle instance de Mastodon va vous faire repartir de zéro en terme d’abonnés à votre compte. Vous allez donc vous sentir seul si vous aviez un grand nombre d’abonnés et mettre des jours, des semaines voire des mois à rassembler votre audience. Cela peut être un drame dans certains cas, si vous avez apporté un soin apportant à faire grandir ce nombre.

Comment éviter de tout recommencer ?

Mettre en place votre compte de secours avant l’incident apparaît comme la meilleure protection possible. La mise en place de ce compte de secours va suivre les différentes étapes décrites ci-dessous.

1. Créer votre compte de secours sur une autre instance

Cela va consister à vous connecter à une autre instance afin de créer un nouveau compte. Si par exemple vous possédez un compte sur l’instance principale mastodon.social, vous pouvez créer votre compte de secours sur l’instance de Framasoft framapiaf.org (merci à eux !). Il ne s’agit ici que d’un exemple, vous pouvez choisir l’instance de votre choix et pourquoi pas votre propre instance. C’est ce que j’ai fait dans mon cas.

2. Indiquer dans le nom de votre compte de secours qu’il s’agit de votre compte de secours

Cette étape ne revêt aucun caractère obligatoire, mais elle va permettre de bien distinguer les deux comptes. Cela se fait simplement depuis l’interface de Mastodon pour votre compte de secours.

3. Sauvegarder la liste de vos abonnements

Il n’est pas possible simplement d’importer puis d’exporter la liste des personnes qui vous suivent. Il faudra les prévenir grâce à des messages publiés via votre compte principal Mastodon. Par contre, vous pouvez déjà importer sur votre compte de secours la liste des comptes auxquels vous vous êtes abonné de vous-même. Pour cela, vous allez dans un premier temps exporter dans un fichier la liste de ces comptes depuis votre compte principal.

Le fichier généré s’appelera par défaut following_accounts.csv.

Et dans un second temps l’importer via la même interface depuis votre compte de secours avec le fichier following_accounts.csv créé précédemment.

N’oubliez pas de cocher le bouton radio Following list. Attendez vous à immédiatement recevoir des abonnements à votre compte de secours, car sans aucun doute un nombre important des personnes auxquelles vous êtes abonné vont comprendre l’objet de votre demande et immédiatement ajouter votre compte de secours.

4. Annoncer votre compte de secours depuis le compte principal

Enfin, il s’agit de faire connaître à toutes les personnes qui se sont abonnées à vous votre compte de secours. Cela va passer tout d’abord par une annonce sur votre compte principal, par exemple comme celle-ci :

Voilà, nous arrivons au bout de la séquence complète pour l’établissement d’un compte Mastodon de secours. Ce dernier sera désormais prêt à prendre la relève du premier si ce dernier venait à disparaître.

Après la création de votre compte de secours

Vous avez maintenant deux comptes Mastodon. Bien que l’essentiel soit fait pour vous assurer de pouvoir vous retourner en cas de problème sur le premier, deux étapes que je qualifie de « maintenance » sont à effectuer régulièrement :

1. Rappeler à vos abonnés l’existence du compte

Vous aurez sûrement remarqué une différence importante entre le nombre d’abonnés de votre compte principal et celui de votre compte de secours. Cela est lié au fait que tous vos abonnés ne peuvent être prévenus de l’existence de votre compte de secours uniquement par le compte principal. Il faut donc reprendre l’étape 4 du chapitre précédent et la répéter régulièrement, selon le nombre de vos abonnés et l’importance que vous attachez à convaincre vos abonnés courants de joindre votre compte de secours.

J’ai personnellement automatisé cette tâche à l’aide du programme toot qui permet d’envoyer des pouets depuis la ligne de commande. À voir de votre côté si cette solution peut vous convenir.

2. Réimporter vos abonnements à intervalle régulier

il s’agit ici de reproduire l’étape 3 du chapitre précédent consistant à exporter la liste de vos abonnements (les personnes auxquelles vous vous êtes abonné) depuis votre compte principal, puis importer cette liste sur votre compte de secours, et cela à intervalle régulier, encore une fois selon vos besoins.

Conclusion

Comme nous l’avons vu, malgré la nature fédérée de Mastodon, vous assurer d’avoir en permanence un compte disponible pour émettre vos messages peut demander un peu de travail.

J’espère que cet article vous aura permis de bien percevoir les différentes étapes nécessaires. Avec le temps des outils permettront sans doute de simplifier ces différentes étapes. Peut-être existe-t-il déjà d’ailleurs. N’hésitez pas à m’en parler dans les commentaires ci-dessous ou via Mastodon

… et pour finir

Pour soutenir mon implication dans le Logiciel Libre et mes articles sur ce blog, n’hésitez pas à donner via ma page Liberapay, même à hauteur de quelques centimes par semaine Mes adresses Bitcoin,et Monero sont également disponibles sur cette page.

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.

Un service gratuit pour se tenir informé des dernières alertes/vulnérabilités

Avec la possibilité d’être alerté par mail en s'abonnant à tel ou tel vendeur ou produit.

https://www.saucs.com/

Original post of System Linux.Votez pour ce billet sur Planet Libre.

Au sujet de Gnu/Linux, il y a 2 écoles :
– les "user friendly" qui se basent sur un constat simple : pas le temps (compétences) de passer 3 plombes à configurer un système Gnu/Linux. Il faut du concret, du rapide, du simple et du fiable !
– les "barbus" qui au contraire, pronent le "fait main", la liberté. Disposer d’un système basique pour le construire, par étapes, et obtenir un environnement “aux p’tits oignons”, fiable et adapté… quitte à y passer quelques heures.

Aujourd’hui, ces 2 écoles semblent se retrouver dans 2 types de distributions Gnu/Linux :
– toute la sphère des Ubuntu, Mint, etc. adaptées au "commun des mortels". L’installation de ce type de distribution se fait en général en "2 clics de souris…" et permet d’obtenir rapidement un système complet (très complet …) qui peut avoir des ressemblances flagrantes avec Windows.
– et puis les distributions qualifiées de "non adpatées aux débutants" qui doivent être "domptées". Outre Debian qui pourrait être à cheval sur les 2 types, actuellement ArchLinux représente la distribution la plus répendue et la "moins adaptée" aux débutants. Oui, je mets beaucoup de guillemets car tout ceci, vous allez me dire, est très subjectif...
La phase d’installation représente un handicap, pour certains, à surmonter, pour pouvoir ensuite construire son système par touches successives (réseau, environnement graphique, applications diverses, ...).

Inconvenients ? Du temps à passer devant sa machine, des recherches préalables, un investissement personnel, des connaissances plus pointues (partitionnement, système de boot EFI, locales, configuration du serveur graphique, etc.)
Avantages ? Un système vraiment adapté à ses besoins, dépouvu de fioritures, maîtrisé et théoriquement fiable. En fait une liberté quasi totale, de l’environnement de bureau en passant par les applications les plus courantes, etc.

Et si une distribution pouvait allier les avantages de stabilité et de liberté qu’offre Arch Linux sans toutefois imposer à l’utilisateur d’être un expert et d’avoir à préparer à l'avance l’installation du système (comment installer ArchLinux sans le wiki ... ou un bon tuto ?)

Ce type de distributions existe : Manjaro, Antergos, etc. Les nombreux utilisateurs d’Arch Linux y trouveront-ils un intérêt ? (moins de temps passé à configurer ? Rapidité ? simplicité ?).
En effet, Manjaro par exemple, permet d’installer en quelques clics une base d’Arch Linux assaisonnée de diverses "améliorations" prêtes-à-l’emploi. Et d’ainsi pouvoir bénéficier d’un système fiable, puissant et communautaire comme l’est Arch Linux.

Ce qui signifierait qu’Ubuntu et autres dérivés ne sont pas fiables ou communautaires ? Communautaires OUI, très certainement. Fiable : tout est relatif ... et encore une fois subjectif lorsqu’on aborde de type de discussion technique. Surtout lorsque notre cher R. Stallman fait passer le message dès 2012 : “N’utilisez plus Ubuntu, c’est mal ! Dans Ubuntu, il y a des spyware !” (http://www.fsf.org/blogs/rms/ubuntu-spyware-what-to-do, http://www.framablog.org/index.php/post/2012/12/08/stallman-ubuntu-espion)

Toujours est-il que cette réflexion, je l’ai eu il y a maintenant quelques temps... Pour moi, il était évident que, après plus de 15 ans d’utilisation de Gnu/Linux, l’idée d’installer Arch Linux (ce que j’ai fait !) n’était pas handicapante. Un bon tuto plus tard et l’affaire était dans le sac !
Mais en voyant poindre des distributions plus "abordables", j’ai tout de suite pesé le pour et le contre. Avoir une bonne base Arch Linux, facilement installable et configurable, c’est pour moi, bien évidemment, une excellente idée.

J’ai choisi Manjaro. Je l’utilise depuis plus de 2 ans maintenant sur mon PC portable (arch linux sur mon PC principal de bureau et Xubuntu sur mon PC N°2 ...).
La base Arch Linux avec notamment AUR à portée de main, c'est à mon goût, sans égal !

Et vous : qu'en pensez-vous ?

Original post of citizenz7.Votez pour ce billet sur Planet Libre.

Dans l’article précédent j’ai optimisé le système de gestion des commentaires Stacosys en :

• remplaçant le serveur HTTP de Flask par Sanic, un serveur HTTP Python tirant parti des capacités asynchrones de Python 3.5 et multi-processus (plusieurs workers)
• ajoutant un cache mémoire à la partie de l’API de Stacosys qui récupère le compteur de commentaires d’un article

J’ai terminé sur une performance bien améliorée :

• plus de 11000 requêtes traitées en 1 minute
• un temps de requête moyen de 1,3 seconde
• une répartition du temps de traitement entre 81 ms et 18 secondes (assez élevé)
• 171 des requêtes (soit 1,5 %) avec un temps de traitement supérieur à 10 secondes

L’architecture avec Sanic ressemble à ceci :

Pour être complet le serveur HTTPS NginX en frontal de Stacosys est configuré avec 4 workers et il déverse les requêtes sur Sanic configuré avec 2 workers, qui lui seul utilise 30% de la CPU lors du test. L’impact sur la CPU est important et doit être mis en balance avec le gain en performance car d’autres services tournent sur le même serveur.

NginX est un serveur Web très complet et il y a des configurations avancées de mise en cache qui, d’après sa documentation, pourraient s’appliquer à mon scénario : un serveur HTTP en mode Proxy qui renvoie au format JSON les résultats d’une API. Si c’est le cas, cela rendrait caduque la nécessité d’ajouter un cache au niveau du serveur HTTP de Stacosys. J’ai fait quelques essais et je ne suis pas arrivé à un résultat fonctionnel. Si vous avez des retours d’expérience, j’aurais voulu mesurer les performances de cette solution. Logiquement, elle devrait l’emporter sur les autres.

Je cherchais depuis un petit moment une occasion excuse pour écrire un peu de Golang. Un test HTTP (hors contexte) de Golang m’a convaincu que je pourrais m’en servir. Le langage Golang a la particularité d’être compilé, typé, multi-plateforme et il fournit en standard des fonctionalités de haut niveau comme HTTP (client et serveur), de la crypto et de la compression, le support du JSON. Le débat reste ouvert sur le fait que Golang soit un langage orienté objet. En tout cas, il propose un paradigme de programmation simple et une richesse de librairies qui le rendent très intéressant pour du développement généraliste où la performance compte.

J’ai donc restauré Stacosys en situation initiale (retour au serveur HTTP de Flask) et j’ai ajouté un serveur HTTP avec cache en Golang qui sert de proxy à NginX pour récupérer le compteur de commentaires. Les autres appels à l’API de Stacosys sont envoyés directement à Stacosys.

L’architecture devient ainsi :

Dans cette configuration, j’ai relancé mon fameux test étalon. On éclate tout avec + de 14000 requêtes traitées, un taux d’erreur équivalent mais surtout un temps de réponse moyen divisé par 4 et une charge CPU d’à peine 7%. Le serveur HTTP est mono-processus mais il utilise à fond les capacitéss des goroutines de Golang pour gérer la concurrence de traitement.

Pour les fans de code, voici celui du serveur HTTP avec cache :

 1     package main
 2 
 3     import (
 4       "encoding/json"
 5       "flag"
 6       "fmt"
 7       "github.com/patrickmn/go-cache"
 8       "io/ioutil"
 9       "net/http"
10       "os"
11       "time"
12     )
13 
14     // ConfigType represents config info
15     type ConfigType struct {
16       HostPort   string
17       Stacosys   string
18       CorsOrigin string
19     }
20 
21     var config ConfigType
22     var countCache = cache.New(5*time.Minute, 10*time.Minute)
23 
24     func die(format string, v ...interface{}) {
25       fmt.Fprintln(os.Stderr, fmt.Sprintf(format, v...))
26       os.Exit(1)
27     }
28 
29     func commentsCount(w http.ResponseWriter, r *http.Request) {
30 
31       // only GET method is supported
32       if r.Method != "GET" {
33         http.NotFound(w, r)
34         return
35       }
36 
37       // set header
38       w.Header().Add("Content-Type", "application/json")
39       w.Header().Add("Access-Control-Allow-Origin", config.CorsOrigin)
40 
41       // get cached value
42       cachedBody, found := countCache.Get(r.URL.String())
43       if found {
44         //fmt.Printf("return cached value")
45         w.Write([]byte(cachedBody.(string)))
46         return
47       }
48 
49       // relay request to stacosys
50       response, err := http.Get(config.Stacosys + r.URL.String())
51       if err != nil {
52         http.NotFound(w, r)
53         return
54       }
55       defer response.Body.Close()
56       body, err := ioutil.ReadAll(response.Body)
57       if err != nil {
58         http.NotFound(w, r)
59         return
60       }
61 
62       // cache body and return response
63       countCache.Set(r.URL.String(), string(body), cache.DefaultExpiration)
64       w.Write(body)
65     }
66 
67     func main() {
68       pathname := flag.String("config", "", "config pathname")
69       flag.Parse()
70       if *pathname == "" {
71         die("%s --config ", os.Args[0])
72       }
73       // read config File
74       file, e := ioutil.ReadFile(*pathname)
75       if e != nil {
76         die("File error: %v", e)
77       }
78       json.Unmarshal(file, &config)
79       fmt.Printf("config: %s\\n", string(file))
80 
81       http.HandleFunc("/comments/count", commentsCount)
82       http.ListenAndServe(config.HostPort, nil)
83     }

La démonstration ne vise pas à conclure qu’il faut tout réécrire en Golang car Python est trop lent !

Hier, je lisais un article à propos de Discord, une application concurrente de Teamspeak avec de la VoIP, des gros besoins de concurrence de traitement (5 millions de messages échangés en permanence), du Web et de l’application mobile. Leur solution mixe 4 langages différents : Python, NodeJS, Golang et Elixir (Erlang) ; chacun a son rôle et son champ d’application dédié. Plus on acquiert une culture large de l’informatique et plus on sera capable de choisir le bon langage / paradigme de programmation / framework en fonction de la tâche à accomplir, ce qui rejoint ce dicton anglo-saxon que j’aime bien même s’il est un peu galvaudé : if all you have is a hammer, everything looks like a nail.

Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.

Dans l’article précédent j’ai optimisé le système de gestion des commentaires Stacosys en :

• remplaçant le serveur HTTP de Flask par Sanic, un serveur HTTP Python tirant parti des capacités asynchrones de Python 3.5 et multi-processus (plusieurs workers)
• ajoutant un cache mémoire à la partie de l’API de Stacosys qui récupère le compteur de commentaires d’un article

J’ai terminé sur une performance bien améliorée :

• plus de 11000 requêtes traitées en 1 minute
• un temps de requête moyen de 1,3 seconde
• une répartition du temps de traitement entre 81 ms et 18 secondes (assez élevé)
• 171 des requêtes (soit 1,5 %) avec un temps de traitement supérieur à 10 secondes

L’architecture avec Sanic ressemble à ceci :

Pour être complet le serveur HTTPS NginX en frontal de Stacosys est configuré avec 4 workers et il déverse les requêtes sur Sanic configuré avec 2 workers, qui lui seul utilise 30% de la CPU lors du test. L’impact sur la CPU est important et doit être mis en balance avec le gain en performance car d’autres services tournent sur le même serveur.

NginX est un serveur Web très complet et il y a des configurations avancées de mise en cache qui, d’après sa documentation, pourraient s’appliquer à mon scénario : un serveur HTTP en mode Proxy qui renvoie au format JSON les résultats d’une API. Si c’est le cas, cela rendrait caduque la nécessité d’ajouter un cache au niveau du serveur HTTP de Stacosys. J’ai fait quelques essais et je ne suis pas arrivé à un résultat fonctionnel. Si vous avez des retours d’expérience, j’aurais voulu mesurer les performances de cette solution. Logiquement, elle devrait l’emporter sur les autres.

Je cherchais depuis un petit moment une occasion excuse pour écrire un peu de Golang. Un test HTTP (hors contexte) de Golang m’a convaincu que je pourrais m’en servir. Le langage Golang a la particularité d’être compilé, typé, multi-plateforme et il fournit en standard des fonctionalités de haut niveau comme HTTP (client et serveur), de la crypto et de la compression, le support du JSON. Le débat reste ouvert sur le fait que Golang soit un langage orienté objet. En tout cas, il propose un paradigme de programmation simple et une richesse de librairies qui le rendent très intéressant pour du développement généraliste où la performance compte.

J’ai donc restauré Stacosys en situation initiale (retour au serveur HTTP de Flask) et j’ai ajouté un serveur HTTP avec cache en Golang qui sert de proxy à NginX pour récupérer le compteur de commentaires. Les autres appels à l’API de Stacosys sont envoyés directement à Stacosys.

L’architecture devient ainsi :

Dans cette configuration, j’ai relancé mon fameux test étalon. On éclate tout avec + de 14000 requêtes traitées, un taux d’erreur équivalent mais surtout un temps de réponse moyen divisé par 4 et une charge CPU d’à peine 7%. Le serveur HTTP est mono-processus mais il utilise à fond les capacitéss des goroutines de Golang pour gérer la concurrence de traitement.

Pour les fans de code, voici celui du serveur HTTP avec cache :

 1     package main
 2 
 3     import (
 4       "encoding/json"
 5       "flag"
 6       "fmt"
 7       "github.com/patrickmn/go-cache"
 8       "io/ioutil"
 9       "net/http"
10       "os"
11       "time"
12     )
13 
14     // ConfigType represents config info
15     type ConfigType struct {
16       HostPort   string
17       Stacosys   string
18       CorsOrigin string
19     }
20 
21     var config ConfigType
22     var countCache = cache.New(5*time.Minute, 10*time.Minute)
23 
24     func die(format string, v ...interface{}) {
25       fmt.Fprintln(os.Stderr, fmt.Sprintf(format, v...))
26       os.Exit(1)
27     }
28 
29     func commentsCount(w http.ResponseWriter, r *http.Request) {
30 
31       // only GET method is supported
32       if r.Method != "GET" {
33         http.NotFound(w, r)
34         return
35       }
36 
37       // set header
38       w.Header().Add("Content-Type", "application/json")
39       w.Header().Add("Access-Control-Allow-Origin", config.CorsOrigin)
40 
41       // get cached value
42       cachedBody, found := countCache.Get(r.URL.String())
43       if found {
44         //fmt.Printf("return cached value")
45         w.Write([]byte(cachedBody.(string)))
46         return
47       }
48 
49       // relay request to stacosys
50       response, err := http.Get(config.Stacosys + r.URL.String())
51       if err != nil {
52         http.NotFound(w, r)
53         return
54       }
55       defer response.Body.Close()
56       body, err := ioutil.ReadAll(response.Body)
57       if err != nil {
58         http.NotFound(w, r)
59         return
60       }
61 
62       // cache body and return response
63       countCache.Set(r.URL.String(), string(body), cache.DefaultExpiration)
64       w.Write(body)
65     }
66 
67     func main() {
68       pathname := flag.String("config", "", "config pathname")
69       flag.Parse()
70       if *pathname == "" {
71         die("%s --config ", os.Args[0])
72       }
73       // read config File
74       file, e := ioutil.ReadFile(*pathname)
75       if e != nil {
76         die("File error: %v", e)
77       }
78       json.Unmarshal(file, &config)
79       fmt.Printf("config: %s\\n", string(file))
80 
81       http.HandleFunc("/comments/count", commentsCount)
82       http.ListenAndServe(config.HostPort, nil)
83     }

La démonstration ne vise pas à conclure qu’il faut tout réécrire en Golang car Python est trop lent !

Hier, je lisais un article à propos de Discord, une application concurrente de Teamspeak avec de la VoIP, des gros besoins de concurrence de traitement (5 millions de messages échangés en permanence), du Web et de l’application mobile. Leur solution mixe 4 langages différents : Python, NodeJS, Golang et Elixir (Erlang) ; chacun a son rôle et son champ d’application dédié. Plus on acquiert une culture large de l’informatique et plus on sera capable de choisir le bon langage / paradigme de programmation / framework en fonction de la tâche à accomplir, ce qui rejoint ce dicton anglo-saxon que j’aime bien même s’il est un peu galvaudé : if all you have is a hammer, everything looks like a nail.

Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.