Thanks Arthur for explaining in depth. LDAP is not yet working . Security is not that big crisis as of now. Feels i should try for CVSNT . Our cvs repo is in linux whereas developers works on windows env using cvs client as Eclipse & Tortoise.
Creating users on linux everytime is a bizarre all time all i infer from ur conversation that we can go for pserver as of now with keeping other advanced level traversed atleast would save creating m/c users & they logging to m/c with it. thanks once again. On Wed, Mar 2, 2011 at 3:56 PM, Arthur Barrett < [email protected]> wrote: > > > cvs users not m/c users.Its working fine also. But many says > > pserver is not better choice as its not very secure. Can > > anyone help me in understand what is the best cvs protocol used > > now-a-days. > > > > It depends on your security requirements. If it is all on an internal > LAN (or encrypted VPN) then maybe you don't care about the trivial > encryption of passwords in pserver, but maybe you do. Note: pserver > also usually stores the password on the client with trivial encoding > (though it appears as though you are using Eclipse as the client which > even stores ssh passwords on the client by default I think). > > I personally prefer CVSNT (yes it runs on Linux and works with Eclipse) > since it has ACL's without the need to patch the sources and has a wider > choice of protocols (eg: sserver, a secure version of pserver). I also > recommend using CVSNT on windows clients with Eclipse since you can use > the extnt.ini file to 'redirect' the Eclipse protocol from pserver to > sserver and also use the cvsagent which stores one time passwords in > memory not on the disk. > > I'm surprised you are needing to create logins for each user - these > days most organisations with more than 3 people have some user directory > (eg: LDAP or Active Directory) which every PC uses to authenticate > users. Your server should be able to authenticate the SSH or PSERVER > users via that same database (eg: using PAM) and you should be able to > set up ACLs on the repository modules based on standard groups (also in > LDAP or AD). > > Anyway - it really boils down to what your security requirements are, > not what options are available. > > Regards, > > > Arthur Barrett > > > > >
