Red Hat Bugzilla – Bug 11224
Problems running cvs as 'root'
Last modified: 2008-05-01 11:37:55 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
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.