Gitolite: Installation

Pour pouvoir travailler à plusieurs sur un projet, ou même tout seul, mais avec un gestionnaire de version et pas un Dropbox inutile, je me suis penché sur l’installation d’un serveur Git, associé à Gitolite pour la gestion des utilisateurs.
Alors, pourquoi se faire son propre serveur, quel intérêt? Bien sûr, Github nous propose déjà ses services, mais pour héberger ses projets persos, pas encore près pour Github car trop jeune, ou ses projets d’école, rien de tel que son installation à soi. Rajoutons à cela la satisfaction d’héberger les données sur son propre serveur, en sachant que nous les contrôlons.

Trêve de bavardage, on va tout d’abord générer une clé rsa avec:
ssh-keygen -t rsa
Donner à la clé votre nom d’utilisateur.

On envoie la clé sur le serveur:
scp ~/.ssh/id_rsa.pub user@serveur.exemple.org:/tmp/user.pub

On se connecte au serveur via ssh et on obtient les droits root:
ssh user@serveur.exemple.org
sudo su –

On commence par installer tous les paquets nécessaires:
aptitude install  git-all perl openssh-server gitolite

On ajoute un utilisateur gitolite avec:
adduser gitolite

On passe à l’utilisateur gitolite:
su – gitolite

Et on exécute le script d’installation de Gitolite:
gl-setup /tmp/user.pub

Retour sur le poste client.
On va récupérer le dépot gitolite-admin qui va nous permettre de donner des droits et d’ajouter des utilisateurs via Git:
git clone gitolite@serveur.exemple.org:gitolite-admin

A ce stade, si un message vous indique que le dépot n’est pas valable, une opération s’impose pour forcer l’utilisation de la clé précédemment générée lors de la connexion.
Dans le fichier .ssh/config sur le poste client:

Host gitolite
User gitolite
HostName 37.26.241.58
IdentityFile ~/.ssh/user
IdentitiesOnly yes

Cela devrait régler le problème, sinon une recherche sur le net s’impose.

On se place dans le dossier:
cd gitolite-admin

On édite le fichier de conf pour ajouter un dépot, par exemple test:
vim conf/gitolite.conf

repo    test
RW+    =   user

On commit:
git commit -a -m « Add test repository »

On peut ensuite cloner le dépôt test:
git clone gitolite@serveur.exemple.org:test

Ajouter un readme à celui-ci:
echo « Test Repo » > README

Faire un commit:
git commit -a -m « Initial commit »

Et faire le premier push:
git push origin master

Voilà, à ce stade, le serveur Git fonctionne parfaitement et je suis en mesure de créer des dépôts, ajouter des utilisateurs, faire des commits, des push, des pull, etc…
Une seule contrainte, paramétrer les clefs sur chacun des postes de développement.
Autre point à éclaircir, le paramétrage des clefs sous Windows (Beurk), pour ceux qui développent sur cette plateforme avec des outils propres à cet OS (Dev Ps Vita).
Prochaines étapes donc: documenter ce point pour les éventuels utilisateurs et étudier l’installation du Etherpad-Lite modifié de Framasoft pour compléter les outils disponibles.
Et bien sûr, proposer ces outils aux amis et connaissances ;).

J’allais oublier les liens qui peuvent servir:
Gitolite sur Github
Gitolite dans la doc Ubuntu
Concernant le problème de dépôts/clefs:
http://serverfault.com/questions/270688/gitolite-clone-not-working-as-intended
http://www.dotkam.com/2010/08/22/gitolite-does-not-appear-to-be-a-git-repository/

Git: Configuration

Les commandes utiles pour configurer Git lors de la première utilisation.

Activation des couleurs dans la console:

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

Configuration du pseudo et du mail:

git config --global user.name "pseudo"
git config --global user.email pseudo@exemple.org

Modification du fichier .gitconfig pour l’ajout d’alias:
vim ~/.gitconfig

[color]
diff = auto
status = auto
branch = auto
[user]
name = pseudo
email = pseudo@exemple.org
[alias]
ci = commit
co = checkout
st = status
br = branch

Pour voir tous les réglages de Git:

git config --list

[Vidéo] Le Dernier Pirate

Un bon bout de temps que cette vidéo a été publié. Je ne l’ai découvert
que récemment, après qu’elle soit restée longtemps dans mes marques-pages.

L’action se déroule en France, où les radios perdent progressivement
leur liberté d’expression. Mais Captain garde l’antenne… jusqu’à la fin.

Une belle vidéo, notamment lorsque Captain s’adresse à ses auditeurs. La
scène finale et son message sont juste superbe.

A découvrir ou redécouvrir.

Le Dernier Pirate par Barnum-Films

[NodeJs] Spawn ou la création de processus fils

Un petit mot sur la façon de créer des processus fils sous node.
Pas compliqué et bien pratique, pour réaliser le cas de test d’une nouvelle fonctionnalité de npm par exemple.

Regardons le prototype:
child_process.spawn(command, [args], [options])
command correspond au programme appelé, ls, grep ou autre…
[args] est un tableau contenant tous les arguments qui seront passés au programme appelé via command.
[options] Plusieurs possibilités, dont le fait de pouvoir définir des règles pour le comportement de stdin, stdout et stderr.

Exemple:

//Set the no-proxy configuration
var noProxy = spawn(node, [npm, 'config', 'set', 'noproxy=localhost']
, { stdio: 'ignore' });

Ici, on crée un processus fils node avec pour paramètres: npm config noproxy=localhost.
On indique également que les entrées et sorties seront ignorées: { stdio: ‘ignore’ }.

Il est bien sûr intéressant de pouvoir effectuer une action particulière dès que notre fils se termine. Ceci est possible grâce à .on(‘exit’, function() { //CODE } ).
Soit avec l’exemple précédent:

noProxy.on('exit', function (code) {
console.log('noProxy process exited with exit code '+code);
});

Concernant les entrées/sorties, il est possible de laisser le processus écrire dans celles du processus parent en spécifiant cette fois: { stdio: ‘inherit’ }.
Un autre point utile consiste à récupérer le contenu de la sortie standard du processus fils.
Pour ce faire, on utilise les options suivantes: [‘ignore’, ‘stream’, ‘ignore’].
stdin et stderr sont ignorés, seule reste stdout.
On peut donc récupérer les données via .stdout.on(‘data’, function (data) { //CODE } ) , où data contient les données.
Pour reprendre l’exemple de npm, on peut ainsi récupérer la valeur de la variable de configuration proxy et la stocker dans une variable locale proxySave

var getProxy = spawn(node, [npm, 'config', 'get', 'proxy']
, ['ignore', 'stream', 'ignore']);
getProxy.stdout.on('data', function (data) {
proxySave = data.toString().trim();
});

Voilà pour les principales infos concernant spawn. Pour en savoir plus, direction la doc officielle ;).

[Conky] Script de démarrage

Conky est maintenant configuré… Prochaine étape, le démarrage automatique à l’ouverture de la session. On se place donc dans notre home où on va créer un dossier .conky pour y placer le script: mkdir .conky. On va ensuite écrire le script dans un fichier que l’on nommera .conkyboot.sh : vim .conkyboot.sh; utilisez ici l’éditeur avec lequel vous êtes à l’aise, nano, vi, vim ou autres.

Le script est très simple et tient en trois lignes:

#!/bin/bash
sleep 20;
conky -d;

Il faut ensuite rendre le fichier exécutable: chmod +x .conkyboot.sh.
Dernière étape, programmer l’exécution du script à chaque démarrage de la session. Pour cela, onglet Système – Préférences – Applications au démarrage. Puis Ajouter, et compléter le champ avec /home/user/.conky/.conkyboot.sh en remplaçant user par votre nom d’utilisateur. Remplissez le champ Nom avec Conky par exemple.

Et voilà, votre conky devrait désormais s’afficher automatiquement 20 secondes après l’ouverture de votre session.