On Tue, Aug 08, 2000 at 03:52:08PM +0200, Patrice PILLOT wrote: > Mais �a ne r�pond toujours pas compl�tement au monsieur qui cherche > aussi � savoir 1) quels sont les probl�mes de s�curit� (je crois > savoir qu'il y a un projet du nom de cvs-nserver ou quelque chose > comme �a qui vise � s�curiser la b�te)
Si on utilise uniquement pserver, le mot de passe passe en clair, donc il faut au moins redefinir un mot de passe pour le pserver dans le fichier CVSROOT/passwd pour ne pas se faire pirater le passwd d'un compte... cf. la doc a ce sujet (l'info-file aussi, au fait...) On peut aussi passer par un tunnel SSH et utiliser la methode :server: (avec $CVS_RSH=ssh) normale et non pas :pserver:, du coup c'est crypte, plus de probleme avec le nombre limite de repositories sous cvspserver (cf. ci-dessous) Mais on ne beneficie plus du masquage des comptes, (avec passwd), la chqaue acces se fait necessairement avec un vrai compte. > et 2) quelle "politique" (policy > :) adopter (un ou plusieurs d�p�t (repository), quand doit-on vraiment > greffer une branche, etc.). Un ou plusieurs depots c'est de l'admin: sous pserver un bug empeche d'en creer a foison (cf. bugreport), environ 4 selon la longueur des chemins des racines des depots. Sauf bien sur a mettre a la main des entrees ad hoc dans /etc/services, avec cvspserver1 sur le port habituel, cvspserver2 sur un autre port, etc. Mais c'est un peu chiant... Donc, si on ne veut pas s'embeter, on fait un depot accessible via pserver avec un sous-repertoire par projet et/ou par personne, il faut alors juste gerer les droits comme il faut (L/E, groupes). Greffer une branche, c'est un probleme de politique de developpement et de genie logiciel, pas d'admin, donc fu2 les newsgroups dedies... > Le premier point n'est que mod�r�ment trait� dans la doc quand au > deuxi�me il r�clame du "v�cu" (la doc est plus diserte > mais... disons... absconse). > > Il me semble donc que le d�bat n'est pas clos :) Mes 2 cents. -- Samuel Landau Doctorant LIP6 - �quipe MIRIAD (SMA - IAD)
