Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
I don't have all the answers, but I'll offer what I can... Thomas Keller wrote: > Hello there! > > I'm currently trying to move over our old cvs repo to cvsnt. > I installed the RH9 2.0.58d rpm from cvsnt.org and are now puzzled > with some problems: > > First thing: The only connection method which is allowed should be > :ext:, so I disabled the pserver in xinetd. Is there any way to enable/ > disable other compiled-in methods explicitely through some config file? > What other connection method could be used e.g. for windows users, is > :sspi: possible on Linux? "pserver" is the name of the server component for CVSNT. Like CVSROOT, it has multiple meanings. You want to remove the unwanted *_protocol files from /usr/local/lib/cvsnt/ to disable a particular protocol (there might be a config option when building manually, not sure, but this works). SSPI is only client side on Linux. You can use PAM with winbind (sorry, never tried it myself so I don't have any details) to authenticate against a Win DC. > > Secondly, I created two user groups: cvsadmins and cvsusers. In my > thoughts all normal modules should be owned by cvsusers, cvsadmins > would only own the CVSROOT dir (history, val-tags and EmptyDir would be > owned by cvsusers, too, since they need to be writable). Then I set the > permissions for each file/ directory that way that single users as well > as group users had read/write access to the specific file/ dir via chmod > 775/664. I did some test commits under various logins and noticed that > the dir and file permissions I set are ignored by cvs. Each file which > is committed gets 444 permissions, obviously I already "hacked" an alias > in /etc/profile > > alias cvs="umask 002;cvs" > > which should make cvs create new files with group-read-write > permissions. Now, its not too bad that commits from other users do not > fail even if the file is not group-writable, but its a problem for the > CVSROOT-directory where really *only* admins should be able to commit > changes. I did a different approach with my repository, but I am *not* a linux security expert and this is a hobby server -- but hopefully it can help. All users (admin and regular) are in CVSUsers group. Group sticky tag is set on all repository directories to keep permissions straight (I don't know what the umask is set to, but it works). Then I set up an admins file. I also apply CVS ACL with chacl command to prevent non-admins from committing to the CVSROOT. I use SSH with mine (aka EXT by typical use) and each user has a login acct on my Linux box. The caveat to this approach is that the users then have (via SSH) physical access to the directory structure, and I don't know enough to work around that -- I assume there is a way but I can afford to be selective about who I let onto my box. > > I know that there are access control ways via passwd and group, but > since the users connect via ssh which needs a valid Linux user account > I thought of minimizing the administrative overhead (I have to move > about 15 repositories, each contains commit and loginfo scripts) and not > add users into cvs via `cvs passwd`. > I don't even know if the build-in access control thing (via readers, > writers, admin and group file) works at all when > not using :pserver: - you can correct me on this point. Those files all works the same regardless of the protocol used AFAIK. > > What is a good way to go? I just need *detailed* help... > > Thank you guys in advance. > -- Glen Starrett