Hébergement de plusieurs référentiels (svn, hg, git)


8

J'ai récemment acquis un serveur dédié et je dois y déplacer plusieurs référentiels à partir d'un service d'hébergement de contrôle de source. N'ayant pas beaucoup d'expérience dans l'administration de serveurs, je ne sais pas comment l'organiser efficacement. Ce que je recherche -

  1. sous-domaines svn.host.com, hg.host.com, git.host.com qui seront les racines des différents dépôts, via les clés SSH
  2. création facile de nouveaux référentiels
  3. authentification à l'aide de la liste d'utilisateurs unix du serveur, mais avec des autorisations par projet, également accès public en lecture seule facultatif pour certains des référentiels

Malheureusement, tous les termes de recherche que j'essaie sur Google me dirigent vers des solutions hébergées commerciales, et non vers des guides sur la façon de créer les miennes. J'ai besoin de quelque chose comme une solution hébergée simplifiée mais sans avoir besoin que les utilisateurs puissent créer leurs propres référentiels.

Des suggestions, des tutoriels ou des solutions scriptées sur où commencer la recherche? Une solution open source pour une interface administrative pour gérer cela (ou du moins pour certains serait parfait ...

Réponses:


6

Je n'utilise que Git, donc j'essaierai au moins de vous aider avec ça:

Si vous ne voyez aucun problème à administrer vos dépôts via la ligne de commande, gitosis devrait très bien faire l'affaire.

Si vous avez vraiment besoin d'une interface Web, vous pouvez consulter repo.or.cz ( http://repo.or.cz/w/girocco.git ) ou gitorious ( http://gitorious.org/gitorious ) . Repo.or.cz est plus laid, mais il est beaucoup plus facile à installer (gitorious est open-source, mais c'est aussi le logiciel qui alimente gitorious.org - ils n'ont pas beaucoup d'incitation à écrire de belles instructions)

Voici une liste d'options plus complète: https://git.wiki.kernel.org/index.php/GitHosting

N'importe laquelle de ces options vous permettra de créer facilement de nouveaux référentiels.

Maintenant, un mot d'avertissement: vous ne devriez jamais, JAMAIS, utiliser la liste des utilisateurs du serveur Unix pour les autorisations du référentiel. Il est assez facile de jouer avec, et les résultats sont facilement catastrophiques (la gitose utilise une configuration de fichier simple et des clés ssh. Devrait faire l'affaire pour vous).

Autre chose, je ne vois pas pourquoi vous avez besoin d'avoir des référentiels subversion, HG et Git. La plupart des projets n'utilisent qu'une de ces options. Vous voulez expliquer pourquoi?


J'ai plusieurs projets, détenus dans plusieurs référentiels. De nombreux commiters ne sont pas particulièrement technophiles et donc hg et git seraient un problème pour eux, donc je garde svn pour les projets les plus ouverts. Personnellement, j'utilise HG comme SCM de mon choix. J'ai également invité quelques projets pour mes amis et certains d'entre eux utilisent git comme SCM de leur choix. Pas moyen de plaire à tout le monde comme il semble :)
Kornel Kisielewicz

1
Pourriez-vous également nous expliquer davantage les dangers de l'utilisation de la liste d'utilisateurs Unix pour les autorisations de mise en pension?
Kornel Kisielewicz

3
Pourquoi utiliser la liste d'utilisateurs Unix pour les référentiels est une mauvaise chose: perte de granularité, perte de portabilité. Si vous devez changer le référentiel sur un autre serveur, vous devrez déplacer la liste complète des utilisateurs Unix. Si vous souhaitez déléguer des autorisations d'administrateur, vous devez donner des autorisations root. Maintenant, sur gitosis, si vous voulez changer de serveur, il vous suffit de cloner le dépôt. Si vous souhaitez déléguer des autorisations d'administrateur, il vous suffit d'ajouter l'utilisateur au groupe gitosis-admin.
Tiago Fassoni

just_testing, convenu, points valides :)
Kornel Kisielewicz

2

SVN peut être fait avec Apache WebDAV, dans un vhost, en utilisant l'authentification Unix et les propres ACL de subversion au niveau utilisateur. Je ne sais rien de mercurial ou de git, mais j'espère qu'ils pourraient également être connectés à DAV.


1

Lorsque vous souhaitez utiliser SSH , vous devez essentiellement restreindre les clés en modifiant le authorized_keysfichier sur le serveur. Pour Mercurial, les principaux moyens d'y parvenir sont les suivants:

  • Vous pouvez utiliser le contrib/hg-sshscript pour restreindre les commandes que les gens peuvent exécuter lorsqu'ils sont connectés avec SSH. Le fichier contient un en-tête pour expliquer comment l'utiliser, mais vous ajoutez essentiellement

    $ command="hg-ssh path/to/repo"
    

    devant la clé du authorized_keysfichier. Cela restreint la clé afin qu'elle ne puisse être utilisée que pour pousser et tirer vers le référentiel indiqué.

  • Vous pouvez également utiliser l' outil serveur mercurial tiers si vous voulez quelque chose comme gitois . Cela vous permet de gérer les utilisateurs et leurs droits d'accès en modifiant les fichiers dans un référentiel administrateur spécial.

Voir le wiki Mercurial pour d'autres outils similaires pour SSH.

Pour HTTP , il existe

  • Le hgwebscript CGI ou WSGI intégré (rapide) fourni avec Mercurial. Cela gère les push et pulls, mais ne permet pas la création de nouveaux référentiels - connectez-vous au serveur pour cela.

  • Le projet tiers RhodeCode . Cela vous donne un frontal Web de type Bitbucket pour Mercurial où vous pouvez configurer les utilisateurs et leurs droits d'accès. Il prend en charge l'authentification LDAP, vous pouvez donc le connecter à votre base de données utilisateur Unix existante.

Consultez la page sur la publication de référentiels pour plus d'informations.


1

SCM-Manager peut être parfait pour vos besoins:

Le moyen le plus simple de partager et de gérer vos référentiels Git, Mercurial et Subversion via http.

  • Installation très simple
  • Pas besoin de pirater les fichiers de configuration, SCM-Manager est entièrement configurable depuis son interface Web
  • Aucun Apache et aucune installation de base de données n'est requis
  • Gestion centralisée des utilisateurs, des groupes et des autorisations
  • Prise en charge de Git, Mercurial et Subversion
  • API de service Web RESTFul complète (JSON et XML)
  • Interface utilisateur riche
  • API de plugin simple
  • Plugins utiles disponibles (par exemple Ldap-, ActiveDirectory-, PAM-Authentication)

0

RhodeCode est un navigateur / outil de gestion de référentiel open source avec un serveur push / pull intégré, LDAP / AD, un système d'autorisations et une recherche en texte intégral.

Vous pouvez le voir en direct ici: http://demo.rhodecode.org/

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.