Pensées Libres dans un Monde Binaire
Il y a quelques semaines sortait le court-métrage Tears of Steel de la Blender Fundation. Aujourd’hui, c’est le court-métrage précédent Sintel que je souhaite partager. Sintel raconte l’histoire émouvante de l’amitié entre une jeune fille et un dragon. Images superbes, bande-son magnifique… A découvrir sans plus attendre:
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/
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
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
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 ;).