[NPM] Wrong python executable at install

In case you get an error similar to this when trying to npm install :

Error: Python executable "python" is v3.4.2, which is not supported by gyp.

You should tell npm which executable to use with the following command:

npm config set python python2

If you are on ArchLinux, you’re likely to encounter this problem since the default python is python3. Fortunately, it’s easy to fix.

[Xorg] no screens found

During my previous installation of Arch Linux, I encountered the « error no screens found » when trying to launch X graphic server. It took me a couple hours to understand that my motherboard had « embedded graphic functionality ». So in order to solve my problem, I had to deactivate Intel pilot from the motherboard in the BIOS, so that the system would use the graphic card instead. So an easy solution in my case, but it seems that this error can be obtained in a wide variety of case. If you’re reading this having a similar problem, I hope you’ll find a solution.

Useful command to see graphic cards detected by the system:

lspci | grep VGA

Dubitatif

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*!

Installing Cabot on Debian

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:

  1. Generate the key-file.
  2. Somehow get the key-file over to the right user-id on the right host.
  3. If that user doesn’t already have an « .ssh » directory, create one AND set its permissions to « 700. » (« rwx——« )
  4. If that user doesn’t already have an « .ssh/authorized_keys » file, create one AND set its permissions to « 600. » (« rw——-« )
  5. Append … don’t overwrite(!) … the new key to that file.

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!

Cabot

Things to do

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.

Movim: Essai d’installation

Dernièrement, j’ai décidé de voir ce que propose les réseaux sociaux alternatifs libres. Ayant eu l’occasion d’assister à une conférence sur Movim et de d’échanger rapidement avec son concepteur, je me suis donc décidé à tenter l’installation complète. Pour cela, j’ai choisi le serveur xmpp Prosody, qui embarque un serveur Bosh nécessaire pour traduire les requêtes entre les protocoles http et xmpp. Nous allons donc commencer par là.

Prosody

L’installation s’effectue via le gestionnaire de paquets (ici, aptitude) :

aptitude install prosody

Une fois Prosody installé, on se tourne vers la configuration de la bête en modifiant le fichier /etc/prosody/prosody.cfg.lua. Les modifications intéressantes sont les suivantes, à adapté selon vos besoins bien sûr.

"bosh"; -- Enable BOSH clients, aka "Jabber over HTTP"
allow_registration = false;

VirtualHost "domain.com"
        enabled = true

cross_domain_bosh = true

Le mode d’authentification doit rester en internal_plain, le changer empêche de se logger correctement. Nous pouvons dès à présent redémarrer le service pour que la configuration soit appliquer :

service prosody restart

A présent, ajoutons un utilisateur :

prosodyctl adduser user@domain.com

Pour supprimer un utilisateur si besoin :

prosodyctl deluser user@domain.com

Les comptes utilisateurs relatifs aux différents domaines sont stockés dans /var/lib/prosody/. Voilà pour la partie relative à Prosody, à ce stade, il est normalement possible de se connecter à un salon de discussion xmpp en utilisant l’utilisateur ajouté tout à l’heure.

Movim

Nous passons ensuite à l’installation de Movim à proprement parler. J’ai d’abord essayer de récupérer directement les sources à partir de la branche master, mais un fichier de dépendance était manquant et empêchait le fonctionnement de l’application. Je me suis donc tourné vers la version 7.2.

On change ensuite le propriétaire de l’arborescence  du dossier movim pour que celui-ci soit utilisable par Apache.

chown -R www-data:www-data movim

Il est maintenant temps de modifier la configuration de movim, soit le fichier movim/config/conf.php, et notamment les champs suivants :

'environment' => 'production',
'dbType' => 'mysql',
'dbUsername' => 'movim',
'dbPassword' => 'password',
'dbHost' => 'localhost',
'dbPort' => '3306',
'dbName' => 'movim',
'boshUrl' => 'http://domain.com:5280/http-bind',

On aura bien entendu pris soin de créer au préalable l’utilisateur et la base de donnée MySQL qui convient.

mysql -p -u root
  mysql> CREATE DATABASE movim;
  mysql> GRANT ALL PRIVILEGES ON `movim`.* TO 'movim'@'localhost' \
    IDENTIFIED BY 'password';

Apache

Pour rendre tout cela accessible, il nous faut maintenant configurer Apache. Soit le fichier movim dans /etc/apache2/sites-available/.

<VirtualHost *:80>
      ServerAdmin webmaster@localhost
      ServerName movim.domain.com
      DocumentRoot /var/www/movim
      <Directory />
              Options FollowSymLinks
              AllowOverride None
      </Directory>
      <Directory /var/www/movim>
              Options Indexes FollowSymLinks MultiViews
              AllowOverride All
              Order allow,deny
              allow from ALL
      </Directory>
</VirtualHost>

Puis les commandes habituelles :

a2ensite movim
service apache2 restart

Suite et fin

Movim est désormais accessible sur movim.domain.com. Un petit tour dans l’interface d’admin du nœud est nécessaire pour s’assurer que tout fonctionne correctement et initialiser la base de donnée. Les identifiants de connexion sont ceux configurés dans le fichier de configuration de movim.

Résultat, nous pouvons nous connecter à notre nœud movim grâce au compte xmpp que nous avons créé précédemment. L’ensemble est bien vide, puisque nous sommes seuls sur le nœud. En essayant diverses fonctionnalités, j’obtiens de temps à autre des messages d’erreur sur la gauche de mon écran. Comme je n’utilise pas la dernière version, je n’ai pas vraiment creusé pour savoir si cela provient de movim ou de mon serveur Prosody. J’arrive par contre à faire communiquer deux utilisateurs entre eux via le chat intégré.

Bilan mitigé, « I have mixed feelings » comme disent les anglais. Movim a un potentiel certain, néanmoins, l’installation de sa propre instance complète Movim et serveur xmpp n’est pas de tout repos. La procédure d’installation est très limitée en ce qui concerne la partie xmpp. J’avais pourtant le souvenir d’une documentation beaucoup plus complète des différentes solutions disponibles lors de mon premier passage sur le wiki il y a de cela plusieurs mois. Je partage donc les quelques étapes que j’ai suivi pour l’installation de Movim. L’ensemble est plus ou moins complet et pourrait servir de base à toute personne cherchant à tester l’application.