Bug 11224 - Problems running cvs as 'root'
Problems running cvs as 'root'
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: cvs (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-04 14:22 EDT by Matt Hamilton
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-05 14:48:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Hamilton 2000-05-04 14:22:13 EDT
If this problem is due to my lack of experience using cvs, I'll be glad to
have someone point that out to me.

History/setup: I have a fresh clean install of RedHat 6.2.  I would like
to preserve everything in and under my /etc directory.  So, when I logged
in for the first time as root, I setup cvs:

export CVSROOT=/home/cvsroot
export EDITOR=/bin/vi
mkdir -p $CVSROOT
chmod ug=rwx,o=rx,g+s $CVSROOT
cvs init
cd /etc
cvs import -m "RedHat 6.2 install" etc v6_2 r1_0

That completed successfully, so I went for the checkout:
cd /
cvs checkout etc

It checked out the files in the /etc directory itself, but as the status
messages were scrolling by, I saw a bunch of '?' next to directory names
under /etc.  Next, to verify the checkout went recursive, I did:
find /etc -name "CVS"
and confirmed that only files in /etc were checked out; none of the
subdirectories were checked out.  This is problem #1.  Also, if I try cvs
release to "undo" the checkout since it didn't work very well for me, it
shows the directories with '?' next to them again and says "unable to
release".

Problem #2: I edited /etc/profile to include the CVSROOT and EDITOR
environment variables, then ran cvs diff to confirm all the changes I had
made -- this worked correctly.  However, when I tried:
cd /etc
cvs commit
I received an error message: "cvs [commit aborted]: cannot commit files
as 'root'".  I then tried creating a new user, then using su - newuser,
but then I had some understandable permission problems in the /etc
directory.

What am I doing wrong?

Thanks,
Matt
Comment 1 Jeff Johnson 2000-05-05 14:48:59 EDT
If you wish to preserve /etc with CVS, do the following (rather than importing)

0) Make sure that you have a repository at CVSROOT (as you have done) and do
	cd $CVSROOT
	mkdir <your_hostname_here>	# <-- put your hostname there

1) Create a top level CVS admin directory:
	cd /
	mkdir CVS
	touch CVS/Entries
	echo <your_hostname_here> > CVS/Repository
	echo $CVSROOT > CVS/Root
1.1) Verify that everything is copacetic by doing
	cd /
	cvs -n updat -l
and you should see a lot of '? bin' etc messages

2) Add /etc to the repository
	cd /
	cvs add etc
You should see /etc/CVS/* populated, and etc mentioned in /CVS/Entries*

3) Choose the files you want to track, and populate. For example, if you
wanted to track inetd.conf, you would do
	cd /etc
	cvs add inetd.conf
	cvs ci inetd.conf

3.1 Verify by doing
	cd /etc
	cvs diff inetd.conf		# <-- try changing a byte
and/or doing
	cd /var/tmp
	cvs get <your hostname here>
	cd <your hostname here>/etc
	cvs diff inetd.conf

4) Get rid of output from files the you don't wish to track. For example, if you
don't want to track /etc/foo, you would do
	cd /etc
	echo foo > .cvsignore
	cvs add .cvsignore
	cvs ci .cvsignore
Iterate with all files that you do not wish to track.

5) CHECK THE PERMISSIONS! When doing cvs checkouts, its *REAL* easy to end
up accidently changing permissions on a critical file. I usually "fix" this
by writing a short shell script (called .cvsfix) that sets the permissions,
something like
	#!/bin/sh
	chmod 644 inetd.conf
	chown root.root inetd.conf
added to the repository as
	cd /etc
	<create .cvsfix with contents above>
	cvs add .cvsfix
	chmod +x .cvsfix
	cvs ci .cvsfix
You can test the script by doing
	cd /etc
	./.cvsfix
You probably should diddle the script to be independent of the "cd /etc" and
you should *not* use absolute paths in the script because you might be
working with a checkout in a different directory.

6) Symlinks are a pain. You have three choices
  a) (dumb and dirty) check in the contents of each symlink (thereby making
   it a separate file).
  b) (ok but a little hard to manage) recreate symlinks as in 5) by adding
   lines to .cvsfix
  c) (hard but possibly elegant) figure out how to have cvs check in symlinks
    asd symlinks (this is possible but I've never done it).

As for the error "cannot commit files as root", you have two choices:
  a) (easy) Rebuild from the src.rpm and enable the ability to check in as root.
  b) (hard) Design a security scheme using membership in system groups that
      permits you to do "chmod g+w /etc". If you don't understand the
      ramifications of adding group write permissions to /etc, go *DIRECTLY*
      to a)

Hope this helps.

Note You need to log in before you can comment on or make changes to this bug.