[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How do I manage our enterprise CVS w/o being root?

From: Eric Siegerman
Subject: Re: How do I manage our enterprise CVS w/o being root?
Date: Fri, 30 Aug 2002 19:30:06 -0400
User-agent: Mutt/1.2.5i

On Fri, Aug 30, 2002 at 04:52:19PM -0500, Doug Poland wrote:
> Dennis Coonich said:
> > How do I manage our enterprise CVS w/o being root?
> > Are there best practices?
> >
> Create a new group called cvs
> Add yourself to that group
> chgrp -R cvs /usr/local/cvs  # or where ever your cvs root is
> make sure files and directories are writable by the new group

Also, on a System-V-like server, you have to
    find /usr/local/cvs -type d | xargs chmod g+s       # or wherever
to make the "cvs" group membership that you just applied
propagate to newly created files and directories.  On BSDish
systems, this step is not required, since they get it right
by default.

There are a few things that might need to be done as root,
depending on your site and your preferences.  But these are all
to do with initial setup; ongoing CVS administration should
rarely if ever require root access, as long as you get the
permissions correct up front, as Doug describes.

It's up to you and your sysadmin to resolve each of these, either
by picking a variant that doesn't require root or by having them
do the privileged work:

  - Installing CVS itself, depending on the permissions on
    /usr/local or wherever you want to put it.  Alternative:
    install it somewhere you *do* have permission, and make sure
    that directory is in everyone's path.  But it's a standard
    GNU "configure; make; make install", so they shouldn't give
    you too much grief about installing it in /usr/local for you.

    N.B.: CVS does NOT intrinsically need root privilege, except
    for "pserver" (see below).

  - Creating the repository:  The sysadmin has to do at least
    some of the stuff Doug and I described above.  Depending on
    where the repo is to live, perhaps they have to do all of it.
    Once they've created the repository's root directory, and set
    its owner, group and mode to something that allows you and
    your team members to write to it, you can take over -- "cvs
    init" and the rest.

  - Setting up client/server access.  There are a number of
    mechanisms that CVS can use.  The ones I know anything about
    require root privilege to set up, if they're not already:
      - pserver method:  You have to add an entry to inetd.conf,
        and maybe some other stuff.  But most people strongly
        recommend against "pserver" anyway, for security reasons
        (see its documentation for details); if your sysadmin
        doesn't want to give you the root password, he probably
        doesn't want to allow CVS "pserver" anywhere near his
        machines :-)
      - ext method, via rsh:  If this is enabled, it does NOT
        require root access to start using it for CVS.  But it
        may well be disabled for security reasons.

      - ext method, via ssh:  Requires root to install, but you
        may well have it installed already.  Judging by what
        people say here, this is the preferred client/server
        method, security-wise.

      - local (non-client/server) access never requires root for
        anything, but may not be sufficient for your needs.

    Do NOT be tempted to get around these client/server issues
      - remote-mounting working directories from one platform to
        another (e.g. UNIX to Windows), since this leads to all
        sorts of problems with the line-endings of files (search
        the list archives; it gets discussed here ad nauseam).

      - remote-mounting the repository itself to the client
        machines, EVER.  This has been known to lead to file
        corruption in the repository.  Not a risk one wants to
        take with one's source-control system!


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
[...] despite reports to the contrary, it is the rare programmer who
permanently loses his sanity while coding ("permanently" being the
operative word).
        - Eric E. Allen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]