Planète auto-hébergement

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)Ferme-la !(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)Ferme-la !(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’aire 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>

2015-12-28

Nylas N1 : un nouveau dans les clients mails lourds


MàJ : Un grand merci à Pafzedog pour son commentaire. J'ai maladroitement raté une information critique : N1 passe par les serveurs de l'entreprise Nylas pour récupérer nos mails. Mails qui ne seront supprimés que dans les 60 jours après leurs suppressions par l'utilisateur. De plus, le binaire téléchargeable contient des bouts de code non libres.
Il reste la possibilité de récupérer les sources pour les compiler sans inconnus et à faire de même avec l'API qui va chercher nos mails. Ce logiciel perd, donc, pas mal de son intérêt. Fausse joie.


Alors que Thunderbird se stabilise pendant que la fondation Mozilla se désengage, l’arrivée d'un nouveau dans les clients mails lourds, par opposition aux clients web (RainLoop, ownCloud Mail, etc), n’était pas vraiment attendue. Pour ma part, du moins.




Pourtant, c'est en cette fin d’année que Nylas N1 fait son apparition. Techniquement, il est entièrement fait avec des technologies sorties toutes droit du web : HTML, CSS et JS, à la manière des applications pour Firefox OS.

Visuellement, c'est classique : une vue divisée en 2 ou 3 colonnes en fonction des envies.


Je m'en sers depuis un peu plus d'une semaine et la seule chose que j'arrive à dire, c'est que son design est trop swag : le thème de base se rapproche de Google Mail et chaque action dévoile une animation chouette mais sobre. Je ne me sers pas des appareils de la marque à la pomme mais je crois reconnaître une ergonomie assez proche.

C'est encore un jeunot : les comptes classiques Gmail, Yahoo, Outlook, etc, sont bien pris en compte alors que ma boite mail personnelle ne passe pas. C'est peut-être une histoire de configuration maladroite de mon serveur alors je ne m'avance pas trop. Je vous laisse tester ça de votre côté.

Pour l'heure, le projet annonce pouvoir supporter tout un tas d'extensions, mais elles n'existent pas encore. Le temps nous dira s'il arrive à se placer au niveau d'un Thunderbird avec la gestion des contacts et de l'agenda.

Je termine en dévoilant les évidences : il est open source et ouvert à toute proposition et/ou aide.


<noscript></noscript>

2015-12-26

Déploiement de la fibre optique, quel avenir, quels enjeux pour la neutralité ?

Préambule

En définitive, on parle assez peu du réseau internet, je veux dire, le réseau physique. Pourtant, il faut bien s'en soucier, car il est au coeur de la neutralité du réseau. Dans cet article, je me contente de résumer les propos de Benjamin Bayard qu'on ne présente plus. Benjamin donne des conférences très instructives et très profondes, elles sont longues et fouillées, c'est ce que j'apprécie. Mon but est de relayer ici un des messages qu'il porte afin de multiplier les canaux de communication.

Ce qui se passe

Echelles de temps, d'espace et de débit.

  • Les plans pour fibrer la France s'étalent sur environ 10 ans Plan du gouvernement.
  • Les politiques actuelles cherchent à fibrer en priorité les grandes villes et les centres villes.
  • Il faut savoir que le volume de données transférées est multiplié par les abonnées par 10 sous les 6 ans. C'est à dire x100 en 12 ans.

Les conséquences

En terme d'espace, le fait que les zones ayant déjà un débit élevé passent à la fibre en priorité fait que la fracture numérique se creuse et continuera à se creuser. Etant donné les volumétries prévues, les régions en ADSL deviendront inhabitables du point de vue de l'internet qu'il s'y trouvera. Pour cette raison, Benjamin parle "d'erreur d'aménagement du territoire". Il faut se rendre compte qu'internet ne sert pas qu'à regarder la télévision mais il est au coeur du développement économique.

Monopole et oligopole... les risques

Si les associations membres de la fédération FDN peuvent fournir de l'internet ADSL, c'est parce qu'ils sont en mesure d'utiliser un réseau existant (dégroupage) et de pouvoir l'utiliser même pour un petit nombre d'abonnées. Avec la fibre, la situation est très différente.

Dans les zones très denses (ex Paris), chaque opérateur déploie le réseau comme il le veut. Il y aura donc plusieurs réseaux de fibres si plusieurs opérateurs sont intéressés. Dans les zones denses, il y a un accord de co-investissement entre les opérateurs, mais la participation ne peut se faire que pour des volumes d'abonnés très importantes. En zone peu dense, c'est de l'investissement public (collectivités territoriales), là où potentiellement ça peut mieux se passer pour des associatifs, mais ça reste vraiment difficile.

Si rien n'est fait, nous allons vers un oligopole (au mieux) ou un monopole orange subventionné par les contribuables 10 milliards d'euros. Bien sûr, l'unicité (ou quasi-unicité) de l'opérateur remet en cause la neutralité du net. En effet, là où il n'y aura qu'un opérateur, la seule solution pour changer de FAI sera de déménager.

Ce que propose Benjamin Bayart est

  • d'expliquer ce qui se passe (ce que je fais ici)
  • suivre les décisions prises sur ces dossiers et dialoguer avec eux
  • commenter, critiquer, conseiller pour que des FAI associatifs puissent continuer à proposer de l'internet.

Références

Le but est de vous motiver à voir par vous même les détails de ce que j'ai résumé.

2015-12-18

rss-bridge : flux rss pour sites qui n'en proposent pas

Les flux RSS me sont incontournables et rss2email est le logiciel que j'utilise. Le choix est expliqué ici.

Le problème survient lorsque des sites ne proposent pas de flux RSS, et généralement, ce sont les sites populaires. Sebsauvage propose un code en php qui se nomme rss-bridge. C'est simple et ça marche : une page en php qui offre la possibilité de générer un flux atom, rss, html, json, txt pour des sites sont les greffons ont été écrit. Il existe de très nombreux greffons activables (s'ils ne le sont pas par défaut). Par exemple, twitter, facebook, google, youtube, leboncoin... la liste se trouve en explorant le répertoire bridges du code. Rss-bridge gère un cache, ce qui permet d'éviter de se faire bannir si le client rss fait trop de requêtes.

Voilà une application simple et utile à auto-héberger !

Mise à jour du plugin pandoc pour ikiwiki

J'utilise Ikiwiki pour ce blog ainsi que des wikis privés ou publics. En deux mots, c'est un outil permettant d'utiliser git pour générer un site statique à partir de fichiers en marquage léger (comme markdown). Pandoc est un outil permettant de convertir du texte dans différents formats, et le nombre de formats supportés est assez impressionnant.

Il y a quelques années, un greffon pour ikiwiki permettant d'utiliser pandoc comme moteur pour générer de l'html avait été écrit mais non maintenu. Plusieurs avantages à ce greffons : la coloration syntaxique pour les codes, la gestion de mathjax pour les équations, les metadonnées, les formats d'écriture. Sur github, j'avais trouvé un certain nombre de forks que j'ai fusionné pour en faire un code dont l'idée serait de le maintenir à long terme. Ces derniers jours, un de ces contributeurs est revenu vers ce code pour réparer un bug causé par l'évolution de perl, que j'avais corrigé il y a plusieurs mois sur mes serveurs mais oublié de corriger dans le dépôt. Le ticket d'un utilisateur a réveillé tout ça. Suite à ma demande, le contributeur en a profité pour améliorer le greffon, tant sur la doc que sur les fonctionnalités, pour le maintenir à flot vis à vis des évolutions de pandoc.

C'est la magie du logiciel libre comme je l'apprécie. On peut ainsi bénéficier d'un meilleur code avec de nouvelles options, une gestion des metadonnées améliorée et un support des formats étendus.

Ikiwiki offre de vraies possibilités de bidouille. Ca le rend sans doute austère et difficile à appréhender, mais l'automatisation et la flexibilité qu'il offre sont sans communes mesures.

2015-12-17

Bonnes pratiques de déploiement PHP en 2015


C'est assez rare de tomber sur d'aussi bonne vidéo alors je me jette sur mon blog pour vous la partager. Au programme, le gars parle beaucoup des effets serveurs de l'utilisation de PHP et d'autres technologies. C'est passionnant pour un Ops comme moi mais ça devrait aussi passionner les développeurs un peu consciencieux puisqu'il donne des débuts d'astuces pour optimiser son travail. En bonus, en fin de vidéo, un commentaire sur Docker.

Bon visionnage !


<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/8O-IeLRgsCI" width="560"></iframe>


<noscript></noscript>

2015-12-14

Let’s Encrypt : easy !

encrypt-2

 

Personne a dû passer à coté de la news du 3/12/15 ?
Enfin des certificats faciles à générer, sans devoir trouze mille euros et watt mille pièces justificatives !

Mais l’avez vous testé ?
c’est  « trop fa-ci-le » !

On commence par installer les paquets et les dépendances :

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Premier défaut de Let’s Encrypt, il ne faut pas de serveur qui écoute sur le port 80, car il embarque lui même un serveur web pour tester la légitimité de votre demande de certificat :/
Donc, dans mon cas on commence par un :

systemctl stop nginx

Puis on lance la création du/des certificats :

./letsencrypt-auto certonly -d mondomaine.fr -d monsousdomaine1.mondomaine.fr -d monsousdomaine2.mondomaine.fr --rsa-key-size 4096

explications :

  • l’argument « certonly » permet de générer seulement le certificat et ses clés dans le répertoire /etc/letsencrypt/live/
  • « -d » permet de passer les domaines et sous domaines en argument (sinon ça sera en Ncurses).
  • « –rsa-key-size » par défaut la taille de la clé RSA est de 2048 bits, ce qui n’est pas recommandé par l’ANSII, on en profite donc pour la passée en 4096 bits.

Si tout ce passe bien, vous aurez une sortie du type :

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/mondomaine.fr/fullchain.pem. Your cert will
   expire on 2016-03-14. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.

 

On modifie le virtual host sous Nginx (/etc/nginx/sites-enabled/default-ssl) :

server {
    root /var/www/;
    listen       443;
    server_name www.mondomaine.fr;
    index index.php index.html;
    ssl_certificate /etc/letsencrypt/live/www.mondomaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.mondomaine.fr/privkey.pem;
}

Tant qu’à y être et à avoir un beau certificat ssl valide, autant avoir une redirection du 80 vers le 443 !
Il suffit de rajouter dans /etc/nginx/sites-enabled/default, la règle :

return 301 https://$server_name$request_uri;

Il suffit de redémarrer le serveur Nginx, et via un navigateur vérifier la validité de votre nouveau certificat, exemple pour moi :

Capture d’écran_2015-12-14_16-16-08

Autre défaut de Let’s Encrypt : la validité du certificat, mais via « letsencrypt-auto », il facile de scripter dans une tache cron, le renouvellement des certificats.

Enjoy 😉

2015-12-09

Mozilla arrête de se battre contre les vendeurs de smartphones


C'est le titre le plus clair que je peux vous offrir tant que Mozilla ne publie pas d'annonce officielle. On va lire ici est là que Mozilla abandonne Firefox OS alors que c'est faux. Ils abandonnent seulement la lutte contre les vendeurs de smartphones. Ils devaient trop en baver, vraisemblablement, et les ventes de produits peu chers n'aidant pas à l'image de marque, rien n'a permis à Firefox OS de s'en sortir face aux mastodontes déjà présents.

La Fondation ne lâche pas pour autant Firefox OS puisqu'ils vont continuer son développement pour en faire un fleuron des OS pour objets connectés. Chouette, je m'en cogne tellement.

On peut imaginer que l'OS va continuer à s’améliorer, en prenant en compte plus de plate-formes, de supports ou que sais-je ? Ça n’enlève pas le sentiment amèr qui me parcourt l'esprit. Je sais que l'aventure va continuer, que le projet va rester vivant, loin des smartphones. C’étaient ces petites bêtes là qui rendaient ce projet si important. Les télévisions Firefox OS, aucun intérêt, personnellement.

L'annonce va en refroidir plus d'un, en commençant par les développeurs d'applications. Pas si nombreux que ça, ils vont devenir un sujet de conversation pour la COP22. Je sais déjà que le responsive design se suffit à lui même quand on se sert d'un smartphone qui sort des chantiers battus et que, donc, ce n'est pas un si grand problème. Mais l’idée folle de voir apparaitre autre chose, quelque chose de plus natif, de plus puissant, vient de foutre le camp.

Après, les bidouilleurs mozilliens vont continuer à porter l'OS sur d'autres téléphones n’arborant pas la marque Firefox OS à leurs dos. C'est ce qui me chagrine le plus. Un Galaxy S42 utilisable sous Firefox OS, c'est moins prenant qu'un Flame mais c'est sans doute la solution la plus simple que Mozilla pouvait prendre.

En attendant la mort de mon Flame, que j'aime toujours autant, je lorgne vers les Ubuntu Phones tant que Canonical ne jette pas l’éponge. Je vais peut-être devoir changer parce que moi aussi, je fais parti des refroidis.


<noscript></noscript>

2015-12-08

Don du mois : la quadrature

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.

La quadrature du net a mis en place (comme d'autres associations april, fsf) une levée de fond pour financer leurs actions futures. Je peux vous conseiller de regarder la vidéo de Benjamin Bayart & Christopher Talib : Ce que font les exégètes amateurs dans leur garage, pour un bilan de ce qui a été réalisé.

Pour ma part, ce sont 30€ qui partent à la quadrature et je pense renouveller plus fréquemment mes dons vers cette association qui possède une action incisive et décisive.

Thunderbird abandonné... Ou pas.


C'est le truc du moment :  Mozilla cherche à abandonner Thunderbird. On dirait que c'est un coup de tonnerre dans le milieu, que personne ne pouvait ou ne voulait le voir venir.



Pourtant, quand on regarde l’évolution de Mozilla, on se rend compte que c'est parfaitement normal. Firefox et Thunderbird ont pendant très longtemps partagé la même technologie et la même infrastructure de développement interne à l'entreprise. C'est terminé.

Firefox est en cours de réécriture complète : Mozilla n'a pas pondu le langage Rust pour faire joli. C'est un choix technique puissant qui permettra à Firefox de se refaire une beauté. Une beauté que tout le monde attend depuis quelques temps. C'est la réponse de l'ancien patron du web à l’arrivée de Google Chrome et des autres.

Qui dit donc changement de langage, dit réorganisation des équipes et modification des procédures de développement.

Il aurait fallu à Mozilla une volonté et des moyens importants pour entraîner Thunderbird dans la même direction que celle choisie pour Firefox. Ils ont clairement décidé que ce n’était pas la peine et je comprends ce point de vue : Thunderbird est stable, complet et puissant mais n'est plus dans l'air du temps. Les gens passent au webmail sans se retourner. Les inconditionnels des clients lourds sont de plus en plus rares, même s'ils sont encore là. Quel intérêt aurait Mozilla à modifier radicalement le code de Thunderbird pour des gens déjà convaincus par leur client lourd et déjà satisfait ?

Parce que oui, les gens sont satisfaits de Thunderbird. D'une part parce qu'il fonctionne vraiment bien et d'autre part parce que les protocoles utilisés par le mail n’évoluent plus.

Thunderbird est fonctionnel. point final.

Pour résumer : Thunderbird est très bon en l’état mais il ne peut plus se glisser dans l'organisation technique de Mozilla. Ce n'est que pragmatisme que de le laisser voguer vers d'autres eaux.

Et je dis ça sans parler de Firefox OS. Cet OS libre pour smartphone doit encore évoluer, continuer sur sa lancée.  On peut trouver des utilisateurs de Firefox OS déçus, mais il serait plus honnête de parler de gens qui n'ont pas compris dans quoi ils se lançaient : c'est un nouveau, un petit jeunot qui n'a rien d'un outil professionnel et qui n'a pas encore les atouts d'un smartphone moderne. Leur déception est liée à une naïveté de leur part plus qu'à une incompétence de Mozilla.

Les développeurs de Firefox OS se démènent pour réussir un tour de force : offrir une alternative crédible et sa création demande des moyens, du temps et une puissante organisation : je suis persuadé que Mozilla y met tout son cœur et ses moyens. J'y crois, en ce petit bout de code pour smartphone.

Firefox et Firefox OS doivent se battre. Quant à lui, Thunderbird est un gaillard aux cheveux blancs que peu de choses peuvent faire encore bouger. L'Histoire avance avec lui, mais on ne lui demande plus grand chose.


<noscript></noscript>

2015-11-30

Gitlab : Error 500 We’re sorry but something went wrong

Suite à sa migration vers un container lxc j’ai eu la joie d’avoir ce joli message d’erreur sur mon nouveau serveur Gitlab.

We_re_sorry__but_something_went_wrong__500_

Je me dis rien de grave avec tous les changements réalisés ses derniers jours sur mes containers je vais rafraîchir le cache de Gitlab.

sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production

Et là c’est le drame, mon serveur commence à m’insulter.

WARNING: This version of GitLab depends on gitlab-shell 2.6.8, but you're running 2.6.7. Please update gitlab-shell.
rake aborted!
Errno::ENOENT: No such file or directory - connect(2) for /var/run/redis/redis.sock
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/connection/ruby.rb:180:in `connect_nonblock'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/connection/ruby.rb:180:in `connect'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/connection/ruby.rb:209:in `connect'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:322:in `establish_connection'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:94:in `block in connect'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:279:in `with_reconnect'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:93:in `connect'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:350:in `ensure_connected'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:207:in `block in process'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:292:in `logging'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:206:in `process'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:112:in `call'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis.rb:441:in `block in keys'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis.rb:37:in `block in synchronize'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis.rb:37:in `synchronize'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-3.2.1/lib/redis.rb:440:in `keys'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-store-1.1.6/lib/redis/store/namespace.rb:37:in `block in keys'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-store-1.1.6/lib/redis/store/namespace.rb:74:in `namespace'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/redis-store-1.1.6/lib/redis/store/namespace.rb:37:in `keys'
/home/git/gitlab/lib/tasks/cache.rake:7:in `block (2 levels) in <top (required)>'
Tasks: TOP => cache:clear
(See full trace by running task with --trace)

Parmi toutes ses vulgarités il y a une ligne qui retient mon attention.

Errno::ENOENT: No such file or directory - connect(2) for /var/run/redis/redis.sock

Premier réflexe, regarder si le service redis-server est lancé.

systemctl status redis-server -l
● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; enabled)
   Active: failed (Result: start-limit) since lun. 2015-11-30 10:07:31 CET; 5s ago
  Process: 18709 ExecStop=/usr/bin/redis-cli shutdown (code=exited, status=1/FAILURE)
  Process: 18707 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
 Main PID: 18708 (code=exited, status=1/FAILURE)

nov. 30 10:07:31 labo systemd[1]: redis-server.service: control process exited, code=exited status=1
nov. 30 10:07:31 labo systemd[1]: Unit redis-server.service entered failed state.
nov. 30 10:07:31 labo systemd[1]: redis-server.service holdoff time over, scheduling restart.
nov. 30 10:07:31 labo systemd[1]: Stopping Advanced key-value store...
nov. 30 10:07:31 labo systemd[1]: Starting Advanced key-value store...
nov. 30 10:07:31 labo systemd[1]: redis-server.service start request repeated too quickly, refusing to start.
nov. 30 10:07:31 labo systemd[1]: Failed to start Advanced key-value store.
nov. 30 10:07:31 labo systemd[1]: Unit redis-server.service entered failed state.

A ce moment un petit frisson me parcours le dos et je me sens moins confiant pour le coup. Je décide de reprendre point par point l’étape pour l’installation du serveur Redis sur la documentation Gitlab. Je commence par vérifier si redis est bien configuré.

nano /etc/redis/redis.conf
port 0
unixsocket /var/run/redis/redis.sock
unixsocketperm 770

De ce côté là tout est bon. je vérifie si le répertoire /var/run/redis/ est présent, mais il est désespérément vide. Et le service refuse toujours de se lancer. Un éclair de lucidité me traverse l’esprit, quid des autorisations ?

cd /var/run
ls -la
total 16
drwxr-xr-x 10 root  root    340 nov.  30 09:56 .
drwxr-xr-x  1 root  root    146 nov.  29 11:55 ..
-rw-r--r--  1 root  root      3 nov.  29 11:55 crond.pid
----------  1 root  root      0 nov.  29 11:55 crond.reboot
lrwxrwxrwx  1 root  root     25 nov.  29 11:55 initctl -> /run/systemd/initctl/fifo
drwxrwxrwt  4 root  root     80 nov.  29 11:55 lock
drwxr-xr-x  3 root  root     60 nov.  29 11:55 log
drwxr-xr-x  2 root  netdev   80 nov.  29 11:55 network
-rw-r--r--  1 root  root      4 nov.  29 11:55 nginx.pid
drwxr-xr-x  2 root  root     80 nov.  30 10:32 redis
drwxr-xr-x  2 root  root     40 nov.  29 11:55 sendsigs.omit.d
lrwxrwxrwx  1 root  root      8 nov.  29 11:55 shm -> /dev/shm
drwxr-xr-x  2 root  root     40 nov.  29 11:55 sshd
-rw-r--r--  1 root  root      3 nov.  29 11:55 sshd.pid
drwxr-xr-x 16 root  root    420 nov.  30 09:57 systemd
drwxr-xr-x  2 root  root     40 nov.  29 11:55 user
-rw-rw-r--  1 root  utmp   3456 nov.  30 11:53 utmp

Effectivement les autorisations ne sont pas bonnes, car seul le root à accès au dossier. Par conséquent le service qui est lancé avec l’utilisateur redis ne peut créer de fichier redis.sock. Pour remédier au problème j’ai donc attribué les bonnes autorisations au dossier.

chown redis:redis /var/run/redis

Nouvelle tentative de lancement du serveur redis.

systemctl start redis-server
systemctl status -l redis-server
● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; enabled)
   Active: active (running) since lun. 2015-11-30 10:32:06 CET; 1h 30min ago
  Process: 18709 ExecStop=/usr/bin/redis-cli shutdown (code=exited, status=1/FAILURE)
  Process: 19694 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
 Main PID: 19695 (redis-server)
   CGroup: /system.slice/lxc.service/system.slice/redis-server.service
           └─19695 /usr/bin/redis-server 127.0.0.1:0

nov. 30 10:32:06 labo systemd[1]: Started Advanced key-value store.

Pour conclure j’ai fait un petit tour sur la page web de Gitlab. C’est avec un gros ouf de soulagement que j’ai retrouvé mon accès. Il s’agit tout simplement d’un oublie de ma part, car la documentation explique qu’il faut mettre à jour les autorisations du répertoire redis et je suis passé à côté deux fois. On ne le redira jamais assez RTFM !

 

2015-11-27

Hackadon 2015 : des dons pour des logiciels libres le 11 décembre

Je reprends une annonce passée sur les canaux de l'April.

Vous voulez soutenir le LIBRE mais ne savez pas envoyer un patch ?

Pour la 3ème année consécutive, les HACKADONS permettent à chacun de contribuer financièrement : nos soutiens financiers mettent de l'argent dans un pot commun que nous distribuons aux participants pour qu'ils en fassent don à des porteurs de projets.

Inscription libre et gratuite à Orléans et Paris, 11 décembre 2015 :

Vous développez un projet LIBRE et n'osez pas demander de l'argent ?

Depuis 2013, une vingtaine de projets ont reçu en moyenne 200€ de dons grâce aux HACKADONS ! Vous avez un projet libre et souhaitez le faire connaître et recevoir des dons ? ou tout simplement des « merci » de la part de vos futurs utilisateurs ? Remplissez notre appel à projet en 2 minutes, et préparer votre présentation !

https://hackadon.org/appel-a-projets-2015.html

Vous êtes une entreprise et vous n'avez pas le temps de faire des dons pour tous les projets LIBRES que vous utilisez ?

Les HACKADONS ont pu démarrer grâce au soutien de l'AFUL et l'APRIL, dès 2013, ainsi que des dons de particuliers et d'entreprises.

Cette année encore, nous avons besoin du soutien des associations, des entreprises et des particuliers, tous ceux qui croient avec nous qu'il est indispensable de soutenir l'énergie de celles et de ceux qui fabriquent le libre au quotidien, modestement, qui croient aussi dans les valeurs que nous défendons dans notre manifeste :

https://hackadon.org/manifeste.html

Si vous souhaitez nous soutenir financièrement pour contribuer aux dons que les participants feront le 11 décembre prochain, merci de nous envoyer un mot !

https://hackadon.org/contact.html

Je veux en savoir plus !

Bravo. Pour les comptes-rendus des éditions de 2013 et 2014 :

Les vidéos des présentations faites en 2014 chez Mozilla :

https://vimeo.com/channels/960363

La F.A.Q. pour tout savoir :

https://hackadon.org/faq.html

  • Contact pour le Hackadon de Paris : withoutmodel@hackadon.org
  • Contact pour le Hackadon d'Orléans : labomedia@hackadon.org
  • Contact général : contact@hackadon.org ou bastien@hackadon.org
  • https://hackadon.org/contact.html

2015-11-26

Simplification d’APT

Hier soir au cours d’une discussion avec un autre Perpinuxien, j’ai appris les nouveautés appliquées à APT avec l’arrivée de Debian Jessie. Pour rappel APT est le gestionnaire de paquets par défaut sous Debian. Il s’agit d’une simplification et d’une uniformisation des différentes commandes utilisées. Au revoir le long et fastidieux apt-get ou autre apt-cache maintenant il suffit d’utiliser la commande apt suivi de l’action souhaitée.

man_aptPour installer un paquet il faut donc taper

sudo apt install monpaquet

et pour une mise à jour

sudo apt update #pour rafraîchir les dépôts
sudo apt upgrade #pour mettre à jour les paquets
sudo apt dist-upgrade #pour monter d'une version

La recherche est aussi grandement simplifiée

searchLa commande retourne plein d’informations utiles :

  • si la paquet est installé
  • quelle version est diponible
  • de quelle branche il est issu
  • un description plus lisible

La seconde modification intervient dans la présentation d’APT. Les développeurs ont rajoutés une barre de progression qui nous informe sur l’état d’avancement de la mise à jour ou de l’installation de paquets.

update

Ce n’est pas un grand bouleversement dans l’utilisation ou la mise en place d’apt, surtout si comme moi vous utilisez les allias dans votre zshrc ou bashrc. Mais je trouve l’initiative très bonne notamment pour les débutants qui étaient souvent perdus entre un apt-get ou un apt-cache search, avec ce système plus de confusion. Qui a dit que Debian ne faisait pas dans le user-friendly ? :p

2015-11-23

Levez les yeux


Note : je voulais poster cette vidéo le soir de mon arrivée au Vietnam. J'ai raté mon coup. J'en reviens, après presque 15 jours là-bas. Des cons ont encore fait des conneries ici pendant que j’étais là-bas. Ces gars-là devraient aussi sortir des écrans qui vendent de la merde et des réseaux qui propagent des idioties.

Billet original : Normalement, si tout va bien, je suis arrivé au Vietnam. Enfin, ça, c'est si on ne se fait pas descendre pendant les 15h de vol. A priori, pas de risque, huhu.

Je suis donc loin de mes ordinateurs et de mes serveurs avec pour seul compagnon technologique mon téléphone sous FirefoxOS incapable de profiter la 3G locale. Déconnecté pour de bon ! Je donnerai quand même des nouvelles, histoire de faire le malin, sur diaspote.

Je profite de cette situation pour vous ressortir cette vieille vidéo qui, même si elle semble moralisatrice, expose un bon fond : se déconnecter, lever les yeux de ses écrans :

<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/m4MZWNmXsVM" width="560"></iframe>

N'oublie pas de vous débrancher et de lever les yeux. C'est franchement bon pour la santé ;-)


<noscript></noscript>

2015-11-05

Rien de nouveau mais ça bouge chez les libristes


Sur le départ pour le Vietnam, où je pars avec mon frère pendant 15 jours, je fais un peu le bilant de tout ce que je n'ai pas traité pendant ces derniers jours, en espérant que le mouvement continu.

D'abord, ownCloud 8.2 a ramené les auto-hébergés sur le devant de la scène. Pas de quoi fouetter un chat, c'est une mise à jour classique, même si majeure. En lisant la liste des évolutions, je ne trouve rien de bien folichon : tant mieux, je n'ai pas le temps de m'en occuper en ce moment. D'ailleurs, le gestionnaire de mise à jour ne me dit rien. On dirait qu'ils doivent encore s'assurer que tout va bien avant de balancer leur popup à tout le monde.

Ensuite, FreshRSS sort en 1.3.0-beta et en 1.2.0 stable. Là, c'est déjà bien plus chouette : même si je ne m'en rendais pas compte, il parait que ça corrige plein de choses. C'est surtout une bonne nouvelle pour le projet qui prend son envole sans son grand créateur. Le libre, ce n'est pas l'apanage d'une seule personne !

Mais aussi Ubuntu 15.10. Franchement, je suis un utilisateur d'Ubuntu sur mon PC fixe pour Steam uniquement. C'est stable, ça marche, c'est maintenu. Ma 14.04 va encore rester sur ce PC jusqu'à la prochaine LTS.
C'est d'ailleurs drôle de dire ça puisque je ne suis tout simplement pas le seul à fonctionner de LTS en LTS. On peut lire que les gens ne vont pas passer par cette version, ce qui change radicalement des retours qu'on avait avant : "Vite ! Une nouvelle version, j'upgrade !" Je parie que c'est une histoire de génération et d'habitude. Je suis toujours les aventures des mêmes gars depuis 10 ans. Ouais, 10 ans. On a une vie, des obligations, des besoins autres que ceux qu'on avait à 20 ans : ça marche, c'est parfait.

FirefoxOS (of course !) 2.5, on l'attend toujours, ou alors j'ai raté un épisode. Ils se la jouent Debian tout en annonçant un jour précis dans leur feuille de route. On l'attendait en début de semaine, on a remarqué que la branch 2.5 du dépôt Github était en place, mais c'est tout. Pas d'annonce. Je voulais profiter de 15 jours loin du monde pour le tester en condition extrême... faut croire que c'est raté !

Sonerezh, le lecteur de musique auto-hébergé dont je vous parlais en avant-première mondiale avant son annonce officielle reprend du poil de la bête. La dernière semaine d'octobre a permis au développeur de corriger pas mal de bug et d'ajouter des petites améliorations. En rapide : il est enfin possible de lancer toute sa collection en lecteur aléatoire sans avoir à l'ajouter dans une playlist, ça change la vie, et la gestion de la page Albums qui avait tendance à couler le serveur lorsque les 100 albums (plus ou moins) étaient atteint. Ça aussi, c'est cool.

TFE Drive, qui me permet de profiter de mon ownCloud depuis Firefox OS passe en version 0.1.1 : des ajouts, des corrections, que du bon.

En presque 15 jours sans pondre un billet, je trouve que c'est pas trop mal. Merci les gars !


<noscript></noscript>

2015-10-26

Bloc-Notes : en octobre, régénère tes certificats

Comme chaque année mes certificats arrivent à expiration, ne faisant cette procédure qu’une fois par an elle passe rapidement aux oubliettes. Voici un petit bloc-notes pour les prochaines années. Tous mes certificats SSL sont signés par Startssl que l’on ne présente plus.

Régénération des certificats

  1. Je supprime tous les certificats arrivant à expiration chez Startssl. Ensuite pour chaque sous-domaines je génère un fichier key et un fichier csr nécessaire pour la création du certificat chez Startssl.

Génération du fichier key

mkdir ~/certificats/exemple.olivierdelort.net/
cd ~/certificats/exemple.olivierdelort.net/
openssl genrsa -des3 -out exemple.olivierdelort.net_avec_passphrase.key 4096

Le mot de passe (passphrase) est obligatoire sans quoi StartSSL va  refuser le fichier key et il doit contenir uniquement des chiffres et des lettres.

Génération du fichier csr en répondant aux question comme suit

cd ~/certificats/exemple.olivierdelort.net
openssl req -new -key exemple.olivierdelort.net_avec_passphrase.key -out exemple.olivierdelort.net.csr
    Country Name : FR
    State or Province Name : L.............
    Locality Name : P.......
    Organization Name : Colmaris Ltd
    Organizational Unit Name : Colmaris Ltd
    Common Name : olivierdelort.net
    Email Address :

Maintenant chaque sous-domaines possèdent un fichier key et un fichier csr, passons maintenant à création du certificat. A noter que le fichier key ne sera plus à générer l’année prochaine, je m’en servirai de nouveau pour générer mon fichier csr.

2. Chez Startssl je vais dans l’onglet : Certificates wizard -> Certificate Target : web server SSL/TLS certificate . Sur la page generate private key je clique sur skip car je la possède déjà, enfin je colle le contenu de mon fichier csr.

startssl1

Je continue en sélectionnant mon domaine (olivierdelort.net) puis le sous domaine (exemple.olivierdelort.net) pour lequel je souhaite créer le certificat. En effet Startssl ne fournit gratuitement qu’un certificat de class 1 par sous-domaine, ce qui m’oblige à répéter cette manipulation pour chaque  sous-domaine que je souhaite chiffrer.

A la fin de l’assistant de génération celui-ci m’affiche mon certificat.

startssl2

3. Je copie-colle ensuite le contenu dans mon fichier exemple.olivierdelort.net.crt

4. Je désactive la passphrase sur mon fichier exemple.olivierdelort.net_avec_passphrase.key utile uniquement pour startssl et la génération du certificat.

openssl rsa -in exemple.olivierdelort.net_avec_passphrase.key -out exemple.olivierdelort.net.key

5. Je récupère les fichiers depuis la tool box de StartSSL nécessaire pour l’authenticité du certificat.

  • StartCom Root CA (PEM encoded) => ca.pem
  • Class 1 Intermediate Server CA => sub.class1.server.ca.pem

A ce stade de l’opération je me retrouve avec un certificat pour chaque sous-domaine à chiffrer accompagnés de leur clef respective. Il est maintenant temps de les déployer sur mes serveurs.

Serveur nginx (serveur web et reverse proxy)

Pour utiliser mon certificat avec nginx je l’unifie avec ca.pem et sub.class1.server.ca.pem.

mkdir /etc/nginx/ssl
#j'importe les fichiers via ssh
cd /etc/ngnix/ssl
#J'unifie le certificat
cat exemple.olivierdelort.net.crt sub.class1.server.ca.pem ca.pem > exemple.olivierdelort.net-unified.crt

Je vérifie le fichier exemple.olivierdelort.net afin de ne pas mettre en erreur nginx, en vérifiant qu’il y ai pas de ligne ressemblant à ceci :

-----END CERTIFICATE----------BEGIN CERTIFICATE-----

Si tel est le cas, ajouter un retour ligne pour obtenir ceci :

-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

Pour finir je sécurise le tout :

chmod 600 exemple.olivierdelort.net-unified.crt exemple.olivierdelort.key

Il ne reste plus qu’à configurer le fichier vhost de mon site internet exemple.olivierdelort.net

server {
  listen 0.0.0.0:443 ssl;
  server_name exemple.olivierdelort.net
  server_tokens off
  root /var/www/html;

  # SSL
  # ============================================================================
  ssl                   on;
  ssl_certificate       /etc/nginx/ssl/exemple.olivierdelort.net-unified.crt;
  ssl_certificate_key   /etc/nginx/ssl/exemple.olivierdelort.net.key;
  ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 5m;
}

et pour mon reverse proxy

server {
        listen 443;
        server_name exemple.olivierdelort.net;
        ssl on;
        ssl_certificate /etc/nginx/ssl/exemple.olivierdelort.net-unified.crt;
        ssl_certificate_key /etc/nginx/ssl/exemple.olivierdelort.net.key;
        location / {
                proxy_pass https://192.168.xx.xx;
        }
}

Serveur courriel Dovecot

Le principe est le même, unifier les différents certificats dans un seul et ensuite renseigner la configuration de dovecot

cd ~/certificats/dovecot/
cat exemple.olivierdelort.net.crt sub.class1.server.ca.pem > exemple.olivierdelort.net-unified.crt

j’importe en ssh les fichiers : ca.pem, exemple.olivierdelort.net-unified.crt, exemple.olivierdelort.net.key dans /etc/ssl/private et je sécurise le tout.

chmod 600 exemple.olivierdelort.net-unified.crt exemple.olivierdelort.key ca.pem

J’édite ensuite le fichier de configuration /etc/dovecot/dovecot.conf

# SSL support.
ssl = required
verbose_ssl = no
ssl_key_file = /etc/ssl/private/exemple.olivierdelort.net.key
ssl_cert_file = /etc/ssl/private/exemple.olivierdelort.net-unified.crt
ssl_ca_file = /etc/ssl/private/ca.pem

Serveur courriel Postfix

C’est exactement la même méthode que pour Dovecot, donc nous récupérons les fichiers :

nano /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/ssl/private/exemple.olivierdelort.net-unified.crt
smtpd_tls_key_file = /etc/ssl/private/exemple.olivierdelort.net.key
smtpd_tls_CAfile = /etc/ssl/private/ca.pem
smtpd_use_tls=yes

Serveur Apache

Même principie que pour nginx :

mkdir /etc/apache2/ssl
#j'importe les fichiers via ssh
cd /etc/apache2/ssl
#J'unifie le certificat
cat exemple.olivierdelort.net.crt sub.class1.server.ca.pem ca.pem > exemple.olivierdelort.net-unified.crt
# je sécurise le tout
chmod 600 exemple.olivierdelort.net-unified.crt exemple.olivierdelort.key

Modification des vhosts apache :

<VirtualHost *:443>
        #ServerName mondomaine.tld
        ServerAlias exemple.olivierdelort.net

        DocumentRoot "/var/www/monsite"
        <Directory "/var/www/monsite">
                Options -IndexeFollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>
        SSLEngine on
        SSLVerifyClient none
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-res$
        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
        SSLCertificateFile /etc/apache2/ssl/exemple.olivierdelort.net-unified.crt
        SSLCertificateKeyFile /etc/apache2/ssl/exemple.olivierdelort.net.key
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-res$
    ServerSignature Off
</virtualHost>

Pour finir

Il ne faut absolument pas garder sur sa machine ses précieuses données, sinon pourquoi s’embêter à tout chiffrer. Tous les certificats sont regroupés dans dans le répertoire ~/certificats. Je compresse le répertoire, je le copie sur mon disque dur externe de sauvegarde et je supprime le répertoire. Me voilà opérationnel jusqu’à l’année prochaine.

Mysearch 1.8

Je viens de mettre en ligne une nouvelle version de mon proxy anonymisant de moteur de recherche Mysearch (license GNU AGPL).

Google vient de changer les balises HTML de ses pages de résultat Image et Video. La nouvelle version de MySearch est compatible avec ce changement.

Vous pouvez la tester sur search.jesuislibre.net

Related Posts:

J'aime(2)Ferme-la !(0)

2015-10-24

Donnez, payez




En ce samedi d'octobre, j'ai envie de vous dire de payer, de donner aux gens, services, aux fondations ou encore aux entreprises qui participent et améliorent votre vie au quotidien.

Je viens de filer 10 malheureux euros à Wikipédia. C'est la première fois que je fais ça et je dois bien avouer que c'est la première fois que je peux vraiment me le permettre. Je ne roule pas sur l'or et le peu que je mets dans ma besace, je m'en sers pour me payer des billets d'avion. C'est une gestion comme une autre de son argent. Je fais ce que je veux.

Des années que je me sers de Wikipédia, jamais je n'avais participé financièrement, modestement, à son fonctionnement. Pourtant, je m'en sers chaque jour.

Je me sens mieux, c'est con. Je n'ai pas fait grand chose.

En y repensant, cela fait longtemps que je paye pour avoir accès à NextInpact, Arrêt sur Image et Mediapart. D'ailleurs, chez @SI, ils sont fantastiques. Ils proposent des abonnements étudiants, chômeurs, sans un radis pour 21 euros par an sans vérifier si c'est vrai. On peut même choisir un abonnement 0 euro en leur envoyant un mail pour expliquer sa situation. J'ai longtemps profité de l'offre étudiante mais je viens de changer, par honnêteté.

La presse, sa situation financière et ses ennuis, je comprends mieux. Ça me choque quand des gens qui s'acharnent à me rendre moins con ne sont pas convenablement payés. Wikipédia, ça me choquait moins. C'est idiot.

Dans les trucs pour lesquels je ne débourse rien et que pourtant j'utilise beaucoup, il y a Ubuntu, Debian, GNOME, Mozilla, ownCloud, Piwik et j'en passe.
Chez Ubuntu, ils ont une entreprise, Mozilla aussi, ownCloud aussi. Je me sens moins honteux de me servir d'eux sans payer. Debian, j’achète des goodies à-la-con quand je croise un stand officiel à leur nom.
Les autres, ils entrent dans ma liste des dons ou achats que je ferai, c'est certain. Ils se cassent pour me faire plaisir, je peux bien leur payer une tournée.

Dans cette liste, j'oublie la Quadrature du Net qui menace régulièrement de ne plus pouvoir nous défendre, faute de moyen. C'est aberrant. Je n'imagine plus mon univers sans ces gars-là.

Bref, donnez ou payez quand vous le pouvez. Si vous ne pouvez pas, ce n'est pas grave : nous sommes beaucoup à vouloir vous faire profiter des bonnes choses de la vie. Profiter de tout ça, c'est super, mais profiter à plusieurs, c'est encore mieux,


<noscript></noscript>

2015-10-21

Où Facebook stocke mes photos privées ?

Les photos que vous envoyez sur Facebook ne sont pas stockées comme vos autres données privées (date de naissance, etc…). Elles sont copiées et hébergées sur ce que l’on appelle des CDN, qui sont des serveurs de proximité , afin réduire le coût en bande passante pour Facebook et augmenter la vitesse de chargement des photos pour vous.

Pour le constater, c’est simple, prenez une photo privée de quelqu’un et regarder son adresse Internet (avec Firefox : clic droit sur l’image -> « copier l’adresse de l’image »). Vous verrez que l’image est stockée chez akamaihd.net

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="363" src="https://www.youtube.com/embed/_6XqiTN23rc?feature=oembed" width="646"></iframe>

Vous devez donc avoir compris que votre photo « privée » est en réalité copiée en quelques secondes sur des centaines de serveurs repartis dans le monde ! Chaque pays ayant sa propre législation pour piocher dans vos données et chaque machine son intermédiaire technique de confiance qui a un accès complet aux données. Je ne suis pas sûr que la confidentialité de votre photo « privée » ait un gros poids face aux bénéfices du CDN.

Ensuite vous aurez compris que les photos sont accessibles à tout le monde qui en connaîtrait l’adresse. Il n’y aucune forme d’authentification. Toutes les photos de tous les utilisateurs de Facebook sont disponibles en permanence sur Internet et peuvent être téléchargées par n’importe qui…  à la seule condition de connaître l’adresse complète de l’image. Il est heureusement quasi impossible de générer un adresse d’image valide par hasard d’un point de vue statistique. C’est la longueur de l’adresse web aléatoire qui constitue la difficulté d’accès et les photos étant demandées en HTTPS par l’interface web de Facebook, on ne peut pas, à ma connaissance, sniffer les adresses des photos (sauf faille dans le moyen de chiffrement).

Mais le plus drôle, c’est que si vous supprimez votre photo « privée » de votre compte Facebook, celle-ci reste sur les serveurs du CDN. J’ai fait un test en envoyant un photo privée que je n’ai partagée avec personne (visible par « moi uniquement »), je l’ai supprimée juste après l’avoir envoyée. Ça fait maintenant 2 semaines que je l’ai supprimée et elle est toujours disponible sur le web…

A coté de ça vous avez des solutions comme Owncloud, qui utilisent la même technique d’adresse longue et aléatoire pour partager du contenu confidentiel. Mais c’est uniquement si on souhaite partager le contenu sans demander de mot de passe. Et lorsque l’on décide de ne plus partager le contenu, le lien n’est plus valide, immédiatement. On peut même mettre des dates d’expiration au lien ;-)


Related Posts:

J'aime(16)Ferme-la !(0)

diaspora* 0.5.4.0 disponible




Le réseau social au pissenlit vient de passer en 0.5.4.0 ! Au programme de cette mise à jour mineure, l’arrivée de la timeline dite Activité publique, une meilleure gestion des droits, un paquet de corrections de bogues et d'améliorations : on parle de 598 commits !

   La timelime Activité publique permet aux utilisateurs de n'afficher que les publications publiques auxquelles il a accès, contrairement à la timeline classique qui mélange tout ce qu'elle peut, publique et privée. Avec elle, nous pouvons maintenant mieux nous concentrer sur les annonces des autres utilisateurs et mieux interagir avec eux. Perso, j'vais enfin laisser souffler ma molette en rentrant chez moi !

  Une nouvelle gestion des droits permet de directement ajouter un utilisateur en tant que modérateur, un rôle permettant de laisser souffler les podmins en les aidant à signaler ou supprimer les publications ou commentaires hors la loi. Souvenez-vous de l'affaire Daesh qui avait pointé du doigt notre si joli réseau. Les modérateurs devraient permettre de mieux contrôler les idiots.
D'ailleurs, en y repensant, cela fait quelques mois que je gère mon propre pod sans avoir reçu le moindre signalement.

   Pour les corrections de bogues et les autres nouveautés, je vous redirige vers la liste des changements/améliorations officielle.

Je profite de cette annonce pour vous dire que j'ai passé un excellent week-end dans les locaux de Mozilla pendant le #Hackaton. C’était une belle occasion de retrouver des contributeurs motivés, drôles et de plusieurs pays différents : un allemand et un finlandais avaient fait le déplacement jusqu'à Paris !

Ce que je retiens le plus, c'est la capacité d'un geek à boire de la bière et le travail réalisé par Lukas sur le futur chat du réseau.



Pour plus d'info et de photos sur ce #hackaton, vous savez déjà quel mot-dièse rechercher ! ;)

Une dernière chose : nous sommes toujours à la recherche de contributeurs. Si vous êtes motivés et que vous savez faire du Ruby, mais pas que, je vous invite sur à venir sur IRC #diaspora-fr, sinon, OpenClassRoom (ex Site du Zéro) vient de sortir un tutoriel complet pour se mettre au Ruby, et aider nos développeurs.


<noscript></noscript>

2015-10-19

Browser Popcorn, l'exemple de la perversion


Vous connaissez tous ou presque PopCorn Time, l'application qu'il vous faut avoir si vous aimez la technologie, les réseaux, les films et les séries trop souvent américaines.

PCT, pour les intimes, vous offre absolument illégalement une quantité dingue de films et de séries en passant par le protocole P2P : les utilisateurs partagent avec les autres utilisateurs ce qu'ils regardent. C'est beau, autant esthétiquement que techniquement. Il a pour avantage de nous épargner le streaming crade qui massacre les connexions entre grands opérateurs. C'est un discours étrange pour ceux qui n'aiment que la gratuité du produit mais c'est extrêmement important pour moi : le P2P, c'est l'avenir.

Voici le fils : Browser Popcorn !

A la bonne heure, PCT fait des petits ! Sauf que là, c'est du foutage de gueule, c'est honteux.

J'dis pas, c'est bien fait, c'est beau et ça marche, surtout si on admet que les informations sur son créateur soient vraies et qu'il s'agit bien d'un gamin de 15 ans.

Sauf que ça massacre l’idée de base, celle qui fait que le P2P peut être fier de lui. On se retrouve avec une interface qui centralise ce que le réseau propose. C'est la fin du partage, la mort du principe technique. Tout le monde peut s'y connecter via une seule adresse, juste une.

Le fonctionnement du bousin est expliqué dans un tweet : The server is downloading torrent, saves it to disk and then uploads to users. So technically yes, but no.
Ce qu'on peut traduire par : Le serveur télécharge les torrents sur le disque et les partages ensuite aux utilisateurs. #Tristitude, comme disent les jeunes.

Pour finir, le lien vers Github qu'on trouve sur le site ne pointe que vers les sources du site web. Rien d'autre. Pas moyen de faire marcher ça à la maison.

Bref, à ne pas utiliser, à supposer que ça reste en ligne plus de deux jours. En attendant, laissez tomber la belle interface à la Popcorn Time et utilisez Yify-Pop, à la rigueur.



<noscript></noscript>

2015-10-17

Don du mois : Framasoft

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.

Framasoft a repris sa campagne sur le "degooglisation" d'internet. Il faut y comprendre

  • acentralisation du réseau internet
  • utilisation de logiciels libres
  • réappropriation des outils
  • respect de la vie privée
  • partage des connaissances

Même si j'utilise peu les outils de framasoft car je m'autohéberge déjà, je ne peux que soutenir leurs actions. J'étais critique envers cette association à l'époque des comptes google, la progression en un an est extraordinaire et ils prouvent qu'une transition rapide vers des outils éthiques est possible.

C'est 25 euros qui vont à l'association qui finance principalement ses salariés.

2015-10-15

TFE Drive : enfin un client ownCloud sur FirefoxOS pour gérer ses fichiers




Depuis le temps que je l'attendais, celle-là, l'application me permettant de me servir de mon instance ownCloud et de ses fichiers depuis mon FirefoxOS.
Parce que oui, mon Flame me convient, mais il n'est pas sans défauts, loin de là. Je prendrais sans doute le temps d'être absolument honnête dans un billet à la sortie de la 2.5, d'ici quelques semaines.

En attendant, ownCloud et FirefoxOS, c'est un peu le combo qu'il me manquait. Il est déjà possible de synchroniser son agenda, mais pas de parcourir simplement ses fichiers et encore moins de les téléverser.
Je pouvais déjà m'en servir, mais même si l'affichage s'adapte à la taille de mon téléphone, c’est laborieux. Rien ne vaut une application dédiée à un usage spécifique. Pour le reste, il y a le responsive design.

Voilà donc que je tombe par hasard sur TFE Drive la miraculeuse. Elle nous propose de gérer ses comptes du type Google Drive, Dropbox, Box, OneDrive et Webdav dont se sert ownCloud.




Me voici donc à l'installer pour tester ça de mes propres yeux. L'interface est simple, je me lance :



Ça marche ! Voici ce qu'elle m'affiche une fois les informations de connexion renseignées :



Youhou ! Je me balade dans mon cloud via mon Flame, le pied ! On a même le droit à des aperçus des fichiers textes et images. Non, ce que vous voyez n'est pas un souci d’encodage mais des morceaux de mots de passe et une partie d'un chemin d’accès sur un serveur.
Si vous cliquez sur les fichiers, vous pourrez les partager, supprimer, modifier, renommer, etc. La base.

Comme vous pouvez le voir en bas de la dernière capture d’écran, on peut ajouter des fichiers/répertoires, rafraîchir la page, faire de la sélection multiple et... synchroniser ?!


Comme vous pouvez le voir, je lance une tache qui va synchroniser mon répertoire contenant les photos (d'une grande qualité) de mon Flame vers une répertoire dédiée dans OC. Mais c’était trop beau : error. Bah, on ne peut pas trop en demander tout de suite ! Je m'en vais rédiger un rapport d'erreur. Deux, en fait, puisque la création d'un répertoire avec un accent ne semble par marcher non plus.

Bref, ce n'est pas encore parfait, mais c'est déjà une vrai bonne nouvelle pour les barbus !

Pour télécharger l'application, c'est par là.
TFE Drive

Le développeur, en plus de pondre une bonne application, héberge son code source sur le Gitlab de Framasoft. Ce mec a bon sur toute la ligne. Merci ! ;-)


<noscript></noscript>

2015-10-14

Internet bas débit

Le « TRÈS haut débit » chez Bouygues Telecom en 2015 c’est ça :

bouygues très haut debitObservez bien l’asymétrie entre le débit montant et descendant. Le ratio est de 40:1 !

Du temps des modem RTC, le ratio était de 1:1. En ADSL, lors de l’arrivée de Free en 2002, le ratio était de 4:1.

C’est très frustrant de voir sa vitesse de transfert divisée par 40 dès l’on que l’on veut travailler à distance, envoyer des fichiers sur un cloud, envoyer des photos à ses amis ou pour le travail, envoyer des gros fichiers, héberger des fichiers, héberger une galerie photo/vidéo, héberger un site web rapide, etc…

Cette asymétrie de vitesse nous pousse vers un comportement de consommateur de contenu. Pas du tout vers un Internet 2.0 où l’on serait interconnectés les uns les autres. Non, c’est tous connectés à quelques serveurs qui ont le débit inverse pour qu’on puisse jouir de nos 200Mb/s de download.

Si bien que le contenu se retrouve concentré ailleurs. Je veux partager une vidéo ou un fichier, je ne peux l’héberger chez moi convenablement donc je la fais héberger ailleurs…. Cette ailleurs est généralement aux USA (Youtube, Gmail, Hotmail, Facebook, Dropbox, Netflix, etc…) parce qu’on n’arrive pas en France à monter des mastodontes aussi vite/bien qu’aux USA.

Bien sûr après on va se plaindre de l’asymétrie du trafic entre opérateurs et des tensions que cela crée : Est ce que c’est Youtube ou l’internaute qui doit payer le transfert de la vidéo? Qui est en position de force pour faire payer l’autre?

Comment voulez vous instaurer une neutralité du net, si quelques serveurs peuvent parler et les autres seulement écouter. En gros si le réseau n’est pas décentralisé mais au contraire hyper-concentré.

Quand j’étais petit, je me disais que quand la fibre arriverait, ce serait une révolution pour les échanges entre personnes parce qu’on aurait tous des débits de folie en upload. Au lieu de cela, on se retrouve avec des embouteillages pour télécharger des fichiers.

Related Posts:

J'aime(9)Ferme-la !(0)

2015-10-09

JAH-7 – De l'installation et de la configuration tortueuse d'un serveur jabber

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

J'avais à présent un serveur auquel je pouvais accéder en SSH, mais pour l'instant la commande de connexion ressemblait à peu près à ça : ssh machin@40.666.666.7 on a déjà fait plus sexe ! Et pour cause, je n'avais pas encore acquis de nom de domaine. À quoi sert un nom de domaine ? Et bien c'est tout simplement une suite de caractères qu'on achète afin de lui associer une adresse IP de son choix, pour que lorsque quelqu'un tape ce nom de domaine, il soit redirigé vers le serveur dont on a spécifié l'adresse IP. Wikipédia regorge d'informations sur la résolution des noms de domaines, les registrars et comment marche un serveur de nom. Au bout de quelques heures de lecture, j'avais compris qu'une fois un nom de domaine acquis auprès d'un registrar, je pouvais configurer leur serveur de nom (DNS) afin que les requêtes de résolution (trouver l'adresse IP correspondante à un nom de domaine) concernant mon nom de domaine soit redirigées vers mon serveur.

Après une rapide comparaison des services compris dans l'achat d'un nom de domaine sur différents registrars, je me suis décidé à acheter mon nom de domaine chez Gandi [1]. La procédure est on ne peut plus simple et rapide. Une fois mon nom de domaine acheté et activé, j'ai eu accès au fichier de gestion de zone de mon domaine sur le DNS de Gandi, ce qui m'a permis de rediriger mon nom de domaine sur l'adresse IP de mon modem (par défaut mon nom de domaine était redirigé sur une de leur page web). La conséquence directement testable fut la nette amélioration de ma commande de connexion distante : "ssh machin@gehenne.net" ça a quand même plus de gueule qu'une suite anonyme de chiffres !

Le fichier de gestion de zone dont je parlais précédemment permet de gérer les résolutions associées à son nom de domaine, ainsi que le service correspondant. En d'autre termes, c'est ce fichier que je dois modifier pour pouvoir recevoir des courriels adressés à mon nom de domaine, définir un sous-domaine (blog.gehenne.net par exemple) ou encore, indiquer sur quels ports sont disponibles quels services [2]. Souhaitant avidement devenir mon propre fournisseur de messagerie instantanée, j'ai donc commencé par définir les ports nécessaires à un serveur XMPP.

Il existe plusieurs logiciels libres pouvant faire office de serveur jabber, plus ou moins facilement configurable, chacun avec ses avantages et ses inconvénients [3]. Suivant les conseils du wiki sur l'auto-hébergement auquel j'ai déjà fais allusion dans ce journal, j'ai opté pour ejabberd et un mode d'authentification basé sur les comptes des utilisateurs du système, ainsi je n'avais pas de base d'utilisateurs supplémentaire à gérer.

Une fois le paquet installé, j'ai édité le fichier de configuration afin d'ajouter une ligne concernant les noms d'hôtes à gérer (la partie après le @ des jabberIDs) et j'ai défini le compte utilisateur système qui serait administrateur du serveur jabber sans oublier de décommenter la ligne concernant l'authentification par PAM. J'ai alors redémarré le serveur jabber plein d'espoir ... ce fût un échec : le serveur indiquait des erreurs au lancement et refusait donc de démarrer.

Ejabberd est écrit en erlang et "d'après wikipédia" ce langage à, entre autre, pour défaut de produire des messages d'erreurs particulièrement inutile à la résolution d'un problème. Je confirme cette affirmation ! Je ne détaillerai pas dans ce journal toutes mes tentatives, toutes plus farfelues les unes que les autres, pour arriver à faire marcher ce serveur. Au final mes erreurs n'était pourtant pas si dramatiques : oublis de certains points à la fin des lignes du fichiers de configuration, conflits entre certaines lignes qui définissaient plusieurs fois des choses différentes et non-cohérence entre certaines lignes que j'avais décommentées et pas les autres. Une fois encore la documentation me fût d'un très grand secours. Après un nombre assez impressionnant de vaines tentatives et d'essais infructueux, causés principalement par mon incompétence et surtout ma précipitation (faites ce que je dis et pas ce que je fais !), je réussis enfin à lancer mon serveur et à s'y faire connecter mon client de messagerie habituel : pidgin.

Mais mon triomphe fût de courte durée car au bout de quelques minutes mon client perdait la connexion car le serveur ne répondait soit disant plus au ping. Passablement fatigué suite à mes premiers déboires et ayant eu l'impression de devoir "bricoler" pour faire marcher mon serveur, j'ai décidé à de tout reprendre à zéro.

Les distributions Debian sont connues pour leur stabilité mais elles font aussi souvent l'objet de railleries comme quoi elles ne seraient pas à jour. En réalité cette affirmation est due au fait que pour raison de stabilité les dernières mises à jour des logiciels ne sont pas disponibles par défaut, il faut activer les dépôts backports. Ayant peur que mon échec à la mise en place de mon serveur jabber soit dû à un bug, j'ai alors décidé d'activer les dépôts backports, de mettre à jour ma distribution (y compris le noyau) et d'installer une version plus récente du paquet ejabberd.

Essayant d'apprendre de mes erreurs, je décide cette fois de faire les choses une à une. Je commence donc par vérifier que, sans modifier le fichier de configuration, ejabberd se lance correctement. Une fois rassuré, je modifie étape par étape le fichier de configuration en vérifiant bien à chaque fois que le serveur peut démarrer sans problème. Définition des noms d'hôtes à gérer puis compte administrateur et enfin authentification par PAM, tout fonctionne correctement. Arrive le moment où je configure le module permettant le chat multi-utilisateurs, le serveur démarre correctement, je me connecte et m'authentifie sans problème puis au bout de quelques minutes mon client perd la connexion.

C'est en étudiant les logs du démon que le problème se révéla à mes yeux. En effet, en observant les logs je pouvais voir des tentatives de connexion et de création de salons mélangeant mes noms de comptes, mes noms de domaines et de ressources ainsi que les noms des salons que j'essayais de créer, concrètement : je pouvais voir, entre autre, une tentative de création de salon avec pour nom de salon mon identifiant. Le problème venait du fait que j'avais défini comme domaine hôte pour mes salons le même nom que pour mes comptes jabber, autrement dit, exemple@gehenne.net pouvait correspondre à la fois au compte jabber exemple sur le serveur gehenne.net mais aussi au salon homonyme, pas étonnant que ejabberd soit perdu ! En changeant le nom d'hôte des salons en un chat.gehenne.net (et en ajoutant la ligne nécessaire sur le fichier de zone) tout rentra dans l'ordre ! J'avais enfin mon serveur de messagerie instantanée personnel qui, de surcroît, pouvait héberger des salons de discussions !

Conclusions :

  • Faire les modifications une à une afin d'identifier rapidement d'où vient un éventuel problème.
  • Ne jamais hésiter à regarder les logs, ils contiennent souvent la solution à un problème même s'ils ne sont pas toujours explicites au premier coup d'œil.
  • On ne le dira jamais assez : il faut lire la documentation !

Maintenant que je pouvais dialoguer avec mes amis, il convenait de s'intéresser à la sécurisation de ces conversations et donc d'installer de quoi pouvoir consulter mon serveur de manière sécurisée.

Prochaine entrée dans le journal : De la sécurisation par certificat SSL

Notes

[1] Une bonne philosophie, de bons services utilisables via une interface utilisateur claire : 5 ans après je recommande toujours Gandi.

[2] Pour des explications plus claires sur ce qu'il est possible de faire grâce au DNS et sur comment le faire proprement je vous renvoie à la conférence de Stéphane Bortzmeyer : DNS tirée de l'excellent cycle de conférences Il était une fois Internet .

[3] "Ce qu'il y a de bien avec les opinions tranchées, c'est que ça relance le débat." Léodagan de Carmélide.

2015-10-08

Quel bordel ces serveurs mails


L'installation d'un serveur mails, c'est quand même un sacré foutoir. La confiance s'emparant de moi depuis que je suis capable de m'auto-héberger, je m’étais lancé dans l'installation de mon adresse mail à moi. Après être passé par ownCloud, FreshRSS, différents CMS de blog, différentes solutions d’écoute de musique en ligne, c’était un peu l’étape ultime.

La première installation tournée avec Citadel, sur mon ancien serveur. C'est simple : on joue de l'apt-get, on configure le DNS et c'est terminé. Ça roule presque tout seul, au point que je me suis fais taper sur les doigts par mon hébergeur de l’époque parce que j’étais devenu un spammeur. Ça roulait bien, mais pas que pour moi.
Après cette histoire malencontreuse, je me suis relevé les manches et j'ai joué avec Postfix et Dovecot sans MySQL. Ça m'avait pris du temps, mais ça marchait. Pendant des mois, je me suis trimballé cette installation stable mais absolument pas sécurisée, ou alors si peu.

Avec ma migration chez mon tout nouvel hébergeur, la question du serveur s'est à nouveau posée. Quelle souffrance, je n'ai pas réussi à reprendre mon ancienne installation. Ce n'est pas plus mal, ça m'a forcé à remettre les mains dedans. Deux semaines avec les mains pleines de crasse, à m'arracher le peu de cheveux qu'il me reste au dessus du front, c'est le temps qu'il m'a fallu pour remettre en marche une installation propre et sécurisée, avec MySQL.

Je dis propre, mais il me reste encore à ne pas passer pour un spammeur auprès des grands de ce monde que sont Google, Yahoo, Orange et j'en passe. Parce que oui, sans la bonne configuration qui va bien, vous et votre adresse personnelle, vous finissez systématiquement dans les indésirables alors que le petit nouveau qui se fait une gmail en 3 cliques, il est tranquille.

Enfin, ça marche. On peut de nouveau me joindre avec mon adresse perso qui est reliée au formulaire de contact de ce blog.

Ceci-dit, un truc me chagrine, un truc dans l'air du temps. On peut lire de plus en plus d'articles traitant du danger de s'installer à son compte sur son serveur. Je ne cache pas que c'est une tache difficile pour un serveur web, mais le mail, c'est encore une toute autre affaire, bien plus critique. Si vous voulez une installation très sécurisée, vous finirez chauve.
Et ça, c'est sans parler de la pérennité des données qui pourront trop facilement disparaître lors d'un changement d’hébergeur et de l’impossibilité d’être contacté ou de recevoir vos mails de routine pendant la durée de l’opération.

Bref, c'est une belle aventure mais il faut savoir dans quoi on se lance : on peut se faire avoir bien plus facilement qu'en passant par un hébergeur dont c'est le cœur de métier.


<noscript></noscript>

2015-10-06

Blog compromis, ma réponse à l'incident

Je vois peu de retours d'expérience concrets sur le net, alors je vais vous livrer le mien. Je ne suis pas spécialiste de la question. Mon analyse est donc probablement imparfaite ou incomplète. Toutefois, je le fais pour plusieurs raisons :

  • Les quelques visiteurs qui passent ici doivent savoir si mon blog est, ou a été, à risque.
  • Communiquer sur un cas réel me semble intéressant. Il est désagréable de parler de son propre cas mais au moins, j'ai accès à toutes les informations.
  • Si je suis en mesure de faire des erreurs, je ne dois pas être le seul. Expliquer quelles ont été mes erreurs pour que d'autres ne les commettent pas ne peut être que bénéfique.
  • Donner la possibilité à mes visiteurs de me faire un retour, notamment sur ma manière de réagir à cet événement, sera peut être pour moi l'occasion de progresser.

Analyse

Comment cela a été possible ?

J'ai passé un peu plus de temps à analyser mes logs et les seules informations que j'ai pu trouver se trouvent dans les logs d'apache. Rien ailleurs et pour cause, les faits datent du 5 novembre 2014. Il n'y a donc plus rien à voir dans les autres logs depuis longtemps.

Je constate donc une forte activité de la part de l'attaquant le 5 novembre 2014, date à laquelle l'un des fichiers a été déposé et exploité. Le fichier en question est un script php déposé dans un répertoire que j'avais créé manuellement à la racine de mon blog wordpress (pas grand chose dans ce dossier à part des photos présentes sur mon blog et quelques bricoles).

Je suspecte donc que l'un des plugins ou l'un des thèmes utilisé sur mon blog contenait une faille permettant l'upload de fichiers. Je précise toutefois que les plugins et thèmes utilisés proviennent tous de sources officielles (trouvés et installés via le panel d'administration du blog). J'écarte peut être trop vite Wordpress lui même mais dans le mesure où il se met à jour automatiquement, les failles connues sont comblées rapidement. Sauf à exploiter une 0 Day, c'est donc peu probable.

Certains répertoires avaient aussi des autorisations trop élevées. Je ne pense pas que ce soit du fait de l'attaquant mais plutôt moi qui a certainement un jour modifié cela (suite probablement à un problème de mise à jour wordpress).

Les logs montrent par ailleurs que pour lister les failles de mon blog et de quelques sites hébergés sur mon serveur, l'attaquant à utiliser au moins un outil open source de recherche de vulnérabilités web. L'outil en question est intéressant pour deux raisons. D'une part, il permet d'auditer ses propres sites, et d'autre part, il me permet de comprendre certains comportement étranges de mon serveur il y a quelques mois (CPU serveur chargé à presque 100% à cause d'un nombre anormal de processus apache2). J'ai donc compris que mon serveur avait fait l'objet de scans en vue d'y trouver des vulnérabilités.

A quoi servaient ces fichiers ?

Le premier fichier n'était clairement fait pour ne pas être lisible facilement (instructions codées en ascii, codes en base64, gzinflate...). Une fois décodé, il montre un peu plus ce à quoi il est destiné car il contient tout un tas de commandes permettant notamment de rechercher des fichiers sensibles du système (utilisable en environnement *nix ou windows). J'ai exécuté le fichier en machine virtuelle dans firefox (avec le module firebug) et je vois qu'il tente de se connecter à des ressources dispo sur un site externe (je continue à essayer de comprendre plus de ce côté là).

L'exécution du scripts en question en machine virtuelle montre qu'il tente de communiquer avec un serveur distant. Le domaine de ce serveur est en .ro . A ce que je peux voir rapidement, ce serveur héberge un certain nombre d'outils permettant le piratage de sites web.

Un autre fichier a été déposé plus récemment (fin juillet) et contient un exploit selinux. Un autre répertoire contient, si je comprend bien, un outil d'analyse open source. Je ne trouve pas de trace quand à l'utilisation de l'un ou l'autre de ces outils, contrairement à l'autre outil dont je parle au dessus et pour lequel je peux voir que l'attaquant l'a utilisé environ 1h sur ma machine.

Comprendre ce qui a été fait et les motivations

Je constate que l'attaquant a possiblement disposé d'une bonne vue de la structure des différents sites hébergés sur mon serveur et accessibles. Il ne me semble pourtant pas que des dégâts aient été fait. Rien non plus en base de donnée (en tout cas, s'il y a eu quelque chose à une époque, il n'en reste rien).

Actions

Actions curatives

Comme détaillé dans un billet récent, j'ai très rapidement vérifié que ma base de donnée Wordpress était saine. J'ai ensuite réinstallé une instance toute propre de Wordpress sans aucuns plugins, histoire d'avoir une solution fonctionnelle le temps de trouver une solution plus durable et plus sûre pour mon blog. La solution retenue a donc été de passer à Pluxml car l'outil correspond parfaitement à mes besoins.

Actions préventives

Pour ne pas avoir à subir un nouvel épisode de ce type, j'ai décidé d'être plus strict au niveau de la gestion de mon serveur. J'ai donc déjà nettoyé et réduit au maximum le nombre de services ouverts sur l'extérieur. Que ces autres services n'aient pas été touchés aujourd'hui ne signifie pas qu'ils ne le seront pas à l'avenir ou qu'ils ne puissent pas donner d'informations à d'éventuels attaquants. Certains services utiles ne sont plus ouverts qu'en local (munin notamment) et d'autres sont tout simplement fermés (webmail rainloop). Au niveau Web, je n'ai conservé sur l'extérieur que ce blog et deux pages statiques.

J'effectue à présent un suivi de l'activité de mon serveur de manière plus stricte. Je suis en train de réfléchir à automatiser ce qui peut l'être et qui est spécifique à mon installation. J'ai un peu chamboulé mon programme de pré-rentrée afin de remettre un peu d'ordre là où c'était nécessaire.

Conclusions

Mes erreurs ont été multiples. Je considère avoir globalement été trop laxiste, que ce soit au niveau de mes réglages apache qu'au niveau des services ouverts sur ma machine. Peu regardant aussi sur l'activité de mon blog. J'aurais, si j'avais bien fait les choses, dû voir immédiatement l'arrivée de ces fichiers.

Je considère avoir eu de la chance. Cette expérience m'a permis de connaitre l'existence d'outils intéressants d'audit de sites web. Je vois d'ailleurs mieux comment se comporte mon serveur lorsqu'il fait l'objet d'une analyse par ce type d'outil.

J'ai aussi pris conscience de l'importance des logs. Il est donc essentiel d'être réactif, sous peine de ne pas avoir de données exploitables. Se faire poutrer une fois, ça peut arriver. Ne pas avoir les éléments pour réagir, c'est l'assurance que ça arrivera une seconde fois.

Proxmox 4.0 en version finale

Logo-ProxmoxVE
containers

C’est officiel, depuis le 05/10/15
Proxmox est enfin rentré dans le 21eme siècle !
http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.0

Au programme :

  • Debian 8.2 (Jessie)
  • kernel 4.2 (fournis maintenant par Ubuntu à la place de Red-Hat)
  • QEMU 2.4
  • de nouveaux outils
  • support de l’ipv6, drbd9 …

mais SURTOUT le support de LXC à la place du vieux (mais fiable !) OpenVZ.

Cela veut dire de nouveaux outils, revoir certains scripts …
Pensez donc à faire un backup de vos containers OpenVZ afin de pouvoir en faire un template et ainsi les convertir en LXC.

Capture d’écran_2015-10-06_15-30-04

Le téléchargement de l’iso se trouve sur le site de Proxmox.com : http://proxmox.com/en/downloads/item/proxmox-ve-4-0-iso-installer

Hackaton Diaspora du 8 au 11 octobre à Paris


Il est prêt, nous sommes prêt : le hackaton diaspora* aura lieu de ce jeudi 8 au dimanche 11 octobre 2015 dans les locaux de Mozilla à Paris.



Vous trouverez toutes les informations sur l’événement en parcourant cette page du wiki de diaspora*.

Au programme, on parle d'avancer sur l’implémentation du chat, l'ordre des commentaires, l’amélioration des sondages, les notifications des utilisateurs non ajoutés dans les contacts mais aussi des discussions sur la gouvernance et la communication du projet.

Mais pas seulement, c'est aussi l'occasion de voir des développeurs (et admins) engagés dans le projet en chair et en os !

Nous vous attendons avec plaisir ! Si vous ne voulez pas coder, nous sommes parfaitement disposés à boire des bières. N’hésitez pas à vous signaler :-)




<noscript></noscript>

2015-10-05

Cloud personnels, attention à la fonctionnalité d’accès à distance

Depuis un petit moment déjà, les fabricants de disque dur proposent sur le marché des produits de « cloud personnel ». On trouve ainsi des produits tels que Western Digital My Cloud, Seagate Personal Cloud pour moins de 200€ avec 3To de stockage.

Le but d’avoir un « cloud » étant de pouvoir y accéder depuis l’extérieur de sa maison, il fonctionnalité essentielle est donc l’accès à distance aux données. C’est là que j’ai trouvé la solution déployée un peu « légère ».

Si vous avez déjà essayé de rendre des données hébergées chez vous accessibles depuis Internet, vous connaissez déjà la problématique:

  • Votre abonnement ne vous octroie qu’une seule adresse IP accessible depuis Internet.
  • Cette adresse IP peut, suivant les formules, être modifiée tous les jours.

Dans ces conditions, pouvoir accéder de manière fiable depuis Internet à une machine hébergée chez vous devient compliqué. (Pas impossible, juste compliqué)

Pour simplifier l’expérience utilisateur, la solution retenue pour ces produits est d’utiliser un relai hébergé par le fabricant.

Le produit est connecté en permanence au service du fabricant, ce qui permet au fabricant de la joindre même si votre IP publique change et sans avoir à toucher à la configuration du routeur de votre Box Internet.

Pour accéder depuis Internet aux données hébergées chez soi, il faut créer un compte chez le service hébergé chez le fabricant (Seagate Access, WDMycloud ,Synology QuickConnect) par utilisateur.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="485" src="https://www.youtube.com/embed/GuiGeobRHFU?start=80&amp;feature=oembed" width="646"></iframe>

Vous remarquerez que le compte sur le service du fabricant ne sert qu’à simplifier l’expérience utilisateur. Sinon vous devriez spécifier à quel produit vous voulez accéder parmi tous ceux vendus par le constructeur. Imaginer le login : « bob@wdcloud_65863 » :D. Pour éviter de vous demander de mémoriser un identifiant de plus, on stocke celui-ci derrière un identifiant plus familier : votre email. Enfin, lors de votre connexion à distance, c’est bien le service du fabricant et non votre boîtier personnel qui déchiffre votre mot de passe.

Donc le fabricant a toutes les cartes en main pour accéder quand il veut à vos données hébergées chez vous. Ce n’est peut être pas ce que vous aviez en tête en achetant la boite dans le magasin…

La solution plus compliquée passe par :

  • une configuration du routeur de votre Box pour rediriger les connexions entrantes vers votre « Cloud » (gratuit)
  • un nom de domaine (payant) ou un sous domaine dont vous pouvez mettre à jour le DNS (gratuit)
  • la génération d’un certificat SSL dont vous seul avez la clé privée pour sécuriser le transfert de vos données et de votre mot de passe (gratuit ou payant. Si vous avez la main sur le nom de domaine, vous pouvez en demander un à StartSSL. Sinon vous pouvez en acheter un ou simplement l’autosigner)

D’après la documentation des produits que j’ai regardé, il faut aller voir les produits plus chers pour pouvoir mettre en œuvre cette solution : les autres NAS de Seagate et Western Digital ou tout produit de Synology. Dommage…

Compte tenu de cette limitation sur les produits « grand public » des fabricant de disque dur, la solution Intel NUC + Owncloud m’a l’air toujours la course niveau prix (un peu plus de 200€).

Related Posts:

J'aime(5)Ferme-la !(0)

2015-10-01

Autohébergement : Pour qui ? Pour quoi ? Contre qui ? Contre quoi ?

Ce billet est en réponse à celui publié par Genma. Je possède un point de vue différent de l'autohébergement et je pense que ça peut contribuer à la réflexion.

En bref, ce que nous dis Genma :

  • On veut s'échapper des GAFAM à l'heure de la surveillance de masse.
  • S'auto-héberger demande des compétences techniques.
  • On pourrait donc mutualiser à une échelle locale l'hébergement par une structure associative.

Dans cette réflexion, il manque selon moi un point important qui porte sur la hiérarchisation. Nous parlons de vie privée. Envers qui je souhaite la protéger ? On peut répondre par cercle (degré du lien, temps partagé...) : la famille, les amis, les voisins, les entreprises (de son pays ou non), la presse, son Etat, les autres Etats.

Si on prend part à la réflexion de Genma, on ne regarde que les cercles étatiques et éventuellement des entreprises. La question est maintenant la suivante : qui est le plus à même d'avoir un intérêt pour mes informations ? Si on est Snowden, alors Genma a raison, il faut se méfier beaucoup des Etats, mais à l'évaluation du risque, on ne se risquera pas à mettre sa vie entre les mains d'une association. Maintenant, si je suis une personne lambda, c'est-à-dire que je n'ai pas de notoriété publique, les personnes pouvant être intéressés par ma correspondance sont les personnes de mes cercles proches (donc familles, amis, voisins). Qui me dit qu'un voisin ne trouvera pas un comportement banal un peu louche ? et décidera d'approfondir, parce que vous comprenez... En terme de probabilité, c'est bien plus important que l'état quand on "n'a rien à se reprocher mais quand même quelque chose à cacher" (cf conférence de J. Vaubourg par ex.).

Le terme autohébergement désigne l'hébergement d'un serveur chez soi. Il ne dit pas ce qu'il y a sur ce serveur. Toujours en cercle, cette fois-ci de vie privée :

  • synchronisation de données (photos, vidéos, documents administratifs)
  • correspondance (courriel, vidéo-conférence...)
  • hébergement de fichiers (pour partage privé)
  • hébergement de sites semi-publiques
  • hébergement de sites publiques

Le haut de la liste est peu appropriée à l'hébergement associatif, le bas de la liste l'est d'avantage, la frontière est à délimiter par chacun. En d'autres termes, les GAFAM ne nous protègent pas des structures puissantes (états, entreprises) mais nous protège pas trop mal des structures proches (voisins...). Je dis "pas trop" car il peut y avoir des failles et/ou des divulgations publiques. L'hébergement associatif est juste le contraire de cette situation (protection contre les structures puissantes par délocalisation mais vulnérabilité aux proches). Le véritable auto-hébergement tend à peser sur toutes les sphères, sans pour autant que ce soit parfait car sécuriser un serveur n'est pas facile et dans certains cas, on peut vouloir s'en remettre à une association ou une petite entreprise.

En résumé, je pense qu'il faut se méfier des règles génériques et chaque élément doit être analysé séparément afin d'accorder la difficulté technique de chaque solution possible avec le produit des risques de perte de vie privée liés à l'ensemble des acteurs et des conséquences (i.e. risques * conséquences).

2015-09-29

Autohébergement d'un gitlab

L'idée de ce billet est d'avoir un github chez soi. Plusieurs raisons à cela :

  • J'ai des dépôts privés. Github propose des dépôts privés payants, mais je n'ai pas confiance dans github pour respecter ma vie privée.
  • J'ai des dépôts semi-privés. Idem à ci-dessus, je veux un cercle restreint.
  • Je ne sais pas quel est l'avenir de github. Google code a fermé, gitorious de même. Je n'ai pas envie de devoir déménager un jour à la va-vite. Voir Et si github fermait.

L'outil git me permet de versionner :

  • mes codes sources (scripts d'adminsys, codes scientifiques).
  • mes articles, rédaction de projets, etc.
  • mes figures.

Je garde des dépôts séparés pour :

  • mes wiki et blog (géré par ikiwiki)
  • mes dépôts git-annex (qui me permettent de synchroniser des fichier dont la masse totale fait plusieurs gigaoctets).

Il faut donc une gestion fine des permission, ce que gitweb ne permet pas (à ma connaissance).

Deux possibilités :

  • gitlab : version entreprise + version communautaire. Des fonctionnalités ne sont pas disponibles dans la version communautaire comme le support de git-annex.
  • Gogs : communautaire, plus jeune et prometteur.

A terme, si Gogs se développe, il sera intéressant. Pour l'instant, je reste sur gitlab qui est une valeur sûre en terme de maturité.

Framasoft ne propose pas (encore) d'explications pour installer gitlab sur sa machine, comme il le fait pour d'autres de ses services sur framacloud. On va donc s'atteler à la tâche (A noter que j'écris la suite de mémoire, je n'ai pas eu de difficultés particulières à la configuration une fois que j'ai su comment j'allais m'y prendre).

On commence à suivre les instructions d'installation sur https://about.gitlab.com/downloads/#debian8. En effet, l'application est empaquetée, ce qui nous facilite grandement la vie.

Ensuite, on va dans /etc/gitlab/gitlab.rb pour faire tourner notre instance sur le port 8888

external_url 'https://git.sciunto.org:8888'
# Unicorn
unicorn['worker_timeout'] = 600
unicorn['port'] = 8888
# Web server
web_server['external_users'] = ['www-data']
# On desactive nginx
nginx['enable'] = false
ci_nginx['enable'] = false

On n'oublie pas l'aspect backup, à agrémenter selon l'infrastructure

# For setting up backups

J'ai une instance apache sur ce serveur, je vais donc faire en sorte que apache serve les pages qui sont sur le port 8888. En clair, on mets en place un reverse proxy. Ma configuration est basée sur cet exemple, on n'oubliera pas de modifier le port 8080 pour le 8888. Une liste de modules est présente dans l'en-tête. Ils doivent être activés avec la commande a2enmod.

On reconfigure et relance tout le monde :

sudo gitlab-ctl reconfigure
sudo service apache reload

Après ça, on a un beau gitlab qui tourne.

2015-09-22

diaspora* s'invite sur Scaleway, votez pour déployer votre pod facilement !




L'ami SpF vient de réussir à pourrir la timeline de la totalité des utilisateurs de diaspora*, mais c'est pour la bonne cause : pousser l’hébergeur Scaleway (ce n'est pas un placement produit, je n'ai pas d'action chez eux !) à fournir une image pré-configurée d'un pod diaspora*, prêt à l'emploi, en 2 cliques et quelques configurations ! Une InstantApps comme ils disent.

Pour que ça se fasse, il faut que les gens votent, que vous votiez, pour soutenir le projet et le faire passer d'une belle idée à du concret. Au passage, on n'oublie pas de garder dans un coin de son crane que ce genre de technique sert de beau coup de pub pas cher. Et paff le placement produit.

Pour les retardataires qui auraient raté mes derniers billets, le pod diaspote tourne sur un C1 de Scaleway.  Il marche bien, vraiment. Pour quelques utilisateurs, c'est parfait.

J'ai l'impression que ce projet pourrait faire revenir diaspora* à ses fondamentaux : un pod pour quelques utilisateurs, ou la mort des grands du réseau comme Framasphere. Je n'ai rien contre eux, loin de là, mais regrouper des milliers de gars sur un même pod ne rempli pas la charte de décentralisation initiale.
Bon, dans le meilleurs de monde, on se retrouverait avec plein de monde chez le même hébergeur, ce qui ne serait que déplacer le problème, mais c'est un bon début.

L'initiative est lancée par SpF, mais c'est Florian qui s'est occupé de nous pondre une image Docker compatible Scaleway.

Bref, pour voter, c'est par ici. L'astuce qui vous permet de soutenir cette initiative sans vous inscrire est décrite ici.

Viendez voter, on a besoin de vous !


<noscript></noscript>

2015-09-21

Scaleway : débloquer l'installation de son serveur mail


Nouvel hébergeur, nouvelles configurations. Passé depuis peu sur les petits serveurs de Scaleway pour ce blog et mon pod diaspora*, je continue à découvrir ce que j'appelle les petites choses à savoir.

En installant mon serveur mail, je me suis rendu compte que rien ne fonctionnait. C'est quand même bizarre de luter pendant des heures avec Postfix, Dovecot ou encore Sendmail pour un résultat nul. J'ai fini par lancer une recherche sur la configuration d'un serveur mail chez Scaleway sur DDG. En résultat, je suis redirigé vers la FAQ et ce passage bien précis :

To avoid spam, remote mail ports (25, 465, 587) cannot be reached from our infrastructure. If you need to open the mail ports to send e-mail, you can go to the advanced options section of your server and change the security group configuration.

Voilà voilà... Suffisait de se renseigner un peu. Pour des raisons de sécurité, l’hébergeur empêche l'utilisation des ports classiques des serveurs mail.

Pour s'en sortir, la solution est simple : connectez-vous au panel d'administration pour désactiver le blocage :



Maintenant, diaspote arrive à envoyer des mails ! Je galère encore avec Postfix et Dovecot. Si vous avez des tutos limpides, je suis preneur ;-)


<noscript></noscript>

2015-09-18

Allez viens, j't'emmène


On a bougé, on a vraiment tout bougé, ça y est. Avec Augier, nous étions partis à l'aventure en s'appuyant sur les prix et l’apparence djeunz de notre ancien hébergeur.  L'aventure avait bien commencé : diaspote tournait et nous étions fiers, mais les aléas de la vie étant ce qu’ils sont, Augier ayant un sacré caractère et Scaleway proposant des serveurs au rapport prix/performance largement rentable, nous avons bougé chez-eux.

Ce n'est pas tout nouveau, la migration s'est faite sans, ou presque, douleur, il y a 10 jours. On s'est retrouvé avec la liste des aspects (ou groupe de contactes) vide alors que la liste des contacts était intacte. Bizarre, sans doute une erreur de ma part, mais le pod ayant relancé la synchronisation des messages, commentaires et autres, c’était une mauvaise idée de revenir en arrière.

Tout ça pour dire que notre pod est maintenant chez un gros hébergeur aux épaules larges. Ce choix me chagrine un peu, mais c'est le prix de la stabilité et du confort. Si vous voulez tester le réseau diaspora*, vous pouvez venir tester notre nouvelle installation !

Une autre chose, c'est que ce blog et tout ce qu'il y a derrière a lui aussi changé de serveur. Là, je dois dire que j'ai vraiment fait ça comme un chef, même ownCloud s'est laissé déplacer sans râler. Ça, c’était dans la nuit de mardi à mercredi, et personne n'a rien remarqué, normalement ! ;-)

Tout n'est pas encore terminée, mon serveur mail est encore dans les choux. Postfix et Dovecat (sans mysql), c'est quand même un gros morceau qui fait grimper la consommation de café/cigarette d'un admin.

J'ai déjà des idées de billets pour vous parler plus ne détail de certaines manipulations parce que quand je dis que tout c'est bien passé, j'ai quand même perdu quelques centimètres de chevelure au dessus du front.



Pour parler du nouvel hébergeur, voici ce qu'il propose :
  • 4 cœurs dédiés ARMv7
  • 2Go de mémoire
  • 50Go de stockage SSD
  • 1 adresse IPv4 publique
  • 200Mbit/s de bande passante
Ce n'est pas dingue, mais pour 3,60 euros TTC, c'est chouette. Tant que nous ne sommes pas 50 sur le pod, ça tiendra, et ce blog ne risque rien. Et même si des problèmes de performance venaient à apparaitre sur diaspote, je prendrai une deuxième machine pour gérer la base de données. Au prix que ça coûte, au diable l'avarice !

Voilà, voilà. J'ai encore passé une bonne semaine. Vivement la suivante ! :o)


<noscript></noscript>

2015-09-13

Mon blog wordpress compromis...

Arf, je viens de me rendre compte que mon blog avait été compromis.

J'ai constaté la chose il y a peu de temps, en naviguant dans les répertoires de mon blog, car j'ai constaté la présence de plusieurs fichiers suspects (dont un présent depuis quelques mois déjà. Une analyse rapide me montre qu'ils ont été posés là par quelqu'un d'autre que moi et que donc, mon blog a potentiellement été compromis à un moment donné. Ce qui est gênant, c'est que je ne sais pas par quel moyen l'attaquant a réussi à déposer ces fichiers. Je suspecte qu'un des plugins ou l'un des thèmes sur mon blog comportait une faille qui a pu être utilisée ici.

Je n'ai pas constaté que des fichiers avaient été modifiés, ni d'autres choses étranges ailleurs sur mon blog ou en base de donnée. Je n'ai pas non plus constaté d'activité réseau suspect sur la période donnée. J'ai suivi les préconisations données par le lien suivant : http://blog.secupress.fr/attaques-wordpress-261.html. J'ai aussi commencé à analyser mes logs mais je ne vois rien jusqu'à présent.

Pour repartir sur une base saine, j'ai réinstallé une nouvelle instance de Wordpress toute propre. J'ai fait un diff entre ma base et une version plus ancienne d'un an et les écarts sont tout à fait normaux. Je l'ai donc conservée. Seul vrai changement, je n'ai rajouté aucun plugin ni aucun thème. J'espère ainsi limiter les risques.

A l'avenir, je vais aussi être plus attentif sur ce qui se passe dans les répertoires de mon blog. J'ai déjà les remontées quotidiennes de mes sauvegardes mais je vais certainement scripter une petit truc spécifiquement pour mon blog.

Il n'est pas impossible que je change de moteur de blog dans quelque temps mais ce n'est qu'une option. J'aime bien Wordpress et mis à part ce qui vint de se passer, je n'ai jamais eu de problèmes avec ce CMS.

Astuces du dimanche #5


Et de 5 ! Si vous avez raté les quatre autres ADD, c'est par ici.

Fichiers / Nautilus

Avec les nouvelles versions, ils ont décidé de faire sauter l’accès au chemin complet vers le répertoire dans lequel on est. Frustrant, mais sans doute rassurant pour le petit nouveau. Pour le retrouver, et surtout le modifier, la combinaison ctrl + l le fait réapparaître.



Faire des recherches dans htop

Htop est un super utilitaire qui permet de voir l'état d'une machine...ou pas :



Il est complet, très complet, ce qui fait que je passe souvent trop de temps à y chercher info. F3 permet de faire des recherches, mais / aussi ! Si vous êtes un adorateur de VIM, pensez-y, ça fait plaisir.

Trouver des liens symboliques cassés

Rien de plus chiant que de vouloir faire une archive en tar.gz et de se prendre une erreur obscure. Souvent, c'est une histoire de liens symboliques cassés. Voici comment les retrouver :
find -xtype l

Et voilà, corrigez le tire, faites le ménage et archivez tranquillement.

Bon dimanche !


<noscript></noscript>
Généré le 2016-02-07 00:25 UTC avec Planet Venus