Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

php-pecl-mysqlnd-ms-1.1.0

Remi Collet

Le RPM Plugin de réplication Mysqlnd et de balance de charge est disponible dans le dépôt remi et en attente de revue pour fedora >= 16.

Cette extension pour mysqlnd permet de gérer la réplication de charge entre les serveurs maitre et esclaves, gérée par l'application ou de manière transparente. Site pecl : mysqlnd_ms Documentation : Plugin de réplication Mysqlnd et de balance de charge Revue pour fedora : Revue request #742729 Installation, après avoir replacé php-mysql par... Lire php-pecl-mysqlnd-ms-1.1.0

Thunderbird 7

Remi Collet

Le RPM de la nouvelle version du client de messagerie de la Fondation Mozilla est disponible dans le dépôt remi pour fedora ≤ 14 (rétro-portage de la version F-15).

Commencez par lire : Thunderbird Release Notes (Notes de version en anglais) Comme toujours : yum --enablerepo=remi update thunderbird\* Les extensions enigmail (version 1.3.2) et lightning (version 1.0b7) sont aussi disponibles. Les RPM de la version 7.0.1 sont disponibles ici pour fedora 12 à 14.... Lire Thunderbird 7

Au boulot, j’ai déjà préparé le poisson d’avril !

Sébastien Natroll C’est en bossant sur un script bash d’automatisation des tâches que m’est venu l’idée d’un petit script rigolo à exécuter le premier avril pour jeter un vent de panique similaire à celui qui souffle sur les bourses en ce moment. Avec la garantie de saturer nos postes téléphoniques… #!/bin/bash # Var à 1 pour une La suite >

1er Octobre

Remi Collet

C'est aujourd'hui le 1er Octobre. Même si votre calendrier vous raconte autre chose, c'est ma fête :) C'est en effet aujourd'hui la Saint Remi, sans accent, j'y tiens beaucoup. C'est la tradition à Reims de fêter Saint Remi à cette date, et lundi se déroulera, comme chaque année la grande braderie de la Saint Remi (sans accent) ou l'on pourra... Lire 1er Octobre

Archivage des fichiers cachés via TAR

Frédéric Thouin

Il est parfois fort utile d'archiver des fichiers cachés ( rien que nos fichier de configuration de nos petits softs adorés dans notre home directory )

Comme vous le savez les fichiers cachés commencent par un "."

Premier réflexe :

cd ~
tar czvf archive-dotfiles.tar.gz .*

Et la c'est le drame, TAR archive tous les fichiers de mon home....

Mais pourquoi tant de haine !!!! Et bien il faut réfléchir un petit peu à la structure même d'un répertoire et se souvenir des notions chemin relatif et absolut; et surtout, du répertoire courant (.) et répertoire parent (..)

Pour bien comprendre la commande d'avant : en mettant .* il devient maintenant évident que les fichier "." et ".." seront interprété et mis en archive par TAR. Hors si TAR prend le répertoire "." en archive, il va obligatoirement prendre son contenue ( TAR est récursif ) donc il prendra en plus des fichiers caché les autres fichiers. et il en ira de même avec l'interprétation du fichier "..".

Comment faire ?

TAR a la possibilité d'exclure des fichiers, et c'est la solution à mettre en place. Notre commande sera donc de la forme :

cd ~
tar czvf archive-dotfiles.tar.gz --exclude . --exclude .. .*

Firefox 7

Remi Collet

Les RPM de la nouvelle version du navigateur de la Mozilla Foundation sont disponibles dans le dépôt remi pour fedora.

A lire : Mozilla Firefox Release Notes (notes de version, en anglais) Installation : yum --enablerepo=remi update firefoxCe paquet utilise xulrunner7, qui s'installe à côté de celui par défaut. Remarque : ce RPM est très proche de celui de firefox 7 présent dans fedora 15/16 Les RPM sont disponibles pour fedora 12 à 14. Devrait aussi être... Lire Firefox 7

PHP: comportement de is_a()

Remi Collet

La fonction is_a() a changé de comportement dans les dernières versions de php. Quelques explications.

Dans la documentation, il est indiqué : bool is_a ( object $object , string $class_name ) Jusque la version php 5.3.6, si le premier argument était une chaine de caractère, le résultat n'était pas vraiment défini / documenté (on aurait pu s'attendre à une erreur sur l'appel), mais ça fonctionnait, et beaucoup d'applications ont utilisé ce... Lire PHP: comportement de is_a()

mysql-worbench-5.2.35

Remi Collet

MySQL Worbench, l'outil de modélisation graphique, de développement, de requêtage et d'administration des bases de données MySQL passe en version 5.2.35 (GA = stable). Les RPM pour fedora ≥ 12 sont disponibles dans le dépôt remi, et seront bientôt dans les mises à jour pour fedora ≥ 14.

Voir la Releases Page pour la liste des modifications ou Changes in MySQL Workbench 5.2.35. Les RPM sont dans mon dépôt pour Fedora 12 à 14 Comme toujours : yum --enablerepo=remi install mysql-workbench Bien sur, il a été construit avec MySQL 5.5.15. Cette version (construit avec le MySQL standard) sera aussi bientôt dans les mises à jours... Lire mysql-worbench-5.2.35

CentOS + Tomcat + beaucoup d'ouvertures de fichiers = java.net.SocketException: Too many open files

Alexandre Frandemiche

ExceptionTout est dans le titre !!! Comme d'habitude, c'est plus un pense-bête qu'un véritable article ... si ça peut aider ...

J'ai eu une surprise ce matin sur un serveur client de constater cette erreur :

java.net.SocketException: Too many open files


C'est un serveur sous CentOS 5.5 hébergeant un serveur MySQL, un serveur tomcat avec plusieurs Webapps, un serveur Apache et enfin un serveur propriétaire qui utilise pas mal de socket et a une base de donnée en interne ...

Cocktail génial pour visiblement dépasser la limite par défaut du système s'élevant à 1024 que l'on obtient en faisant un :

ulimit -n

Il y a 2 valeurs possibles à modifier, celle présente dans le fichier /proc/sys/fs/file-max par défaut, celle-ci est assez élevée (plus de 64000). Au besoin il faut modifier la ligne suivante :

...

fs.file-max = 64000

...

Si (comme tel était mon cas) la valeur de ce fichier est plus élevée, il reste à ajouter une entrée au fichier /etc/security/limits.conf :

user         -          nofile          8192

ou

@group         -          nofile          8192

La première colonne désigne l'utilisateur ou le groupe (grâce à @) ou encore n'importe qui grâce à *.
La seconde colonne, on détermine si la limite est soft ou hard, ou les 2 grâce à -.
La troisième colonne indique sur quel paramètre cette configuration s'exécute, ici nofile correspond au paramètre open files retourné par ulimit.
Enfin la dernière colonne indique la valeur.
Dans mon cas, j'ai rajouté :

@tomcat         -          nofile          8192
optitime           -          nofile          8192

Il est indiqué sur la documentation Red Hat de redémarrer le serveur pour que cela prenne effet. La solution peut consister à relancer le ou les services concernés ainsi que les sessions utilisateurs.

Voilà, en espérant que ça puisse aider et surtout m'éviter de rechercher cette information à nouveau ;) !

Migrer de CentOS vers Scientific Linux

Marc Bessière Dans mon dernier billet, je vous expliquais que j’avais pris la décision de changer la distribution de mon serveur principal qui tournait sous CentOS pour Scientific Linux. Voici la méthode que j’ai employé. Je me suis appuyé sur la méthode décrite par redman qui est l’administrateur du Forum Scientific Linux. Je vais vous donner ici [...]

Momonga Linux, l’écureuil japonais.

Sébastien Natroll Aujourd’hui, j’ai pris 15 minutes au boulot pour agir de manière à rassembler les deux grandes composantes de mon blog, à savoir : Linux et le Japon. Le résultat ? C’est Momonga Linux. Une distribution au look un peu Chibi manga faîte par des Japonais pour des Japonais. J’ai donc chopé une vieille machine à La suite >

Un an sans internet - dédicace

Pierre-Yves Chibon

Ce week-end j'ai pu rencontrer Ced qui m'a gentiment dédicacé son album Un an sans internet.

20110918-Ced-Toulouse3.png

Merci Ced pour cette dédicace très personnalisé.

À noter que son prochain album Le passeur d'âme est en prévente !




PS: Oui, je me suis posé la question, et non, je ne sais pas si j'arriverais à faire un an sans internet ;-)

NomNom présent dans les dépôts !

Fabien Nicoleau

clive et cclive sont deux logiciels (du même auteur) permettant de récupérer les vidéos de sites tels que youtube ou dailymotion (et beaucoup d'autres !). Il existait auparavant un "frontend" à ces utilitaires, toujours du même auteur : abby. Ce dernier a été remplacé par NomNom (encore et toujours du même auteur), et permet de visionner les vidéos directement en streaming, ou simplement de les télécharger. Il permet aussi de profiter des options de umph (dont je vous laisse deviner l'auteur ..) pour télécharger toute une liste de lecture, ou de favoris de YouTube. NomNom peut être une bonne alternative à ceux ne souhaitant pas utiliser de plugin flash avec leur navigateur.

umph et NomNom n'étaient pas présents dans les dépôts. Je les ai donc packagés et  proposés. Ces deux paquets ont été acceptés et sont maintenant disponnibles dans les dépôts de Fedora, à partir de la version 15. Pour installer NomNom, en root :

# yum install nomnom


Fabien (eponyme)

NomNom présent dans les dépôts !

Fabien Nicoleau

clive et cclive sont deux logiciels (du même auteur) permettant de récupérer les vidéos de sites tels que youtube ou dailymotion (et beaucoup d'autres !). Il existait auparavant un "frontend" à ces utilitaires, toujours du même auteur : abby. Ce dernier a été remplacé par NomNom (encore et toujours du même auteur), et permet de visionner les vidéos directement en streaming, ou simplement de les télécharger. Il permet aussi de profiter des options de umph (dont je vous laisse deviner l'auteur ..) pour télécharger toute une liste de lecture, ou de favoris de YouTube. NomNom peut être une bonne alternative à ceux ne souhaitant pas utiliser de plugin flash avec leur navigateur.

umph et NomNom n'étaient pas présents dans les dépôts. Je les ai donc packagés et  proposés. Ces deux paquets ont été acceptés et sont maintenant disponnibles dans les dépôts de Fedora, à partir de la version 15. Pour installer NomNom, en root :

# yum install nomnom


Fabien (eponyme)

Orphan de certains de mes paquets

Fabien Nicoleau

Bonjour,

En raison de manque de temps, et souhaitant me concentrer sur les paquets que j'utilise avec Fedora, j'ai pris la décision "d'orphan" 6 des paquets que je maintiens dans les dépôts :

  • gestikk : permet de lancer des logiciels avec un simple mouvement de souris
  • immix : mixage de photos
  • itaka : serveur de capture d'écran
  • perl-WWW-Curl : extension perl pour manipuler libcurl
  • vbindiff : visualiseur de fichiers en hexadécimal, avec prise en charge de fichiers à forte taille
  • xcftools : suite d'utilitaires en ligne de commande permettant de manipuler les fichiers au format XCF

J'ai de plus retiré deux paquets :

  • abby : cette interface graphique à clive et cclive a été remplacée par nomnom, que j'ai ajouté dans les dépôts (j'en parlerai bientôt)
  • trustyrc : mon robot IRC, que je ne maintiens plus

Ceux qui souhaitent maintenir ces paquets pourrons compter sur moi en cas de besoins/questions.


Fabien (eponyme)

Orphan de certains de mes paquets

Fabien Nicoleau

Bonjour,

En raison de manque de temps, et souhaitant me concentrer sur les paquets que j'utilise avec Fedora, j'ai pris la décision "d'orphan" 6 des paquets que je maintiens dans les dépôts :

  • gestikk : permet de lancer des logiciels avec un simple mouvement de souris
  • immix : mixage de photos
  • itaka : serveur de capture d'écran
  • perl-WWW-Curl : extension perl pour manipuler libcurl
  • vbindiff : visualiseur de fichiers en hexadécimal, avec prise en charge de fichiers à forte taille
  • xcftools : suite d'utilitaires en ligne de commande permettant de manipuler les fichiers au format XCF

J'ai de plus retiré deux paquets :

  • abby : cette interface graphique à clive et cclive a été remplacée par nomnom, que j'ai ajouté dans les dépôts (j'en parlerai bientôt)
  • trustyrc : mon robot IRC, que je ne maintiens plus

Ceux qui souhaitent maintenir ces paquets pourrons compter sur moi en cas de besoins/questions.


Fabien (eponyme)

Publication de Gauffr 0.9

Guillaume Kulakowski

Après pas mal de travail, la version 0.9 de Gauffr vient de voir le jour. Cette version préfigure à peu de chose près ce que sera la version 1.0 une fois que les derniers ajustements seront réalisés.

Ecran de connection de Gauffr

Pour énième rappel, Gauffr est un système permettant de connecter des applications diverses appelées GauffrSlave qui vont utiliser le couple "login / mot de passe" issu d'une seule application déjà existante appelée GauffrMaster. Gauffr vous offre donc un niveau d'abstraction entre vos applications GauffrSlave et votre application maitresse que vous pouvez changer sans avoir à tout re-développer.

Les nouveautés de cette 0.9 sont essentiellement centrées autour de la GauffrAdmin qui permet de manipuler certaines données telles que les informations étendues qui vous permettent d'enrichir vos données maitresses sans en altérer le modèle de données ni le code.

Informations étendues sur les utilisateurs

Pour le moment, ces informations étendues sont essentiellement orientées vers les logins alternatifs, par exemple, si comme pour Fedora-Fr vous avez un login de type forums (llaumgui dans mon cas) et un login pour les wiki (GuillaumeKulakowski). A terme, j'envisage de stocker les informations OpenID mais surtout de permettre d'étendre ces données à partir d'un fichier de configuration.

Une autre fonctionnalité de la GauffrAdmin est de permettre de configurer les droits utilisateurs. Vous pouvez par exemple permettre à vos membres qui en ont le droit et seulement eux de se connecter au wiki, les plugins mwGauffr créera automatiquement le compte à la première connexion.

Droits utilisateur

php-pecl-mysqlnd-qc-1.0.1

Remi Collet

Le RPM Plugin de cache des résultats de requêtes Mysqlnd est disponible dans le dépôt remi et en attente de revue pour fedora >= 16.

Cette extension pour mysqlnd permet de gérer un cache du résultat des requêtes, géré par l'application ou de manière transparente. Site pecl : mysqlnd_qc Documentation : Plugin de cache des résultats de requêtes Mysqlnd Revue pour fedora : Revue request #739367 Installation, après avoir replacé php-mysql par php-mysqlnd : yum --enablerepo=remi... Lire php-pecl-mysqlnd-qc-1.0.1

Mon GIT à la maison ! Git - Gitolite - cgit (ou gitweb)

Johan Cwiklinski

Ces derniers temps, je m'intéresse de plus en plus à Git en remplacement partiel de mes anciens dépôts SVN (partiel seulement, car j'apprécie aussi Mercurial, certains de mes anciens projets ont dores et déjà migré).

Ce que je souhaite :

  • avoir un accès via le web au dépôt, au minimum pour consulter le code,
  • pouvoir assez facilement régler les droits en lecture et/ou écriture par dépôt.

Côté accès web, je dispose actuellement de nombreux outils pour naviguer dans mes dépôts SVN :

Mercurial n'est pas en reste ; puisqu'il est est facile de mettre en place une interface web de consultation des dépôts.

L'interface web, en plus de me permettre de consulter mes dépôts depuis n'importe quel matériel permet de lancer un navigateur web, donne aussi un aspect public pour mes projets (la plupart étant sous licence libre) ; l'écriture étant restreinte aux accès SSH.

Le pendant Git de ces interfaces est Gitweb, utilisé par de nombreux projets hébergé sous Git, comme le Projet Fedora par exemple. Cependant, j'ai très vite rencontré certaines « limites » avec gitweb, qui ne me semblent pas acceptables :

  • je ne suis pas parvenu (bien qu'à priori cela soit possible) à mettre en place le clonage des dépôts via HTTP :-/" class="smiley
  • lorsqu'un dépôt n'est pas autorisé en lecture à l'utilisateur spécial gitweb, il n'est certes pas affiché dans la liste des dépôts ; mais est tout de même accessible via l'interface, pour le peu que l'on connaisse le nom du dépôt !

J'ai donc décidé de me tourner vers une alternative à gitweb : cgit.

Bien entendu, des service d'hébergement Git tels que gitorious ou github existent ; mais ce n'est absolument pas envisageable pour le travail ; et à titre personnel, j'aurai aimé avoir des dépôts privés, ce qui n'est pas possible avec les formules gratuites de tels hébergeurs. De plus, seul gitorious repose actuellement sur des technologies libres...

En ce qui concerne la gestion des accès, j'avais évoqué ici-même l'utilisation de mercurial-server sous Fedora ; dont le pendant Git est gitolite (en quelque sorte le successeur de gitosis).

Let's go :

$ sudo 'yum install git-all gitolite'

git-all installera l'ensemble des paquets git-* présents sur les dépôts, vous pouvez si vous le souhaitez préférer ne lister à la place que les paquets que vous souhaitez réellement installer :-)" class="smiley

gitolite

En plus des explications fournies ici, je vous conseille vivement de consulter la documentation d'installation de gitolite ;-)" class="smiley

Commençons par mettre en place gitolite. Le paquet présent sur les dépôts installera bien entendu tout ce dont vous aurez besoin :

  • les fichiers de l'application (ben oui, heureusement !),
  • un utilisateur dédié (gitolite),
  • un répertoire de stockage (/var/lib/gitolite - qui est également le $HOME de l'utilisateur gitolite).

Gitolite offre un accès aux dépôts Git via SSH. L'intégralité des dialogues avec le serveur passeront donc par l'utilisateur gitolite ; le programme se chargera ensuite de vérifier qui vous êtes et ce à quoi vous avez accès... ou pas :-p Il vous faut donc créer une clé SSH (si ce n'est déjà fait) :

$ ssh-keygen

Il faut ensuite copier la clé sur le serveur en la renommant de la forme username.pub. Il faudra pour la suite que cette clé soit lisible par l'utilisateur gitolite, la copier dans /tmp semble une bonne idée :

$ scp ~/.ssh/ir_rsa.pub user@server:/tmp/machin.pub

Note : le nom de la clé SSH n'est pas anodin. En effet, c'est sous ce nom que vous serez identifié ; et c'est celui qui sera utilisé un peu plus tard lors de la configuration des droits des dépôts. Cette remarque est valable d'une façon générale avec gitolite ; on y reviendra ;-)" class="smiley

Sur le serveur, il faudra ensuite initialiser gitolite :

# su - gitolite
$ gl-setup /tmp/machin.pub
creating gitolite-admin...
Initialized empty Git repository in /var/lib/gitolite/repositories/gitolite-admin.git/
[...]
 2 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 conf/gitolite.conf
 create mode 100644 keydir/machin.pub

Et... Voilà ! Gitolite est installé et configuré sur votre serveur ; vous pouvez profiter de la magie !!

L'administration de Gitolite se fait par... un dépôt Git, on peut voir qu'il a été créé et peuplé par la commande gl-setup Récupérons un clone (depuis la machine sur laquelle est installée la clé SSH uploadée. Ben ouais ; faut suivre un peu ! :-D" class="smiley ) :

$ git clone gitolite@server:gitolite-admin.git

Examinons le dépôt ainsi cloné :

$ tree gitolite-admin 
gitolite-admin
|-- conf
|   `-- gitolite.conf
`-- keydir
    `-- machin.pub

On a donc un dossier conf qui contient l'unique fichier de configuration de gitolite ; et un dossier keydir dont la fonction est de recevoir toutes les clés des utilisateurs. Le fichier de configuration par défaut donne tous les droits à l"utilisateur machin sur le dépôt d'administration, un dépôt de test accessible librement à tous créé à l'initialisation est aussi configuré :

$ cat conf/gitolite.conf
        repo    gitolite-admin
                RW+     =   machin

        repo    testing
                RW+     =   @all

        repo    mailletest
                RW+      =  machin chouette
                R        =  chose gitweb

Pour créer un nouveau dépôt, il suffit d'ajouter l'entrée au fichier de configuration. Dès que vous aurez fait un git push dans le dépôt gitolite-admin, le nouveau dépôt sera initialisé automatiquement. Cool, non ? :-p
Le dépôt ajouté portera le nom mailletest ; il sera accessible en lecture/écriture aux autilisateurs machin et chouette, en lecture seule pour les utilisateurs chose et gitweb. N'oubliez pas dans ce cas d'ajouter les fichiers chouette.pub et chose.pub dans le dossier keydir, et de les ajouter au dépôt avant de commiter. En cas d'oubli, gitolite se fera un plaisir de vous informer que le ou les utilisateurs qui ont été configurés n'ont pas de clé. L'utilisateur gitweb est particulier, il définit la liste des dépôts qui seront exportés dans le fichier projects.list.

$ git add
$ git commit conf/gitolite.conf -m"Test de création de dépôt"
[...]
$ git push 
[...]
remote: Initialized empty Git repository in /var/lib/gitolite/repositories/mailletest.git/
[...]

Votre installation de gitolite est complète, votre premier dépôt est créé ! Que demander de plus ? Ha oui, une interface web on avait dit...

Si vous souhaitez en savoir plus sur les possibilités de gitolite :

Interface web

Si vous souhaitez utiliser une des interfaces web sur les futurs dépôts créés, il faudra effectuer une petite modification supplémentaire dans la configuration de gitolite. Dans le fichier /var/lib/gitolite/.gitolite.rc, changez la valeur pour $REPO_UMASK de 0077 à 0027 (les commentaires présents dans le fichier devraient être assez parlants).

La configuration expliquée ici est basée sur le serveur web Apache HTTPD. Il est évidemment possible d"utiliser les différentes interfaces web à Git avec n'importe quel serveur web capable de faire du CGI, mais cela dépasse largement le cadre de ce tutoriel.

Notez que lors de l'installation des paquets de chacune des interfaces présentées ici, un fichier de configuration par défaut sera placé dans le dossier /etc/httpd/conf.d/, nommés respectivement cgit.conf, git.conf et webgit-caching.conf. Comme nous utiliserons un hôte virtuel dédié, nous commenterons chacune des lignes présentes dans le fichier par défaut (on ne supprime pas le fichier, puisqu'il est fourni avec le paquet RPM ;-)" class="smiley ).

Chaque dépôt sur le serveur requiert d'être initialisé pour répondre aux requêtes HTTP :

$ cd /var/lib/gitolite/repositories/mailletest.git
$ git update-server-info

L'opération est à répéter après chaque commit. Évidemment, il y a une solution automatisée, le faire à la main n'est même pas envisageable ;-)" class="smiley Utilisons les hooks pour parvenir à nos fins, l'opération sera automatiquement effectuée sur le dépôt après chaque commit :

$ cd /var/lib/gitolite/repositories/mailletest.git
$ cp ./hooks/post-commit.sample ./hooks/post-commit
$ chmod +x ./hooks/post-commit

Gérer les droits...

On arrive à une partie un peu plus sensible : la gestion des droits. En effet, les dossiers et les dépôts créés sont par défaut uniquement accessibles à l'utilisateur gitolite ; mais nous souhaitons que l'utilisateur apache puisse y accéder. Heureusement, nous avons modifié les REPO_MASK de gitolite. Voyons ce qu'on a :

# ls -al /var/lib/gitolite/projects.list
-rw-------. 1 gitolite gitolite 0 16 sept. 23:43 /var/lib/gitolite/projects.list
#  `--# ls -al /var/lib/gitolite/repositories 
total 40
drwxrwxr-x. 5 gitolite gitolite 4096 16 sept. 23:43 .
drwxr-x---. 5 gitolite gitolite 4096 16 sept. 23:13 ..
drwx------. 8 gitolite gitolite 4096 16 sept. 23:43 gitolite-admin.git
drwxr-x---. 7 gitolite gitolite 4096 16 sept. 23:43 mailletest.git
drwx------. 7 gitolite gitolite 4096 16 sept. 23:43 testing.git

Ok, commençons par ajouter l'utilisateur apache au groupe gitolite. Une fois cela fait, le dépôt nouvellement créé (mailltest.git) sera accessible depuis le web ; mais pas gitolite-admin, c'est voulu. En effet, je ne souhaite vraiment pas que le dépôt de configuration soit accessible par le web ; ne pas pas autoriser le serveur à lire son contenu est un bon moyen ; bien qu'il soit aussi possible de configurer les dépôts que gitweb n'affichera pas... L'un n'exclut de toutes façons pas l'autre « Deux précautions valent mieux qu'une ».
Nous aurons aussi à adapter les droits sur le fichier projects.list pour que apache puisse le lire :

# usermod -a -G gitolite apache
# chmod g+r /var/lib/gitolite
# chmod g+r /var/lib/gitolite/projects.list

SELinux...

Mais-heu ! SELinux, il est méchant avec moi, il me bloque l'accès à mes jolis dépôts Git avec lesquels moi je veux m'amuser !

Si SELinux est activé (je ne vois pas pourquoi il ne le serait pas, à plus forte raison sur un serveur !!), l'accès aux fichiers et dossiers de Git sera bloqué depuis les interfaces web. Il semble que la solution consiste à utiliser le contexte git_system_content_t sur les fichiers adéquats.

Toutefois, appliquer ce contexte sur certains dossiers pourrait poser problème. Un mauvais contexte sur le dossier ~/.ssh entraînerait l'impossibilité de se connecter au dépôt via SSH... Plutôt gênant, non ? :-p
J'ai donc choisi de modifier le dossier home de l'utilisateur pour séparer les données système de l'utilisateur, et les données des dépôts Git :

# usermod -d /home/gitolite -m gitolite
# mkdir /var/lib/gitolite && chown -R gitolite:gitolite /var/lib/gitolite
# chmod o-rx /var/lib/gitolite
# mv /home/gitolite/* /var/lib/gitolite/
# mv /home/gitolite/.gitolite* /var/lib/gitolite
# su - gitolite
$ ln -s /var/lib/gitolite/* .
$ ln -s /var/lib/gitolite/.gitolite* .

Appliquons maintenant le contexte SELinux adéquat :

# semanage fcontext -a -t git_system_content_t '/var/lib/gitolite(/.*)?'
# restorecon -R -v /var/lib/gitolite

Bon... On ne devrait pas être trop mal là :-)" class="smiley Lancez donc votre navigateur sur votre sous domaine, et voyez si ça fonctionne !

En cas de problèmes :

  • si c'est SELinux qui bloque, les erreurs vous seront signalées dans /var/log/messages ou /var/log/audit/audit.log,
  • s'il s'agit de problèmes de droits ; vous n'obtiendrez pas d'erreurs dans les logs, juste un 404 dans le navigateur. Assurez vous que le groupe ait le droit de lire les fichier et dossiers, et de traverser les dossiers,
  • tout semble correct, et pourtant, votre dépôt n'apparaît pas ? Vérifiez que vous avez bien ajouté les droits en lecture sur le dépôt pour l'utilisateur gitweb dans la configuration de gitolite.

cgit

Cgit est est une application CGI écrite en C, un peu comme gitweb. Pour l'installer :

$ sudo 'yum install cgit'

La configuration de cgit passe par le fichier /etc/cgitrc. Il suffira d'ajouter les lignes suivantes à ce fichier :

enable-gitweb-owner=1
project-list=/var/lib/gitolite/projects.list
scan-path=/var/lib/gitolite/repositories/

Ensuite, nous configurerons notre hôte virtuel apache pour utiliser cgit :

# git repositories
<VirtualHost *:80>
        ServerName git.domain.com

        # Logs :
        ErrorLog /var/log/httpd/git_error_log
        CustomLog /var/log/httpd/git_access_log combined

        Alias /cgit-data /usr/share/cgit
        ScriptAlias /cgit /var/www/cgi-bin/cgit

        RewriteEngine on
        RewriteCond %{REQUEST_URI} !^/cgit
        RewriteRule (.*) http://git.domain.com/cgit$1 [P]

        <Location />
                Options FollowSymLinks

                # Limitation commits
                <Limit POST PUT>
                        Require valid-user
                </Limit>
        </Location>
</VirtualHost>

Vous aurez ainsi accès à l'interface cgit depuis l'URL http://git.domaine.com ; et pourrez cloner un dépôt en utilisant le protocole HTTP :

$ git clone http://git.domaine.com/mailletest.git

Vous pouvez afficher automatiquement les différents URL de clonage de vos dépôts via cgit, en renseignant dans le fichier de configuration :

clone-prefix=http://git.domain.com ssh://gitolite@git.domain.com

gitweb

Gitweb est aussi une application CGI. Pour l'installer :

$ sudo 'yum install gitweb'

Créons ensuite notre hôte virtuel dans le fichier /etc/httpd/conf.d/git.mondomaine.com.conf avec le contenu suivant :

# git repositories
<VirtualHost *:80>
        ServerName git.mondomaine.com
        DocumentRoot /var/www/git/

        # Logs :
        ErrorLog /var/log/httpd/git_error_log
        CustomLog /var/log/httpd/git_access_log combined

        <Directory /var/www/git>
                DirectoryIndex gitweb.cgi
                Options ExecCGI FollowSymLinks

                ## Controls who can get stuff from this server.
                Order allow,deny
                Allow from all

                <Files gitweb.cgi>
                        SetHandler cgi-script
                </Files>

                # Limit commits
                <Limit POST PUT>
                        Require valid-user
                </Limit>

                # Redirections
                RewriteEngine on
                RewriteRule ^$ gitweb.cgi [L]
                RewriteCond %{REQUEST_FILENAME} !-f
                RewriteCond %{REQUEST_FILENAME} !-d

                RewriteRule (.*) /gitweb.cgi/$1 [QSA,L]
        </Directory>
</VirtualHost>

Le fichier de configuration principal de GitWeb se trouve à /etc/gitweb.conf. Pour notre configuration, il faut simplement configurer deux choses : le fichier qui liste les projets, et le dossier contenant les différents dépôts. On ajoutera donc au fichier gitweb.conf les lignes suivantes :

$projects_list = "/var/lib/gitolite/projects.list";
$projectroot = "/var/lib/gitolite/repositories/";
Clonage via http

Le clone d'un dépôt en utilisant le protocole HTTP n'est pas natif avec la configuration mise en place. D'abord, nous allons ajouter sur la pages des différents projets l'URL de clonage. Ajoutez la ligne suivante dans le fichier /etc/gitweb.conf

@git_base_url_list = qw(http://git.mydomain.com)

Normalement, il suffit d'ajouter une règle de ré-écriture semblable à celle-ci pour que le clonage avec une adresse du type http://git.domain.com/mailletest.git soit opérationnel :

RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ gitweb.cgi%{REQUEST_URI}  [L,PT]

Je ne suis cependant pas encore parvenu à faire fonctionner ceci :'(

gitweb-caching

giweb-caching fournit les mêmes fonctionnalités que gitweb, mais avec le support du cache en sus. Pour l'installer :

$ sudo 'yum install gitweb-caching'

Pour l'activer il suffira de remplacer les deux occurrences /var/www/git par /var/www/gitweb-caching dans le fichier de configuration de l'hôte virtuel apache.

Le script CGI installé par défaut ne possède pas le contexte SELinux adéquat pour fonctionner, il faudra le modifier :

# semanage fcontext -a -t httpd_git_script_exec_t '/var/www/gitweb-caching/gitweb.cgi'
# restorecon -v /var/www/gitweb-caching/gitweb.cgi

Et c'est tout ! :-)" class="smiley

Notez que les remarques concernant le clonage de dépôts par HTTP sont également valables pour gitweb-caching :'(

libmemcached-0.52

Remi Collet

Le RPM de la nouvelle version 0.52 de la biliothèque libmemcached de communication avec le serveur memcached est disponible dans le dépôt remi pour Fedora et Enterprise Linux. Il est aussi dans le dépôt rawhide.

Comme toujours : yum --enablerepo=remi install libmemcached Cette bibliothèque est nécessaire à l'extension PECL memcached, (une nouvelle alternative à memcache) en plein développement. Cette mise à jour cassant l'ABI avec la version 0.49, je ne prévois pas de MAJ dans les dépôts fedora ≤ 16. Donc : fedora 14 : version 0.43, libmemcached.so.5... Lire libmemcached-0.52

Page générée le 20 déc 2014 à 12:49