Pensées Libres dans un Monde Binaire
Du logiciel libre tout simplement! Et même de l’Open Source.
Pour utiliser son propre serveur de synchronisation dans Firefox, il est nécessaire d’effectuer une petite modification dans about:config. Chercher la propriété nommée services.sync.tokenServerURI et la remplacer par l’url du serveur en faisant attention à ajouter token/1.0/sync/1.5 comme chemin.
Ce qui nous donne par exemple:
services.sync.tokenServerURI: http://sync.exmpl.com/token/1.0/sync/1.5
Source: Documentation Sync-1.5 Server.
C’est le sentiment qui ressort après un petit test de Diaspora*.
J’ai installé une instance il y a quelques jours, un pod comme on dit. Côté wiki et documentation d’installation, rien à redire, une fois que l’on a la bonne configuration apache, tout fonctionne comme sur des roulettes. Diaspora* fait mieux que Movim sur ce point et j’arrêterai la comparaison ici pour me concentrer sur Diaspora*.
Le projet me plaît bien, l’interface est agréable… mais alors qu’est-ce donc qui assombrit le tableau? La découverte d’autres utilisateurs! Si vous connaissez quelqu’un présent sur un autre pod et êtes en possession de son identifiant (de la forme identifiant@autre-pod.org), aucun problème, vous pourrez ajouter cette personne à votre liste de contact et voir ses messages dans votre flux.
En revanche, impossible de suivre une personne postant des tags #photography sur un autre pod que le votre, sauf à priori par partage dans son flux de la part d’un contact présent sur le pod en question. Dans le cas d’un pod avec une faible population, les possibilités de découvrir une autre personne avec laquelle on aurait des intérêts communs semblent plus que jamais limitées.
Un dilemme se présente alors à l’utilisateur technophile. Commencer ou continuer à héberger un pod avec peu d’utilisateurs et ainsi, contribuer à une vision décentralisée du web, où chaque petite instance fait partie d’un ensemble plus grand. Ou céder à la facilité et rejoindre un pod avec une communauté plus grande, ou disposant de plus de visibilité donc attirant plus de monde. On pourra alors partager plus simplement ses dernières prises de vues, pensées, opinions politiques, recettes de grand-mère et j’en passe. On repasserait alors à un système centralisé. Certes moins que les silos de données comme Facebook et Twitter.
Ce « problème » fait d’ailleurs l’objet d’une issue Github. A ce sujet, je vous conseille donc la lecture de cet article de Flaburgan qui résume bien le pourquoi du comment.
Sur ces considérations, j’ai donc pris la décision de tenter le coup et de continuer à faire fonctionner une instance de Diaspora* sur ce serveur. J’affinerai encore la configuration dans les semaines à venir et nous verrons bien ce que cela donnera. Alors, à bientôt sur Diaspora*!
Let’s say we want to install Cabot on a server, but not on AWS, nor on DigitalOcean. And because we like challenges, let’s just use Debian Wheezy 7.5 instead of the recommended Ubuntu 12.04 LTS. Ready?
We will try to follow Cabot quickstart to perform the installation.
But first, we must set up a few things. I’ve discovered that during installation, Cabot locks the password of the root account using passwd -l root. So be aware that you won’t be able to log with root and ssh if you haven’t set an authentication process using SSH keys. As The Hitchhiker’s Guide to the Galaxy would say: « Don’t Panic », you can reverse the process if you want using passwd -u root. As a security, you could always create another user with adduser mynewuser and give him an admin status by adding it to the suddoers file with visudo.
So let’s create our keys and configure ssh.
Generate the key:
ssh-keygen -t rsa
Now that we have a key named id_rsa.pub in our .ssh directory, we should do the following steps:
Or we can use ssh-copy-id:
ssh-copy-id -i ~/.ssh/id_rsa.pub root@hostname.org
You should now be able to log in without having to type in a password.
Before going further, we need to install Fabric as it is used to provision the server and deploy Cabot.
pip install fabric
Fabric also requires some dependencies which are described on Fabric installation page.
Next step, clone the repository. I am using the deploy branch of lincolnloop fork which include awesome python packaging.
git clone https://github.com/lincolnloop/cabot.git git checkout deploy cd cabot
Modify configuration: (might need to use development.env with the fork here)
cp conf/production.env.example conf/production.env vim conf/production.env
Before doing anything, make sure you can or can’t install nodejs: aptitude search node. If nodejs can’t be found, you’ll need to install it manually.
A few changes before provisioning our server. Edit file bin/setup_dependencies.sh
and remove line 57 and 58: ‘nodejs‘ and ‘npm’
Install nodejs manually, npm should come it.
fab provision -H root@your.server.hostname
Once it’s done, we can deploy cabot:
fab deploy -H ubuntu@your.server.hostname
You should get an error because cabot is trying to use upstart but can’t find it.
To run Cabot, log in to your server under the user ubuntu.
cd 2014-06-19-e662635
(Your directory will have a different name following a similar pattern year-month-day-wathever)
foreman start
Congratulations, Cabot should now be running!
I will certainly add a simple init.d script to my Cabot fork so that we can run it easily. I will maybe change one or more things as the ubuntu username.
Understanding how to install and run Cabot took me a few hours. I got disturbed by the quickstart speaking of AWS or DigitalOcean server. I also tried to install it manually but didn’t manage to get it work, although I was close to it (I think. Or at least I hope ^^). Installing it on Debian added some difficulties, but nothing insurmountable. As a conclusion, I must say that Cabot is worth the effort. It provides a great way to monitor your service with Http checks and the possibility to alert based on Graphite metrics is just priceless.
Or, « What I’ve learned about Graphite configuration ».
Last week, I worked on configuring Graphite and had to understand how it stores and aggregates data. So here are a few facts.
The way our data will be stored is described in /opt/graphite/conf/storage-schemas.conf. As an example:
[default] pattern = .* retentions = 1s:30m,1m:1d,5m:2y
This worked great when I was looking at data from the last 30 minutes.
If I was trying to display last hour metrics: nothing.
Drawing null as zero was giving me a horizontal line at the bottom of the graph.
This behaviour comes from the file /opt/graphite/conf/storage-aggregation.conf where we find the following lines:
[99_default_avg] pattern = .* xFilesFactor = 0.5 aggregationMethod = average
Our problem comes from xFilesFactor. It means that by default, we need at least 50% of the data to be non-null to store an average value. Think about it.
So here, I’m having a metric every second during 30 minutes. If Graphite doesn’t have something for a given second, the value is set to null. Fine, let’s move forward.
For interval higher than 30 minutes (and lower than a day), Graphite will gather data based on the aggregation configured. So it will average data and set the value null if it has less than 50% usable values (not null).
In our case, Graphite tries to average one minute of data (1m:1d) with the precision of 1s from the first retention rule (1s:30m). To understand why nothing is displayed, consider I’m Collectd is sending data to Graphite. On average, metrics are arriving every 3s. On a one minute interval, we gather 20 values but Graphite is considering 60 values, 40 being null. We only have 33% (0.33) metrics usable which is lower than 50% Graphite is waiting for so the averaged value is set to null.
Now that we updated our configuration, set xFilesFactor to 0 to be sure, restart carbon-cache, everything should work fine…
But that’s not the case; no change.
In fact, previous configuration is still being used in wsp storage files. We can check it with whisper-info.py.
whisper-info.py /opt/graphite/storage/whisper/collectd/test-java01/cpu-0/cpu-user.wsp maxRetention: 63072000 xFilesFactor: 0.5 aggregationMethod: average fileSize: 2561812 Archive 0 retention: 1800 secondsPerPoint: 1 points: 1800 size: 21600 offset: 52 Archive 1 retention: 86400 secondsPerPoint: 60 points: 1440 size: 17280 offset: 21652 Archive 2 retention: 63072000 secondsPerPoint: 300 points: 210240 size: 2522880 offset: 38932
See, we still have xFilesFactor: 0.5.
If you don’t care about previous data, a good solution is to delete files so that the new parameters will be used (rm -rf /opt/graphite/storage/whisper/collectd/). Maybe it’s a little bit overkill, (but easy and fast).
The other solution consists in using whisper-resize.py to enforce the new configuration.
whisper-resize.py /opt/graphite/storage/whisper/collectd/test-java01/cpu-0/cpu-user.wsp 3s:30m,1m:1d,5m:2y –xFilesFactor=0.1
The above works fine, but this is the other way to configure how many metrics Graphite can keep. It has the format n:i, which means we store a measure every n seconds and we want i points to be stored (computed with interval / n).
Example: 3s:30m
30m = 1800s
1800 / 3 = 600
3:600
So 3s:30m,1m:1d,5m:2y gives us 3:600 60:1440 300:210380.
« An average Gregorian year is 365.2425 days = 52.1775 weeks = 8765.82 hours = 525949.2 minutes = 31556952 seconds (mean solar, not SI). » Wikipedia
Thing to remember concerning storage-schemas.conf (taken from Graphite doc):
« Changing this file will not affect already-created .wsp files. Use whisper-resize.py to change those. »
Petit Proof of Concept réalisé la semaine dernière autour des technologies Puppet et Docker. L’idée consiste à utiliser Docker pour pouvoir facilement déployer un environnement master-slave Puppet et avoir ainsi la possibilité de tester ses scripts de déploiement ou plus généralement, d’étudier et de comprendre le fonctionnement de Puppet avant de passer à une utilisation en production.
Le projet permet donc la création de deux containers Docker, l’un contenant le master et l’autre l’agent. Après création du container master, on peut créer l’agent et lier les deux containers à l’aide du paramètre -link de Docker. On permet ainsi aux deux containers de communiquer entre eux sans avoir à essayer de déterminer leur IP respective à la main. Par la suite, après signature du certificat de l’agent par le master, la configuration décrite dans le fichier site.pp sous le nœud agent pourra être mise en place sur celui-ci.
node 'agent' { class { 'apache': } }
Par exemple, on installe ici apache dans le container de l’agent.
Mes différents tests m’ont également permis d’identifier certains limitations au niveau de Docker:
Le code est bien sûr disponible disponible sous licence libre sur Github: vvision/docker-puppet-master-agent.