Planète auto-hébergement

2016-04-27

Senya répond à mes questions après le succès de sa campagne de financement participatif





J'ai honte. Cela fait un mois que Senya m'a fait le plaisir de répondre à mes questions et c'est seulement maintenant que j'en sors la traduction. J’espère que vous apprécierez autant que moi les réponses à ces quelques bafouilles. Le texte orignal en anglais est disponible par ici (en).
La campagne ayant commencé, vous pouvez suivre son aventure via ce tag.

Commençons par une présentation classique. Est-ce que tu peux nous en dire un peu plus sur toi ?

Je m'appelle Senya et je suis un développeur de logiciels russe. Je fais aussi de l’activisme en aidant les utilisateurs de logiciels libres autour de moi tout en en faisant la promotion. J’ai 25 ans. J’ai commencé à coder à 14 ans et j’ai dégoté mon premier travail en tant que développeur junior à 17 ans. Il y a un an, j’ai quitté le développement commercial pour me dédier, ou du moins essayer de me dédier, au logiciel libre.

Comment as-tu entendu parler du projet diaspora* ?

Si je ne me trompe pas, j’ai tout d’abord entendu parler du projet dans un magazine en ligne dont je ne me souviens plus du nom. C’était un test d’alternatives open sources de réseaux sociaux. Plus tard, j’ai commencé par réfléchir aux moyens de diminuer ma dépendance à vk.com, le réseau social « national » russe qui s’impose dans l’ancien bloc soviétique. Je voulais pouvoir partager et m’informer sans ce vk.com, à l’aide d’une plate-forme libre.
Je me suis alors souvenu du projet diaspora* que j’ai réessayé. Il comble mes besoins : il m’apporte un flux de nouvelles exportable en ATOM.

Es-tu un utilisateur actif de diaspora* utilisant le pod d’un podmin ou es-tu un poweruser gérant toi même ton propre pod ?

Non, je n’ai pas mon propre pod. J’utilise socializer.cc (Merci Nico Suhl !). J’étais d’abord un utilisateur et c’est plus tard que je suis devenu un contributeur. Je continue encore à me servir du même compte. Je n’envisage pas de mettre en place un pod à moi pour le moment.

Diaspora* est assez connu en Allemagne et en France. Le projet a commencé aux USA. Quel est son état en Russie ?

En fait, il n’est pas très connu. La communauté russe de diaspora* est plutôt petite. Malgré ça, il existe tout de même le pod russiandiaspora.org et quelques autres. A vue de nez, il n’y a pas plus 200 utilisateurs actifs par mois. De temps en temps, je rencontre des gens qui connaissent le projet parce qu’il est connu (mais pas populaire). Ceci-dit, je ne connais physiquement quasi personne de mon flux.

Tu t’es lancé dans une campagne de crowdfunding pour bosser à temps plein sur ce projet. Comment t’es venue cette idée ?

D’une certaine façon, c’est pour moi une preuve de concept pour voir si je peux travailler en tant que développeur payé sur un projet qui n’est pas d’essence commercial. Depuis mes débuts, je suis un défenseur des logiciels libres. Aujourd’hui, les logiciels libres sont largement utilisés par des entreprises commerciales pour différents buts. Mais, au final, ça aide les patrons à gagner de l’argent. Aujourd’hui, nous avons des systèmes d’exploitation libres bien foutus mais ils sortent la tête de l’eau principalement via l’intérêt qu’a le secteur commercial dans son développement. J’aime l’idée d’une communauté d’utilisateurs qui embauche un développeur pour améliorer les outils dont elle a besoin. Ainsi, c’est un mouvement qui vient de la base et c’est super ! La technologie s’améliore sans les fonds ni l’intermédiaire de quelqu’un de riche qui influerait sur son développement à son profit, bien plus que pour l’intérêt général, la justice sociale et un monde en paix.

Quels sont tes objectifs ? Tu penses que ce projet aura un bel avenir ou va-t-il rester un réseau social de geeks ?

Tout de suite, mon principal objectif est de faire mon travail le plus rapidement et le mieux possible. J’ai reçu un soutien financier, la communauté m’a supporté et a confiance en moi : c’est à mon tour de faire de mon mieux.
Je crois que diaspora* et le principe de la fédération ont un grand futur. Depuis des dizaines d’années, Linux et l’Open Source ont été en quelque sorte marginaux mais maintenant, Microsoft s’y met. L’astuce pourrait marcher une fois de plus. L’Open Source donne les moyens d’adapter le logiciel à ses propres besoins. J’ai contacté un groupe de personnes qui ont travaillé en tant qu’aide technique pendant la manifestation des conducteurs de camions en Russie. On m’avait dit qu’ils avaient à l’esprit de faire un réseau social pour les conducteurs dans lequel ils pourraient avoir confiance. Ils sont prêts à se baser sur de l’existant plutôt que de tout refaire depuis le début.
Aussi, diaspora* apparaît dans quelques niches : le réseau social pour geek/nerds, comme tu dis. Il comble les besoins en matière de respect de la vie privée, d’informations technologiques et de discussions. C'est aussi une zone de partage pour gauchistes. Diaspora* attire les gens à l’état d’esprit idéaliste. En partant de ces niches, la fédération pourrait atteindre le moment où elle commencerait à atteindre un public plus large mais ça n’arrivera pas sans amélioration du logiciel et c’est là que je veux aider.

Je pense aussi que le futur d’un web fédéré doit reposer sur une diversité de logiciels. C’est aussi pourquoi nous devrions nous orienter vers la standardisation des protocoles propulsés par l’open source. Les outils de médias/réseaux sociaux peuvent bien être implémentés d’une douzaine de façons différentes mais s’ils se servent du même protocole, leurs utilisateurs pourront communiquer les uns avec les autres malgré leurs désaccords « idéologiques ».

Un exemple, pour le moment théorique, serait l’implémentation du logiciel des pods qui n’utiliserait pas du tout de JavaScript, ce qui est logique puisqu’il est difficile de contrôler ce qui est exécuté sur son ordinateur quand le JS est activé. A cause de lui, actuellement, nos ordinateurs dépensent une quantité considérable de ressources pour nous afficher de la publicité. La fédération pourrait aider un groupe de personnes avec ce genre de point de vue à rester en contact avec ceux qui ne le partagent pas. Plus globalement, la fédération pourrait délier le contenu des échanges via réseaux sociaux des outils qu’il faut utiliser. Et c’est franchement génial.

Tu commences une période de trois mois de travail à temps plein. A la fin, tu envisages de recommencer à travailler pour le projet ?

On verra bien. Ça dépend du résultat de ce projet. Le retour de la communauté et de l’équipe de développeurs est important pour moi.


Merci encore pour tes réponses Senya !

<style type="text/css">p { margin-bottom: 0.25cm; line-height: 120%; }</style>
<noscript></noscript>

Senya answers my questions about the successful diaspora*'s crowdfunding campaign




Everything is already said in my post's title. Senya pleased me answering my questions about him. He luckily has won the right to be paid to work on our lovely social network's improvements thanks to his crowdfunding campaign. Enjoy reading ! Interview available in French here.

Let start with a classic presentation. Can you tell us about who you are ?

My name is Senya and I'm a software developer from Russia. I also do some free software activism supporting free software users locally and spreading the word. I'm 25 now. I started programming at 14 and by 17 I got my first job as a junior developer. A year ago I quit the commercial development to dedicate or at least try to dedicate myself to free software participation.

How did you hear about the diaspora* project ?

If I'm not mistaken, the first time I read about diaspora* project in an online magazine which name I can't remember anymore. It was a review of alternative open source social media project. After a while I started to think about the ways to lower my dependency on vk.com which is Russian "national" social network which predominates in the ex-USSR space. I wanted to have a possibility to share and follow news without the vk.com, but rather with using some free software platform. And I remembered about the diaspora project and tryed it and it fit my purposes: it provided the news stream exportable to ATOM.

Are you an active diaspora* user using a podmin's pod or are you a "poweruser" handling your own pod ?

No, I don't handle my pod. I'm using socializer.cc (thanks, Nico Suhl!). I first became a user and only after a while a contributor, and therefore I just continue to use an account I'm used to and I don't think about my own production pod yet.

diaspora* is well known in Germany and in France. The project has started in the USA. What about in your country, Russia ?

Well, it's not well known. Russian community on diaspora* is rather small. However there is even a pod russiandiaspora.org and a couple of others in Russia. By subjective feeling it's no more than a couple of hundreds active Russian users per month. From time to time I meet people, who know about the project, because it is quite famous (but not popular). But there are almost no one on my stream who I know personally offline.

You started a crowdfunding to work fulltime on this project. How does this idea came out ?

To some extent it is a proof-of-concept for me, that I can work as a paid developer on a project which is inherently non-commercial. Since my early years I was a free software advocate. Today, the free software is widely used at commercial companies for different purposes. But finally it helps to earn money for bosses. Today we have well-developed free operating systems, but it happened mostly because of the commercial sector interest in that development. I like the idea of a community of users which hires a developer to improve the tool they need. Thus, it is entirely grassroots communication and it's awesome! The technology develops without anyone's rich and powerful funding or mediation, so there is no their influence which is usually has a purpose of profiting even more rather than social development, social justice or world peace.

What's your objectives ? Do you feel like this project has a great futur or is it going to remain a geek/nerd social network ?

Now my main objective is to finish the project as soon as possible and as well as possible. I was funded, the community gave me their support and trust, now it's my turn to do my best.

I beleive that the diaspora and the federation at whole may have a great future. For decades Linux and Open Source was thought by many as something margnial, and now Microsoft turns towards it. The trick might work once again. Open source code gives a possibility to adapt the software for your own purposes. I contacted a group of people who worked as a technical support for the truck drivers strike in Russia and I was told that they have an idea of making a social network media for truck drivers which they may trust and they are interested in basing it on some existing code base rather than making it from scratch. Also diaspora now has some well-known niches - as you said "geek/nerd social network" - it supplying users with privacy/technology news and discussions and also as a platform for some sort of leftist news sharing. Diaspora is attractive to people of the idealistic mindset. And starting with niches the federation may reach the point where it has content interesting enough to attract the general public. But that can't happen without well implemented software. And that's where I want to help.

Also, I think the future of the federated web must lay in the diversity of the software. That's what we may also reach with the standardization of protocols powered by open source - software platforms for social media may be implemented in a dozens of ways and if they all support the same exchange protocol their users will communicate with each other in spite of "ideological" disagreement. One, yet theoretical at least for now example may be the implementation of the pod software which doesn't use any JavaScript at all but still works with the federation. There are some people who don't like JavaScript, and it's fair enough because it's hard to control what is being executed on your computer when you have JavaScript enabled. Because of this, today our computers spent considerable amount of resources to show advertisement to us. The federation may help the group of people with such point of view to build a tool of their preference and stay in contact with people who don't agree with them. Generally speaking, the federation will untie the content exchange in social media of the tools we use for that. And that's also awesome.

You're starting a 3 months full-time job on diaspora* thanks to your campaign. At its end, will you try another crowdfunding to keep working on the project ?

We'll see. It depends on the results of this project. The feedback of the community and the core team is important for me.



@Seny, thanks again for your time and your answers. I can't wait to see the result of your work and to meet you at the FOSDEM 2017, who knows ?


<noscript></noscript>

2016-04-25

Anticiper les ennuis en auto-hébergement

Introduction

L'auto-hébergement permet de retrouver un certain contrôle sur ses données et c'est le gros intérêt de la démarche. Mais, l'auto-hébergement implique, et c'est le revers de la médaille, d'assumer seul plusieurs risques supplémentaires. Il est donc utile de se poser quelques questions à un moment.

Précisions

Précision importante, l'auto-hébergement dont je parle ici est typiquement celui mis en œuvre par un particulier dans un cadre privé par exemple. C'est la forme qui m'intéresse là.

Venons en à mon cas

Google, Yahoo!, ou n'importe quel autre fournisseur habituel de mail n'est pas responsable si mon serveur de mail n'est plus accessible ou si mes données sont perdues par exemple. Les ressources physiques sous mon contrôle sont sous ma responsabilité. Cela couvre à la fois les problèmes logiciels et les problèmes matériels qui pourraient intervenir.

Méthode d'analyse

Je ne passe pas vraiment par une méthode particulière mais par simplement un peu de bon sens. L'idée, c'est d'anticiper ce que je peux et d'avoir déjà des réponses à apporter lorsque je me trouverai réellement en situation. Avant de proposer des réponses, il faut se poser les bonnes questions et pour se poser les bonnes questions. Je vais donc procéder comme suit :

  • Identifier le système sur lequel je veux agir.
  • Estimer les impacts des défaillances sur ce système complet.
  • Indiquer ce qui est déjà prévu en cas de défaillance.
  • Identifier les "trous dans la raquette".
  • Identifier les actions à mener afin de combler ces faiblesses.

Vue assez fidèle de mon réseau :

note : pour ce schéma, j'ai utilisé dia et les icônes de Jean Cartier.

Estimation de l'impact des défaillances :

Chaque élément sur ce réseau peut tomber en panne. Que le problème soit d'origine logiciel ou matériel importe peu, la seule chose importante est que l'élément considéré peut ne plus fonctionner à un moment donné. Élément par élément, quels sont donc les impacts d'une panne sur le système entier ? C'est aussi l'occasion d'estimer le niveau de gravité des impacts causés par chaque panne. J'en profite donc pour classifier chaque impact avec un niveau allant de 1 (impact mineur) à 3 (impact majeur). J'ai estimé qu'il était possible de fonctionner avec un effet de niveau 1. Pour les effets de niveau 2, j'ai considéré qu'une gène était visible que ce soit à l'intérieur ou à l'extérieur de mon réseau et qu'il n'était de fait pas possible de fonctionner en l'état. Enfin, les effets de niveau 3 traduisent un risque irréversible de perte de donnée. Voyons voir :

Modem ADSL HS :
  • (2) Plus de connexion à internet possible depuis mon réseau.
  • (2) Serveur auto-hébergé n'est plus visible de l'extérieur.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (1) Téléphonie fixe non fonctionnelle.
Parefeu HS :
  • (2) Plus de connexion à internet possible depuis mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible, y compris depuis le réseau local.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
Switch 16 ports HS :
  • (2) Plus de connexion à internet possible pour le serveur auto-hébergé, le serveur NAS et les autres postes sur mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible, y compris depuis le réseau local.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
Switch 8 ports HS :
  • (2) Plus de connexion à internet possible les postes bureautique sur mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible en local.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
  • (1) Impression sur l'imprimante réseau locale impossible.
Serveur public HS :
  • (2) Services auto-hébergé non fonctionnels.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (3) Selon la panne du serveur, risque possible de perte des données stockées dessus.
Serveur NAS HS :
  • (2) Serveur NAS inaccessible en local.
  • (3) Selon la panne du NAS, risque possible de perte des données stockées dessus.
Ensemble des équipements réseau, serveur, bureautique HS :
  • Reprendre l'ensemble des points listés précédemment.

Je ne traite pas le cas d'une panne sur la box OVH car la maintenance de cet appareil n'est pas à ma charge. En cas de défaillance, le problème est à traiter par OVH.

On peut déjà voir que certains éléments sont plus critiques que d'autres mais ils ont tous ou presque la possibilité d'entrainer des pertes de données. Si je n'en avais pas conscience avant, au moins là, c'est clairement établi. A y regarder de plus près, je vois deux types de problèmes sur les données. La non récupération de données externe et la perte de données préalablement récupérées. Dans le premier cas, c'est la conséquence d'une défaillance réseau et dans le second cas, il s'agit de la défaillance du système de stockage.

Ce qui est prévu en cas de défaillance :

S'il me faut maintenant assumer la défaillance d'un équipement, comment est-ce que j'ai prévu de réagir ? Voici ma réponse élément par élément :

Modem ADSL :
  • J'ai un modem équivalent de rechange.
Parefeu :
  • Aie ! Pas de machine de remplacement.
  • Configuration sauvegardée.
Switch 16 ports :
  • Aie ! Pas de switch manageable de remplacement.
  • Configuration sauvegardée.
Switch 8 ports :
  • Aie ! Pas de switch manageable de remplacement.
  • Configuration sauvegardée.
Serveur public :
  • Aie ! Pas de machine identique de remplacement.
  • Sauvegarde journalière des données importantes sur DD USB externe
  • Sauvegarde journalière des données importantes sur le NAS
Serveur NAS :
  • Aie ! Pas de machine identique de remplacement.
  • NAS deux baies en RAID 1. Réduction du risque de perte des données.
  • Les données les plus importantes stockées sur le NAS sont aussi sauvegardées sur une machine bureautique.
Ensemble des équipements réseau, serveur, bureautique HS :
  • Aie ! Pas de solution de remplacent de matériel.
  • Perte de toutes mes données.

Comme on peut le voir, je ne dispose pratiquement pas d'équipements "sur étagère" afin d'intervenir immédiatement en cas de défaillance, ceci afin de repartir sur une configuration strictement identique. Ça ne veut pas dire que je suis bloqué mais ça demande quelques aménagements.

Mon réseau actuel n'est que l'évolution d'un réseau à plat. Si mon parefeu ou l'un de mes switchs manageable venait à dysfonctionner, j'ai la possibilité de basculer rapidement vers une architecture réseau plus simple. Je dispose d'un switch de secours et mon modem ADSL étant un modem/routeur en mode bridge, je n'ai qu'à en modifier la configuration si besoin pour le repasser en routeur. Reste ensuite simplement à revoir l'adressage IP. Ces manipulations ne sont pas longues à réaliser et me permettent de passer facilement dans un mode dégradé.

Les données importantes sur le NAS ou le serveur public sont aussi stockées ailleurs.

Globalement donc, je sais quoi faire si un élément de mon réseau tombe et mes données sont protégées contre une défaillance isolée de matériel.

Les trous dans la raquette :

Bien que le NAS soit en mesure d'assurer mon hébergement web et mail, tout comme il est possible au serveur public d'assurer le stockage des données actuellement sur le NAS, je préfère si possible éviter de rassembler l'ensemble de ces usages sur une même machine. Une défaillance du NAS n'est pas dramatique mais une défaillance du serveur public l'est plus dans la mesure où je ne peux m'en passer et parce que je ne dispose pas de solution à déployer rapidement s'il venait à me lâcher.

Le problème le plus important pourrait se produire en cas d'incendie ou de vol de matériel. Je ne dispose pas aujourd'hui de moyen de repartir même en mode fortement dégradé après ce type de problème. Pire, je perds toutes mes données puisque je ne dispose que de sauvegardes locales.

Actions à mener afin de combler ces faiblesses :

Je vais prévoir assez rapidement une machine supplémentaire que je serai en mesure de configurer rapidement en cas de défaillance de mon serveur public ou de mon parefeu.

Je vais prévoir de placer une sauvegarde récente de mes données sur un autre lieu, de sorte que les pertes de données soient minimes même en cas de problème grave.

Dernier point, je vais aussi réfléchir à une solution permettant de poursuivre mon activité ailleurs en cas de problème grave chez moi.

Conclusion

Tant que ça marche, on ne se pose pas de question mais dès que ça ne marche plus, il peut être trop tard pour chercher des réponses. Cette petite analyse me montre quels sont les points à travailler sur mon installation. Chaque installation auto-hébergée est différente mais je pense qu'elles méritent toutes une petite réflexion de ce type.

2016-04-24

Chiffrement du filesystem en auto-hébergement

J’ai investigué quelques solutions pour chiffrer le filesystem de mes serveurs auto-hébergés. En prenant notamment en compte leurs contraintes particulières : pas d’accès « console » simple, faible puissance et filesystem sur carte SD.

Première solution : chiffrer entièrement le filesystem

Avec dm-crypt / cryptsetup + LUKS, comme proposé par Debian (ou Ubuntu) lors de l’installation.

Cela chiffre également la partition système. C’est clairement le plus sûr, car tout est chiffré.

Saisie de la phrase de passe à distance

Mais cela pose la contrainte de saisir la phrase de passe au démarrage. Or je peux avoir besoin de le faire à distance (après une coupure de courant par exemple). Et il s’agit de machines physiques, pour lesquelles l’accès console requiert une branchement physique dessus…

Dropbear

Heureusement, il est possible de le faire à distance, via un serveur SSH simple (Dropbear), qui se lance suffisamment tôt dans la séquence de démarrage pour être accessible lors de la demande de saisie de phrase de passe.

Source : zcat /usr/share/doc/cryptsetup/README.remote.gz

En résumé, il s’agit de :

  • installer les paquets dropbear et busybox
  • copier les clés SSH publiques des machines qui pourront s’y connecter dans /etc/initramfs-tools/root/.ssh/authorized_keys
  • puis mettre à jour le initramfs avec sudo update-initramfs -u

Ensuite on peut s’y connecter depuis l’extérieur avec un script du type :

#!/bin/bash
echo -n "Quel serveur? "
read serveur
echo -n "Quelle phrase de passe? "
read -s passphrase
ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" root@$serveur "echo -ne \"$passphrase\" >/lib/cryptsetup/passfifo"

(NB : noter l’utilisation d’un fichier known_hosts à part, pour éviter que le client SSH ne soit perturbé par le fait qu’un même serveur puisse avoir 2 clés publiques SSH différentes : une avec OpenSSH, l’autre avec Dropbear)

Petit risque de sécurité : la clé privée du serveur Dropbear est (forcément) stockée en clair sur la machine. Quelqu’un qui aurait eu accès au filesystem pourrait ainsi se faire passer pour le serveur qui aurait redémarré, et intercepter la phrase de passe.

Déchiffrement de plusieurs partitions d’un coup

La procédure décrite ci-dessus fonctionne bien s’il n’y a que la partition système à déchiffrer.

Mais, sur mes machines auto-hébergées, j’utilise fréquemment plusieurs partitions sur des devices différents (cartes SD ou microSD, clé USB, voire disque dur). Si je les chiffre et qu’elles sont montées au démarrage, le serveur demande la phrase de passe sur la console, après avoir demandé celle du filesystem principal. Donc il faut ruser un peu pour pouvoir les déchiffrer toutes d’un coup, et à distance.

Normalement, il y a un script decrypt_derived qui fait ça très bien : http://unix.stackexchange.com/questions/110081/decrypt-second-encrypted-lvm-during-headless-server-boot

… sauf qu’il ne fonctionne pas sur Debian Jessie (à cause de systemd d’après ce que j’ai compris) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862)

Bref, il y a une autre solution (clairement moins sécurisée), qui consiste à mettre dans la partition système (chiffrée) un fichier de clé qui permet de déverrouiller les autres. Évidemment, il faut protéger l’accès à ce fichier.

Création du fichier de clé (avec un contenu aléatoire) :

sudo dd if=/dev/urandom of=/etc/keyfile bs=1024 count=4
sudo chmod 0400 /etc/keyfile

Ajout de ce fichier de clé dans les clés acceptées par la partition chiffrée :

sudo cryptsetup luksAddKey /dev/mmcblk1p1 /etc/keyfile

Ajout de la partition dans /etc/crypttab avec une ligne du type :

nom_2eme_partition_chiffree UUID=uuid_de_la_partition /etc/keyfile luks

(et il faut classiquement rajouter la partition dans /etc/fstab)

Pour plus de détail : http://ubuntuforums.org/showthread.php?t=837416

Autres difficultés

Certains appareils fournissent une image Debian toute prête (et customisée) de l’OS, et on ne peut pas toujours utiliser son installeur. Notamment si l’appareil n’est pas encore complètement supporté par le noyau linux. Il est alors plus compliqué de chiffrer le filesystem root après coup. Heureusement, ce n’est pas les cas de mes machines.

Mais, dans mon cas personnel, il y a un autre petit soucis : je n’ai pas toujours accès à un client SSH :

  • soit parce que je suis derrière un proxy HTTP d’entreprise qui ne laisse pas passer le SSH (à l’occasion j’investiguerai SSLH, merci à Genma pour l’idée : http://genma.free.fr/?SSH-derriere-un-proxy-Sslh)
  • soit parce que mon téléphone (sous Firefox OS) n’a pas de client SSH

Pour toutes ces raisons, on peut avoir besoin d’une autre solution :

Deuxième solution : chiffrer uniquement une partition de données

C’est clairement moins sûr, mais peut fonctionner sur n’importe quel Linux déjà installé. Et surtout, après un redémarrage, on peut directement avoir accès aux services qui n’utilisent pas la partition chiffrée (AJaxterm, par exemple, patché comme dans un précédent article).

Si les données chiffrées sont accédées par un service lancé au démarrage (ex : MySQL), il échouera avec des messages d’erreur au démarrage. Il faut donc ensuite se connecter en SSH, monter manuellement la partition chiffrée (en saisissant sa phrase de passe), puis redémarrer les services qui ont besoin de l’être. Exemple :

sudo cryptsetup luksOpen /dev/nom_device_partition partition_chiffree
sudo mount /dev/mapper/partition_chiffree /mnt/partition_chiffree
sudo systemctl restart mysql

Sauvegardes

Faire des sauvegardes régulières est toujours indispensable, quel que soit le contexte.

Mais, en l’occurrence, quand on utilise des partitions chiffrées, il y a une sauvegarde supplémentaire à faire : les entêtes LUKS de la partition, qui peuvent être extrêmement précieuses. Si ces quelques octets sont corrompus sur le filesystem, il serait complètement impossible d’accéder aux données.

Pour sauvegarder :

sudo cryptsetup luksHeaderBackup --header-backup-file luksHeaderBackup-nom_device_partition /dev/nom_device_partition

Performances

Les machines qui hébergent mes services sont des petites machines à très faible consommation. Donc la puissance CPU a besoin d’être économisée.

L’impact du chiffrement sur les performances mérite donc d’être surveillé. Pour cela, l’accélération matérielle du chiffrement peut rendre service.

Accélération matérielle du chiffrement

  • La Sheevaplug est le matériel le plus ancien et le moins puissant. Par contre, l’accélération matérielle du chiffrement est bien supportée par le noyau linux (depuis la version 2.6.32 a priori)
  • L’Olinuxino A20 est plus puissant, mais la prise en charge du chiffrement matériel dans le noyau linux est plus récente : il faut au minimum un noyau 4.3. Cf http://sunxi.montjoie.ovh/

Mes serveurs tournent sur Debian Jessie (noyau Linux 3.16 par défaut) donc pas de problèmes pour la Sheevaplug, mais il faudrait mettre à jour le noyau sur Olinuxino A20 pour avoir l’accélération matérielle. Je préférerais éviter car ça obligerait ensuite à le mettre à jour manuellement quand il y a des failles de sécurité.

Quoi qu’il en soit, pour que l’accélération matérielle du chiffrement fonctionne, il faut à la fois que le logiciel utilisé sache l’exploiter, et qu’il utilise un algorithme supporté par le matériel. D’où l’importance de vérifier :

Performances brutes du chiffrement

Sur Sheevaplug

Avec une installation par défaut

cryptsetup benchmark sur Sheevaplug (Debian Jessie, noyau 3.16.0-4-kirkwood) :

PBKDF2-sha1        64503 iterations per second
 PBKDF2-sha256      48188 iterations per second
 PBKDF2-sha512       5665 iterations per second
 PBKDF2-ripemd160   56109 iterations per second
 PBKDF2-whirlpool    4768 iterations per second
 #  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b    20.4 MiB/s    20.9 MiB/s
 serpent-cbc   128b    10.8 MiB/s    11.8 MiB/s
 twofish-cbc   128b    12.4 MiB/s    13.3 MiB/s
     aes-cbc   256b    19.6 MiB/s    19.9 MiB/s
 serpent-cbc   256b    11.4 MiB/s    11.8 MiB/s
 twofish-cbc   256b    12.9 MiB/s    13.3 MiB/s
     aes-xts   256b    13.9 MiB/s    13.9 MiB/s
 serpent-xts   256b    11.7 MiB/s    11.8 MiB/s
 twofish-xts   256b    13.1 MiB/s    13.3 MiB/s
     aes-xts   512b    11.0 MiB/s    10.9 MiB/s
 serpent-xts   512b    11.9 MiB/s    11.8 MiB/s
 twofish-xts   512b    13.4 MiB/s    13.3 MiB/s

L’algorithme CBC est bien plus rapide que les autres sur cette machine. Certainement parce que c’est le seul de la liste qui est accéléré matériellement, ce qui semble confirmé par un cat /proc/crypto : certains algorithmes sont implémentés par un driver mv-* (mv comme Marvell, je suppose : le fabricant du microprocesseur) :

$ cat /proc/crypto | grep mv-
driver : mv-cbc-aes
driver : mv-cbc-aes
driver : mv-ecb-aes

Pas de bol : par défaut, cryptsetup utilise l’algorithme aes-xts. Donc si on installe Debian avec chiffrement, il n’est (par défaut) pas accéléré matériellement sur cet appareil…

En spécifiant l’algorithme AES-CBC

Heureusement, on peut choisir l’algorithme de chiffrement (cipher) lors de l’installation. Sauf qu’il faut pour cela faire un partitionnement complètement manuel : créer la partition chiffrée, le LVM dedans, et les deux partitions root et swap à l’intérieur. On ne peut hélas pas demander à l’installeur un partitionnement automatique, puis revenir le modifier (pour être précis : si, on peut. Mais il refuse de modifier la partition chiffrée, donc ça ne nous sert à rien en l’occurrence).

Bref, en partitionnant manuellement, on peut utiliser l’un des algorithmes aes-cbc-essiv:sha256 ou aes-cbc-plain.

Sauf qu’une faiblesse a été trouvée dans cet algorithme CBC : voir paragraphe 5.14 de https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions.

Sur Olinuxino A20

cryptsetup benchmark avec l’image Debian Jessie fournie par le fabricant (3.4.103-00033-g9a1cd03-dirty) :

PBKDF2-sha1        86231 iterations per second for 256-bit key
PBKDF2-sha256      60681 iterations per second for 256-bit key
PBKDF2-sha512      28006 iterations per second for 256-bit key
PBKDF2-ripemd160   80908 iterations per second for 256-bit key
PBKDF2-whirlpool    6869 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b    14.9 MiB/s    16.4 MiB/s
 serpent-cbc   128b    11.3 MiB/s    12.9 MiB/s
 twofish-cbc   128b    17.5 MiB/s    19.5 MiB/s
     aes-cbc   256b    12.3 MiB/s    12.8 MiB/s
 serpent-cbc   256b    11.7 MiB/s    13.0 MiB/s
 twofish-cbc   256b    17.8 MiB/s    19.5 MiB/s
     aes-xts   256b    16.1 MiB/s    16.3 MiB/s
 serpent-xts   256b    11.9 MiB/s    12.7 MiB/s
 twofish-xts   256b    18.0 MiB/s    18.5 MiB/s
     aes-xts   512b    12.3 MiB/s    11.9 MiB/s
 serpent-xts   512b    11.8 MiB/s    12.3 MiB/s
 twofish-xts   512b    18.1 MiB/s    18.6 MiB/s

/proc/crypto ne semble indiquer aucun driver matériel.

Avec le noyau de l’installeur de Jessie (3.16.0-4-armmp-lpae), les résultats sont similaires.

Avec un noyau 4.4.1 patché (cf mon autre article), on peut exploiter l’accélération matérielle :

PBKDF2-sha1        80908 iterations per second for 256-bit key
PBKDF2-sha256      57487 iterations per second for 256-bit key
PBKDF2-sha512      26425 iterations per second for 256-bit key
PBKDF2-ripemd160   76204 iterations per second for 256-bit key
PBKDF2-whirlpool    6527 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b    25.5 MiB/s    25.5 MiB/s
 serpent-cbc   128b           N/A           N/A
 twofish-cbc   128b           N/A           N/A
     aes-cbc   256b    25.4 MiB/s    25.4 MiB/s
 serpent-cbc   256b           N/A           N/A
 twofish-cbc   256b           N/A           N/A
     aes-xts   256b           N/A           N/A
 serpent-xts   256b           N/A           N/A
 twofish-xts   256b           N/A           N/A
     aes-xts   512b           N/A           N/A
 serpent-xts   512b           N/A           N/A
 twofish-xts   512b           N/A           N/A

et /proc/crypto indique bien des drivers adaptés au matériel :

$ cat /proc/crypto | grep sun4i
driver : ecb-des3-sun4i-ss
driver : cbc-des3-sun4i-ss
driver : ecb-des-sun4i-ss
driver : cbc-des-sun4i-ss
driver : ecb-aes-sun4i-ss
driver : cbc-aes-sun4i-ss
driver : sha1-sun4i-ss
driver : md5-sun4i-ss

Comme sur Sheevaplug, on peut utiliser le CBC, mais pas le XTS. Par contre, le CBC accéléré apporte sur le papier un gain de performance notable.

Hélas, je n’ai pas eu le temps d’aller au bout de la mise en œuvre de cette accélération matérielle sur Olinuxino A20 (il doit me manquer des options de compilation du noyau qui permettent l’utilisation réelle par dm-crypt). Tant pis, sur les Olinuxino A20, j’en bénéficierai avec la prochaine version de Debian.

Performances réelles

Les services que je fais tourner sur mes machines ne font que très peu d’I/O disques. Donc je n’ai pas vu de différence par rapport au filesystem non chiffré. Il est probable qu’il y ait une différence sur le temps de démarrage, mais ça n’a pas grande importance dans mon contexte (machines allumées 24h/24).

J’ai commencé quelques mesures en AES-CBC : sur Sheevaplug, j’atteins autour de 10Mo/s en écriture (mais le chiffrement consomme 80 % de CPU malgré l’accélération matérielle). Sur Olinuxino A20, 18Mo/s (sans accélération matérielle, mais il utilise 100 % des 2 coeurs du CPU).

Alors que, sans chiffrement, j’atteins 30Mo/s (en USB2, avec 30 à 40 % d’utilisation du CPU) sur les 2 appareils.

Si je trouve un peu de temps, je ferai des mesures plus complètes dans un autre article.

Conclusion dans mon cas particulier

On voit bien qu’il n’y a pas de solution universelle. Tout est affaire de compromis entre les contraintes qu’on veut accepter (dépannage à distance, complexité d’installation/administration), l’exigence de sécurité (chiffrement ou pas de tout le filesystem, avec quel algorithme), et les performances (vitesse des I/Os disque, consommation de CPU). Et cela peut dépendre de l’appareil au niveau de l’accélération matérielle du chiffrement.

Dans mon cas de figure, il me paraissait crucial de pouvoir dépanner mes serveurs à distance (après une coupure de courant, par exemple), et sans devoir passer par un client SSH. Quitte à faire des (petits) compromis sur la sécurité.

Donc j’ai chiffré tout les filesystems de mes serveurs sauf un, sur lequel tourne un nginx + ajaxterm (patché comme dans un précédent article), pour permettre de m’y logger en HTTPS (après saisie d’un login/mot de passe). Sur ce serveur, il y a plein d’autres services (Apache, notamment) dont la configuration et les données sont sur une partition chiffrée (non montée au démarrage). Donc, au démarrage, leur démarrage échoue. Ce n’est qu’après m’être loggé (via SSH ou Ajaxterm) que je déverrouille le filesystem, arrête nginx, et les relance. Et ensuite je peux déverrouiller tous les autres serveurs à travers lui, en SSH.

2016-04-22

diaspote.org passe à Tor



C'est un truc que je voulais faire depuis la lecture de cet article, publié le 4 avril dernier : permettre l’accès au pod diaspora* que j'administre avec Augier via le réseau Tor, The Onion Routeur.

Rappel rapide sur Tor, tiré de Wikipedia :

Tor est un réseau informatique superposé mondial et décentralisé. Il se compose d'un certain nombre de serveurs, dont la liste est publique, appelés nœuds du réseau, et permet d'anonymiser l'origine de connexions TCP ; entre autres, cela peut servir à anonymiser la source d'une session de navigation Web ou un utilisateur de messagerie instantanée.

Un peu de travail, mais pas trop, quelques modifications dans la configuration du serveur du pod et voilà, on peut donc maintenant profiter du réseau social diaspora* via Tor ! Pour celles et ceux qui voudraient tester, l'adresse est ici et la version de Firefox qui permet d'y aller est à télécharger ici.

En clair, une adresse Tor, c'est ça :  https://cw3ibtoml2xnwphi.onion. C'est pas super sexy, mais ce n'est pas vraiment fait pour. Vous aurez un avertissement à cause du certificat SSL : c'est normal, pas de panique.

Si on y réfléchit bien, cette situation fait rêver : se connecter à un réseau social décentralisé via mon pod, son nœud d’entrée, en passant par un système qui vous fait traverser tout un tas de nœuds Tor pour scrupuleusement respecter votre vie privée. C'est beau, vraiment.

Je ne reviens pas sur la méthode qui permet cette merveille puisque tout est très bien expliqué dans le billet que je cite plus haut. Ceci-dit, si vous avez des questions, les commentaires/messages privées sur diaspora* sont là.

Note : pas de panique, le pod est toujours joignable par son adresse classique. L’accès via tor est un plus, pas une obligation.

Je dis plus haut que ce système permet de scrupuleusement respecter votre vie privée, tout comme diaspora*. Notez quand même que c'est un réseau social et que tout ce que vous y publierez sera rattaché à votre pseudo et que votre pseudo pourrait peut-être être rattaché à votre identité IRL si vous n’êtes pas assez vigilants.

Pour terminer, n'oubliez qu'Augier et moi restons les patrons de ce point d’accès et que, même si vous êtes anonymes et que nous sommes très très tolérants, nous feront ce qu'il faut pour vous obliger à aller foutre le bordel ailleurs. On n'a pas encore eu besoin de s'exciter. Tenir ce pod est une aventure parfaite jusque là, faisons en sorte que ça continue ;-)


<noscript></noscript>

2016-04-20

Nouvelle interface web pour Proxmox 4

Une petite mise à jour mineure, pas si anodine que ça !

La dernière update du 15/04 (la 4.1.30), propose entre autre :

  • un kernel 4.4
  • et une nouvelle interface en Sencha Ext JS 6

On passe donc de ça :

Capture d’écran_2016-04-20_09-18-40

à ça :

Capture d’écran_2016-04-20_09-26-23

Une nouvelle interface playskool =)
Dans l’ensemble pas de grands changements, mais de petites améliorations qui sont parfois bien pensées.

La partie Firewall est plus claire :

Capture d’écran_2016-04-20_09-29-40

Les icones sont plus lisibles :

Capture d’écran_2016-04-20_09-30-32

Les graphs également :

Capture d’écran_2016-04-20_09-34-45

Capture d’écran_2016-04-20_09-39-46

 

Bref, dans l’ensemble c’est pas trop mal, et ça donne un coup de jeune à Proxmox.
Kernel 4.4, lxc, kvm, interface récente … Proxmox n’est pas encore mort !

Manque encore la gestion complète du Lxd 😉

Première version de B2G OS pré-alpha (ex Firefox OS pour smartphone)


Oh, une nouvelle de Firefox OS, ça faisait longtemps ! On parle ici d'une première version compilable de la version communautaire de Firefox OS dont le nouveau nom est B2G OS. On est d'accord, ce n'est pas sexy comme nom, mais absolument pas choquant si on revient au début de l'aventure chez les OS mobiles de la Fondation Mozilla. Eh oui, B2G était le nom de code de Firefox OS.

Bref, une version communautaire pour le Z3C donc, les derniers téléphones que Mozilla s’était amusée à distribuer gratuitement au contributeurs quelques semaines avant d'annoncer la mort du support pour smartphones. Joie.

Les images sont récupérables par ici ou .

Attention, ce n'est pas une version utilisable en l’état. Ce n'est que la preuve que la communauté est en marche et qu'elle s'en sort pas trop mal.

Pour les courageux qui voudraient la compiler maison, ça vous prendra quand même plusieurs heures si votre machine approche la configuration du développeur à l'origine de ce billet : un core i7 de chez Intel et 8 Go de RAM.

Sinon, moi ça va. J'attends ma tablette sous Ubuntu. Je viens de recevoir le mail annonçant que j'allais être livré, pas encore que le livreur était en route. Trois semaines que j'attends, j'avais presque oublié avec ces événements qui me font traîner dehors pour parler avec des gens IRL du monde qu'on aimerait bien un jour.

Petit rappel pour ceux qui se demanderait si je suis encore en activité ou pas : abonnez au flux Atom de mon compte diaspora*, ça vous rassurera !


<noscript></noscript>

2016-04-15

Samba serveur dans une mise à jour sécurité de Debian?

La dernière mise à jour de sécurité dans Debian 8 a eu un petit raté.

Le serveur SAMBA s’est invité comme paquet à installer alors que vous n’aviez probablement pas envie d’avoir ce serveur tourner chez vous.

Bilan, après la mise à jour, le serveur SAMBA était actif (on peut le désactiver avec la commande # systemctl stop smbd) et on ne pouvait le désinstaller sans désinstaller Gnome également…

Le problème est heureusement corrigé depuis hier (version du paquet 2:4.2.10+dfsg-0+deb8u2)

Vous pouvez réparer la bourde ainsi :

# apt-get update
# apt-get upgrade -f
# apt-get remove samba
# apt-get autoremove

Voila, je vous conseille de jeter un oeil sur vos machines Debian pour vérifier que SAMBA serveur n’est pas en train de tourner ;-)

Related Posts:

J'aime !(5)Je n'aime pas !(0)

2016-04-14

ownCloud Passwords et Firefox : retrouver le copier/coller




Avant, je me servais de Passman pour gérer mes mots de passe via ownCloud, mais ça, c’était avant, comme dirait la pub. Aujourd'hui, c'est Passwords. Il a tout un tas d'avantages que je vous laisse découvrir sur sa page. Ses deux principaux sont qu'il est encore maintenu, contrairement à l'autre, et qu'il est bien plus "visuel". Si votre mot de passe est lamentable au niveau sécurité, il vous tartinera l'écran de rouge. Agréable.

Cette application ownCloud a un comportement futé : elle permet de copier/coller le mot de passe que vous souhaitez récupérer sans pour autant l'afficher clairement. Passman le faisait aussi, normal, c'est la moindre des choses. Sauf que ce truc là ne marchait pas avec mon fantastique Firefox.
J'ai cherché, fouillé les logs, surveillé ma console pendant l’exécution du script... rien.

En fait, la solution est simple, elle réside dans une sécurité mise en place dans Firefox : la protection contre les popups, des fenêtres trop souvent remplies de conneries qui s'affichent devant nos yeux.

Du coup, pour récupérer la copier/coller de Passwords, il suffit d'ajouter l'adresse de votre instance ownCloud dans la liste blanche ! Pour ce faire, passez par le menu contenu, dans les préférences, pour débloquer la situation :



Ouais, je sais. C'est une astuce basique, mais j'ai vraiment passé beaucoup trop de temps sur ce faux bug...! Bon, il faut aussi Flash sinon ça marche pas. :-(


<noscript></noscript>

2016-04-11

Installer Gitlab CI en moins de 5 minutes avec Docker

Si comme moi vous avez une instance Gitlab qui tourne avec Docker, vous serez heureux d’apprendre, si vous ne le saviez pas que Gitlab fourni un outil de CI et que l’installation de Gitlab CI ne prend pas plus de 5 minutes, si vous utilisez des containers Docker

Bien sûr, pour installer Gitlab CI via Docker, il vous faudra une instance Gitlab (si possible à jour) et avoir Docker installé sur votre machine.

1ère minute : Installation du container

Tout d’abord, il faut créer un répertoire ou l’on va stocker la configuration des runners que l’on voudra utiliser. Ce répertoire sera monté en tant que Volume :

$> mkdir -p /data/gitlab/runner

Ensuite, on initialise le container gitlab-runner qui va s’occuper de créer les containers Docker pour le build :

$> docker run -d 
   --name gitlab-runner \
   --restart always \
   -v /var/run/docker.sock:/var/run/docker.sock \
   -v /data/gitlab-runner:/etc/gitlab-runner \
   gitlab/gitlab-runner:latest

Vous devriez avoir un nouveau container qui tourne nommé gitlab-runner en plus du container de gitlab-ce:

$> docker ps -a 
CONTAINER ID       IMAGE                         COMMAND                  CREATED             STATUS                      PORTS                                      NAMES
502c4768d70d       gitlab/gitlab-runner:latest   "/entrypoint run --us"   34 hours ago        Up 26 hours                                                            gitlab-runner
30b0ce74588f       gitlab/gitlab-ce:latest       "/assets/wrapper"        34 hours ago        Up 26 hours                 80/tcp, 443/tcp, 0.0.0.0:2777->22/tcp      gitlab

Voilà, l’installation à proprement parlé est terminée, maintenant il y juste un peu de configuration à faire pour définir un runner et configurer le projets.

2e minute : Création d’un runner

Maintenant que le container gitlab-runner est lancé, il faut créer un runner qui pourra être utilisé par les builds. Mais avant cela, il faut se rendre dans l’admin de votre installation Gitlab et récupérer un token d’enregistrement.
Ce token permettra la communication entre le runner et l’instance Giltab.

Le token s’obtient en allant dans l’administration de Gitlab puis dans la page «Runners» :

Page d'administration des runners vide

Une fois que vous avez récupérer votre token, vous pouvez créer un runner. Comme on utilise Docker, on va utiliser une commande docker pour exécuter une commande sur le container «gitlab-runner».

$> docker exec -it gitlab-runner gitlab-runner register
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci):
https://votre.domain.gitlab/ci
Please enter the gitlab-ci token for this runner:
pokPOKzceiDDaddadZvNLbzjL
Please enter the gitlab-ci description for this runner:
[f5bb1e7dbd6c]: Ruby builder
Please enter the gitlab-ci tags for this runner (comma separated):

Registering runner... succeeded                     runner=WdVv9BYz
Please enter the executor: shell, ssh, virtualbox, docker+machine, docker-ssh+machine, docker, docker-ssh, parallels:
docker
Please enter the default Docker image (eg. ruby:2.1):
ruby:2.1
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Il y a deux étapes importantes avec la précédente commande :

  • un «executor» est simplement ce qui va exécuter vos builds. Comme nous sommes dans un environnement Docker, je ne vois pas pourquoi ne pas utiliser des containers. Ainsi pour chaque build, un nouveau container sera créé et sera supprimé ensuite,
  • la «default Docker image» est l’image qui sera utilisée par les executors. Choisissez votre images en fonctione de votre environnement.

Si tout c’est bien déroulé et que vous retournez dans l’admin de Gitlab dans le menu «Runners», vous devriez voir une nouvelle ligne dans la tableau des runners :

Page d'administration des runners avec notre nouveau runner

Si vous retournez au répertoire que l’on a créé au début de l’article, vous verrez qu’un nouveau fichier a été créé et qu’il contient la configuration de notre runner. Ainsi il sera possible de modifier rapidement des runners à la main en éditant le fichier config.toml :

concurrent = 1

[[runners]]
  name = "Ruby builder"
  url = "https://votre.domain.gitlab/ci"
  token = "4d5478b71ffcb094d8b2d34c244a4b"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "ruby:2.1"
    privileged = false
    disable_cache = false
    volumes = ["/cache"]
  [runners.cache]
    Insecure = false

Place maintenant à la configuration du build de votre projet.

3e minute : Configuration du projet et du build

A la racine de votre dépôt git créer un fichier gitlab-ci.yml. C’est ce fichier qui contiendra les instructions de build.

Vous avez une minute pour la lire la documentation de Gitlab CI et linter votre fichier gitlab-ci.yml dans le linter disponible dans votre instance Gitlab.

Ok, ça va être difficile d’écrire la configuration du build en une minute. Mais cette étape n’est pas essentiellement lié à l’installation de Gitlab CI, mais c’est ici que le fun commence !

4e minute : Enjoy !

J’avais dit moins de 5 minutes et le pari me semble rempli. Grâce au travail des équipes de Gitlab, l’installation de Gitlab CI s’est considérablement simplifié et avec Docker on a une fléxibilité de build remarquable…

Petite précision, si vous ne voyez pas le menu «Build» dans le menu de gauche dans votre projet, vérifiez que la feature «Builds» est activée dans les options de votre projet.

Voilà, happy building !

Debian 8.4 + ATI + GNOME Shell = freeze ?





Vous savez assez que je suis un utilisateur assidu de Debian, que ce soit sur mes PC portables ou mes serveurs. En fait, il n'y a que mon PC fixe qui tourne sous Ubuntu 14.04. Vous assez aussi sans doute remarqué que je ne publie plus grand chose autour de l’utilisation de GNU/Linux : la raison est simple, je n'ai plus que des distributions dites stables. Je n'ai plus le temps de m'amuser à bidouiller mon outil de travail entre #NuitDebout, #OnVautMieuxQueCa, le pod diaspote.org, le serveur du blog et les autres. Bref, du stable pour la tranquillité, pour pouvoir me concentrer ailleurs. En plus, en 10 ans, j'ai quand même fait le tour de ce qu'il me fallait. On pourrait dire que je suis comblé.

Sauf que depuis la sortie de Debian 8.4 (Jessie), mes portables gèlent complètement. C'est le genre de truc qui n'arrivait jamais, mais au grand jamais. Mes deux PC potables freezent lamentablement sans action étrange de ma part. Vendredi, alors que je bossais chez un client, c'est fièrement que j'utilisais mon laptop sous Debian dans un environnement noyé par des Windows.
En fait, ma fierté n'a pas duré longtemps : j'ai redémarré 4 fois mon PC en moins de 3h. Pour un gars qui redémarre son PC une fois par jour, ça m'a bouleversé. #Tristitude.
Ajoutez à ça mon autre ordinateur portable qui se met lui aussi à freezer alors que je ne faisais que trainer sur le web.

Les raisons du freeze sont encore floues, mais je connais mon matos : deux vieux ordinateurs portables sous Debian, équipés de vieilles cartes ATI n’exploitant pas les drivers propriétaires, GNOME Shell et la mise à jour vers Debian 8.4. Je sais aussi qu'un écran figé, c'est une histoire de drivers et que les drivers, ça touche au kernel.
Pour ma première tentative de sauvetage-de-face-de-libriste-ridicule, j'ai forcé la réinstallation des drivers libres ATI/Radeon : rien, ou plutôt re-freeze.
En deuxième action, je suis passé par les dépôts backports pour installer une version du kernel plus récente : bingo ! Les freezes ont disparu !
Du coup, si vous avez vous aussi ce problème gênant, voici la démarche à suivre (disclaimer traditionnel : chez moi ça marche. C'est pas dit que ça marchera partout) :

Vérifiez que vous avez bien ces dépôts dans votre sources.list

Ils devraient apparaitre dans le fichier /etc/apt/sources.list.

deb http://ftp.fr.debian.org/debian/ jessie-backports main 
deb-src http://ftp.fr.debian.org/debian/ jessie-backports main

Installez le kernel qui va bien 

Pour du 64 bits :

apt-get update && apt-get install linux-image-4.4.0-0.bpo.1-amd64
Pour du 32 bits:
apt-get update && apt-get install linux-headers-4.4.0-0.bpo.1-686

Et voilà, fin de la manipulation, vous pouvez redémarrer votre ordinateur et reprendre votre travail comme si de rien n'était. Si vous avez des infos sur l'origine du souci, je suis preneur.


<noscript></noscript>

2016-04-07

WebTorrent Desktop, un nouveau Popcorn Time-like



Oserai-je parler d'un nouveau Popcorn Time ? Non, pas vraiment, mais le fonctionnement est quasi le même : du streaming via torrent. Ça peut être un détail technique mais c'est extrêmement important pour moi. Je rêve de voir la mort des sites de streaming direct qui balancent à tout va des vidéos en flash à des gens qui pompent le réseau sans savoir les dégâts qui ça peut entraîner. Le réseau est pour tout le monde, ça serait bien qu'il le reste et pour ça il faut se servir du torrent, des réseaux pairs à pairs, décentralisés et puissants.
Autre point commun, tout comme PCT, c'est un logiciel libre dont le dépôt, même si il est hébergé sur Github, est ouvert à cette adresse.

Maintenant que ça c'est dit, passons à WebTorrent Desktop : il s'agit d'un outil vous permettant de regarder des vidéos en direct, comme Netflix, sauf que là, c'est un lien torrent ou un magnet qui en est la source. Impeccable. Chopez le .torrent ou le lien magnet de votre choix, faites-le avaler par WTD et c'est parti.
L'interface est pour le moment très sobre : on y trouve la liste des fichiers que vous pouvez regarder, trois boutons pour lancer la lecture, arrêter de seeder (de partager) et supprimer les fichiers. Je parle de fichiers parce que WTD  peut aussi bien lire des fichiers audios que vidéos.



Sinon, vous avez bien lu : WebTorrent Desktop se comporte comme un logiciel P2P classique : il télécharge ET partage. Pour parler plus clairement, vous ne serez pas un simple leecher, un mec qui se sert sans redonner à son tour, mais bien un membre du réseau avec la possibilité d’arrêter quand vous le voulez, of course.

Pour tester la bête, c'est assez simple : dirigez-vous vers le site officiel pour télécharger la version Windows, GNU/Linux ou MacOS. Les linuxiens devront installer Node.js, pour les autres, j'en sais rien, je ne connais pas leurs plateformes.

Un détail à remarquer est visible dans la barre de chargement, celle qui s'affiche en rouge en bas de la vidéo. Si vous regardez bien ma capture d’écran, vous pouvez voir que le chargement n'est pas uniforme, qu'il manque des bouts.



Le torrent est décentralisé, il se sert de plusieurs sources différentes. Pour optimiser le chargement, cette technologie va chercher des morceaux chez plusieurs serveurs et reconstitue le fichier par la suite. Il y encore quelques années, personne ne pouvait dire qu'on arriverait à organiser la reconstruction de cette multitude de petits bouts avant d'avoir tout téléchargé sur son ordinateur... C'est beau l’évolution !

Ah, les films libres de droit ne manquent pas, c'est plus compliqué pour les séries. Si jamais l'envie vous prenait de faire du tipiakage avec cet outil, pensez à sortir couvert avec un VPN. C'est toujours une bonne idée.


<noscript></noscript>

2016-04-06

Mise à jour blog vers PluXml 5.5

Le blog évolue et passe de PluXml 5.4 à PluXml 5.5 . La mise à jour s'est effectuée sans incident. Une fois les nouveaux fichiers copiés (tous sauf les répertoires /data, /plugins et /themes, ainsi que le fichier config.php) et leurs droits vérifiés, il suffit de se rendre sur le blog et d'exécuter la mise à jour proposée afin de finaliser la migration. C'est tout.

J'apprécie toujours autant la simplicité d'utilisation de ce CMS. Merci donc aux contributeurs.

Page officielle du projet : www.pluxml.org

2016-04-03

Passer à PluXml 5.5




PluXml, c'est ce qui propulse ce blog depuis quelques temps maintenant. Presque deux ans en fait.

Ce premier avril, en plus de voir apparaitre la drôle entreprise Diaspote Inc (ahah) est sortie la version 5.5 de ce moteur de blog.

Au programme, une interface d'administration retravaillée. Ce ravalement est bien agréable sachant que l'ancienne commencait sérieusement à se faire vieille. Un truc agréable fait son apparition : la possibilité, en plus de la date de publication, de préciser la date de la dernière modification. En gros, maintenant, vous aurez la date précise à laquelle j'ai corrigé les dernières fautes d’inattention.
Si vous voulez parcourir la liste complète des changements, c'est par ici. L'annonce officielle est par là.

Si vous ne connaissez pas du tout PluXml, sachez que ce CMS ne s’embête pas avec une base de données. C'est fondamental quand on n'a pas envie de dépenser une fortune dans un serveur bien trop puissant : c'est donc fondamental pour moi.

Pour les utilisateurs actifs de PluXml, la mise à jour est fichtrement triviale. Tout doit être remplacé par les nouveaux fichiers à l’exception du répertoire de votre thème, de vos plugins, de votre config.php et du /data. C'est tout. C'est quand même bien plus simple que de lutter avec owCloud !



<noscript></noscript>

2016-04-01

[1 avril] Bienvenue Diaspote Inc




C'est une grande nouvelle. Le pod diaspora* diaspote.org a tapé dans l'oeil de la French Tech. Pour celles et ceux qui ne connaissent pas la French Tech, c'est une sorte de label qui reconnait le travail des startups innovantes dans le domaine du digital.

Cela fait des semaines que les #podmins de diaspote sont en négociation avec les porte-paroles de la FT pour organiser une startup bien de chez nous qui s’appuierait sur le logiciel libre diaspora* pour propulser un réseau social bénéficiant des lois françaises.

Nous sommes fiers de pouvoir apporter un soutien financier de près de 50 000 euros pour lancer un nouveau pod, dont le nom reste encore à définir, et embaucher 5 développeurs ruby à temps plein. De quoi faire passer le succès de la campagne de Senya pour un léger amuse-bouche ! ;-)

Le tout sera géré par une nouvelle entité créée pour l'occasion : Diaspote Inc, dont la gestion sera partagée entre les podmins et la CNIL.
Je pense qu'il n'est pas nécessaire de préciser que, contrairement à diaspote, le pod se servira de la branche stable de diaspora* et qu'il sera configuré pour vous permettre de partager vos publications sur Facebook et Twitter.

On espère pouvoir rapidement vous montrer le résultat de notre travail. Restez branchés et n'hésitez pas à passer par les commentaires pour nous proposer vos idées de nom !


<noscript></noscript>

2016-03-25

[Wiki]Utilisation d’Nginx comme reverse proxy avec un certificat auto-signé, Let’s Encrypt et un chiffrement fort

Cette fois pas d’annonce d’une nouvel article, mais celle de la refonte complète de la gestion d’NginX en tant que reverse proxy pour gérer le SSL (https):

Le SSL est de plus en plus utilisé par les services auto-hébergés. En général ce protocole est géré par le serveur web qui reçoit les requêtes directement. Par contre si vous avez mis en place un reverse proxy, la chaîne de chiffrement se fera entre le navigateur, et ce fameux reverse proxy.

Utilisant NginX, je l’ai donc configuré pour qu’il fonctionne correctement avec ce type de requête en lui laissant gérer les certificats. Ceux-ci pourront être auto-signés grâce à openssl, ou délivrés par une autorité de certification. L’arrivée de Let’s Encrypt permet à chacun d’avoir son propre certificat délivré par une autorité reconnue par tous les navigateurs. Nous verrons comment gérer ce type de certificats avec un reverse proxy, ainsi que la mise en place d’un système de chiffrement digne de se nom. Il faut d’abord avoir mis en place NginX en tant que cache et reverse proxy comme décrit ce tuto Installation et configuration d’un reverse proxy avec NginX.

Ca se passe par là sur le wiki: Utilisation d’Nginx comme reverse proxy avec un certificat auto-signé, Let’s Encrypt et un chiffrement fort

Récupérer l'application Tasks avec ownCloud 9




J'ai fait la mise à niveau hier soir et tout s'est très bien passé. Je n'ai rencontré aucune erreur pendant le passage de 8.2.2 à 9.0. J'ai récupéré les mises à jour des applications Galerie, Passwords, Contact, Mail, Documents, Agenda, même Tasks est bien passée. Sauf qu'elle s'appuie sur une version d'Agenda qui n'est plus du tout maintenue depuis cette neuvième évolution majeure d'ownCloud. La preuve, quand on clique dessus, on se retrouve avec une page blanche aussi fraîche qu'inattendue.

En clair, vous avez bien les dernières versions des applications Tasks et Agenda qui sont correctement installées mais qui, du coup, deviennent incompatibles entre-elles. #Tristitude, comme j'ai trop souvent l'habitude de dire.

Bref, c'est chiant si comme moi vous en êtes un peu accro. Du coup, je vous propose la solution pour récupérer Tasks et respirer tranquillement à nouveau.

Étape 1 - Désactivez l'application

Commençons doucement par désactiver l'application depuis le gestionnaire d'application.

Étape 2 - Supprimez les sources de la version de Tasks défectueuse

Allez dans le répertoire apps de votre installation et supprimez le répertoire tasks. En ligne de commande, ça donnerait quelque chose comme ça :
cd /var/www/html/owncloud/apps && rm -rf tasks

Étape 3 - Récupérez les sources de la branche DAVclient de tasks

Vous allez maintenant choper les sources de tasks depuis le dépôt Github et vous placer sur la branche DAVClient :
git clone https://github.com/owncloud/tasks.git && cd tasks && git checkout DAVclient

Étape 4 - Vérifiez les droits

N'oubliez pas de bien vérifier que votre serveur web peut librement manipuler les fichiers
chown -R www-data: /var/www/html/owncloud/apps/tasks

Étape 5 - Réactivez l'application et mettez encore à jour la base de données

Une fois l'application réactivée depuis le gestionnaire d'application, OC va vous demander de mettre à jour la base de données. Là, c'est comme vous le sentez puisque vous venez de jouer avec ce processus pour passer de 8.x à 9.x ! :)


Et voilà, Tasks revient à la vie, vous pouvez aller dépiler vos trucs à faire. Pour finir, notez que cette version est plus lente que l'ancienne puisqu'elle charge l’intégralité des tâches en cours et terminées d'une seule traite.


<noscript></noscript>

2016-03-24

Ressources sur le libre

Voici une liste de ressources pour se tenir informer, se sensibiliser ou encore agir sur les thématiques du logiciel libre et de la neutralité de l'internet.

Actualités

 Conférences

 Sites de sensibilisation

Sites d'activité citoyenne

Miscellanées

Autres ?

Si vous avez des suggestions, ne pas hésiter à me les envoyer par courriel.

Devoir installer un Wiko Rainlow Lite, loin de FirefoxOS


Soyons direct : c'est un téléphone sous Android, la version 5.1.1 pour être précis, Lollilop d’après Wikipedia.
Pourquoi un utilisateur de Firefox OS aurait besoin d'un autre jouet sous Android ? Simple, les mois de mai et d'avril sont ceux des anniversaires chez moi. La grande initiative de l’année, c'est de refourguer un nouveau téléphone à ma tendre mère, une femme impressionnante de 66 ans.

C'est une vieille, quoi.

Non, ce n'est pas grossier. Elle est bien plus à l'aise avec des plantes, un marteau, du tissu, un tournevis, de la peinture, des dossiers de droit tordus, et j'en passe, qu'avec un smartphone. C'est la reine du jardin familiale et l’égale de son mari dans le travail. Cela fait deux ans environ qu'elle se traîne un smartphone de récupération qui m'a suivi en Inde, en Syrie ou encore au Monténégro. Il a prit le vent, la flotte, la canicule et ma transpiration pendant des années avant de finir dans ses mains. Autant dire que je suis franchement étonné qu'il ait tenu jusque là !

J'ai essayé de lui donner mon Open C. Vraiment. Ses besoins sont simples : flooder ses enfants et secouer son mari, principalement. Pas de jeux vidéos, pas d'applications tordues ni de client diaspora* pour suivre mes aventures sur diaspote.org : seulement des appels, des textos, des photos et un peu de navigation. Quand on pose le cadre, mon Open C remplit parfaitement ses besoins, sauf qu'elle ne veut pas se sentir perdue, incapable de s'en sortir sans demander de l'aide. Elle n'est pas très à l'aise avec un smartphone mais elle a trouvé le courage de se servir d'un PC portable sous Ubuntu pour me skyper quand j’étais à l'autre bout du monde. L'informatique fait partie des quelques éléments qui ne font pas partie de son univers même s'il y traîne de temps en temps par la force des choses.
Pour remplir cette dernière condition, il lui faut impérativement un bouton retour, cette flèche en bas à gauche du téléphone qui vous fait revenir sur l’écran précédent. L'Open C n'en a pas, la panique prend le pas, l'impression de ne pas pouvoir réussir à être indépendante est là, c'est trop tard : ce téléphone n'est pas pour elle. Il est bien trop différent de ce qu'elle maîtrise.

C'est triste, mais c'est ainsi. J'ai du accepter de participer à l'achat de ce machin, peu couteux certes, mais sous Android. Comme je n'ai pas le temps et plus les compétences pour lui installer une autre ROM plus libre, je fais ce que je fais de mieux : je préconfigure à ma sauce, F-Droid en tête.
J'avoue être passé par un moteur de recherche pour retrouver le nom de ce marketplace alternatif ! Je suis vraiment largué avec des trucs là. #Tristitude.
Je récupère donc ce truc pour pouvoir, en plus d'enfin voir que ça marche pour de vrai, installer Firefox et K9 Mail. En clair, je fais ce que je préconise dans mon vieux billet : Conseils à un libriste pour faire passer au libre. Quand on a la main, nous, libristes, nous nous devons d'en profiter. Il ne faut pas tomber dans la barbarie en installant des trucs trop pointus, genre un machin qui chiffre les textos, sans le consentement du futur utilisateur et qui ne sera qu'une surcouche compliquée, mais on peut déjà balancer Firefox comme navigateur par défaut, c'est la base.

Je n'ai pas d'autres idées d'applications alternatives qui pourrait l’intéresser ou remplacer de l'existant trop bavard, j'attends vos idées pour, éventuellement, transformer son futur smartphone en un outil tolérable de mon point de vue et utilisable du sien.


<noscript></noscript>

2016-03-21

Où sont stockées vos données sur iCloud?

Saviez vous que les données du cloud d’Apple (iCloud) sont hébergées en partie sur les serveurs d’Amazon, de Microsoft et de Google?

Ça me fait marrer cette sous traitance. In fine, l’utilisateur ne sait rien d’où sont stockées ses données privées et qui y a accès.

Pourtant les intermédiaires des cette chaîne ont en pratique accès à vos données. De même que les autorités des pays qui les accueillent. (Safe harbour haha)

J’aimerai bien savoir combien de NDA intermédiaires il y a entre vous et le propriétaire du disque dur qui stocke vos données privées (non chiffrées bien sûr pour pouvoir les traiter facilement).

Si vous voulez rire, allez regarder du coté des CDN de Facebook. Vos photos privées sont copiées sur de multiples serveurs dans le monde et un simple lien permet à tout le mode d’y accéder.

Heureusement, Apple a l’air de vouloir moins dépendre de ses compétiteurs pour opérer son service de cloud et a investi 4 milliards de $ pour construire ses propres serveurs de stockage en Arizona, Irlande et au Danemark.

Bref, stocker ses données chez soi, c’est pas une mauvaise idée si on veut les garder privées :p

Edit suite au commentaire de barmic :

D’après ce document sur la sécurité d’Apple de septembre 2015, on trouve le passage suivant sur les données d’iCloud (page 41):
« Each file is broken into chunks and encrypted by iCloud using AES-128 and a key derived from each chunk’s contents that utilizes SHA-256. The keys, and the file’s
metadata, are stored by Apple in the user’s iCloud account. The encrypted chunks of the file are stored, without any user-identifying information, using third-party storage
services, such as Amazon S3 and Windows Azure. »

En clair, les prestataires (Amazon et Microsoft) ne peuvent déchiffrer seuls les données. Le chiffrement se fait par Apple sur ses machines, puis le fichier chiffré est envoyé à ses prestataires pour y être stocké. La clé de chiffrement restant sur les machines Apple (donc toujours à la portée des autorités américaines).

Related Posts:

J'aime !(2)Je n'aime pas !(1)

2016-03-16

FreshRSS 1.3-1 beta et Wallabag 2 beta 2


Des nouveautés de nos applications adorées !



FreshRSS d'abord, parce que c'est mon bébé. C'est un lecteur de flux RSS, autrement dit : il s'occupe pour nous de récupérer chaque article d'un site d'info, d'un blog ou de tout ce qui propose son contenu via RSS et vous le propose via une belle interface web. Le must de la veille technologique, comme on dit.
Si vous êtes déjà utilisateurs des versions de développement, foncez faire la mise à jour automatique via l'interface de mise à jour, ça passe tout seul. Pour la télécharger et l'installer à la main, c'est par ici.

Au programme :

Wallabag



Wallabag, c'est un outil que je n'utilisais plus depuis la frustration de ne pas pouvoir profiter de la v2 sur mon serveur. C'est chose faite maintenant, j'ai remonté mes manches pour l'installer en bonne et due forme. Wallabag, c'est un read-it-later. Il permet d'enregistrer le contenu d'une page web dans sa belle interface pour pouvoir le lire plus tard, au calme.
Exemple simple : je passe pas mal de temps à rechercher tout et n'importe quoi sur le net pendant mes heures de travail. Il m'arrive de trouver des articles franchement intéressants que je ne peux pas me permettre de lire pendant mes heures de service, alors, hop, dans Wallabag ! Je le lirai le soir, au calme, chez moi.  C'est un peu une façon particulièrement classe de mettre du contenu en favori.

Pas de liste de nouveautés pour cette beta2, l'annonce officielle s'en charge très bien. Pour l'installer, c'est par là.

Ces deux services libres complètent ma panoplie de geek accro à l'information. FreshRSS récupère le contenu des sites que je suis consciencieusement et Wallabag récupère le contenu aléatoire.
Une astuce perso : mon flux RSS craque régulièrement. Je ne peux pas tout lire et je ne lirai jamais tout ce qu'il peut récupérer. Du coup, je parcours rapidement mes flux, sauvegarde les quelques articles pertinents dans Wallabag et marque la sélection comme lue. Avec cette magouille, je n'atteins plus les 1000 articles non lus avec 150 articles mis en favoris. C'est psychologiquement déstressant !

Si vous voulez en profiter, il serait plus sage de vous servir des versions stables plutôt que des betas, mais après, c'est à vous de voir.


<noscript></noscript>

2016-03-11

J'ai mis à jour mon Flame


On dirait une phrase sortie d'une réunion de groupe de gens qui ont des problèmes :

- Bonjour, je m'appelle dada et j'ai mis à jour mon Flame.
- Bonjour dada !

C'est un peu ça, quand même. Avec l'annonce de Mozilla d’arrêter les frais sur le portage de Firefox OS pour smartphone, on se sent quand même un peu seul. Il y a encore de l'espoir, ceci-dit : des développeurs se sont réunis hier soir pour proposer un avenir de Firefox OS. On n'a pas encore beaucoup d'information sur le sujet mais la Fondation est prête à bosser sur la transition pendant plusieurs mois. C'est court mais ça peut permettre l’émergence d'un futur qui s’appellerait B2G OS, l'ancien nom de code du système d'exploitation. Pour l'histoire, le changement de nom doit intervenir puisque Firefox OS est maintenant réservé aux objets connectés, comme la télévision que j'ai pu prendre en photo chez Harrods à Londres.

Donc, une mise à jour de mon Flame, via OTA. Je ne m'y attendais pas du tout, et pourtant c'est sans doute l'une ou la dernière sous le contrôle de Mozilla. L'avenir s'annonce plus laborieux, avec du flashage à la main et tout le bordel que ça peut entraîner. Au programme, on reste en 2.6 mais sur les bases de Firefox 46. Les nouveautés ne semblent pas se bousculer au portillon mais je n'en attends pas vraiment : un téléphone stable, qui passe des appels, envoi des textos, affiche un GPS correct et qui prend des photos à-la-con, c'est tout ce dont j'ai besoin. En gros, RAS.

Cette mise à jour et le billet de Genma me rappellent que les modules complémentaires sont là et qu'on peut s'en servir ! Personnellement, je me sers de Quick Settings Enhancement et de Kill All : la première permet d'ajouter tout un tas d'options en affichant le menu déroulant du téléphone et l'autre... de massacrer d'un coup toutes les applications que j'oublie régulièrement de fermer. Ces deux modules sont un must ! Je profite de ce billet pour encore parler de TFE Drive qui permet de se servir de son ownCloud avec Firefox OS !

Bon, la prochaine étape sera peut-être aussi agréable pendant deux ans, puis une galère comme ça l'est maintenant avec Firefox OS, mais tant pis : je prendrai une tablette sous Ubuntu ! Peut-être que mon frangin aussi d'ailleurs : mon jumeau commence à se laisse tenter par toutes les conneries que je peux lui raconter et il serait temps !


<noscript></noscript>

2016-03-10

NAS : choix des composants

Dans ce billet, j'établis mon choix pour le montage d'un NAS.

Mon état des lieux est le suivant. J'ai plus de 8To de données personnelles et professionnelles qui sont actuellement sur des disques durs usb. Il devient compliqué de brancher et débrancher, de manipuler sans laisser tomber, de savoir quoi est sur qui.

La sauvegarde est un enfer : sauvegarde de machines sur des disques, de machines sur des machines, de disques sur des disques, etc. J'ai toutes les chances de rater un étape. L'idée est donc de rationnaliser tout ça :

  • Une machine qui héberge données et sauvegarde des desktops/serveurs.
  • Une autre machine qui sauvegarde les données critiques du NAS.

Avantages/inconvénients d'un NAS

Avantages

  • Espace de stockage continu plutôt que N disques distincts
  • Espace disponible sur le réseau (communication avec plusieurs machines, montage NFS...)
  • Facilite grandement la sauvegarde régulière
  • Résilient à des pannes disques (ça dépend du RAID choisi, mais je m'intéresse à un système résilient)

Inconvénients

  • Si un nombre critique de disques flanche ou un autre problème apparait (erreur de manipulation, matériel défaillant causant une perte majeure des disques), on perd tout.
  • Machine supplémentaire donc coût supplémentaire comparé à un boitier de disque externe.
  • Les disques de parité sont de la mémoire morte, c'est-à-dire de l'espace non visible par l'utilisateur.
  • Un système RAID n'est pas une sauvegarde, il faudra donc sauvegarder.

Choix technologiques

  • De la redondance de données pour être résilient aux pannes disques.
  • Système de fichiers ZFS qui est éprouvé pour ce genre d'usage (en attendant que btrfs soit mature).

Par conséquent, on s'oriente vers un RAIDz1, 2 ou 3, c'est-à-dire 1, 2 ou 3 disques de redondance. A l'heure actuelle, il semble que RAIDZ1 soit déconseillé. L'argument est le suivant. Les disques sont de plus en plus gros. Par conséquent, si un disque est en panne, il est nécessaire de le remplacer pour reconstruire le pool. La charge appliquées sur les disques est d'autant plus grande que chaque disque est volumineux. Il y a donc un risque (non négligeable ?) qu'un second disque casse à ce moment là. RAIDZ3 demande beaucoup d'investissement. J'opte donc pour RAIDZ2. Le nombre minimal de disques est de 4 et il est conseillé d'avoir un nombre pair.

Les NAS commerciaux

On va voir que notre machine sans disque présentée ci-dessous peut recevoir jusqu'à 12 disques. Bien plus qu'il nous en faut. Les NAS commerciaux de 2 ou 4 disques sont courants. Si on se base sur des marques bien connues comme synology, il faut compter

  • 2 baies 300-350€
  • 4 baies 450€
  • 5 baies 600-700€
  • 6 baies 700-800€
  • 12 baies à 1300€.

C'est un prix typique plutôt minimaliste, on peut sans problème trouver bien plus cher. Je n'ai pas vu de synology à 6 baies.

D'un point de vue rentabilité, un 4 baies est juste pour un RAID6 (=RAIDZ2 pour ZFS), car seule la moitié de l'espace acheté sera disponible. Le 5 baies étant le plus proche, je vais comparer avec le DS1515 :

  • quad core 1.4 GHz
  • 2 Go RAM
  • disques EXT4 hot swappable
  • Extension possible à 15 disques, mais avec un module coutant 450€ / 5 disques supplémentaires
  • Ajout d'un disque SSD possible (Les tests de performance présentés sur le site utilisent un SSD)

L'avantage d'un tel NAS est le coté clef en main du produit (d'après ce que je lis). Par contre, les inconvénients que je vois :

  • peu d'évolutivité en nombre de disques ou chère
  • logiciel propriétaire
  • pour un RAID6, je n'ai que 5-2 = 3 fois la taille d'un disque disponible. La sacrifice est important.
  • le 8 baies est bien plus cher

Pour un prix légèrement inférieur, ma proposition ci-dessous me donne

  • quad core 2.4 GHz
  • 16Go RAM ECC
  • disques en ZFS (ou autre chose)
  • Avec le boitier, on peut y mettre jusqu'à 8 disques facilement, 10 sans trop de difficulté.

Pour l'évolutivité :

  • Possibilité d'ajouter deux disques SSD pour améliorer les performances si le besoin sans fait sentir (pour NFS ?).
  • Possibilité de monter jusqu'à 64 Go de RAM (je reviendrai là dessus).
  • Possibilité d'ajouter de la ventilation.
  • Possibilité d'en faire autre chose qu'un NAS si les besoins devaient évoluer brutalement.

Le choix

Pour le matériel, et notamment la partie critique (carte mère, mémoire, etc), je conseille LDLC car ils ont un excellent support téléphonique (déjà testé), une bonne politique de retour, un site bien fait et une livraison gratuite dans des points relais. Les choix ne sont pas neufs en soi. Je me suis largement inspiré des conseils donnés sur le forum de freenas et quelques blogs.

Le système d'exploitation

BSD gère nativement ZFS, mais ça reste possible avec debian. Néanmoins, j'ai une confiance plus grande sur un support natif, je m'oriente donc vers FreeNAS pour la distribution. La documentation de FreeNAS est exhaustive, le forum est très actif et possède beaucoup de contenu.

UPS

Le nombre de disques durs peut être important. Je veux que ça tienne un minimum et avoir le temps d'éteindre proprement. De plus, les capacités des batteries peuvent diminuer au cours du temps, il faut prendre ce paramètre en compte.

Carte mère

Les critères que j'ai retenu :

  • le nombre de port SATA
  • la capacité en mémoire vive (FreeNAS en consomme beaucoup et de manière générale, c'est plutôt bien de ne pas en manquer)
  • le réveil par réseau (Wake On LAN)
  • la consommation énergétique (inférieure à 50W)

ASRock fabrique de très belles cartes mères pour les serveurs. Mon choix s'est porté sur une version 4 coeurs. En 8 coeurs, la différence de prix est selon moi trop importante pour une utilité relative sur un NAS. Le petit plus que j'apprécie : le CPU est livré avec la carte mère, pas besoin d'aller jouer avec la pâte thermique.

Version Quad core

Caractéristiques :

  • mini itx
  • Intel Avoton C2550 Quad Core 2.4GHZ featuring 14W TDP
  • 16 Go par slot, 64 max, 4 slots
  • 12 SATA (4 SATA2, 8 SATA3)
  • Support de l'IPMI
  • 3 ports USB (dont un pour l'UPS, et un pour l'OS)

Version Octa core

Les autres caractéristiques sont identiques à ci-dessus.

RAM ECC

Il est important d'utiliser des mémoires ECC. C'est recommander par freenas pour éviter les corruptions de données.

8Go est le minimum pour FreeNAS, 16Go devrait être à peu près confortable avec la possibilité de passer à 32Go. Les mémoires de 16Go sont un peu trop couteuses ici. Notre système se limitera donc à 32Go pour des raisons de coûts.

Chassis

Critères :

  • de l'espace, pour faire circuler l'air et pour faciliter l'installation.
  • un grand nombre d'emplacements pour disques 3.5"
  • de la ventillation et des filtres pour la poussière
  • des cables bien rangés
  • compatible carte mini itx

Mon choix :

Caractéristiques :

  • alim ATX/EPS
  • 2 SSD (à placer sur le coté)
  • 8 disques 3.5" ou 2.5"
  • 2 espaces pour lecteurs optiques dans lesquels il serait possible de mettre deux racks pour disques durs 3.5" ou 2.5"
  • 2 ventilateurs 140mm fournis
  • un grand nombre de réceptacles pour des ventilateurs supplémentaires

 Alim

Il faut donc choisir une alimentation ATX/EPS. Toujours prendre de la qualité pour éviter de sentir un jour le plastique brûlé.

  • FSP AURUM S400 400W 80PLUS Gold 60€ (LDLC)
  • Enermax Revolution XT ERX430AWT 80PLUS Gold 75€ (LDLC)

USB

  • SanDisk Cruzer Fit 16 Go 6€

Avantages :

  • petit prix
  • deux fois l'espace nécessaire à freenas
  • 5 mm de longueur. Elle s'oublira à l'arrière de la machine.

Disques

Je privilégie :

  • des disques de récupération (en bon état tout de même)
  • des disques à faible vitesse (5400 tours/min) car ils chauffent moins
  • des disques WD red, j'en ai une très bonne expérience

A noter que la taille totale disponible dépend de la taille du plus petit disque. Il faut aussi réfléchir aux besoins futurs avec les remarques suivantes :

  • On ne pourra pas ajouter de disques. Il n'est pas raisonnable de mettre deux vdev, et il est impossible d'étendre un vdev.
  • Quel coût existera-t-il si on veut augmenter la taille de chaque disque ? Quel gain ? Faut-il le faire maintenant ou plus tard (évolution des prix, existant).

Ces choix sont à faire au cas par cas. A noter aussi qu'il est déconseillé d'acheter tous les disques de même modèle, en même temps, chez le même fournisseur. La probabilité qu'ils tombent en panne simultanément est plus grande.

Connectique

  • La carte mère est venue avec 6 cables SATA. A compléter si on veut passer à 8.
  • L'alimentation possède un nombre limité de connecteur d'alim SATA (5). Il faut donc soit mettre des dédoubleurs sur des fiches molex (que l'on utilise pas), soit des extensions de fiche SATA.

SSD

Il n'est pas encore clair qu'un disque SSD apporte des améliorations pour mon utilisation (cf reddit ou Introduction to vdev, zpool, ZIL, L2ARC). Le point sensible est ici la partie NFS qui peut avoir besoin d'un cache pour être plus rapide. De même que pour les NAS assemblés, c'est optionnel et souvent laissé au regard de l'utilisateur. La documentation de freenas indique qu'il faut privilégier la RAM en premier.

Liens intéressants

2016-03-09

ownCloud 9 disponible et fin de vie de ownCloud 7




Trois mois environ après la dernière salve de mises à jours, ownCloud enchaîne avec une version 9 (y'a des images derrière ce lien, pas dans ce billet). Pour une logiciel qui a soufflé ses 6 ans le 1 janvier 2016, c'est franchement pas mal. Un petit tour de la liste des nouveautés est de rigueur !

Une fédération améliorée

Quand je parle de fédération, j'ai l'habitude d’enchaîner sur diaspora* alors qu'ownCloud le fait tout aussi bien. On pouvait déjà incorporer l'installation d'un ami ou d'une entité quelconque à sa propre instance pour pouvoir accéder, en quelques cliques, à ses fichiers partagés. Maintenant, on peut interagir avec ses propres utilisateurs. Du coup, on pourra facilement partager son cloud avec le cloud du voisin et de ses amis.

Une installation certifiée

Là, c'est le truc assez cool de cette version 9 : la mise à jour ou l'installation de son instance va déclencher le contrôle des fichiers utilisés. Pour ceux qui ne savent pas trop comment fonctionne une installation d'ownCloud sur un serveur, c'est assez simple : on copie/colle un paquet de fichiers dans le répertoire qui va bien et, avec un peu de magie, ça roule tout seul. Ce procéder est efficace, mais pas mal de monde, moi le premier, ne pensent pas à vérifier si ce qu'on dépose sur son serveur est bien le résultat du travail des développeurs. L'histoire de Linux Mint rappelle que ce genre de négligence peut entraîner un drame. Avec cette version 9, la vérification de l’authenticité des sources est automatique. Si ça vous intéresse, vous pouvez aller plus loin par ici (en anglais).

Un système de tags, de commentaires et des mises à jours d'application enfin visible

Dans les dernières nouveautés notables, on peut parler de l'ajout d'un système de commentaire. Vous allez pouvoir commenter vos répertoires et vos fichiers. Dans mon cas, l’intérêt est limite puisque je suis le seul à me servir de mon instance mais je me vois déjà hacker le système pour ajouter des notes par-ci, par-là pour ne pas oublier de modifier un répertoire ou de faire un truc important. Pour les tags, c'est à peu prêt la même conclusion personnelle, mais nul doute que des plus gros utilisateurs seront les apprécier.
Un dernier truc important, c'est l'ajout, enfin, de notifications lorsqu'une mise à jour d'une application est disponible. Avant ça, j'allais un peu au petit bonheur la chance, et pas très souvent, regarder si des màj étaient à faire. Les notifi', c'est toujours cool !


Pour finir, et je l'ai mis dans le titre parce que c'est important et parce que personne ne pensera à regarder : avec la sortie de ownCloud 9, c'est la version 7 qui est poussée vers la sortie. Ce 8 mars 2016 est sortie la dernière mise à jour de la branche 7 d'ownCloud et il est maintenant conseillé de passer à la version 8, ou 9 !

Si vous vous servez déjà d'ownCloud, n'attendez pas tout de suite la notification de mise à jour de l'Update Center. Comme d'habitude, il faudra encore attendre quelques jours avant de profiter de cette nouvelle version.


<noscript></noscript>

2016-03-05

Webmasters, installez vos libs pour respecter vos utilisateurs

C'est un fait désormais bien établi, les services pour webmasters permettent de suivre le déplacement des utilisateurs sur le web. A titre d'exemple, on trouve google analytics ou les bibliothèques (javascripts, fonts) hébergées notamment par google. A titre d'exemple, une liste est disponible sur developers.google.com.

Installer ces libraries sur son serveur est en réalité très simple. Prenons l'exemple de jquery et mathjax sur apache. Pour ceux qui ne sont pas familier, mathjax permet d'afficher des équations sur son site web ou dans Jupyter. Dans le cas de l'hébergement de fichiers privés, l'intérêt apparaît clairement. Les équations étant envoyées vers le service de mathjax (si vous l'utilisez directement), celui-ci connait l'intégralité des équations de votre document.

On commence par installer jquery et mathjax

sudo apt install libjs-jquery
sudo apt install libjs-mathjax fonts-mathjax-extras

On crée un virtual host pour apache dans sites-available

<VirtualHost *:80>

ServerName mylibs.mydomain.tld
ServerAdmin webmaster@sciunto.org
ServerAlias mylibs.mydomain.tld
Alias /mathjax/ /usr/share/javascript/mathjax/
Alias /jquery/ /usr/share/javascript/jquery/

ErrorLog ${APACHE_LOG_DIR}/mylibs.mydomain.tld-error.log
CustomLog ${APACHE_LOG_DIR}/mylibs.mydomain.tld-access.log combined

</VirtualHost>

Il est ensuite souhaitable de dupliquer cette configuration en https, ou de n'utiliser que https. letsencrypt permettra d'avoir un certificat pour ça.

Maintenant, dans le code du site web, on peut remplacer l'appel de mathjax (par exemple)

  src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-MML-AM_CHTML"

par

  src="//mylibs.mydomain.tld/mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML"

pour le cas d'un appel http ou https ou

  src="https://mylibs.mydomain.tld/mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML"

pour un appel en https seulement.

En rédigeant ce billet, je me dis que des hébergeurs comme les CHATONS pourrait aussi proposer ce type de services pour les personnes n'ayant pas la possibilité d'héberger ces bibliothèques.

2016-02-29

Surveiller la qualité de l’air avec du open hardware et du logiciel libre

J’ai commencé un petit projet de mesure de la qualité de l’air intérieur, le tout en utilisant un maximum de open hardware et de logiciel libre. Pas de préoccupation particulière par rapport à la qualité de l’air chez moi, mais une curiosité qui peut déboucher sur des comportements utiles (l’aération du logement notamment).

Inspiré par les projets :

Me suis donc procuré quelques capteurs pour commencer à jouer avec arduino, micropython ou ESP8266:

J’ai branché l’ensemble sur une Arduino UNO (toujours la même qui me permet de prototyper en réutilisant essentiellement du code d’autres personnes).

1er montage avec le DHT11 (température et humidité) et le MQ135 (CO2)

1er montage avec le DHT11 (température et humidité) et le MQ135 (CO2)

2ème montage en ayant ajouté le détecteur de particules fines (avec les pinces crocodile et les allumettes pour tester!)

2ème montage en ayant ajouté le détecteur de particules fines Sharp GP2Y1010AU0F Optical Dust Sensor (avec les pinces crocodile et les allumettes pour tester!)

J’ai alors écrit (principalement copier/coller/modifié à la marge) un bout de code C++ pour arduino (merci git.framasoft.org pour l’hébergement du code) pour sortir du CSV sur le port série. Ce port série est ensuite lu par node-red qui permet de travailler les valeurs (pour l’instant juste débugger de temps en temps et limiter à 2 messages par minute), et on balance ensuite direct dans le nœud emoncms (qui génère un POST HTTP). Le tour est joué.

Screenshot from 2016-02-29 17-15-25

La sortie CSV ressemble à clef:valeur,clef2:valeur2,etc…  ce qui donne : humidity_percent:27.00,temperature_C:22.00,temperature_F:71.60,heat_index_C:20.96,heat_index_F:69.73,dust_raw_signal:152.00,dust_voltage:0.74,dust_density_ug_m3:26.17

Une fois arrivé dans emoncms (auto-hébergé chez moi, bien évidemment), je configure ces input pour qu’ils soient loggués. On peut ensuite construire des tableaux de bord à partir de ces enregistrements, un exemple ci-dessous :

Dashboard construit sur emoncms

Tableau de bord construit avec emoncms

Un peu insatisfait des manipulations et du graphisme dans emoncms, je me suis tourné vers graphite+grafana (que j’utilise au boulot). J’ai fait un petit script (très imparfait) qui reprend les données de emoncms et qui les injecte dans carbon+graphite (si vous le voulez, mettez moi un commentaire, je le mettrais au propre pour le publier). Je peux ensuite utiliser grafana pour faire de beau tableau de bords et post-traiter les données (par exemple lisage en utilisant des moyennes sur 5 minutes, dérivées, etc.). Notez que j’utilise aussi les valeurs collecté par la téléinfo et la mesure de la chaudière (cf précedent blog).

 

Dashboard construit sur Grafana

Tableau de bord construit avec Grafana

Reste encore beaucoup de boulot pour que ce soit utilisable, mais j’apprends plein de trucs et j’y vais progressivement.

Je doit avouer que le montage est toujours sur la breadboard (platine d’experimentation) depuis 2 mois, donc il va falloir que je mette le tout dans un boîtier (avec éventuellement un ventilo pour la détection de poussière).

Comme d’habitude, une petite liste de choses à faire par la suite :

  • effectuer le calibrage de CO2 et de poussière,
  • envoyer en simultané vers carbon pour ne pas avoir à jouer le script d’import,
  • construire des écrans de consultation utilisables,
  • trouver un moyen d’afficher ces données sur mes bureaux d’ordinateur (un widget gnome qui récupère une valeur en HTTP ?),
  • mettre l’électronique dans une boite,
  • brancher l’ESP8266 dessus pour la liaison wifi et rendre autonome le trucs (remplacer l’arduino?),
  • avoir des LED de feedback où je décide de mon propre algorithme (combinaison des mesure pour déterminer la qualité de l’air), suggérant ainsi qu’il faut aérer,
  • harmoniser les capteurs en utilisant partout du  node-red,
  • etc.

À suivre.

2016-02-25

Présentation de l'Aquaris M10 sous Ubuntu


En ce moment, le World Mobile Congress bat son plein en Espagne. Les grandes nouveautés de ce salon touchent particulièrement les téléphones portables, mais pas que ! On, surtout moi, attendait tous la présentation et les premiers testes de la tablette tournant avec Ubuntu Touch, la version de la distribution dédiée à ces appareils. C'est maintenant chose faite !



D’après mes flux RSS, les premiers furent les gars de chez Numerama avec leur article : Prise en main de la tablette BQ Aquaris M10 sous Ubuntu.

On y trouve un long blabla et des photos, pas mal de photos. Pour une vidéo rapide, vous pouvez passer par Clubic. Au final, on se rend plutôt bien compte qu'il s'agit d'une tablette tactile ordinaire. Ouf, on est sauvé. Les caractéristiques étaient elles aussi attendues :
  • CPU : Un Quadcore à 1.5 Ghz ( ARM - MediaTek MT8163)
  • GPU : Mali-T720 MP2
  • 2GB de mémoire vive
  • Un appareil photo de 8 Mpix
  • Une webcam de 5 Mpix
  • 16 Go de mémoire interne
  • Un port MicroSD supportant jusqu'à 200 Go.
Autant dire que ce n'est pas du gros haut de gamme, comme l'auteur ne manque pas de le souligner, même si c'est loin d’être au niveau d'un ZTE OpenC. Oui, je commence les hostilités puisqu'il semblerait que tout le monde soit d'accord pour affirmer que seul le haut de gamme peut permettre à un nouveau venu d’espérer une petite place dans le monde déjà très occupé des tablettes tactiles. Dans ces commentaires, on retrouve le brave Alterlibriste qui ne baisse plus sa garde depuis que Cyrille BORNE s'est occupé de gentiment lui tailler les croupières à propos de FirefoxOS.

Il doit y avoir un fond de vérité, puisque les gens semblent d'accord. Pourtant, avec mon esprit de bidouilleur libriste et d'hacktiviste, je ne peux pas m’empêcher d’être heureux. Ce produit présente des limites techniques, certes, mais c'est aussi une alternative. Rien que ça, c'est beau. Ce n'est pas l'alternative parfaite : Ubuntu pourrait se servir de Wayland et pas de Mir, par exemple, ou tourner avec 4Gb de mémoire vive serait pas mal non plus. Mais ça reste une alternative.

Je me demandais si j'allais m'en offrir une, ou pas. Tout comme j'ai acheté un Flame sous FirefoxOS le jour exact de sa sortie, je ferai pareil avec cette tablette. Je suis un mec simple : j'ai envie de faire le malin avec un appareil sous Ubuntu tout comme j'avais envie de faire le malin avec un téléphone sous FirefoxOS. En plus d'une indépendance royale vis-à-vis des services de Google & co, j'adore voir les gens dévisager mon téléphone et je veux qu'ils dévisagent cette tablette. J'annonce donc ici que j’achèterai cette Aquaris, que je ferai exactement le même pari qu'avec le système d'exploitation de Mozilla : celui d'une alternative.

Marchera, marchera pas ? Tant pis. Critiquer, c'est bien, c'est même important. J'entends les critiques mais je reste borné. Je veux supporter cette tablette et je le ferai. Pour être honnête, la convergence, qui est mis en avant par Canonical, ne sera qu'un bonus pour moi. Tout comme je ne suis pas un utilisateur extrême de mon Flame, je ne le serai sans doute pas avec cette Aquaris : poster des trucs et d'autres sur diaspote, lire mon flux RSS, regarder des vidéos et des séries dans le train, voici à quoi ressemblera l'utilisation que j'en aurai. Après, je m'imagine volontiers faire des présentations et des démos avec ce jouet pour ne plus traîner le vieil ultra portable que je ne supporte plus.

Bref, tête baissée, j'y vais. Firefox OS n'a pas tenu mais mon Flame tiendra jusqu'à sa mort. Cette tablette ne tiendra peut-être pas plus longtemps mais je m'en servirai jusqu'à ce qu'elle flanche.


<noscript></noscript>

2016-02-24

Chiffrement matériel sur Olinuxino A20

Le processeur Allwinner A20 est capable d’accélérer matériellement un certain nombre d’algorithmes de cryptographie. J’ai voulu tester s’il était possible d’en tirer parti sur Olinuxino A20, avec Debian Jessie.

Etat des lieux

D’après les spécifications du matériel (voir page 9), il supporte notamment l’AES-CBC en 128 à 256 bits.

Cette accélération matérielle n’est pas disponible dans le kernel 3.4.x fourni par Olimex, mais l’est depuis peu dans un noyau linux récent (à partir de la version 4.3) : http://sunxi.montjoie.ovh/

Après avoir contacté l’auteur de ce patch (il y a plusieurs mois déjà), j’ai eu confirmation que son code ne peut pas s’appliquer facilement sur la branche 3.4 du noyau.

Mise à jour du noyau Linux

Je n’ai pas trouvé de meilleur moyen que de compiler moi-même le noyau.

En soi, ce n’est pas très compliqué, mais il faut avoir la possibilité de se brancher en mode « console » sur la machine pour comprendre ce qu’il se passe s’il y a un problème au démarrage (chargement du noyau linux par u-boot, avant que le serveur SSH soit démarré).

Mode console sur Olinuxino A20

Il faut brancher physiquement son ordinateur sur l’appareil, avec un câble USB.

Sur l’ordinateur, on peut y accéder ensuite avec Putty. Il faut lui demander de se connecter en mode série sur /dev/ttyUSB0, à 115200 bps (vous pouvez enregistrer ces paramètres de session pour les retrouver plus tard). Mais, sur Ubuntu en tous cas, un user standard n’a pas le droit d’accéder à /dev/ttyUSB0 : il faut donc soit lancer putty en tant que root (via sudo), soit donner au user courant le groupe « dialout ».

PuTTY configuration Olinuxino A20

Compilation du noyau Linux

Pour compiler le noyau pour cette machine, tout est expliqué sur le site linux-sunxi.org : http://linux-sunxi.org/Mainline_Kernel_Howto.

J’ai pris la version 4.4.1 depuis https://www.kernel.org/

Sur Ubuntu, il faut installer quelques paquets pour la compilation :

apt-get install gcc-arm-linux-gnueabihf ncurses-dev u-boot-tools build-essential

A noter que, sur Ubuntu 14.04, j’ai eu un message d’erreur « error Your compiler is too buggy ; it is known to miscompile kernels ». J’ai donc fait la compilation avec une version plus récente (la 15.04 : probablement que d’autres conviennent aussi)

make ARCH=arm sunxi_defconfig

make ARCH=arm menuconfig

Dans les menus, il faut activer « User-space interface for symmetric key cipher algorithms » dans la section « Cryptographic API » (cocher plutôt avec une étoile, pour qu’il soit intégré dans le noyau au lieu d’être un module à part)

Option kernel chiffrement matériel A20

Ensuite on est prêt à lancer la compilation :

make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage dtbs

Une fois la compilation terminée :

  • Copier les fichiers arch/arm/boot/zImage et arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dtb dans la partition de boot
  • Créer un fichier boot.cmd dans la partition de boot, avec le contenu suivant :
    fatload mmc 0 0x46000000 zImage || ext2load mmc 0 0x46000000 zImage
    fatload mmc 0 0x49000000 sun7i-a20-olinuxino-micro.dtb || ext2load mmc 0 0x49000000 sun7i-a20-olinuxino-micro.dtb 
    setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait panic=10
    bootm 0x46000000 - 0x49000000
  • Créer le fichier boot.scr à partir de ce fichier :
  • mkimage -C none -A arm -T script -d boot.cmd boot.scr

Au départ, j’avais également compilé et upgradé u-boot sur une nouvelle carte SD, mais ce n’est finalement pas nécessaire. Le u-boot livré par Olimex suffit (U-Boot 2014.04 ou 2015.10)

Il faut donc dans la partition de boot les fichiers suivants :

  • zImage
  • sun7i-a20-olinuxino-micro.dtb
  • boot.scr
  • boot.cmd (facultatif : c’est la source qui a permis de générer boot.scr)
  • uEnv.txt (facultatif : pour passer des paramètres au noyau)

Attention, si vous utilisez l’image actuellement fournie par Olimex (A20-OLinuXino-MICRO Debian Jessie with kernel 3.4.103+ release 11), il y a un petit piège : sur une machine allumée, la partition de boot n’est pas montée sur /boot (qui contient pourtant des données de démarrage), mais dans /media/olimex/6B4C-FFFD : c’est bien là qu’il faut déposer le nouveau noyau. Autre solution : déposer les fichiers directement dans la partition de boot de la carte SD, en la mettant dans un ordinateur.

NB : je n’ai pas encore testé de faire ces mêmes manipulations en partant d’un filesystem installé avec l’installeur de Debian Jessie (et non issu de l’image fournie par Olimex). A priori ça devrait être la même chose.

En cas de noyau qui ne démarre pas

Pour comprendre pourquoi, il est possible de compiler le noyau en ajoutant des options de debug : https://linux-sunxi.org/Mainline_Kernel_Howto#Early_printk

Nécessité d’un patch sur les versions 4.3.x et 4.4.x

En l’état, il y a hélas un bug qu’il faut patcher manuellement : https://lkml.org/lkml/2015/11/16/46

Deux lignes de code à ajouter manuellement. Merci à plaes, apritzel et montjoie pour leur aide au diagnostic sur IRC (#linux-sunxi).

Ce correctif devrait être intégré dans la version 4.5 du noyau Linux.

Comment vérifier si l’accélération matérielle est disponible ?

cat /proc/crypto | grep sun4i devrait renvoyer :

driver : ecb-des3-sun4i-ss
 driver : cbc-des3-sun4i-ss
 driver : ecb-des-sun4i-ss
 driver : cbc-des-sun4i-ss
 driver : ecb-aes-sun4i-ss
 driver : cbc-aes-sun4i-ss
 driver : sha1-sun4i-ss
 driver : md5-sun4i-ss

Parmi les applications qui savent en tirer parti, il y a dm-crypt :

cryptsetup benchmark –cipher aes-cbc devrait donner des valeurs de plus de 25 Mo/s (au lieu de 12 à 15Mo/s avec le noyau 3.4 fourni par Olimex, qui ne supporte pas d’accélération matérielle) :

# Algorithm | Key | Encryption | Decryption
    aes-cbc   256b  25.4 MiB/s   25.5 MiB/s

Si cette commande vous renvoie une erreur « Required kernel crypto interface not available. Ensure you have algif_skcipher kernel module loaded. », c’est que vous n’avez pas activé l’option « User-space interface for symmetric key cipher algorithms » mentionnée plus haut dans la configuration du noyau linux.

Édité le 09/03/2016 : si le cryptsetup benchmark fonctionne bien et donne effectivement de bons résultats, je n’ai pas encore réussi à utiliser dm-crypt sur une partition chiffrée. Probablement parce qu’il me manque d’autres options à la compilation du kernel ?

2016-02-23

JAH-12 – Du contournement d'un serveur mandataire HTTP

Journal de bord du capitaine :
Date : 04 avril 2012
Lieu : Perdu dans le cyber espace

Il arrive que l'on se retrouve en "milieu hostile" avec un accès restreint vers l'extérieur et une surveillance de tout ce qui circule sur le réseau local auquel on est rattaché. Or on peut parfois avoir le besoin, ou tout simplement l'envie, de faire tomber ces barrières. Attention ! Il convient d'être prudent, si ces mesures de protection ont été mises en place par les administrateurs du réseau que vous utilisez c'est probablement pour de bonnes raisons. Les contourner se fera à vos risques et périls et représentera le plus souvent une rupture de la charte que vous vous êtes engagé à respecter lorsqu'on vous a donné vos accès au réseau.

Mes besoins étaient les suivants :

  • Utiliser des applications nécessitant l'accès à d'autres ports distants que les classiques 80 et 443.
  • Utiliser d'autres protocoles que HTTP et HTTPS.
  • Naviguer sur le web sans restriction.
  • Naviguer sur le web en toute confidentialité.

Mon but était donc d'utiliser un tunnel HTTP pour faire passer une connexion SSH vers mon serveur personnel et utiliser cette connexion SSH pour faire transiter toutes mes requêtes vers l'extérieur via mon serveur. Ainsi la connexion entre mon bureau et mon serveur serait chiffrée ce qui empêcherait l'espionnage et les restrictions. Le principe d'un tunnel HTTP est d'encapsuler des paquets d'un protocole différent dans des paquets HTTP. Dans la pratique, j'allais devoir me connecter au serveur mandataire de mon entreprise en lui envoyant des paquets de type HTTP, à destination d'une adresse et d'un port qu'il autorisait, dont le contenu contiendrait de quoi ouvrir une connexion SSH.

La première chose à faire était de récupérer des informations sur mon "ennemi" ("Know your foe" comme disent ces chers anglophones), pour cela j'ai simplement regardé la configuration de mon navigateur internet. J'ai alors pu constater que la configuration du navigateur pour accéder à internet via le serveur mandataire utilisait un fichier d'auto-configuration (extension "pac"). Ayant l'adresse de ce fichier je l'ai simplement récupéré via mon navigateur. Il contenait tout un tas de règles pour utiliser tel ou tel serveur mandataire selon le domaine auquel on souhaitait accéder (pour tout les services intranet) et, à la fin, l'adresse (et le port) du serveur servant à toutes les requêtes vers l'extérieur.

En l'occurrence l'adresse désignait un ensemble de machine sur lesquelles étaient reparties l'ensemble des requêtes, ce qui signifie que ma connexion sortante n'avait pas la même adresse à chacune de mes requêtes. Cela a son importance, car de ce fait je ne pouvais pas programmer une règle sur mon serveur du type : "rediriger toutes les connexions venant de cette adresse IP vers tel port".

Sur mon serveur personnel, il me fallait mettre en place un serveur SSH qui écoute sur un des ports autorisés par le mandataire. En général, on utilise le port 443 car c'est celui du protocole HTTPS. Le problème est qu'il n'est, en principe, pas possible que deux applications distinctes écoutent sur le même port de la même interface réseau. Donc si SSH écoutait sur le port 443, apache ne pouvait pas et donc mon site web n'aurait plus été accessible sur ce port. La solution est venue sous la forme du logiciel sslh conçu spécifiquement pour faire cohabiter sur le même port les services SSL et SSH. Techniquement, la seule application qui écoute sur l'interface réseau externe sur le port 443 est sslh qui va avoir pour rôle de détecter la nature de la connexion (SSL ou SSH) et de la transférer sur un autre port et/ou une autre interface réseau.

Une fois sslh installé, il ne se lance pas automatiquement ; il faut modifier le fichier de configuration afin de décider ce qui sera transféré et où. J'ai choisi de ne pas modifier la configuration de mon serveur SSH (en écoute sur toutes les interfaces réseaux sur le port 22) mais d'adapter celle de mon serveur HTTP pour qu'il n'écoute plus que sur l'interface réseau interne (mais toujours sur le même port). Ainsi lorsqu'une connexion extérieure arrive sur le port 443, sslh va la rediriger vers l'interface interne sur le port 22 dans le cas d'une connexion SSH et vers le port 443 dans le cas d'une connexion SSL. L'aide de sslh, ainsi que les nombreux exemples disponibles sur internet m'ont permis de configurer correctement, dès la première tentative, sslh et apache [1] .

Une fois mon serveur prêt et les informations essentielles sur le mandataire récupérées, il n'y avait plus qu'à tester. Travaillant sous Microsoft Windows XP, j'ai dû commencer par installer un client SSH (et oui malgré la taille gargantuesque de leurs systèmes d'exploitation, Microsoft n'inclut toujours pas de client SSH); j'ai donc opté pour le célèbre PuTTY.

Pour se connecter, rien de plus simple: je rentre le nom de mon serveur et le port cible (en l'occurrence 443) puis je vais dans la section Connexion->Proxy, sélectionne HTTP, et rentre le nom du mandataire et le port cible. PuTTY va empaqueter les informations pour la connexion SSH dans des paquets HTTP, le mandataire, n'y voyant pas d'objection, va laisser passer le paquet vers sa destination finale. Là, sslh détecte qu'il s'agit d'une demande de connexion SSH et va transférer le paquet sur le port d'écoute du serveur SSH. PuTTY ouvre alors un terminal demandant le login puis le mot de passe, une fois les identifiants acceptés la connexion SSH est établie. J'ai ainsi accès, via mon serveur, au monde extérieur sans surveillance, ni restriction d'aucune sorte. Les paquets transitant par le mandataire ne contenant que du contenu chiffré, l'ingérence est donc impossible.

À cet instant, je n'avais accès qu'à un terminal sur mon serveur, or ce dont j'avais besoin c'est que des applications puissent utiliser ce tunnel pour se connecter à des serveurs distants. La solution la plus simple : utiliser un serveur mandataire SOCKS. Le principe était de créer un mandataire qui écoutait sur un port local et faisait transiter les paquets qui lui étaient envoyés, via ma connexion SSH, vers l'extérieur. Bien sûr, la connexion était bidirectionnelle, les réponses des serveurs contactés par mes applications utilisant le tunnel étaient envoyées à mon serveur qui via le mandataire SOCKS les renvoyait aux applications demanderesses.

PuTTY sait très bien gérer la création de mandataire SOCKS, pour cela il suffit, au moment d'entrer les informations de connexion, d'ajouter dans la section Connexion->SSH->Tunnel le numéro du port d'écoute sur la machine locale et cocher Dynamic. Une fois la connexion ouverte, j'ai modifié les paramètres de connexion de mon navigateur en lui indiquant d'utiliser le mandataire de type SOCKS se trouvant sur le port que j'avais défini. Un rapide test, en tentant une connexion à un site normalement bloqué par le mandataire de mon entreprise, m'a montré que mon tunnel fonctionnait bien.

J'ai pu utiliser ce tunnel pour mon navigateur web (Firefox), un logiciel de messagerie instantanée (Pidgin), un logiciel de messagerie (Thunderbird) et un logiciel de musique en streaming (Spotify). Pidgin permettant de configurer chaque compte avec des paramètres réseau distincts cela m'a permis d'utiliser un seul et même client pour ma messagerie instantanée professionnelle et personnelle. En théorie, toutes les applications nécessitant un accès à internet et pouvant se configurer pour utiliser un mandataire SOCKS peuvent être utilisée via ce tunnel, et pour les applications ne gérant pas "nativement" le protocole SOCKS, il existe des programmes permettant de SOCKSifier une application [2]. Dernier point bien pratique, une option permettant d'autoriser les connexions venant de l'extérieur sur mon mandataire m'a permis de dépanner des collègues qui avaient besoin d'accéder à certains serveurs extérieurs normalement bloqués.

Sous GNU/Linux, créer un tel tunnel avec proxy SOCKS n'est pas plus compliqué. Openssh gérant très bien la redirection de port (locaux, distants ou dynamique) il suffit d'utiliser une petite application complémentaire qui va se charger d'encapsuler cette connexion pour le mandataire HTTP. J'ai choisi d'utiliser corkscrew qui se configure en quelques lignes et fait parfaitement son travail. Une fois le tunnel établi, comme sous Windows, il suffit de configurer les applications pour utiliser le mandataire SOCKS précédemment créé.

Un des principaux problèmes de cette solution est la limitation du débit. En effet, dans le cas où le serveur servant à établir le tunnel est relié à internet par une connexion ADSL domestique, le débit montant sera le plus souvent de l'ordre d'une centaine de kibioctet tout au plus. Pour de la navigation web, du streaming musical (en faible qualité) et de la messagerie instantanée cela suffit amplement ; mais pour tout autre type d'application, tel que le téléchargement de fichiers volumineux, cela peut vite devenir extrêmement long.

Autre point à bien comprendre : les connexions ne sont chiffrées qu'entre le client et le serveur de destination du tunnel. Une fois sorties de ce relais, les informations ne seront pas systématiquement chiffrées. Tout se passera exactement comme si les applications tournaient nativement sur le serveur relais; d'un point de vue extérieur c'est donc l'adresse IP du serveur relais qui sera vue.

Conclusions :

  • Mettre en place un tunnel est somme toute assez simple une fois que l'on a identifié les outils nécessaires pour répondre à nos besoins.
  • Il faut être bien conscient de ses responsabilités lorsque l'on contourne de tels systèmes de protection, on créé une brèche dans la sécurité qui, si elle était exploitée à des fins malhonnêtes, pourrait s'avérer catastrophique.
  • Toute prison à ses tunnels vers l'extérieur. :-)

Prochaine entrée dans le journal : De la gestion des certificats SSL

Notes

[1] J'ai depuis modifié ma configuration suite à des conflits et des instabilités dans cette configuration. Apache écoute maintenant sur le port 444 en local et tout va bien.

[2] Toutes les tentatives de connexions sortantes d'une application sont interceptées par un programme tiers qui se charge de les rediriger vers le mandataire SOCKS.

Sonerezh 1.0.0 et Nativefier


Je vous parlais déjà avec grand bien de Sonerezh en mars dernier. Depuis, plus grand chose. Pourtant, la version 1.0.0 de cette application est sortie ce 16 janvier. Avec les copains de diaspora*, on préparait notre balade en Belgique pour le FOSDEM 2016, d’où l'absence de billet sur cette release : j'me rattrape !

Au programme de cette première vraie version stable, peu de nouveautés. Il faut dire qu'elle était déjà bien fichue. Personnellement, je trouvais l'interface déjà impeccable. Les développeurs ont quand même trouvé la bonne idée d'afficher la liste des 6 derniers albums ajoutés à la collection. C'est un détail, mais un détail agréable. Pour le reste, c'est de la stabilisation à gogo.



Pour certains, il manque toujours la possibilité de téléverser directement sa musique via l'application. C'est pas faux, m'enfin, je transfère mes albums à travers un point de montage SSH directement depuis Nautilus (ou Fichier). Y'a toujours moyen de se débrouiller.

Sonerezh, c'est donc bien. Je ne me sers plus que de lui pour écouter ma musique et pouvoir l’écouter absolument partout, y compris depuis mon Flame, même si l'interface mobile pourrait être un peu améliorée.

En bon fanboy, j'ai décidé de proposer à mon frère de s'en servir. Lui, le windowsien classique, cherchait un bon moyen d’écouter du bon son sans trop se prendre la tête. On n'a pas vraiment les mêmes goûts musicaux, mais ça passe, comme on dit.
Pour lui faire passer la pilule extrêmement facilement, je suis passé par Nativefier. Voici le résultat :



Ce logiciel permet d'encapsuler un site web et de le transformer en application. Je schématise beaucoup en disant ça, mais l’idée est là.
Ci-dessus, c'est mon instance Sonerezh, un site web donc, qui est affiché comme si c’était un logiciel de bureau classique. Chouette, non ? Peu importe le système d'exploitation que vous utilisez, Nativefier permet de pondre une application pour GNU/Linux, Windows et MacOS.
J'ai donc exécuté la commande qui va bien et j'ai envoyé le .exe (via un partage ownCloud) à mon frangin. Mis à par le fait que je passe encore plus pour une sorte de magicien à ses yeux, j'ai offert à mon double une belle façon d’écouter de la musique sans s'emmerder à utiliser des trucs pleins de pubs, chers et qui n'ont pas forcément les albums qu'on aime.

Le seul gros truc qui coince, c'est que la couche technique qui permet ça est basée sur Chrome. Grosse tristitude. Si vous avez des infos sur un système équivalent mais basé sur Firefox, faites tourner !


<noscript></noscript>

2016-02-21

[Documentaire] Les gardiens du nouveau monde


Voici un documentaire incroyable qui n'est pas tout jeune mais que je vous propose de regarder. Il est réalisé par Flo Laval et on y retrouve Jean-Marc Manach, Jérémie Zimmermann et des gars de chez Telecomix.
Quand je dis que je vous le propose, c'est faux : profitez de votre dimanche au calme pour foncer le regarder si vous ne l'avez pas vu ! ;-)

<iframe allowfullscreen="" frameborder="0" height="360" src="https://www.youtube.com/embed/t5tBsVX5g0g" width="640"></iframe>


Bon visionnage et bon dimanche !


<noscript></noscript>

2016-02-19

Contributions #1

Voici une brève d'un certain nombre de mes contributions (les plus abouties) de ces deux derniers mois.

Archlinux

J'ai amélioré l'empaquetage de Dask avec l'ajout de la suite de tests, ce qui m'a demandé d'empaqueter plusieurs autres modules. J'ai dialogué avec le développeur de dask afin d'améliorer la documentation pour les empaqueteurs. Ce module python sera utilisé comme dépendance par défaut de scikit-image. Il est fort à parier que pour la prochaine sortie de scikit-image, le paquet dask passera dans community. Mon travail devrait donc permettre un transfert plus rapide.

J'ai aussi mis à jour pims avec aussi un retour vers le projet ici ou encore à cause d'échecs de tests unitaires.

D'autres paquets ont été mis à jour comme Joblib ou mat.

Jirafeau

Jirafeau est un projet permettant d'héberger des fichiers. J'en héberge une instance sur mon serveur. J'ai contribué à deux petits patchs pour mieux documenter l'API et l'usage du script bash et faciliter la compréhension d'erreurs lors de l'utilisation du script d'envoie. J'ai passé pas mal de temps à résoudre des problèmes sur mon installation et j'espère que cela facilitera l'appropriation de ce code à l'avenir.

Scikit-image

Peu de temps pour contribuer à scikit-image ces temps-ci. Néanmoins, j'ai notamment trouvé une erreur dans la doc que j'ai patché, et ceci avant la sortie d'une version stable. Ca devrait permettre d'éviter de perdre quelques débutants.

Scipy

J'ai rapporté un bug que plusieurs personnes avaient rencontré mais pas remonté. Avec Ralf, on a compris que le bug était déjà réparé dans master (la prochaine fois, je commencerai pas ça) mais ça a au moins eu le mérite de remonter un rapport à pip qui n'affiche plus les informations de compilation depuis 0.8.x, c'est-à-dire l'instauration du spinner. Ce qui est très gênant.

Ikiwiki-pandoc

C'est un projet dont j'assure la maintenance, plus que l'écriture.J'ai eu la chance de pouvoir fusionner les contributions de Baldur qui ont permis de porter le code aux dernières évolutions de pandoc. Je n'ai presque rien fait et je suis heureux de voir qu'avoir regrouper un certain nombre de contributions sur un dépôt mort donne vie au code et que des gens l'utilise.

Gitbackup

Suite au billet de Carl Chenet sur les dangers de github, j'ai décidé de mettre du propre un script que je possédais et qui permet de gérer des miroirs de dépôts git.

Python-bibtexparser

Du travail est en cours sur bibtexparser, grâce à de très belles contributions d'Olivier Mangin pour utiliser pyparsing. Il reste cependant encore du travail pour arriver à la prochaine sortie. Les utilisateurs sont de plus en plus nombreux, ce qui obligent à gérer finement les changements d'API.

share.sciunto.org

Pour la bidouille, j'ai créé une page sur le remplacement d'un couvercle cassé de chambre à vide en verre pour avoir, au final, une étuve à vide fonctionnant à 130°C.

Publication aussi du montage d'un interféromètre de Mach-Zehnder.

Quartzy : fermeture d'un service SaaS

Notre labo utilisait quartzy, un service en ligne permettant de gérer du matériel de laboratoire. Quartzy a décidé de fermer une partie de ses services, dont ceux que nous utilisions. Déjà discuté sur ce blog, la solution que je propose est d'héberger ses services car le SaaS n'assure aucune pérennité, et ceci est un exemple supplémentaire. Un thésard du labo était preneur d'apprendre l'administration système et le webmastering. J'ai donc fait du mentoring pour installer une machine hébergée par l'université et installer un service sur ce serveur. Le choix s'est porté vers un logiciel sous licence GPL. Au passage, ce thésard passe à l'auto-hébergement pour son site web. Une personne sensibilisée et un service libéré.

2016-02-17

Entretien avec Adrienne Charmet-Alix de la Quadrature du Net


Entendre Adrienne Charmet-Alix parler d'Internet, c'est rassurant et encourageant. Prenez donc le temps de regarder cette courte vidéo de 12 minutes !

<iframe allowfullscreen="" frameborder="0" height="360" src="https://www.youtube.com/embed/9ve-BC2MAjw" width="640"></iframe>

En plus, ça sort tout droit d'Arte : de quoi passer pour une sorte d'intellectuel ;-)


<noscript></noscript>

2016-02-13

JAH-11 – Du partage des données par BitTorrent

Journal de bord du capitaine :
Date : 20 mars 2012
Lieu : Perdu dans le cyber espace

Ellipse de temps, partie 2, le retour. Voilà près d'un an que je n'avais pas consigné mes tribulations dans ce journal. Les jours, semaines, mois, années passent, j'ai le temps ponctuellement de dépiler certaines tâches de ma liste de choses à faire mais cela n'avance pas aussi vite que je le voudrais et je préfère parfois prendre du temps pour faire avancer les choses que de les consigner par écrit. Bref, le temps nous file entre les doigts, c'est pas nouveau, tout le monde le sait et tout le monde s'en fout.

J'ai décidé de consacrer cette entrée de journal au partage de données par BitTorrent. Le problème s'est présenté à moi en ces termes : j'avais une grande quantité de vidéos (une douzaine de Gio [1]) à partager avec des personnes distantes, comment m'y prendre ?

J'envisageai quatre possibilités :

  • Graver le tout sur des DVDs et utiliser le bon vieux système postal pour envoyer tout ça.
    • Avantage : pas de problème de bande passante.
    • Inconvénients : coût (DVDs vierges, envois recommandés etc), flexibilité (les gens ne pouvaient pas choisir les vidéos) et surtout cette méthode était "Soooooooooo XXème siècle !"
  • Mettre à disposition mes vidéos sur un serveur tiers :
    • Avantage : téléversement une unique fois des vidéos (donc économie de bande passante pour moi).
    • Inconvénients : centralisation (les données ne sont disponible qu'à un seul endroit) et données personnelles sur un serveur que je ne contrôle pas.
  • Mettre à disposition les vidéos sur mon serveur pour un téléchargement direct.
    • Avantage : les données restent sur mon serveur.
    • Inconvénients : centralisation et téléversement des mêmes données multipliées par le nombre d'utilisateurs or la bande passante montante étant très limitée en ADSL, cette solution augmentait énormément le temps d'obtention des données.
  • Mettre en place un système de partage des données pair à pair en utilisant le protocole BitTorrent.
    • Avantages : données sur mon serveur, décentralisation des données au fur et à mesure et donc téléversement des données inférieur ou égal à la solution de téléchargement direct.
    • Inconvénients : Temps d'obtention des données assez long mais néanmoins inférieur à la solution précédente (ou au pire égal).

La solution me semblant la plus adaptée était la quatrième, je me suis donc mis à chercher de la documentation sur le protocole BitTorrent. Petit rappel pour les nouveaux : l'utilisateur télécharge un fichier .torrent qui contient des informations sur les données à échanger et l'adresse du tracker (le tracker est en fait un serveur qui recense tout les pairs partageant ces données qu'elles soient en cours de téléchargement ou complète), le client va alors se connecter au tracker pour connaître les pairs avec qui il va ensuite pouvoir communiquer directement pour échanger des parties de données qui leur manquent. L'avantage de ce protocole apparaît dès qu'il y a plus de deux pairs : le transfert devient plus efficace que du téléchargement direct car une fois qu'un pair a récupéré un morceau de fichier, il peut à son tour le partager avec ceux qui ne l'ont pas encore, évitant ainsi à la source originelle de retransmettre à tout le monde cette partie de donnée [2]. Dernier point de vocabulaire : celui qui envoie est un seeder et celui qui reçoit un leecher. Lorsqu'on télécharge un fichier via le protocole BitTorrent on est donc en général les deux à la fois.

Pour partager mes données il fallait donc :

  • Mette en place un tracker sur mon serveur.
  • Créer le fichier de métadonnées .torrent.
  • Utiliser n'importe quel client pour commencer le partage.
Mais là, surprise ! Les logiciels concernant la partie client sont légion, alors que les serveurs ne sont qu'une poignée. Les deux principaux qui étaient disponibles dans les dépôts Debian étant : BitTorrent (le serveur originel développé et maintenu par un des auteurs du protocole) et BitTornado (un fork du précédent). Les deux logiciels étant relativement semblable, notamment en terme de configuration, j'ai décidé d'utiliser BitTorrent. Il est intéressant de noter que la documentation upstream de ce logiciel est quasi inexistante et que la man page fournie dans Debian est l'œuvre du l'empaqueteur.

Ce faible nombre de serveurs BitTorrent se répercute de manière très visible sur la quantité de documentation disponible sur le web. En effet, les tutoriels ou autre exemples de configuration se comptent presque sur les doigts de la main. Au final, la configuration n'est pas très compliquée et j'ai pu obtenir rapidement un serveur fonctionnel. La génération du fichier de métadonnées est on ne peut plus simple et une fois cette étape faite il n'y a plus qu'à lancer le partage depuis n'importe quel client.

Recherchant un client utilisable en console, je me suis tourné vers rTorrent. Là encore, il n'y a que quelques paramètres à ajuster afin de personnaliser sa configuration et rTorrent est prêt à échanger avec d'autres pairs. À noter que rTorrent dispose d'une option intéressante lors du démarrage d'un partage : superseed. Elle permet entre autre d'optimiser la bande passante de la source originelle en choisissant les morceaux de fichiers à partager, afin que les autres pairs puissent le plus rapidement possible échanger entre eux sans se reposer uniquement sur la source. À noter également, j'ai lancé rTorrent dans le multiplexeur de terminal : screen, cela permet de le garder actif même lorsque la session qui a servi à le lancer est fermée.

Lors de ce premier essai, j'ai rencontré plusieurs fois des problèmes de stabilité : au bout d'un certain temps le serveur s'arrêtait. En cherchant la cause du problème dans les logs, j'ai pu me rendre compte de leur inutilité ! En effet, ils sont gérés de telle manière que lors d'un plantage, l'écriture dans les logs est interrompue avant que les dernières données aient pu être inscrites, ce qui rend l'investigation d'éventuels problèmes assez complexe. Je soupçonne malgré tout un problème lié aux connexions en IPv6.

Devant ces problèmes de stabilité et manquant de temps pour investiguer, j'ai changé de serveur pour utiliser BitTornado et j'ai par la même occasion désactivé l'IPv6. Une fois ce serveur lancé, je n'ai plus eu de soucis de plantage, par ailleurs BitTornado semble mieux maintenu que BitTorrent, je recommanderai donc plutôt l'utilisation de BitTornado.

En approfondissant mes recherches sur BitTorrent, j'ai appris qu'aujourd'hui un tracker n'était plus nécessaire, il suffit d'utiliser la Distributed Hash Table (DHT). En pratique lorsqu'on utilise la DHT n'importe quel pair peut servir de tracker, il n'y a donc plus besoin d'un tracker central, cela simplifie grandement le processus de partage. Néanmoins, pour l'instant, elle est surtout vue comme un complément des trackers classiques. En effet, les outils fournis avec BitTorrent ou BitTornado ne permettent pas de créer un fichier de métadonnées sans préciser de tracker, bien que cela soit parfaitement possible [3].

Conclusions :

  • L'échange d'importantes quantités de données est tout à fait possible de manière optimisée sans utiliser de service tiers et centralisé.
  • Les outils existent mais nécessitent un minimum de temps et d'investissement pour bien les utiliser, la documentation n'étant pas abondante.
  • L'utilisation de la DHT permet de faciliter le partage et rend le processus accessible au plus grand nombre si la génération d'un fichier de métadonnées est par exemple incluse dans le client BitTorrent.
Prochaine entrée dans le journal : Du contournement d'un serveur mandataire HTTP .

Notes

[1] Non le « i » n'est pas une faute de frappe, il s'agit de Gibioctets (230 octets) et non de Gigaoctets (109 octets). Plus de précisions sur les préfixes binaires ici .

[2] L'article Wikipédia sur le protocole BitTorrent contient une animation expliquant très bien ce principe. Vous pouvez la voir ici .

[3] On peut néanmoins trouver des scripts permettant de le faire comme par exemple celui-ci.

2016-02-11

Erreur curl: (60) SSL certificate avec FreshRSS




Je vous propose une magouille, un hack, pour contourner ce genre d'erreur rencontré avec mon instance FreshRSS. J'adore ce lecteur de flux RSS, j'y suis accro, au point que je deviens tremblant quand un de mes abonnements déconne. Pour le coup, j'avais de quoi trembler : c'est mon Mediapart qui refusait de convenablement se faire relever. Je ne suis abonné qu'à trois journaux numériques : Mediapart, Next Inpact et Arrêt sur Images. Si vous ne savez pas quoi suivre sur l'Internet mondial, vous pouvez commencer par ces trois là.

Donc, plus d'articles du quotidien numérique le plus chouette du moment. Une sombre histoire de certificat SSL qui ne passe plus et qui retourne une erreur. Curl refuse de le gober. Tristitude.

Pour contourner ce problème, le hack consiste à faire sauter la vérification de ce certificat via ces quelques lignes à ajouter dans le fichier de configuration :

[...]
'curl_options' =>
array (
        CURLOPT_SSL_VERIFYHOST => 0,
        CURLOPT_SSL_VERIFYPEER => false,
 )
[...]

C'est un hack, je me répète. Il n'est pas très grave, mais il fait sauter une vérification ayant pour but de certifier l'origine de l'information délivrée via HTTPS. Si vous avez d'autres idées, les commentaires sont ouverts. Je ne suis pas très à l'aise avec cette magouille mais je n'ai pas (encore) trouvé d'autres solutions.


<noscript></noscript>

2016-02-09

Mozilla dépecée



Je parle ici de la communauté Mozilla, pas seulement de la Fondation ou de la MoCo.

Il y a des rumeurs qui courent. Les gens savent assez peu l'histoire de la vie interne de la Fondation, mais certaines personnes racontent des choses de-ci, de-là. Loin de moi l'envie de colporter des rumeurs infondées mais j'ai comme une envie de raconter ce que je sais, ce qu'on m'a dit.

Lorsque le web était étouffé par Internet Explorer de Microsoft, Mozilla est née des cendres de Netscape pour proposer un nouveau navigateur. On connaît tous l'histoire et nous sommes heureux d'en profiter.
Ce que les gens savent moins, c'est que Google était partie prenante via son financement. C’était dans l’intérêt de tout le monde. Google arrosait Mozilla pour pousser les nouveaux standards du web dans les ordinateurs du tout à chacun. Mais, un jour, Google s'est lancé dans l'aventure avec Chrome. Les technologies étaient là et la notoriété de l'entreprise de Mountain View n’était plus à faire. Dans les jours qui ont suivi l'annonce officielle de Chrome, certaines rumeurs parlent même du lendemain, la Fondation Mozilla a vu ses développeurs foutre le camp pour se poser dans les bureaux de Google. On ne parle pas de nombre, mais nul doute que c’était suffisant pour faire serrer des dents. Chrome venait de siffler une bonne partie des effectifs chargés de développer Firefox.

Il y a quelques jours, on apprenait l'abandon de FirefoxOS. Tristement. On se sent encore frustré, touché par une trahison. On touchait du doigt un début d'alternative aux OS emmerdants que nous refusons d'utiliser. On était fier de pouvoir se servir d'autre chose, loin de iOS et d'Android, même s'il restait du travail à faire. Quand on aime, qu'on est enthousiaste, on passe sur les petits bogues et les finitions douteuses.
Ce qu'on sait moins, c'est qu'une quarantaine, 40, de développeurs de FirefoxOS avait quitté le navire pour rejoindre une startup et développer un fork au doux nom de H50S. Là, je peux vous sortir des sources. Une histoire de gros sous et de gros morceaux de Mozilla : des développeurs et des gros patrons.

Ce sont deux histoires différentes, à des époques bien différentes, mais elles ont en commun une chose : dépecer Mozilla et le travail de sa communauté pour le bénéfice d'autrui. Je m'avance peut-être, mais ces deux anecdotes laissent un goût amer. Au choix, on se dira que l'ambiance de travail était à chier, ou que les idées étaient à choper, quitte à ébranler sérieusement et froidement le processus déjà fragile qui nous offre des alternatives. Je ne blâme personne, tout le monde fait ses propres choix. Je constate juste que la vie de la Fondation ne doit pas toujours être une partie de plaisir et que les jugements, les commentaires et les articles qui paraissent depuis quelques jours n'aident pas à trouver une solution à un problème classique : garder les idées et les cerveaux.


<noscript></noscript>

2016-02-03

JAH-10 – Des petits réglages pas indispensables mais bien pratiques

Journal de bord du capitaine :
Date : 21 avril 2011
Lieu : Perdu dans le cyber espace

Pendant les longues heures que j'ai passé à jouer avec mon serveur auto-hébergé, je me suis parfois détourné de mes grands objectifs initiaux pour m'occuper de petits détails à la fois divertissants et instructifs.

Lorsque l'on se connecte à l'aide d'un terminal sur une machine distante sans aucun serveur graphique, les réglages de résolutions d'affichage du serveur sont inintéressant car sans conséquence pour le client. Néanmoins, après mon déménagement, j'ai eu l'occasion de travailler directement sur mon serveur en y connectant un écran et en travaillant dans des TTYs or dans ce cas la résolution du TTY redevient un sujet d'actualité.

Sur le web on trouve beaucoup du tutoriels sur ce réglage pour grub 1 or dans debian squeeze, grub est par défaut dans sa version 2. Avec un peu de patience, j'ai pu trouver le nom du paramètre qui m'intéressait : GRUB_LINUX_GFX_MODE. En cherchant ce paramètre dans le man et le info de grub, j'ai pu avoir les informations nécessaires sur les valeurs qu'il pouvait accepter (déterminée à l'aide de vbeinfo) et son paramètre complémentaire : GRUB_LINUX_GFX_PAYLOAD. Auparavant la configuration de grub se faisait principalement en éditant le fichier menu.lst, dorénavant la configuration de grub est "éclatée" en plusieurs fichiers et scripts qui créent le fichier de configuration final avec la commande update-grub. Il convient donc de définir ces deux paramètres au bon endroit en l'occurrence dans /etc/default/grub. Une fois ce réglage fait et grub mis à jour, j'avais, au redémarrage suivant, le menu de sélection de grub ainsi que mes TTYs en 1280 x 1024 x 32 (le dernier paramètre étant lié à la profondeur des couleurs).

De même, lorsque l'on passe de nombreuses heures à lire des fichiers de configuration dans un terminal, il est très appréciable de pouvoir bénéficier de la coloration syntaxique. Cela permet de colorer certaines parties de texte selon leur fonction, par exemple : mettre les commentaires d'un fichier de configuration dans une couleur différente du corps du fichier. J'utilise comme éditeur de texte : nano, qui est installé par défaut avec des exemples de configurations de coloration syntaxique qui ne sont néanmoins pas activées. Selon l'emplacement du fichier de configuration de nano qui est modifié pour activer cette option, la coloration syntaxique sera disponible pour tout les utilisateurs ou seulement pour un utilisateur en particulier. Étant administrateur sur ma machine, j'ai fais le choix de l'activer pour tout les utilisateurs. Il peut être bon de noter qu'une des raisons pour lesquelles la coloration syntaxique est désactivée par défaut est certainement le surcoût en ressources processeur que cela induit, en effet, des règles de coloration parfois complexes appliquées à un gros fichier peuvent occasionnellement provoquer un ralentissement [1].

Chaque fichier de configuration de coloration syntaxique regroupe un certain nombre de règles qui s'appliquent à tout les fichiers dont l'extension correspond à ce qui est inscrit dans l'en-tête du fichier. Concrètement, cela signifie par exemple que les règles de coloration pour les fichiers écrit en langage C seront regroupées dans un seul fichier prenant en charge les fichiers d'extension "c" et "h". Bien que nombreux, les types de fichiers pris en charge pour la coloration syntaxique ne sont pas exhaustif, heureusement on trouve facilement sur le web des fichiers pour compléter ceux déjà présent. Dans mon cas, j'ai trouvé un exemple de fichier gérant les .conf et .cnf auquel je n'ai eu qu'à apporter de petites modifications pour colorer les fichiers de configurations d'ejabberd.

Dans un autre domaine, par soucis d'économie d'électricité et de bruit (bien que globalement très faible), je me suis intéressé aux utilitaires de gestion de vitesse du ventilateur de ma carte mère. Pour que fancontrol puisse fonctionner, il doit récupèrer les informations de la carte mère grâce aux sensors dont j'ai brièvement parlé dans une précédente entrée de ce journal. Ces sensors permettent de connaître, par exemple, la température du contrôleur de la carte mère ainsi que celle du processeur ou encore la vitesse de rotation des ventilateurs. Lors de mon installation sous lenny cela fonctionnait parfaitement mais j'ai dû faire face à une difficulté imprévue lors de la mise à jour de mon noyau : les données de vitesse des ventilateurs et de températures ne pouvaient plus être lues. Une recherche sur le site de lm-sensors m'apprit que cela était dû à un mauvais fonctionnement de l'ACPI et que pour contourner ce problème, il fallait lancer le noyau avec une option particulière [2]. Bien que déconseillé, j'ai activé cette option en modifiant la configuration de grub. Après un redémarrage, les données étaient de nouveau accessibles et j'ai pu procéder à la configuration de fancontrol.

Les paramètres nécessaires à la configuration de fancontrol ne sont pas nombreux mais néanmoins pas forcement triviaux. La création du fichier de configuration est assistée par un programme interactif faisant par exemple varier l'intensité du courant dans un bus de la carte mère et il faut surveiller à quel moment le ventilateur s'arrête, redémarre etc. En soit cela n'est pas compliqué mais les vérifications demandées à l'utilisateur ne sont pas forcément claires. Malgré tout, j'ai fini par obtenir un fichier conforme à mes attentes.

Comme la plupart des logiciels de mon serveur fancontrol est configuré à l'aide d'un fichier texte placé dans le répertoire /etc [3]. Lorsqu'un logiciel est complexe et qu'il nécessite plusieurs fichiers de configurations, ils sont en général regroupés dans un sous répertoire de /etc tel apache2, dans le cas contraire le fichier est à la racine du répertoire. Étant débutant dans l'administration avancée d'un système, il pouvait être intéressant de garder une trace des évolutions de mes fichiers de configurations afin de pouvoir revenir en arrière à une configuration fonctionnelle en cas d'erreur de ma part. En discutant sur le salon debian-fr@chat.jabberfr.org, j'ai découvert etckeeper qui est en réalité une surcouche au gestionnaire de version git. Il permet tout simplement d'automatiser le versionnage du répertoire /etc en effectuant, par exemple, des commits automatiques après chaque installation d'un paquet. Son installation et sa configuration sont enfantin, je n'ai même pas eu à modifier les paramètres par défaut.

Dans la catégorie des petits utilitaires bien pratique, le salon debian-fr m'a également permis de découvrir ncdu qui ajoute une navigation graphique à l'aide d'une interface ncurses au programme du permettant de connaître le Disk Usage.

Conclusions :

  • Augmenter la résolution et ajouter un peu de couleurs dans un terminal est très simple et permet de rendre les heures passées sur un serveur beaucoup plus agréable.
  • De nombreux utilitaires simple à installer et à configurer existent afin de mieux contrôler son PC, il ne faut pas hésiter à s'en servir.
  • Les utilisateurs d'expérience sont une des meilleures sources pour découvrir de nouveaux logiciels bien pratiques. De plus, ils peuvent donner des retours sur leurs utilisations qui permettent de connaître les qualités et les défauts d'un logiciel

Prochaine entrée dans le journal : Du partage des données par BitTorrent.

Notes

[1] Précisons tout de même que je n'ai pu observer ce type de ralentissement que sur de très gros fichiers de logs, de plusieurs dizaines de mébioctets, et jamais sur de simples fichiers de configuration.

[2] Heureusement, rien ne disparaît jamais vraiment d'internet. Malgré la disparition du site officiel de lm-sensors, grâce à web.archive.org j'ai pu retrouver l'information qui m'avait aidée à l'époque, donc pour les curieux elle est ici .

[3] Il est amusant de noter la controverse quand à la signification du nom de ce répertoire : dans d'anciennes documentation UNIX il était appelé le répertoire etcetera car il contenait tout ce qui n'allait nulle part ailleurs, par la suite le nom fût réinterprété comme l'acronyme de Editable Text Configuration ou Extended Tool Chest.

2016-02-02

Réparer un NUC qui ne démarre plus

J’ai récemment eu un soucis avec un Intel NUC. Il ne voulait plus démarrer. Pas de lumière blanche indiquant qu’il est actif, pas de signal vidéo, pas d’activité disque. Nada. Juste une petite lueur verte constante sous le voyant disque et le bouton d’allumage.

La solution fut de réinitialiser la mémoire CMOS. Les carte mères Intel ont un cavalier (jumper) pour effectuer cela.

Sur le NUC, il ressemble à ça :

jumpers nuc1Il suffit de le brancher sur les pins 2/3 au lieu de 1/2 et de redémarrer. Vous verrez alors le NUC démarrer. Joie !

Il ne vous reste plus qu’à remettre le cavalier comme avant si vous voulez pouvoir sauver à nouveau les réglages du BIOS ;-)

Related Posts:

J'aime !(0)Je n'aime pas !(0)

Le retour du FOSDEM 2016



Franchement, quelle aventure ce FOSDEM. C’était déjà pas mal l’année dernière mais ce fut encore mieux cette année !

Comme on était là-bas pour présenter le dynamisme de diaspora*, je vous laisse traîner par ici et par là pour que vous vous en rendiez compte par vous même. Ici, je vais vous donner les retours des différentes personnes avec qui j'ai parlé pendant ce FOSDEM.

Toujours en vie ?

Alors, celle-là, elle revient tout le temps : Oui ! Le projet diaspora* est toujours en vie et continue son bonhomme de chemin. Nous voir au FOSDEM étonnait, dans le bon sens du terme. Les gens sont heureux de voir que ce projet tient toujours la route. Je ne pourrais pas vous dire combien de personnes m'ont dit qu'elles avaient créé un compte aux premières heures mais qu'elles avaient oublié leurs identifiants depuis, en pensant le projet mort. Eh non. Comme l’année dernière, la bienveillance des visiteurs s'est révélée chaleureuse : ils ont tous un a priori positif, même s'ils ne savent plus vraiment comment ça marche, diaspora*.

Comment ça marche ce truc ?

Après avoir montré que le projet est bien vivant, il faut montrer qu'il est fonctionnel. Rappeler que c'est un réseau décentralisé, ça fait mouche chez les geeks, mais les gens ne comprennent pas vraiment comment. C'est là qu'on a créé le compte FOSDEM2016 en ajoutant les gars du stand et d'autres comme contacts. Avec ça, je pouvais rapidement montrer aux gens que Fla, Framasoft, Jason et FOSDEM2016 sont tous sur des serveurs différents, avec une mention spéciale pour le pod de Jason dont le nom a fait mouche à chaque fois. I Like Toast, c'est quand même pas mal !

Y'a des gens dessus ?

Quelle question... C'est tentant de dire que oui, mais je ne voulais pas vendre du rêve. C'est clair qu'il n'y a pas le quart de l’humanité sur notre réseau social. On est loin des Facebook et Twitter. Ceci-dit, en expliquant avec le sourire qu'on y retrouve des photos de chats et des photos de bouffe, on rassure le badaud. On peut ensuite enchaîner sur ce qui est vrai : moi, par exemple, je ne peux pas lire tout ce qui passe par mon flux ! Avant d'arriver à mon niveau, ça demande un peu d'effort parce que diaspora* ne va pas demander vos goûts en matière de films et de musiques puis vos contacts Gmail pour vous assurer une timeline déjà bien fournie à la première connexion. Il faut un peu travailler ! Et hop, un tacle qui passait bien. Je terminais sur le fait que les posts des utilisateurs sont souvent très engagés et argumentés, ce qui en rend la lecture très instructive.
Après, je restais honnête et les FOSDEMeurs et FOSDEMeuses le savaient déjà : diaspora* ne peut pas faire venir tout le monde et tout le monde ne viendra que si tout le monde est déjà là. Un cercle vicieux, mais bon, on ne peut pas accueillir toute la planète pour le moment.

Comment tester diaspora* ?

Les gens ne savent pas comment tester diaspora*. La notion de pod est étrange, quand on y regarde de plus près. Il a fallu que j'explique que les comptes sont tributaires d'un pod, d'un serveur et qu'il n'est pas encore possible de les déplacer. C'est d'ailleurs le "reproche" le plus dur que j'ai entendu. Du coup, pour tester diaspora*, il faut connaître un pod ou monter le sien sur son serveur. Pour les moins courageux et francophone, je redirigeais vers Framasphere, pour les plus courageux, je leur expliquais que monter son propre pod n’était pas d'une difficulté terrifiante. Je répète, pour les plus courageux. Sinon, je montrais le site de Jason : The Federation. A partir de là, ils voyaient que les pods sont repartis dans plusieurs pays et qu'ils peuvent choisir. En passant par The Federation, j’enchaînais sur l'initiative de Jason, qui voudrait que les réseaux sociaux libres puissent discuter entre eux. Ça marche déjà un peu avec Hubzilla, Friendica et Redmatrix pour le moment, mais il reste Movim, Salut à Toi et d'autres.

Et voilà pour ce billet d’après FOSDEM. J'ai vraiment adoré et j'y retournerai l’année prochaine. Par contre, ce coup-ci, je prendrai le train et consommerai les bières belges avec plus de modération, histoire d’être en état le dimanche et de ne pas me taper 5h de transport au retour !

Merci à Augier et Greenman pour m'avoir supporté !

Je vous propose de finir ce billet sur un truc plutôt chouette : nous avions un stand, contrairement à Movim, Cozy Cloud et Framasoft, alors, vous savez quoi ? On a fait ce qu'on fait de mieux : fédérer ! ;-)




<noscript></noscript>

2016-02-01

L’Université Libre de Bruxelles choisit Owncloud

Pour permettre à ses étudiants d’avoir un espace de stockage en ligne, l’Université Libre de Bruxelles (ULB), la principale université francophone de Belgique, a choisi le logiciel libre OwnCloud depuis février 2015.

L’ULB résume ainsi ce qui a dicté son choix :

Pourquoi confier ses données à n’importe qui dans le monde avec tous les problèmes de confidentialité que cela entraîne et aussi de saturation de notre liaison internet alors que nous disposons en interne d’une solution de stockage cloud ?

Un étudiant de l’ULB, PostBlue décrit en détail les services disponibles sur le OwnCloud de l’ULB (stockage de fichiers, calendrier, éditeur de documents…)

Related Posts:

J'aime !(3)Je n'aime pas !(0)

2016-01-30

Les joies de l’auto-hébergement

Tranche de vie d’un admin reseau at home

Vous l’avez peut-être remarqué que le blog et mes autres services web ont connus une grosse interruption de service une bonne partie de mercredi dernier. La faute à une méchante coupure de courant.

9h30 l’heure du crime en ce début de mercredi matin, je reçois un sms de mon épouse « y a plus de courant à la maison » Après avoir dépatouillé le problème au téléphone, le courant est revenu. Je lui fais redémarrer un par un les serveurs, tout à l’air correct. Cinq minutes plus tard un autre sms « pas d’internet », étant au boulot je ne peux passer ma matinée au téléphone pour un problème perso, cela tombe je ne travaille pas cet après-midi je verrai le problème en rentrant. Une fois à la maison je fais le tour des ordis de la maison et j’identifie rapidement le problème, le réseau n’es plus brassé entre le pare-feu et mon réseau local. Et effectivement je découvre mon swicth Netgear, véritable colonne vertébrale de mon infrastructure ne répond plus. Je débranche-rebranche toujours aucune réaction. Je décide de déclarer la mort du switch à 13h15.

La cause du problème étant trouvé, je fonce chez mon assembleur de quartier pour voir les switch qu’il a en stock. Il ne lui reste que des switch 10/100/1000 que du D-link 8 ports. Comparé à Netgear 10/100/1000 16 ports c’est très petit mais c’est juste ce qu’il me faut pour rétablir la connexion internet sur mon infrastructure. Cela me laissera du temps soit pour réparer le Netgear, soit pour en acheter un autre tout en gardant le D-link en secours pour anticiper ce genre de situation.

Cela fait partie des aléas de l’auto-hébergement, une petite panne par-ci, un petit débuggage par là, tout ce qui donne vie à notre infra. Cela permet de voir les choses aux-quelles je n’est pas pensé à l’époque, d’améliorer ce qui peut l’être. En tout cas aujourd’hui mon réseau est reparti, il fonctionne parfaitement.

J’ai profité de l’occasion pour mettre à jour la Debian de mon Nas encore en version Wheezy. Mise à jour sans encombre, comme toujours avec Debian. Un seul petit souci avec apache2 qui sert mon instance ownCloud.

Première erreur au lancement du service apache2 :

Invalid command 'LockFile', perhaps misspelled or defined by a module not included in the server configuration

Après une recherche succincte j’ai trouvé la solution remplacer dans le fichier /etc/apache2/apache2.conf la ligne

LockFile ${APACHE_LOCK_DIR}/accept.lock

par

Mutex file:${APACHE_LOCK_DIR} default

Ensuite lorsque j’ai voulu à nouveau lancer apache :

AH00526: Syntax error on line 13 of /etc/apache2/sites-enabled/owncloud:
Either all Options must start with + or -, or no Option may.

J’ai donc modifié le virtualhost de owncloud comme indiqué dans le message d’erreur en ajoutant un « + » devant les options FollowSymlinks et MultiViews.

DocumentRoot "/var/www/owncloud"
        <Directory "/var/www/owncloud">
                Options -Indexes +FollowSymLinks +MultiViews
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>

Par la suite tout est rentré dans l’ordre et le Nas a été validé d’un « tout marche bien navette ».

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="394" src="https://www.youtube.com/embed/trvqZZrKQqQ?feature=oembed" width="700"></iframe>

 

2016-01-28

gitbackup : maintenir une copie conforme (miroir) d'un dépôt git

Problématique

J'ai déjà argumenté à plusieurs reprises du risque que l'on prend à utiliser des systèmes que nous ne gérons pas nous même, comme github (ref). Cette problématique fonctionne aussi pour des dépôts maintenus par des personnes qui peuvent avoir envie de supprimer les données, bien que vous les trouviez intéressantes. Mêmes arguments pour des organisations comme framasoft ou FFDN. Ainsi, je ne peux qu'encourager à avoir son propre serveur git, pour les dépôts privés, mais aussi pour les miroirs. Le Logiciel Libre a la copie dans son génome, utilisons-le.

Principe

J'ai appris comment faire proprement un miroir d'un dépôt sur la doc de github.

# On clone le depot sur github
git clone --mirror https://github.com/exampleuser/repository-to-mirror.git

cd repository-to-mirror.git
# On ajoute comme destination chezmoi.org
git remote set-url --push origin https://git.chezmoi.org/exampleuser/mirrored

# On pousse
git push --mirror

A intervalle régulier, on peut faire

git fetch -p origin
git push --mirror

L'avantage est qu'on synchronise toutes les branches et les tags, mais on ne synchronise pas les tickets.

gitbackup

Pour tout dire, ce billet trainait dans mon dossier en préparation. J'utilisais un petit script et suite à l'article de Carl Chenet et repris sur framablog, je me suis convaincu qu'un code propre pouvait être utile à d'autre. Comme le dit Benjamin Bayart, il faut faire !. En quelques bouts de soirées, j'ai tenté de mettre les choses au propre.

Le but est d'avoir un outil proche de git d'un point de vue syntaxique pour automatiser les commandes ci-dessus. J'ai aussi gardé le même format (configparse) pour le fichier de configuration.

# On se crée un chez soi
mkdir backup_github && cd backup_github

# On initialise
gitbackup init

# On clone deux dépôts dont on veut un miroir
gitbackup clone sametmax_0bin https://github.com/sametmax/0bin.git

gitbackup clone carl_backupchecker https://github.com/backupchecker/backupchecker.git

# Quand les développeurs auront fait évolué le projet,
# on pourra synchroniser les changements
# sur un dépôt spécifique
gitbackup pull sametmax_0bin

# ou sur tous les dépôts
gitbackup pull

Le code est sur github (sinon, ce ne serait pas drôle) en GPLv3.

Sous peu, je vais ajouter une fonctionnalité pour ajouter un remote afin de pousser le miroir sur un autre site. Je vais pousser le code sur pipy, et faire un paquet pour archlinux.

C'est libre, ce code est aussi le votre. Commentaires et surtout pull requests sont les bienvenus.

2016-01-27

JAH-9 – De l'avancement des choses dans une faille temporelle

Journal de bord du capitaine :
Date : 23 mars 2011
Lieu : Perdu dans le cyber espace

Comme dirait Cartman : Goddammit ! Cela fait une éternité que je n'ai pas écrit dans ce journal et pourtant que de choses ce sont passées, autant au niveau personnel qu'au niveau de mon auto-hébergement. En vrac : déménagement, mise à jour de distribution, configuration du serveur ejabberd pour gérer les salons, installation d'un web-client pour pouvoir procrastiner en paix au boulot et début de configuration d'un serveur de courrier. Pour faire un court résumé tout s'est étonnamment bien passé !

Concernant mon déménagement, je pense que tout le monde s'en bat les gonades de comment il s'est passé et au niveau des conséquences pour l'auto-hébergement une simple mise à jour du fichier de zone du DNS à suffit à remettre tout en l'état. Une fois mon serveur remis en route et de nouveau connecté au réseau des réseaux, j'ai décidé avant toutes modifications de mettre à jour ma distribution.

J'entends par mise à jour une augmentation de mon numéro de version (passage de lenny à squeeze) et non pas mises à jour de sécurité et autres correctifs de bugs. Mon système était bien sûr maintenu à jour tout en restant dans le cadre d'une version debian stable (avec les backports activés) mais lors du passage en freeze de la future version stable de debian, je me suis décidé à faire la migration pour anticiper la mise à niveau sur un système plus complexe. En effet, ma crainte, sans justification à posteriori, était que la migration me fasse perdre mes fichiers de configuration déjà personnalisés (ou tout du moins que les merges soient complexes).

Suivant à la lettre les consignes de migration décrites dans les release notes [1] de debian squeeze (sautant quelques passages superflus dans mon cas) j'ai pu effectuer une migration sans problème. Je retiendrai de cette migration une installation massive de paquets qui ne se justifiait que partiellement. Pour faire simple, plusieurs paquets liés à ejabberd ont été installés alors que je n'en voyais pas forcément l'utilité et étrangement ces paquets ont été désinstallés lors de la première mise à jour des paquets via aptitude …

Pressé par la fermeture du salon IRC sur lequel mes amis avaient l'habitude de se retrouver, je me suis motivé pour mettre en place la gestion de salons de discussion sur mon serveur jabber. La configuration fut assez simple, la plupart des options par défaut me convenant tout à fait. Je n'ai eu qu'à jeter un rapide coup d'œil à la documentation officielle pour savoir comment désactiver toutes formes de log (y compris le rappel des X dernières phrases lors de l'entrée d'un nouvel utilisateur dans le salon) et j'ai pu ouvrir officiellement mon serveur à l'hébergement de salon.

Restait néanmoins un problème majeur : le serveur mandataire de mon entreprise bloquait toutes communications extérieures en dehors des protocoles HTTP et HTTPS sur leur ports habituels donc pas question de messagerie instantanée. Pour IRC, j'utilisais des web-clients tout à fait correct qui ne demandait aucune information confidentielle, or pour rejoindre les salons XMPP je devais utiliser un compte et je n'avais aucune envie de confier mes données confidentielles à un site dont je ne connaissais rien. Je me suis donc mis en quête d'un web-client XMPP que je pourrais installer chez moi et je suis tombé sur jappix. Ce projet, mené par un jeune français qui plus est, me semblait pas mal du tout. L'installation fut un jeu d'enfant [2] à part un problème d'ouverture de port sur ma freebox. J'ai pu en quelques lignes de commandes avoir ma propre instance de jappix fonctionnel.

Pour que la communication soit possible entre un web-client et un serveur XMPP, il faut passer par un serveur BOSH. Dans un premier temps, j'ai laissé la configuration par défaut de jappix et utilisé le serveur BOSH de jappix.com, mais ejabberd proposant cette fonctionnalité, il était logique que je configure jappix pour utiliser mon propre serveur. Les modifications à effectuer dans ejabberd et dans jappix étant détaillées dans leurs documentations respectives cela ne présenta pas de difficultés majeures. Mon instance de jappix ainsi configurée fonctionnait parfaitement ... sauf sur mon lieu de travail. En effet, le serveur mandataire refusant toutes connexions en dehors des ports 80 et 443, jappix ne pouvait joindre le serveur BOSH d'ejabberd sur le port 5280. La solution, là encore tirée de la documentation de jappix, fut de configurer apache sur mon serveur en tant que serveur mandataire afin de rediriger toutes les requêtes pour une adresse précise vers le port d'écoute du serveur BOSH et pour que les réponses à ces requêtes suivent le même chemin. Dès le lendemain, j'avais un web-client de messagerie instantanée parfaitement fonctionnel et ne dépendant que de services fournis par mon serveur personnel.

Une fois la messagerie instantanée configurée sur mon serveur, j'allais maintenant devoir m'attaquer à la part du lion : le courrier électronique. Avoir mon propre serveur de courriel était l'une de mes motivations premières lorsque je me suis lancé dans l'auto-hébergement mais ceci étant un service des plus critiques, je voulais me faire les dents sur d'autres services avant. Ici, j'entends par "critique" que la non disponibilité de ce service peut s'avérer très handicapante, voir catastrophique, en cas de perte de courriel, et non que c'est un service beaucoup plus dur que les précédents à mettre en place; bien que le nombre d'options de configuration des serveurs de courriels puisse faire peur. Il convient donc de prendre toutes les précautions nécessaires et de tester suffisamment longtemps sa configuration avant de l'ouvrir au monde et de se reposer exclusivement dessus. Il ne faut bien sûr pas négliger l'aspect sécurité de l'installation, être responsable d'un serveur de courriel signifie qu'en cas d'erreur on peut rejoindre en quelques minutes la grande famille des ordinateurs zombies pourvoyeur de pourriels !

Jusqu'à présent, les conseils et exemples de configuration trouvés sur le wiki dédié à l'auto-hébergement s'étant avéré judicieux, je me suis, une fois de plus, basé dessus pour la mise en place de mon serveur. Après m'être documenté sur le fonctionnement d'un serveur de courrier et familiarisé, autant que faire se peut, avec le vocabulaire spécialisé : MTA, MUA, serveur de boîte aux lettres, etc ; je me suis lancé. J'ai donc installé postfix et l'ai configuré très simplement dans un premier temps, ajustant juste quelques paramètres et dès le premier test cela s'avéra fonctionnel ! En utilisant, pour le moment, uniquement des outils en ligne de commande, je pouvais envoyer, recevoir et lire des courriels. Il ne me restait plus qu'à configurer mon serveur pour avoir accès à mes courriels depuis une autre machine : à l'aide d'un logiciel de messagerie, bien sûr, mais également grâce à un web-mail afin de pouvoir les consulter partout, notamment depuis mon lieu de travail.

Conclusions :

  • Déménager un serveur n'est pas compliqué.
  • Migrer vers une version plus récente de sa distribution est un processus sans risque, documenté et relativement rapide.
  • Configurer un serveur jabber pour gérer des salons de discussion se fait en quelques lignes.
  • Les web-clients jabber ne sont pas nombreux mais certains sont suffisamment avancé pour être pleinement utilisable.
  • Un serveur de courriels n'est pas plus compliqué à installer et configurer qu'un autre service (la documentation est foisonnante).
  • Le caractère critique d'un serveur de courriels oblige à une plus grande attention dans les tests et dans sa configuration.

Doucement mais sûrement, je commençais à être de plus en plus indépendant, gérant moi-même la plupart des services dont j'ai besoin sur internet. Bientôt, je l'espère, je pourrais commencer à m'intéresser aux services dont je me refusais l'usage car je ne les contrôlais pas, tels que : les galeries photos et/ou vidéos ou encore l'ouverture d'un blog, d'un wiki ... Les possibilités ne manquent pas et sont toutes plus intéressantes les unes que les autres.

Prochaine entrée dans le journal : Des petits réglages pas indispensables mais bien pratique

Notes

[1] Il faut savoir que les instructions de migration d'une version debian ne font pas partie du manuel d'installation mais bien des notes de publication. Par exemple, celles de squeeze se trouvent ici

[2] J'ai longtemps hésité avant d'installer jappix car il n'était pas dans les dépôts officiels. Pour des raisons de stabilité et de sécurité, je souhaitais maintenir un système le plus intègre possible et donc sans logiciel externe. Jappix est encore à ce jour mon seul coup de canif dans le contrat.

diaspote in backstage





Le FOSDEM, c'est à la fin de la semaine, déjà ! C'est pour moi l'occasion de vous partager le fonctionnement de diaspote.org, notre pod diaspora avec Augier. Parce que oui, même si les utilisateurs s'en cognent royalement la plupart du temps, j'ose espérer que ceux de diaspora* seront un peu plus curieux. Les autres, vous pouvez venir flooder avec nous, c'est open bar !

Ce billet est un peu technique mais je vais essayer de faire simple, promis.

Debian powered

Diaspote.org tourne sur une Debian Jessie 8.3. Ceux qui me lisent depuis un moment savent que c'est mon système d'exploitation libre de prédilection, c'est donc un choix classique.
Ce serveur est automatiquement mis à jour via ce qu'on appelle les unattended-upgrades. C'est une configuration que je croyais classique mais je peux vous certifier que ce n'est pas toujours le cas dans le milieu professionnel.
Ça permet de ne plus se soucier des mises à jour de sécurité, les plus critiques : elles se font toutes seules la nuit, quand les utilisateurs dorment, et moi aussi. Un mail me prévient quand c'est fait, histoire de me rassurer, mais je n’hésite jamais à accélérer le processus quand c'est une faille sévère, autant dire rarement.

Scaleway to heaven

Déjà dit mais voici la configuration matériel du serveur :
  • 2 Go de RAM
  • 60 Go d'espace disque
  • ARMv7 4 cores
C'est peu mais ça passe ! On ne fait tourner, nativement, qu'un serveur MySQL (pas de MariaDB encore) et un serveur Apache. Le reste, c'est pour diaspote.

À votre service

C'est un truc assez récent, il date de cette semaine. Avant, nous avions un screen dans lequel le processus diaspora tournait, mais ça, c’était avant. Maintenant, nous avons un script qui nous simplifie la vie. Plus besoin de lutter avec un screen encombrant : nous voici capables de faire un start et stop proprement, en passant par systemd.
Juste après cette configuration, pour des raisons de gestion des faibles ressources dont nous disposons et à cause de la consommation mémoire de diaspora*, nous avons une tache planifiée, un cron dans le jargon, qui relance diaspote toutes les nuits à 4h20 du matin. Ça vide la mémoire, ça soulage et ça n'affecte en rien l'utilisation du pod.
Pour les curieux, il existe un système d'auto-protection dans les OS libres : l'OOMKiller. Ce petit nom est plus clair quand on dit Out Of Memory Killer, je ne sais pas trop comment le traduire en français, mais c'est assez clair, non ? Quand un processus, genre diaspora, se met à consommer assez de mémoire vive pour mettre en danger le fonctionnement du serveur en entier, l'OOMK dézingue ce qu'il peut autour pour essayer de sauver la situation. En général, ça finit mal.

Statistiques à Facette

C'est toujours chouette de voir, réellement, ce qu'il se passe sur son serveur avec des graphiques. Un mail de temps en temps, c'est mignon mais loin d’être sexy. Facette s'occupe de ça pour nous. Il s'occupe d'organiser toutes les informations sur l’état du réseau, de la charge serveur, du CPU et de la RAM en superbes graphiques. C'est beau, c'est efficace et ça permet de connaître exactement l'heure d'un incident et de donner les premières indications, comme un souci de mémoire. Au hasard.

En parlant d'incidents, je suis en train de mettre en place un Cachet. C'est un outil de suivi. Il va nous permettre d'annoncer les futures opérations et de garder une trace de tout ce qui a pu se passer. Une mémoire des crashs, en gros. Il sera rapidement disponible à l'adresse suivante : status.diaspote.org.


Le reste des opérations consiste à mettre à jour le pod avec les dernières améliorations tirées du dépôt Github. Avec ce que nous avons là, l'installation est bien stable et ne plante plus. Ça reste à confirmer, on n'est jamais 100% couvert et il suffit d'en parler pour se prendre une mauvaise blague en pleine figure.

En quelques chiffres

C'est dans cette partie du billet qu'on redescend sur Terre. J'en parle souvent ici, diaspora* n'est pas un outil inconnu, mais il souffre d'un manque cruel : des utilisateurs. Si on se penche sur les statistiques de diaspote, on parle de 39 utilisateurs inscrits pour 22 actifs. C'est pas mal, on dépasse les 55% d'utilisateurs actifs, qui se sont connectés ces 4 dernières semaines. Sauf que ce ne sont que des statistiques et que 90% de ces comptes ne sont pas du tout actifs. Tant pis. On ne se compare pas vraiment aux autres réseaux, mais c'est dommage. D'ailleurs, on a déjà assez de photos de chats comme ça ;-)


<noscript></noscript>

2016-01-23

Don du mois : debian

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices.

Le don de ce mois est pour debian. J'utilise cet OS pour mes serveurs. J'ai bien essayé pour les stations de travail, mais la lenteur de l'évolution de debian m'a fait reculer pour préférer archlinux auquel j'ai déjà consacré un don. Néanmoins, debian est une distribution de choix pour les serveurs. C'est stable, c'est documenté, la communauté est active et les mises à jours sont de qualité. Donc 15$ pour debian.

Pour faire un don à debian

2016-01-22

La touche finale à mon équipement de rêve : la tablette Ubuntu


Vous avez sans doute tous vu passer la nouvelle, c'est Phoronix qui m'a mis ça sous les yeux. Première digression : si seulement le système d'abonnement du site était moins foireux, je serais déjà abonné. Ubuntu va enfin proposer sa tablette tactile.




On s'avance en disant que c'est pour 2016, mais les indices sont là : Ubuntu 16.04 comme base, présentée pendant le Mobile World Congress de fin février. Ça ne dit pas tout, mais quand même.

Actuellement, j'ai un smartphone sous FirefoxOS, qui reprend des couleurs, et des ordinateurs sous Debian/Ubuntu et... pas de tablette. Je n'en voulais pas par manque d’intérêt. C'est quand même con de payer un truc une fortune quand on habite dans 20m2 et qu'on préfère lire dans le train. Mais bon, avec le temps, je me dis que ça pourrait être un chouette outil de démonstration, comme au FOSDEM pour présenter diaspora*, ou un bon appareil pour faire défiler mes photos que je conserve dans ownCloud.

Ce cheminement allant du "ça ne sert à rien" à "pourquoi pas?" a pris plusieurs années et avec le temps, seul le fait que c’était de l'Android m'a refroidi. Je me souviens quand même avoir testé une tablette Intel sur laquelle j'avais installé Debian avec GNOME Shell. C'est à ce moment là que je me suis dit qu'il ne manquait qu'un bon OS à ces petites bêtes pour devenir vraiment attirante. Avec l’arrivée des Ubuntu Tablets, on touche du doigt une solution.

Sans doute pas la meilleure, mais c'est un bon début. Il est presque certain que si elles font tourner Ubuntu, elles pourront faire tourner d'autres distributions, comme Debian tout simplement. C'est même presque une évidence quand on sait qu'Ubuntu est une Debian modifiée à la sauce Canonical. A partir de là, d'autres suivront, même celles basées sur cette maudite CentOS. Du coup, on se retrouverait avec une tablette tournant sur autant d'Ubuntu que les autres, mais là je rêve.

Je sens qu'on me fusille du regard parce que je ne parle pas de Jolla et des SailfishOS, mais un OS qui fait tourner des applications Android, ça me refroidi. J'aime souffrir en ne pouvant pas me servir de ce qui traîne sur les stores de Google et des autres. Ça doit être mon esprit routard.

Enfin, ici, je rêve à clavier haut (qui repèrera la tentative de blague foireuse ?) d'un environnement informatique parfaitement maîtrisé par mes soins avec tout un tas d'OS alternatifs. L’opposé des envies de convergence de Canonical, d'Apple ou de Microsoft, mais que du libre, rien que du libre, je le jure.


<noscript></noscript>

2016-01-21

FirefoxOS disponible pour Fairphone 2




Le Fairphone 2, c'est un peu le téléphone qui me fait envie en ce moment. C'est le smartphone idéal pour les bien-pensants : il est conçu autour des idées du commerce équitable et de l’écologie. Je vous laisse la page Wikipedia pour en apprendre plus à son sujet. Pour moi, il faudra attendre la version 3 ou 4 avant que je me laisse tenter puisque mon Flame me convient toujours autant.

Le truc qui me gène encore, c'est qu'il n'y a pas d'OS alternatif dessus, et je ne mets pas Cyanogen dans la liste des systèmes d'exploitation alternatifs. On sait tous que c'est une blague. Dedans, je pense à Ubuntu Phone ou à Firefox OS. Je n'ai pas de nouvelle du support d'Ubuntu, mais il y en a pour Firefox OS !



C'est dans ce rapport de bogue qu'on apprend que le programme Foxfooding et ses bénévoles ont réussi à faire fonctionner Firefox OS sur le Fairphone 2 ! C'est un premier jet et tout n'est pas encore parfait.

Pour le moment, le lien direct permettant de télécharger l'image à faire avaler à votre smartphone équitable n'est plus disponible puisqu'elle contient des bouts de code propriétaire. Si je comprends bien, Mozilla ne peut pas sponsoriser ce genre d'initiative si elle contient du code dont elle n'a pas les droits. C'est un peu comme le codec MP3 : tout le monde peut l'avoir mais la plupart des distributions GNU/Linux vous obligent à faire une petite opération pour les débloquer.

C'est pourtant un problème mineur, semble-t-il, puisqu'il existe une méthode blobfree qui permettrait aux propriétaire d'un Fairphone de s'en sortir. Un peu comme le coup du MP3 . Le script devrait aller chercher ce dont il a besoin dans le téléphone, balancer Firefox OS dedans avec ces trucs au bon endroit, et vous laisser entre les mains de l'OS alternatif de la fondation. N’étant pas expert, le conditionnel est de mise même si ça me parait logique.

Cette nouvelle, et avec elle le fait que mon Flame tourne en 2.6 depuis une mise à jour OTA, me redonne espoir en Firefox OS. Un espoir qui avait souffert de la dernière grande annonce de Mozilla.


<noscript></noscript>

2016-01-20

JAH-8 – De la sécurisation par certificat SSL

Journal de bord du capitaine :
Date : 29 janvier 2010
Lieu : Perdu dans le cyber espace

Mon registrar, Gandi, incluait dans sa prestation un certificat SSL (Secure Sockets Layer) la première année. Un certificat SSL est un fichier contenant une empreinte certifiée authentique par une autorité de certification. En terme clair : le certificat délivré par Gandi (et certifié par eux) permet à une personne se connectant sur mon domaine de savoir qu'elle n'a pas été, à son insu, redirigée vers un site frauduleux. C'est grâce à ce certificat que mon domaine est accessible en utilisant le protocole HTTPS, ainsi les données qui transitent vers et depuis mon serveur sont chiffrées et donc inexploitables pour quelqu'un qui "snifferait" [1] mon réseau .

Il existe plusieurs autorités de certifications proposant des certificats payants ou non. Il est même possible de signer soi-même son certificat mais les certificats auto-signés et ceux de certaines autorités de certifications pas encore très reconnues peuvent provoquer un message d'avertissement lors de la première tentative de connexion sur le site qu'elles sont sensées authentifier.

Grâce aux étapes détaillées pas à pas dans le wiki de Gandi la création de mon certificat SSL se déroula sans encombre, une première depuis mes débuts d'administrateur système ! Une fois le certificat obtenu, il me fallait l'installer sur mon serveur et donc pour cela installer le fameux paquet apache2. Apache est certainement le plus connu et le plus utilisé des serveurs HTTP [2] , son rôle est simple : c'est lui qui, selon l'adresse demandée par un utilisateur, va renvoyer tel ou tel contenu.

Comme d'habitude l'installation par aptitude prit moins d'une minute, le serveur apache se lance et avant de modifier quoi que ce soit, je me décide à tester si la configuration par défaut est fonctionnelle. Je me connecte donc depuis mon navigateur internet sur mon nom de domaine et là, comme prévu, malgré une petite appréhension, je vois s'afficher un magnifique It works ! (page renvoyée par défaut par apache). Jusqu'ici tout allait bien comme dirait l'autre ...

Suivant toujours le wiki de Gandi, je commence à modifier les fichiers de configuration d'apache pour mettre en place l'accès sécurisé à mon site en utilisant mon certificat SSL. Je suis scrupuleusement le tutoriel, redémarre le serveur apache et là ... c'est, une nouvelle fois, le drame ! Ça faisait longtemps ...

En me basant à la fois sur la documentation officielle et sur les fichiers gérant la configuration par défaut, j'ai pu rapidement modifier mes propres fichiers de configuration et après quelques essais, une connexion sur https://gehenne.net me renvoya un très attendu It works ! .

L'intérêt d'avoir un accès sécurisé à mon domaine est que cela me permettait de mettre en place une connexion entièrement sécurisée à mon serveur ejabberd. En effet, pour l'instant l'envoi du mot de passe pour accéder à mon compte se faisait en clair. Après avoir lu la documentation d'ejabberd et le wiki sur l'auto-hébergement, j'ai pu configurer mon serveur de messagerie instantanée avec le niveau de sécurité qui me convenait le mieux. La configuration d'ejabberd étant toujours aussi sensible, il m'a quand même fallu quelques tentatives avant de refaire fonctionner le serveur.

Conclusions :

  • La sécurisation d'un serveur est une chose essentielle à mettre en place le plus rapidement possible.
  • Les certificats des plus importantes autorités de certification (le plus souvent payant) garantissent une connexion sécurisée sur le domaine sans message d'avertissement.

Prochaine entrée du journal : De l'avancement des choses dans une faille temporelle

Notes

[1] "Sniffer des paquets" consiste à récupérer les paquets qui circulent sur un réseau afin d'analyser à des fins plus ou moins frauduleuses ce qu'ils contiennent.

[2] En réalité Apache est le nom d'une fondation aux multiples projets dont le plus connu est le serveur HTTP. La liste le tout les projets se trouve ici.

2016-01-19

FOSDEM 2016 nous voilà !


Comme l’année dernière, une équipe de développeurs, de podmins et d'utilisateurs va s'envoler pour la Belgique pour représenter notre beau réseau social diaspora* au FOSDEM du 30 au 31 janvier.





Le FOSDEM, c'est une institution pour les développeurs et les utilisateurs de logiciels libres et open source. C'est une occasion en or pour rencontrer et discuter avec les créateurs des logiciels que nous utilisons au quotidien. ET accessoirement, de choper des stickers, des tshirts, etc à l’effigie des logiciels, langage de programmation ou encore distribution préférés !

Bref, diaspora* y sera présent, avec un stand à nous, un étendard, des stickers et des barbus. Je ne sais pas encore dans quel coin de l'ULB nous seront mais j’espère que nous seront aussi bien entourés que l’année dernière : entre la FSFE et ownCloud.

N’hésitez pas à venir nous voir, on ne mord pas, et même s'il y a beaucoup de chance pour que nous soyons en train de parler anglais, nous "switcherons" pour troller clavarder avec tout le monde !

Toutes les informations sur l'événement sont disponibles sur le site officiel, aussi disponible en cliquant sur la discrète image qui traîne depuis quelque temps à la droite de ce billet.


<noscript></noscript>

2016-01-17

Auto-hébergement et page d'accueil perso

Après cinq ans d'auto-hébergement (voir mon article de présentation), quelques services me sont devenus très vite indispensables. Mon top 3 est sans aucun doute celui-ci : Subsonic pour lire mes musiques depuis n'importe où (en particulier au boulot), un agrégateur de flux RSS (depuis deux ans, j'utilise Selfoss) et surtout, une page d'accueil perso. Cette page est la page de démarrage de tous mes navigateurs Web et c'est la page sur laquelle je vais en premier lors de n'importe quelle navigation, depuis n'importe où. Je vais vous présenter cette page et comment vous pouvez la récupérer dans cet article.

maison-maison-icone-3648-64.png

Genèse

Une page d'accueil perso a été un des premiers services que j'ai mis en place sur mon serveur, c'est tout de suite devenu un indispensable. Ma première page d'accueil (que j'ai utilisé pendant près de 4 ans) ressemblait à ça (j'avais trouvé l'idée de la mise en page sur le site de Hackurx) :

accueil.png

J'ai fait de petits ajout au fil du temps : les favicons, une réécriture des liens (à faire en fichier de conf, plus dans le code directement), l'ajout d'une todolist directement sur la page (comme un widget), etc.

Et maintenant

Il y a quelques mois, je suis tombé sur un super projet : AdminLTE, un "free bootstrap admin template". Entendez par là, tout plein d'outils pour faire sa propre page perso. En fait, il ne s'agit "que" d'un template, il a donc fallu mettre en place tout le code derrière pour transformer cette coquille vide en un outil super pratique : ma page d'accueil !

Après pas mal de creusage de tête et de code, voici ma page d'accueil dans le détail. Ce n'est plus une simple page avec des liens, c'est devenu un mini-site rebond avec une sidebar (menu latéral) qui me donne accès en un clin d’œil à tous mes services les plus utilisés.

Première page

Cette première page est celle sur laquelle je tombe en homepage. J'y retrouve les liens vers les principaux sites que je vais visiter ainsi que des formulaire pour de la recherche sur un moteur de recherche, sur Youtube ou pour la traduction d'un mot. J'ai aussi ajouté mon formulaire de todo list qui va écrire dans un fichier todo.txt (comme je l'avais expliqué dans mon précédent article).

accueil.jpg

Lecteur RSS

J'ai fait en sorte d'afficher le nombre d'actus RSS non lus dans l'icône de la sidebar correspondante à mon lecteur RSS. Ainsi, je vois tout de suite quand j'ai des news et je peux aller rapidement sur mon agrégateur en cliquant sur l'icône correspondante.

feeds.jpg

Transmission

J'ai également un lien vers l'interface web de mon logiciel de téléchargement. C'est simplement un iframe affichée (protégée par un login et mot de passe différent de ma page d'accueil).

dl.jpg

Album photos

J'ai aussi un lien vers mon album photos. Là encore, il ne s'agit que d'une iframe affichée à côté de ma sidebar.

photos.jpg

Subsonic

L'icône en forme de note de musique me redirige vers mon interface web de Subsonic. Ce n'est pas une iframe ce coup là, c'est juste un lien tout bête, je sors donc de ma page d'accueil.

Shaarli

Un lien vers mon instance Shaarli (en iframe, toujours).

Calendrier

J'ai utilisé le plugin full-calendar en javascript pour afficher mon calendrier de la semaine (fusionnant 3 calendriers différents). Je récupère les 3 fichiers ics correspondant toutes les heures en crontab et le rendu est fait automatiquement.

cal.jpg

Munin

Un lien vers mon interface web de supervision (iframe, là encore).

Widgets

Une page de "widgets". Je ne sais pas trop quoi y mettre, j'ai mis une météo histoire de voir le rendu mais je n'ai pas d'autres idées pour le moment. Si vous avez des suggestions, n'hésitez pas :)

widgets.jpg

Logout

Et enfin, le lien vers mon logout.

Interface mobile

Un autre gros avantage d'AdminLTE est son interface bootstrap, adaptée aussi pour les smartphones/tablettes. Le rendu de ma page est parfait sur mon téléphone, qu'il s'agisse de la page d'accueil ou de mes flux RSS :

tel.jpg

À vous maintenant

J'ai fait cet article suite à plusieurs mails que j'ai eu après mon précédent article de personnes qui me demandaient le code de ma page d'accueil (que j'avais brièvement évoqué). Parallèlement à ça, je travaille de plus en plus avec git au boulot et j'ai toujours un peu de mal à suivre, du coup, je me suis décidé à faire d'une pierre deux coups et à mettre ce code sur github !

Alors certes, tout le code n'est pas super génial. Je faisais au plus vite, selon mes besoins du moment (et ne prévoyait pas de publier ce code à l'origine). L'authentification par exemple est extrêmement simpliste (un pauvre cookie), mais ça me suffit en tout cas. Je sais qu'il y a beaucoup de choses à modifier, certains à ajouter, d'autres à supprimer : ne vous gênez pas, vous êtes libre de prendre le code et d'en faire ce que vous voulez.

Vous pouvez voir une démo ici et récupérer le code à l'adresse suivante : https://github.com/bseclier/homepage

Si vous mettez cette page chez vous, ça serait cool de faire un petit screenshot, afin que je puisse voir l'étendue de vos idées (et peut-être en récupérer certaines). Si c'est une page publique, je pourrais l'ajouter en lien sur le github du projet. Dans tous les cas, si vous avez des problèmes avec ce code, si vous avez des idées d'amélioration, n'hésitez pas à me contacter (ici, sur github ou via mon formulaire de contact).

À bientôt

2016-01-16

Profilage CPU de rss2email et feedparser (python)

J'ai déjà parlé à plusieurs reprises sur ce blog de rss2email pour récupérer les flux rss. Avec plus d'une centaine de flux, il est un peu lent et consomme tout de même pas mal de CPU. Je me suis donc lancé dans un profilage du code pour comprendre ce qui consommait le plus.

Deux objectifs à ce billet :

  • rapporter ma méthode
  • demander à la communauté ce qu'on peut faire pour optimiser ce que j'ai identifié (cf la fin de ce billet)

Mise en place du profilage

On commence par cloner le dépôt de rss2email

git clone https://github.com/wking/rss2email
cd rss2email

ainsi que feedparser, la bibliothèque principale car je pressens qu'on va devoir y jeter un coup d'oeil.

git clone https://github.com/kurtmckee/feedparser.git

Je crée un virtualenv avec pew, comme suggéré par sametmax, c'est bien plus pratique.

pew new profiler

Construction et déploiement du code avec la méthode develop. Elle fait un lien symbolique, ce qui permet de ne pas avoir à faire une installation à chaque modification de code, ce qui est très intéressant lorsqu'on avance à petit pas dans le profilage.

cd feedparser
python setup.py develop
cd ..
# rss2email
python setup.py develop

On vérifie que ça tourne comme on l'attend. J'ai importé mes fichiers de conf et de base de données du serveur de prod pour être en condition de données réelles. L'option -n permet de faire un dry-run, c'est-à-dire de ne pas envoyer le courriel.

r2e -c rss2email.cfg  run 30 -n

J'installe la bibliothèque qui permet de profiler le CPU. Voir cette référence que j'ai trouvé utile pour les différentes méthodes de profilage en python.

pip install line_profiler

Pour activer le profilage sur une fonction, il suffit d'utiliser un décorateur.

@profile
def func(var):
    ...

On lance ensuite kernprof

kernprof -l -v r2e -c rss2email.cfg  run 30 -n

De manière récursive, je descend dans le code en répérant les fonctions qui prennent le plus de temps CPU.

Résultats

Le résultat est que le temps CPU est principalement utilisé par feedparser, que la moitié du temps sert à récupérer des données à travers le réseau (urllib) et l'autre moitié à faire du parsage de date. Ce parsage est traité en interne par feedparser.

Ces résultats sont rapportés dans ce ticket.

Regardons plus en détails. Il existe plusieurs formats à gérer. Pour mes flux, c'est principalement rfc822.

Le code commence par ceci

timezonenames = {
    'ut': 0, 'gmt': 0, 'z': 0,
    'adt': -3, 'ast': -4, 'at': -4,
    'edt': -4, 'est': -5, 'et': -5,
    'cdt': -5, 'cst': -6, 'ct': -6,
    'mdt': -6, 'mst': -7, 'mt': -7,
    'pdt': -7, 'pst': -8, 'pt': -8,
    'a': -1, 'n': 1,
    'm': -12, 'y': 12,
    'met': 1, 'mest': 2,
}

def _parse_date_rfc822(date):
    """Parse RFC 822 dates and times
    http://tools.ietf.org/html/rfc822#section-5
    There are some formatting differences that are accounted for:
    1. Years may be two or four digits.
    2. The month and day can be swapped.
    3. Additional timezone names are supported.
    4. A default time and timezone are assumed if only a date is present.
    """

    daynames = set(['mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun'])
    months = {
        'jan': 1, 'feb': 2, 'mar': 3, 'apr': 4, 'may': 5, 'jun': 6,
        'jul': 7, 'aug': 8, 'sep': 9, 'oct': 10, 'nov': 11, 'dec': 12,
    }

    parts = date.lower().split()

Avec le profilage, j'ai vu que 10% du temps était utilisé à construire le set(). Les avantages de set sont de garantir l'unicité et d'avoir des opérations de type union ou intersection (comme le dit la doc). Ici, daynames n'est pas modifié, on n'a pas donc besoin de fabriquer l'unicité sur quelque chose qu'on définit. Seule une itération est faite sur cet élément. Le set() ne me semble donc pas justifié.

J'ai ouvert un pull request pour corriger le set en tuple, et passer la déclaration en variable globale.

Si vous avez des suggestions pour améliorer les performances, n'hésitez pas à les partager sur github ou par email. Merci !

Note : email.utils.parsedate_tz semble être plus lent que l'implémentation de feedparser, en terme CPU, c'est relativement comparable.

2016-01-14

Les nouveaux trusts


Si j'en crois la définition de Wikipedia, le mot trust désigne le plus souvent une entreprise qui possède une position forte, voire dominante, dans un secteur donné.

Et ben, vous savez quoi, c'est ce qui me traverse l'esprit quand je traîne sur l'internet à la recherche d'information. On sait que l’époque des blogs est quasi révolue, qu'ils n’intéressent plus vraiment grand monde. De nos jours, ce genre de vieux média est remplacé par les youtubeurs. La transmission de l'information se fait par la vidéo, moins par l’écrit. Pourtant, il reste des gars qui usent leurs touches de clavier, mais ce ne sont plus des blogueurs.

Les fermes de billets, c'est aussi comme ça qu'on pourrait les appeler. Vous savez, ces sites qui se donnent un apparence professionnelle et qui ne sont qu'une accumulation d'articles ou de tutoriels sur un thème donné. Dans le domaine technique, on en trouve sur l'utilisation de CentOS, de Debian, de MySQL, etc. On parle ici de sites qui ne parlent que de ça, reprenant le contenu du web pour le centraliser sur leur ferme de billets. Et ces gars là, ils assurent avec Google.

Rien qu'une recherche sur l'installation de MySQL sur CentOS et on se retrouve sur le site de Tecmint, par exemple. Je pourrais me marrer en voyant que ce sont sont des indiens qui y pondent le plus de billets alors que je me souviens très bien du bordel que c’était quand j'ai passé un an au MIT, mais nan.
Ces sites, comme celui de DigitalOcean sont des bonnes sources d'information, fiables. Je m'en sers souvent, pour installer autre chose que MySQL sur CentOS, même si cet OS est une plaie. Ils sont bon, donc ils montent dans les résultats de recherche. Comme ils sont alimentés par une foule de gars (et de nanas), leurs articles sont toujours à jour. Pour finir, ils se servent de CMS bien calibrés pour s’emboîter avec Google.

Au quotidien, je me rends compte que je ne passe plus que par des sites vitrines, regroupant l'intelligence globale pour vendre leurs services et/ou produits. Ça me navre.



Elle est où l’époque où une recherche sur le net retournait un billet de blog bien foutu avec l'avis du blogueur et ses anecdotes drôles, ou pas, autour de l'installation et la configuration de bidule et truc ? On dirait que c'est foutu. Qui va s'amuser à pondre un billet dans cet environnement trusté par ces gros tas ? Des irréductibles, qui vont temporairement s'arroger le droit d’apparaître dans le Top 3 de Google pendant deux mois puis disparaître.


<noscript></noscript>

2016-01-13

Installer Gitlab en 5 minutes avec Docker

Le sujet du serveur git auto-hébergé me tient à coeur puisqu’il a été le sujet de nombreux articles sur la SheevaBoite. Ces articles commencent à dater d’autant plus que cela fait longtemps que j’utilise Gitlab pour mes dépôts personnels.

Comme je suis entrain de réinstaller mon serveur suite à un petit upgrade matériel, j’installe des containers Docker pour tous mes services et j’ai pensé que cela serai intéressant d’en faire un article sur Gitlab, puisque c’est simple, rapide et efficace.

1re minute : Installation du container

Je ne parle pas de l’installation de Docker, le site officiel explique tout cela en détail très bien.

Pour mon service Gitlab, on va utiliser l’image docker officielle de la Community Edition. Selon la doc, il faut créer 3 répertoires qui seront montés en tant que volume dans le container. Ainsi les données importantes du container seront isolés sur la machine hôte et facilement «backupables».

$> mkdir -p /data/gitlab/{config,data,logs}

Il suffit maintenant de lancer le container avec la commande :

$> sudo docker run --detach \
    --hostname gitlab.mon-domaine.fr \
    --publish 4433:443 --publish 8080:80 --publish 2222:22 \
    --name gitlab \
    --restart always \
    --volume /data/gitlab/config:/etc/gitlab \
    --volume /data/gitlab/logs:/var/log/gitlab \
    --volume /data/gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ce:latest

La commande semble compliquée mais en fait elle est vraiment simple :

  • on donne le url que l’on va utiliser pour accéder à Gitlab,
  • on déclare le mapping entre les ports de la machine hôte et le container,
  • on donne un nom au container,
  • on veut qu’il redémarre s’il crash (ainsi qu’au login),
  • on déclare les volumes de l’hôte qui seront montés dans le container,
  • on déclare l’image que l’on utilise pour le container.

Je n’utilise pas directement les ports 80, 443 et 22 puisque j’ai déjà des services qui tournent sur ces ports (et c’est probablement le cas pour vous aussi ! ).

Une fois que le container est démarré, vous pouvez vérifier qu’il est bien démarré avec la commande suivante :

$> docker ps -a
CONTAINER ID        IMAGE                     COMMAND                  CREATED             STATUS              PORTS                                                                  NAMES
f8011b5157f9        gitlab/gitlab-ce:latest   "/assets/wrapper"        53 seconds          Up 53 seconds       0.0.0.0:8080->80/tcp, 0.0.0.0:4433->443/tcp, 0.0.0.0:2222->22/tcp      gitlab

Gitlab est accessible maintenant sur http://<MON-IP>:8080/ et vous pourrez vous connecter en SSH sur le port 2222 sur votre serveur.

2e minute : Configuration de Gitlab

L’installation de Gitlab est terminée mais il faut encore faire un peu de configuration.

Par défaut, un utilisateur root a été créé avec le mot de passe 5iveL!fe. Connectez-vous et vous devriez changer immédiatement le mot de passe de cet utilisateur. Profitez-en aussi pour changer le nom de l’utilisateur, ça permettra d’éviter le brute-force sur l’utilisateur root.

Ajoutez aussi votre clé privée à votre compte afin de pouvoir communiquer avec le serveur en SSH et créer un dépôt de test, par exemple «dummy_repo».

3e minute : Configuration de votre machine

Sur votre machine, il faut faire un peu de config aussi, afin de justement se connecter en SSH. Editez le fichier ~/.ssh/config et ajoutez les lignes :

Host mon-domaine.fr
   Port 2222
   Identityfile <PATH_VERS_MA_CLE_PRIVE>

Dorénavant, vous devriez pouvoir cloner le projet que vous avez créé :

$> git clone git@<VOTRE_IP>:<VOTRE_USER>/dummy_repo.git

4e minute : Création d’un proxy

Le serveur Gitlab opérationnel en moins de 5 minutes… Mais si vous vous souvenez lors du démarrage du container, on avait un paramètre hostname, si on veut pouvoir accéder à notre serveur via cette url, il faut installer un petit proxy. Installez nginx si ce n’est pas déjà fait et ajouter un vhost avec la configuration suivante :

server {
  listen 80;
  server_name gitlab.mon-domaine.fr;

  location / {
    proxy_pass https://0.0.0.0:8080;
    proxy_set_header        X-Real-IP  $remote_addr;
  }

}

Redémarrer votre instance nginx et vous pouvez accéder maintenant à votre service Gitlab via l’url mon-domaine.fr, ce qui est tout de même plus pratique que via l’adresse IP.

5e minute : Enjoy !

Voilà comment installer rapidement une instance Gitlab, je n’ai pas besoin d’envoyer des mails donc le sujet de la configuration SMTP n’a pas été abordé, mais si cela est important pour vous, tout se trouve dans le fichier : /data/gitlab/config/gitlab.rb.

Pour finir, Gitlab a ses défauts, il est un peu lourd (comptez 1,33Go pour l’image de base) et il demande de la puissance pour fonctionner, mais avec Docker il n’est plus du tout compliqué à installer. Avant que les package omnibus existe l’installation de Gitlab était bien compliqué mais avec Docker c’est une question de quelques minutes…

Profitez-en pour l’essayer et l’adopter si ce n’est pas déjà fait…

La VOD sous GNU/Linux, bordel, c'est pas encore ça.


Des fois, on se dit qu'il ne serait pas trop mal d'acheter un produit pour remercier/participer au travail de ses créateurs. C'est exactement le sentiment qui m'a traversé l'esprit quand j'ai voulu me lancer dans le visionnage du documentaire : Le prix à payer, de Harold Crooks.



Alors, dans ces cas là, un idiot comme moi se lance dans l'offre légale. En 2016, naïvement, je pensais que les choses seraient fluides, faciles et interopérables. On trouve encore beaucoup d'anciens articles traitant du désastre technique et éthique de la vidéo à la demande depuis qu'elle existe. Mais ça, c’était avant ? Non.

On va rapidement passer sur les offres clairement non compatibles. Exemple : Orange.



Les gars ne sont pas compatibles avec mon Ubuntu 14.04, les emmerdeurs, mais ils l'affichent en gros, en clair : Service non compatible avec les configurations Linux déforme le header du site. Suivant.

L'autre offre que je suis allé voir est celle de UniversCiné. Là, content de traîner sur un site à l'ergonomie pas vilaine sans bandeau m’indiquant d'aller voir ailleurs, je me lance dans l'achat de la version HD, sans streaming. L'option "Acheter" s'oppose, pour moi, à la location. Bêtement.



Après avoir laissé les informations de ma carte bleue sur le site, mais pas que, la réception du mail de confirmation de ma commande et tout le bordel, je me jette sur l'interface de téléchargement. A moi le documentaire !

Et non. On ne télécharge pas un fichier acheté.

Le site fonctionne comme Steam : on doit se coltiner un client pour profiter de ses achats. Autant, chez VALVe, ça ne me choc pas plus que ça, autant sur l'achat d'un autre produit qu'un jeu, ça me les brise. Surtout que le client qui me sépare de mon achat est fait via Adobe Air, dont je ne connaissais pas l'existence mais dont la marque me donne la nausée.
En bon bidouilleur, j'arrive à installer Adobe Air, le sésame qui doit me permettre d'installer le client UniversCiné. Mais nan, ça ne suffit pas. Le client, même avec sa dépendance installée et reconnue par l'OS et le navigateur, ne s'installe pas. Rien n'y fait.

Je rageais, vraiment. Deux heures perdues pour ça. Je le voulais, ce documentaire, et je le voulais légalement. Je suis déception.

Au final, je tiens à terminer sur une bonne note. J'ai directement envoyé un mail au service après-vente qui m'a répondu dans les 24h en confirmant que j'allais être remboursé. C'est la moindre des choses, mais on n'est jamais très détendu en faisant ce genre de démarche.

Conclusion, je vais encore me retourner vers le torrent que je chérie tant. Si je n'y trouve pas mon bonheur, j'irais acheter le DVD là où je pourrai et je vous laisse deviner ce que j'en ferai. Au mieux, si l'un de vous peut me rediriger vers une plate-forme légale avec laquelle je peux m'entendre, je ferai mon bon samaritain.


<noscript></noscript>

2016-01-12

[Docu] 2 degrés avant la fin du monde


Deux degrés avant la fin du monde, c'est le documentaire passionnant que les gars de #DataGueule ont pondu pour la COP21. Si vous ne l'avez pas encore vu, n’hésitez plus une seule seconde :

<iframe allowfullscreen="" frameborder="0" height="360" src="https://www.youtube.com/embed/Hs-M1vgI_4A" width="640"></iframe>

Faites tourner cette vidéo, d'1h30 certes, mais allez-y. C'est frustrant de loucher sur le compteur pour réaliser qu'elle n’atteint même pas les 350 000 vues.
Ouais, je sais, un libriste qui gonfle déjà son monde avec son utilisation farfelue de l'informatique et qui en plus parle écologie, ça fait un joyeux mélange pendant les soirées bières, mais bon.


<noscript></noscript>

2016-01-10

Le problème du logiciel libre dans le cloud


En matière d'informatique dans les nuages, les logiciels libres et open source sont souvent des pointures. Qu'on parle d'ownCloud, de FreshRSS, du futur de Sonerezh pour ne parler que de ceux que j'utilise au quotidien, on se rend compte de leurs potentiels et de leurs intérêts : on se débarrasse de toutes contraintes pour ne faire que ce que l'on veut.

Pourtant, leur utilisation se heurte toujours à un problème : il faut avoir un nom de domaine et un serveur. Le nom de domaine est presque un souci négligeable quand on le compare à la gestion d'un serveur. Quelle distribution GNU/Linux ? Quel fournisseur ? Une fois qu'il est là, j'en fais quoi ? J'installe quoi ? Si on arrive à installer un petit quoi que ce soit, la question qui suit est la pérennité du serveur, sa stabilité, sa sécurité. Autant de choses qui font peurs et qui empêchent les Michus de se lancer dans l'aventure.

Je suis personnellement convaincu que ces services peuvent trouver leur place dans la vie numérique d'un grand nombre de personne une fois l'obstacle du serveur dépassé. Framasoft et sa campagne de Dégooglelisons internet montre qu'il existe un beau paquet d'utilisateurs qui aimerait se servir de la puissance du logiciel libre mais qui ne peuvent pas passer outre l'obstacle serveur.

Il existe des solutions pourtant : passer par des associations, comme Framasoft, passer par des fournisseurs de serveurs déjà configurés comme ceux de Scaleway ou se servir de Yunohost qui surcouche les traces de l'utilisation d'un serveur.
La première se veut être un POC, un Proof of Concept, une façon de montrer que les logiciels libres sont capables. La deuxième offre des outils intéressants mais ne dédouane pas l'utilisateur de savoir gérer un serveur. La dernière surcouche un fonctionnement complexe qui, sans prévenir, peut disjoncter et laisser l'utilisateur complètement perdu,

J'ai une idée en tête, je ne veux pas encore m'avancer sur sa définition, tellement elle me parait au choix trop simpliste ou trop tordue.


<noscript></noscript>

2016-01-06

Mon matériel pour 2016


Pas de grosse nouveauté autour de mon équipement pour 2016. J'avais déjà changé de classe en passant d'un vieux Quad-Core (Q6600) par un Eight-Core (AMD FX-8350). La claque s'est bien faite sentir, surtout qu'en même temps, je suis passé de 4 à 8 Go de mémoire vive.

Au niveau où j'en suis, en utilisant Ubuntu 14.04, un seul écran, passant le plus clair de mon temps avec Firefox, Thunderbird et un nombre terrifiant de terminaux ouverts sur mes différents serveurs, mon vieux portable Dual-Core et ses 4 Go de mémoire vive avec lequel je supporte mes week-end en famille me va encore plutôt bien, même si le couple Firefox/Thunderbird s'amusent à me donner des sieurs froides.

Ubuntu 14.04 LTS donc. L'OS demande des ressources, mais pas tant que ça. Je suis largement au dessus des recommandations. C'est un diktat que je m'impose depuis des années qui fait que j'en suis là : pas de changement si ça marche. Je foutrais bien des claques à ces gens qui changent un bout de leur tour chaque trimestre parce que, soit-disant, c'est plus assez rapide. J'comprends pas.
Quand je change, c'est un peu un événement tellement c'est rare. Je fais parti de ceux qui se limitent à jeter leurs anciens équipement tellement il est usé. Tant que ça tient, ça tient, après poubelle.

Alors, pour terminer ma configuration de tueur et commencer 2016 avec un petit plaisir de la vie, je me suis attaqué au disque dur. Je tournais sur un vieux Caviar Green de 2 To, au 3/4 vide. Ceux qui savent un peu ce que c'est vous confirmeront que ce sont des disques durs de stockages et pas des trucs sur lequel on installe son OS. J'ai donc virer ce vieux coucou dont les grincements ne me manqueront pas.
Exit le vieux modèle de plusieurs To que je traînais, place au SSD !



Le SSD, c'est une claque, vraiment. Il parait que ce n'est pas encore super au point, mais mon choix était fait : un truc de 512Go est au chaud dans ma tour. Waaa, clairement, Waaa ! J'ai pris conscience de la puissance des ces bêtes là lorsque la réinstallation complète de mon OS et de mes outils s'est terminée sous la barre de la demi-heure : 30 min ! Ça remet les idées en place quand le téléchargement des paquets est plus lent que leurs installations. Et que télécharge jusqu'à 6Mo/s, pas théorique, du vrai.

Que dire du chargement des mastodontes que sont les Firefox, Thunderbird, TheGimp ou encore LibreOffice une fois la bête dans ma tour : la panade. L'envie de le tester en me faisant une partie de Dota2 ou autre se fait attendre mais le résultat doit être identique. C'est quand même con de sortir de genre de gadget et de ne plus avoir envie de lancer des gros jeux bien lourds.

Je suis vraiment content de cet achat et si j'en crois la pub, je suis tranquille pour presque 5 ans, ce qui va bien avec mon agenda de changement de matériel. D'ici là, mon processeur montrera des signes de fatigue et je pourrais me remettre une claque technologique sans me dire que je consomme comme un con.


<noscript></noscript>

2016-01-05

Cap sur LXC

Rendez-vous à Farpoint

Il y a quelques mois j’entamais une réflexion sur le changement de ma solution d’hébergement. Ce fut le point départ de longues semaines de travail. J’ai parcouru les quatre coins de la toile afin de me documenter sur la mise en place de LXC. Après huit mois de travail le projet commence à se concrétiser. Voici la configuration que j’ai installée afin de réaliser mes essais sur LXC. Mon cahier des charges étant très simple, exécuter mes différents serveurs (mails, dns, web, et autres) dans des containers et en faire une sauvegarde externalisée en cas de pépin. Ce sera l’occasion de faire une petite série d’articles sur mon utilisation de LXC.

Le serveur

Tout d’abord j’ai cherché un nouveau matériel, quelque-chose de peu encombrant, le moins énergivore possible et qui me permettrait de pouvoir exécuter des containers. Actuellement mon serveur hôte datant de 2010 abrite un vieil Athlon II dual-core accompagné de 8Go de ram et d’un disque dur de 500go de disque dur en sata. C’est largement suffisant pour héberger mes quatre containers Openvz et mes deux VM Kvm (qui seront amenées à disparaître avec la nouvelle solution) le tout orchestré par Proxmox. Ma démarche actuelle n’est pas de changer pour plus puissant, je n’utilise même pas la moitié de la RAM et le processeur ne vacille jamais au dessus de 15% d’utilisation. Ce que j’ai mis en place en 2010 n’est plus en adéquation avec ce que  j’aspire aujourd’hui. En effet ce serveur est en configuration moyen tour avec une alimentation de 450 watts et un ventilo de 120mm en façade. Au niveau encombrement il n’est pas facile de lui trouver une place loin du lieu de vie et à cause de sa ventilation vieillissante il a de plus en plus de mal à se faire oublier.
J’ai donc opté pour un petit Brix de chez gigabyte le GB-BXBT-2807. Équipé d’un intel dual-core qui ne consomme que 4w. J’y ai rajouté 8go de ram et un disque-dur de 500Go.  L’encombrement est minimal et je retrouve presque les mêmes performances que mon vieux serveur.

La bête mise à nue

La bête mise à nue

Voici le détail du matériel que j’utilise pour cette configuration :

  • BRIX GB-BXBT-2807
  • 8 Go de ram Corsair Value Select SO-DIMM 8 Go DDR3L 1333 MHz CL9
  • Disque dur Seagate Constellation 500 Go 7200 RPM 64 Mo Serial ATA 6Gb/s

Le choix du disque n’est pas encore arrêté, je me demande si au de niveau bruit il ne vaudrait pas mieux prendre un 5400 tours, mais d’un autre côté j’ai peur de perdre des performances. La vitesse du disque dur est-elle prépondérante dans le fonctionnement des containers ? Je planche encore sur la question. Je commence aussi à regarder du côté des SSD, mais j’avoue que la technologie me fait encore un peu peur.

Mise en place

Le choix du moteur de containers n’a pas était long à prendre, car d’un côté j’avais OpenVZ :

  • Vieux noyau
  • Incompatible avec systemd donc condamné à utiliser Wheezy
  • Silence complet sur le nouveau projet Virtuozzo 7(au moment où j’écris ses lignes)

et de l’autre LXC :

  • basé sur les outils noyau donc noyau plus récent
  • compatible systemd utilisable sur Jessie et supérieure
  • Projet très actif, la dernière mise à jours date de novembre 2015
  • Mon goût pour l’aventure, essayé quelque chose de nouveau, bousculer ma routine de geek.

C’est pourquoi j’ai souhaité migrer sous LXC, plutôt que de continuer dans la valeur sûr OpenVZ que j’utilise depuis quelque année déjà.

Pour mon système hôte j’ai donc choisi de partir sur :

  • Une Base Debian 8
  • Système de fichier BTRFS
  • Un point de montage NFS pour les sauvegardes

Voici comment sera organisé mon installation système.

HDD
├── /(/dev/sda1)ext4
│           
├── swap(/dev/sda2)swap
│
└── /lxc-data(/dev/sda4)btrfs
      ├── /var/lib/lxc/(sous-volume0)btrfs
      │       ├── container1
      │       ├── container2
      │       ├── container3
      │       └──....
      │           
      └──/var/lib/lxcsnaps/(sous-volume1)btrfs
              ├── snapshot container1
              ├── snapshot container2
              ├── snapshot container3
              └──....

Dans un premier temps l’intérêt du dispositif LXC+BTRFS réside dans la possibilité de créer très rapidement des instantanés et des clones. Pour les instantanés (snapshot) il faut que le dossier lxcsnaps soit intégré dans le système de fichier btrfs. Les instantanés sont utiles avant une mise à jour système par exemple pour un retour en arrière rapide en cas de problème ou sauvegarder le container en toute simplicité. Le clonage est aussi très intéressant il permet de gagner du temps lors de la création d’un nouveau container. Dans un second temps il s’agit d’une meilleure gestion de l’espace disque lorsque l’on fait plusieurs instantanés d’un même container il ne copie que la partie du conteneur qui a changé. La finalité étant de mettre la partition /var/lib/lxcsnaps sur mon Nas en évitant de sauvegarder les containers sur le serveur.

Pour bénéficier de ce système de fichiers je crée la partition mère lxc-data qui hébergera les différents sous-volumes

mkfs.btrfs /dev/sda4

et de je la monte de façon permanente dans le fstab. Il est recommandé de monter les partitions et sous-volumes btrfs avec l’UUID. Ici l’UUID de sd4 est a69d9182-f4c7-4276-b35d-7d5f9bd50a57.

UUID=a69d9182-f4c7-4276-b35d-7d5f9bd50a57      /lxc-data      Btrfs      rw,noatime,compress=zlib,autodefrag      0      0

Ensuite je crée les deux sous-volumes,

#le sous-volume des containers
btrfs subvolume create lxc
#le sous-volume des instantanés
btrfs subvolume create lxcsnaps

et toujours pour que le montage soit permanent j’ajoute dans le fstab.

UUID=a69d9182-f4c7-4276-b35d-7d5f9bd50a57      /var/lib/lxc      Btrfs      rw,noatime,compress=zlib,autodefrag,subvol=lxc-data/lxc      0      0
UUID=a69d9182-f4c7-4276-b35d-7d5f9bd50a57      /var/lib/lxcsnaps      Btrfs      rw,noatime,compress=zlib,autodefrag,subvol=lxc-data/lxcsnaps      0      0

Voila l’environnement des containers est en place. A voir avec le temps si celui-ci viable pour mon utilisation de LXC, ça tombe bien cela fait parti du test.

Installation et configuration de LXC

Préparation du noyau :

LXC est en perpétuel évolution afin de bénéficier des récents changements, j’utilise un noyau plus récent que celui fournit avec Jessie. J’installe donc celui de la branche testing. Je crée un fichier préférence pour définir la priorité des dépôts :

nano /etc/apt/preferences.d/kernel

Package: *
Pin: release a=stable
Pin-priority: 900
 
Package: *
Pin: release a=testing
Pin-priority: 100
 
Package: linux-image-*
Pin: release a=testing
Pin-priority: 1001
 
Package: linux-headers-*
Pin: release a=testing
Pin-priority: 1001
 
Package: linux-kbuild-*
Pin: release a=testing
Pin-priority: 1001

Ensuite dans le fichier source.list d’apt j’ajoute :

nano /etc/apt/sources.list

# Kernel Testing
deb http://ftp.fr.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.fr.debian.org/debian/ testing main non-free contrib

Pour finir dans mon terminal :

apt update
apt install linux-image-amd64

Après un redémarrage me voilà en version 4.3 du noyau. En revanche, j’ai été obligé de désactiver la mise en veille de l’écran, car celui-ci ne se rallume pas une fois en mode veille.

nano /etc/default/grub
#ajouter consoleblank=0 à la ligne
GRUB_CMDLINE_LINUX_DEFAULT="quiet consoleblank=0"
#reconfiguration de grub
update-grub
#redémarrage du serveur

Installation de LXC sous Debian 8.2 :

apt install lxc bridge-utils libvirt-bin debootstrap cgroupfs-mount

Souhaitant gérer la mémoire et le swap de mes containers je suis obligé d’activer le cgroup responsable de la mémoire qui est déactiver par défaut. Debian a choisi de ne pas activer par défaut ce cgroup afin de ne pas pénaliser les utilisateurs qui ne souhaitent pas les utiliser. Cela évite une trop grande consommation mémoire pour rien. Il me suffit d’ajouter l’instruction « cgroup_enable=memory » et pour le swap « swapaccount=1 » au démarrage de Grub.

nano /etc/default/grub
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'
 
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet consoleblank=0 cgroup_enable=memory swapaccount=1"
GRUB_CMDLINE_LINUX=""
[...]

Pour activer les changements sur grub.

update-grub

Pour finir je redémarre mon hôte et vérifie l’installation de LXC

lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.16.0-4-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

Tout est OK, je continue avec la configuration réseau de mon hôte. Pour plus de simplicité la configuration de l’interface réseau de mon hôte sera en mode bridge. L’activation du mode bridge sur le serveur hôte se fait dans le fichier interfaces. Attention toutefois à ce que le paquet bridge-utils soit installé sur l’hôte. Ce fichier régente la configuration des tous les périphériques réseau du système. Il se trouve dans /etc/network/interfaces.

nano /etc/network/interfaces
# je commente les lignes de l'’interface réseau principale 
#allow-hotplug eth0
#iface eth0 inet dhcp

#J'active le bridge avec ip statique sur l’hôte
auto br0
iface br0 inet static
       bridge_ports eth0
       bridge_fd 0
       address < IP de l’hôte ici, exemple: 192.168.1.20>
       netmask 255.255.255.0
       network <IP du réseau ici, exemple: 192.168.1.0>
       broadcast <IP de broadcast ici, exemple: 192.168.1.255>
       gateway <IP de la passerelle ici, exemple: 192.168.1.1>
       dns-nameservers <Adresse IP du DNS ici, exemple: 192.168.1.1>
       dns-search votre.domaine.de.Recherche.ici

Validation de la modification.

systemctl restart networking

Sur le container qui me servira de base pour cloner les autres, j’applique la configuration réseau suivante.

## Réseau
lxc.utsname = containershostname
lxc.network.type = veth
lxc.network.flags = up

# Ceci est l’interface définit plus haut dans le fichier interface de l’hôte :
lxc.network.link = br0

# Nom de l’interface réseau dans le container,
# lxc.network.name = eth0 

lxc.network.hwaddr = 00:FF:AA:00:00:01

# L’ip du container 
lxc.network.ipv4 = 192.168.1.110/24

# Définissez la passerelle pour avoir un accès à Internet
lxc.network.ipv4.gateway = 192.168.1.1

LXC est maintenant en place, le gros du travail commence. Découvrir l’utilisation des containers, leur configuration, leur sauvegarde et bien d’autre. D’après mes premières manipulations, LXC est aussi facile d’utilisation qu’OpenVz. Il faut que je me familiarise avec les différentes commandes et la philosophie qui ne sont pas les mêmes.  J’ai encore pas mal des questions en suspend, c’est pour cela que je me lance dans ses essais grandeurs natures. Petit à petit je basculerai certains des mes serveurs sur cette nouvelle infrastructure en mode presque réel afin d’observer le comportement de tout ce petit monde. Suite au prochain épisode.

Merci à Deimos et au Wiki Debian qui m’ont beaucoup aidés à mettre en place cette plateforme de test.

 

 

2015-12-31

Fin d’année, fin des certificats, coucou LetsEncrypt !


Quand j’écris ce genre de titre, je me demande toujours comment je vais faire pour pondre un billet convenable. Pas grave, essayons :

Alors, ce serveur et celui de diaspote.org (vous savez, le pod diaspora* ) traînaient deux types de certificats : celui offert par Gandi pour dadall.info et un StartSSL pour diaspote. Rien de très reluisant, ni très fiable, alors cette fin d’année et leurs dates d'expirations m'ont motivé pour me lancer dans l'utilisation de LetsEncrypt .

Une fois en place, voici ce qu'on peut maintenant admirer :




Pas mal, non ?

L'utilisation est passablement simple pour ceux qui ont l'habitude de jouer avec des certificats. Le script est à exécuter avec comme paramètre le nom de domaine et les sous domaines qui nous intéressent. Les certificats apparaissent tout seuls et y'a plus qu'à configurer Apache/Nginx. Un restart et c'est terminé.

La seule chose un peu contraignante, c'est qu'il ne faut pas oublier que ces certificats ne sont valables que pour une durée de 90 jours. Certains râleront mais les raisons sont multiples : forcer le renouvellement de certificats entretient le niveau de sécurité et force l'utilisation des dernières configurations efficaces. Ajouter un rappel à son agenda est donc un bon réflexe !


<noscript></noscript>

2015-12-30

diaspora* entre dans les dépôts unstable





C'est en train de devenir une réalité : diaspora* s'installe dans Debian ! Bon, ce n'est qu'un début. On n'est pas encore au niveau d'un paquet disponible dans les dépôts stable, mais c'est déjà ça.

Cette nouvelle me donne l’opportunité de revenir sur la grande nouveauté de cette année 2015 : la mise en place d'un pod diaspora* en tandem avec l'ami Augier.

On va commencer par les choses qui fâchent : oui, à l’époque, j'ai insisté pour que nous restions chez mon ancien hébergeur pour mettre en place le pod. Choix malheureux puisque lors de son lancement, Pulseheberg s'est retrouvé incapable de fournir un service stable, la faute à des attaquants et, sans doute, de mauvais choix. Diaspote en a souffert. Voilà, c'est dit.

En chiffre, ce n'est pas la gloire, loin de là. Ceci-dit, c’était prévisible : des inconnus se lancent dans l’hébergement d'un morceau de réseau social qui personne ne connaît, ou a oublié. Personne ne connaît ? Les attentifs se souviendront de la promotion faite par la presse lorsque des idiots se sont mis à utiliser diaspora* pour répandre leurs idées dites terroristes.
Enfin, peu de monde chez nous : 30 utilisateurs et 14 actifs. On pourrait quand même dire que ce n'est pas si mal pour un pod tournant sur une version instable de diaspora*

Nous utilisons une version instable à des fins de tests. Rares sont les pods avec des caractéristiques techniques (4 cores ARM/2Gb de RAM) aussi faibles et tournant avec le couple MySQL/Apache. N’empêche que ça marche pas trop mal !

Cela nous permet aussi de tester les compétences en expérience utilisateur d'Augier puisqu'il nous gratifie d'un design perso :



Notez aussi le joli panneau latéral dévoilant le superbe système de discussion instantanée ! Ça aussi, c'est un privilège de pod en version instable.

Une année pleine d’expérience, il faut bien le dire. On se lance dans l'aventure sans trop savoir comment ça va se passer. Pour le coup, je dirais que c'est franchement chouette. Tout n'est pas rose mais je peux me servir de mon propre pod pour parler à mes amis blablatant depuis d'autres pods : j'adore.

Dans les points négatifs, même si ça s'arrange avec le temps : la connexion avec les autres pods déraille parfois. On rate des commentaires ou des posts, mais ça fait partie du jeu et ce n’est pas si grave : on a toujours quelqu'un pour reposter ce qui nous échappe, et râler.

Bref, si vous avez du temps à perdre et/ou que vous êtes curieux, je vous invite à venir vous faire un compte chez nous : c'est ouvert !


<noscript></noscript>
Généré le 2016-04-29 01:26 UTC avec Planet Venus