Re: cvs admin command, potential problems

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bret <address@hidden> writes:

> Our CVS admin quit, and the admin duties were turned over to me.  I've
> used CVS as a normal user, but never as an admin.  First, here's my
> environment:

It is also a good idea to run the

    'cvs version'

command for reports like this.

> CVS is running on Solaris, 

Which version of Solaris? (The command: 'uname -a' provides this)

> the usernames are _not_ tied to the Unix login.

So, you are using the :pserver: access method?

> I don't have root access to the Solaris machine.

Fine, but you do have normal shell access to it?

> I am accessing CVS from a WinXP machine, using the command line
> program from cvshome.org.

Read:
  https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_2.html#SEC31

> The issue:
> I was told to add a new user, which I didn't know the process.  After
> using cvs --help and cvs -H admin, I tried this command from the root
> of the project:
> cvs admin -a username

I suggest you use

  cvs admin -e username

to undo your change.

> 
> The result was that every file in the project got a new time/date
> stamp, and the user was still unable to get into cvs.  

You will probably never want to use the RCS 'access' methods with CVS.

In fact, in general, use of the 'cvs admin' command is to do something
to the RCS files in your repository that is NOT the standard way to do
business. It is very simple using 'cvs admin' to make a lot of problems
for yourself and your users. You really do NOT want to use it unless you
know exactly what you are doing any why it needs the admin command
instead of being done via the 'normal' cvs commands.


> I eventually found an addcvspasswd.pl file in the CVSROOT directory of
> the repository root, and got the user added - so I thought everything
> was ok. Problem then was that the user could not update files.

Is the user able to checkout files at all? Problems doing an update of
existing files could be do to permission problems in the checked out
tree. Without the exact text of error messages, helping you is
difficult.

> Also, the ownership (user/group) of all files are cvsuser/other.  The
> Solaris admin recursively changed the group to "cvs" (which is the
> primary group of cvsuser)on all files and my new user can now update
> them.  But anytime something is updated, the group changes to "other".

That means that the 'root' user doing the update running out of
inetd.conf is in group 1 which is okay.

Ask your Solaris admin to use the sticky-bit on the directories in your
repository.

        chgrp -R cvs $CVSROOT
        find $CVSROOT -type d -exec chmod g+s {} \;

this tells solaris that new files created in the repository should all
inherit the group of the parent directory instead of the default group
for the user process.

> I know nothing about the "other" group, and neither does the Solaris
> admin.

The default /etc/group "other" is gid 1 on Solaris 8 and 9 boxes. It is
usually considered to be an administrative group and should probably not
be what you are using for cvs files.

> I guess my questions are:  what exactly did I do to the repository when
> I ran that cvs admin command?  

You altered the RCS 'access' section of the files in your CVS
repository. This is not usually a useful thing to do.

> Is that why I'm seeing this "other" group, or is the "other" group a
> normal occurance? 

It should be unrelated

> What can I do to back out the changes made by that admin command if
> they were detrimental to my repository?

'cvs admin -e username' is the inverse command of 'cvs admin -a username'
and you should probably use it... if you can.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBud0k3x41pRYZE/gRAs65AKDJ5eu1Pj4JfLkzECA0Zx7N5+9HfACgvpVv
5qjFN7zGD6Y5eiTIC55wnQM=
=JLqp
-----END PGP SIGNATURE-----