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.
Dianne Chen wrote: >>So PServer configuration must be done, but it is not >>the same as :pserver: . Ok. It's good to know the >>history of that. Note that you can disable the pserver protocol by deleting the pserver_protocol.so file in the cvsnt install directory. /usr/local/lib/cvsnt/pserver_protocol.so (at least that works under Windows -- CVSNT is set up to see the file is not there, then fail it gracefully). >> >>For wiki section 1.4.1 the actual /etc/xinetd.d/cvs >>file looks like this, which does not look like the >>example in the wiki. I'll assume that the wiki is >>out >>of date (i.e., no longer need a reference to group, >>log_type, and env)? Correct? I'm not sure about those options or what they default to (it's entirely possible that they default to the differences). It's probably just fine. >>Regarding section 1.7 then, I'll wait for additional >>Linux-savy users to respond, but I'm guessing groups >>need to be added like: >> cvsuser >> cvsadmin >> >>and then the group for the repository would be, um, >>cvsuser, and an owner specified (cvsuser who belongs >>to group cvsuser?). Right? With my setup the owner is the last person who modified that file, but it's the group that's important (thus the sticky bit on it). You can control commit authority with the CVS ACL system. For example: cvs chacl -u adminuser -a read,write,create,tag,control cvs chacl -a read,nowrite,nocreate,notag,nocontrol ...to prevent everyone but adminuser from writing to those. Tony -- In case you're reading this far, is there a shortcut way to 'deny all' or what is the best way to secure CVSROOT from regular users? noread? Then use an admins file directly in the CVSROOT on the repository (not under source control, see the wiki docs) to control who has admin command authority. Regards, -- Glen Starrett