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

Migrer son WordPress

C’est effectif depuis jeudi soir, Unicoda dispose maintenant d’un serveur tout neuf. Effectuer une migration de WordPress est en fait relativement simple pour peu qu’un terminal ne vous fasse pas peur et sinon, des interfaces graphiques et autres plugins peuvent parfois vous simplifier encore le travail. Le nom de domaine ne changeant pas, la procédure en est encore simplifiée.

On arrive donc sur un serveur vierge de tout paquets, les paquets de base et c’est tout. Quelques installations s’impose donc, à coup d’aptitude ou de apt-get si vous préférez. Avant toute chose, on met à jour les informations concernant les paquets avec aptitude update, puis mise à jour via aptitude safe-upgrade. Suite à ces manipulations, un petit dpkg-reconfigure tzdata s’impose, histoire d’avoir une heure correcte sur le serveur. L’heure de Moscou, c’est bien beau, mais pour avoir des logs lisibles, une heure française c’est mieux (Bonjour à nos amies russes et biélorusses au passage). Arrive donc la phase d’installation à proprement parler. Via aptitude install, on installe donc les paquets suivants: php5, mysql-server, php5-mysql, php5-gd, vsftp.

Vient ensuite la configuration de vsftp, serveur FTP comme vous avez pu le deviner. On édite le fichier /etc/vsftpd.conf et on relance avec /etc/init.d/vsftpd restart pour que les modifications soient prises en compte.

On s’attaque ensuite à la partie MySQL pour préparer la nouvelle base de données de notre site à accueillir celle provenant de l’autre serveur : mysql -p. Puis dans votre invite de commande MySQL:

>CREATE DATABASE nomBaseDeDonnees;

>GRANT ALL PRIVILEGES ON nomBaseDeDonnees.* TO "NomUtilisateur"@"hostname" IDENTIFIED BY "motDePasse";

>FLUSH PRIVILEGES;

>EXIT;

Concernant les différents paramètres, nomBaseDeDonnes correspond au nom que vous donnez à votre base de données, nomUtilisateur parle de lui-même, hostname est généralement à remplacer par localhost et motDePasse c’est limpide. Votre base de données est donc prête à accueillir vos anciennes informations relatives à vos articles, utilisateurs, commentaires, etc…

Il faut également récupérer le contenu de votre dossier wp-content qui contient toutes les images que vous avez pu héberger sur votre site, les thèmes et les plugins. Un téléchargement du dossier via un client FTP fonctionnera très bien. Compresser le dossier avant envoi vous permettra de patienter moins longtemps pendant le téléchargement de vos données et surtout, pendant leur upload à venir. Une fois le dossier téléchargé, on l’upload justement vers le nouveau serveur; cette étape prend du temps surtout si votre dossier n’est pas compressé et que votre upload se résume à du 36Ko/s. On peu ensuite remplacer le dossier wp-content de notre installation toute fraîche de WordPress par celui de notre ancien site.

Il faut également transférer les données de  l’ancien base de données et les injecter dans la nouvelle. La commande suivante vous permet de récupérer les anciennes données dans un fichier:

mysqldump --add-drop-table -h mysqlhostserver -u mysqlusername -p databasename | bzip2 -c > fichier.bak.sql.bz2.

Au niveau des paramètres, localhost pour mysqlhostserver, votre nom d’utilisateur pour mysqlusername, le nom de l’ancienne base de données à la place de databasename et remplacer fichier par le nom que vous voulez pour votre sauvegarde des données. On récupère ensuite le fichier via notre ftp, on l’upload à son tour vers le nouveau serveur, on décompresse au préalable le fichier: bzip2 -d fichier.bak.sql.bz2 et on injecte les données dans notre nouvelle base de données:

mysql -h mysqlhostserver -u mysqlusername -p databasename < fichier.bak.sql

Avec localhost pour mysqlhostserver, votre nom d’utilisateur mysql pour mysqlusername et le nom de votre nouvelle base de données en lieu et place de databasename. A ce stade, votre nouveau site est presque opérationnel, il ne reste plus qu’à faire pointer le nom de domaine vers le nouveau serveur, configurer apache (Doc Ubuntu) et éditer le fichier wp-config.php de votre nouveau WordPress avec les paramètres utilisés pour la création de la nouvelle base de données.

On trouve la plupart des informations dont on a besoin sur le web, et notamment sur le site de WordPress. Quelques heures suffisent donc à effectuer la migration d’un site WordPress vers un nouveau serveur si on conserve le même nom de domaine, le plus long étant à mon sens, l’upload du dossier wp-content.

Installation d’un serveur Murmur (Mumble)

Aujourd’hui, je teste l’installation d’un serveur Murmur pour mettre en place un espace d’échange VoIP. Murmur représente la partie serveur, le côté client étant assuré par Mumble. Tout cela étant bien sûr libre!

On commence par ajouter les dépôts qui vont bien:                                                         nano /etc/apt/sources.list                                                                   deb http://ftp.de.debian.org/debian sid main

On installe les paquets:                                                                                                 apt-get install mumble-server mumble-server-web

On configure:                                                                                                 dpkg-reconfigure mumble-server

On modifie les paramètres:                                                                                              nano /etc/mumble-server.ini                                                                                        Notamment le message d’accueil:                                                                                          # Welcome message sent to clients when they connect                            welcometext= « <br />Welcome to this server running <b>Murmur</b>.<br />Enjoy!<br /> »                                                                                                                     Le mot de passe de connexion:                                                                                              # Password to join server                                                                           serverpassword=

On redémarre le serveur pour appliquer les nouveaux paramètres:                                 /etc/init.d/mumble-server restart

 

A ce stade, le serveur fonctionne sans problème. Il est possible de s’y connecter via un client Mumble. Pour ensuite personnaliser votre serveur en lui ajoutant des salons par exemple, il suffit de vous connecter au serveur en spécifiant son IP et en utilisant Superuser comme identifiant. Le mot de passe demandé pour valider la connexion est celui que vous avez choisi lors de la configuration.

Il ne reste donc plus qu’à tester la montée en charge avec la connexion simultanée de plusieurs personnes et espérer que tout fonctionne sans latence ni perte de signal.