Discussion:
Which cvs protocol better ?pserver/extssh??
Kapila Kohli
2011-03-01 13:50:14 UTC
Permalink
Hi,
My team is currently using cvs protocol as extssh. Its working fine
except one big issue - i have to create userid on the cvs repo m/c for every
a/c.
Due to which users can login to my cvs repo using its cvs id(thou read) +
there are so many ssh connections get formed on m/c (as team is working on
cvs repo).
like

$>ps -ef | grep ssh
$>sshd: *cvsuser-id*@notty

Hence thought of moving to pserver with which i will have to create pserver
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.

*CVS version-*

Concurrent Versions System (CVS) 1.11.22 (client/server)
with CVSACL Patch 1.2.5 (cvsacl.sourceforge.net)
Arthur Barrett
2011-03-02 10:26:45 UTC
Permalink
Post by Kapila Kohli
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
Kapila Kohli
2011-03-04 07:58:26 UTC
Permalink
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 <
Post by Arthur Barrett
Post by Kapila Kohli
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
Gary Funck
2011-03-05 20:27:46 UTC
Permalink
Post by Kapila Kohli
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.
A few years back, we were faced with a similar issue of how to
easily manage a set of CVS users, but still maintain security
at the external firewall.

To solve the problem, I developed cvspsproxy:
http://intrepid.com/~gary/cvspsproxy/

- Gary
Arthur Barrett
2011-03-08 02:09:09 UTC
Permalink
Kapila Kohli,

TortoiseCVS includes CVSNT (it requires it to be able to run) so it
seems you are already using CVSNT on the client, you'll get a lot more
out of TortoiseCVS with a CVSNT server including merge tracking, user
defined change sets, atomic commit id's, access control lists etc etc.

What is your LDAP problem - something internal to your organisation or
do you mean that LDAP is nor working with CVS at your site due to bugs?


What LDAP server are you using? I have limited experience settings up
LDAP authentication on Linux servers, but when I've done it (from Red
Hat Enterprise Linux to Active Direcrtory) it seemed quite
straightfoward and well documented by Red Hat and then getting LDAP/AD
to work with CVSNT was just a couple of commands...

Regards,


Arthur Barrett


-----Original Message-----
From: Kapila Kohli [mailto:***@gmail.com]
Sent: Friday, 4 March 2011 6:58 PM
To: Arthur Barrett
Cc: info-***@nongnu.org
Subject: Re: Which cvs protocol better ?pserver/extssh??


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
Post by Kapila Kohli
cvs users not m/c users.Its working fine also. But
many says
Post by Kapila Kohli
pserver is not better choice as its not very secure.
Can
Post by Kapila Kohli
anyone help me in understand what is the best cvs
protocol used
Post by Kapila Kohli
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
Pradeep Sharma
2011-03-08 06:01:27 UTC
Permalink
We are using cvs default-built in RHEL5 i.e. 1.11.22 to hold our CVS
repositories.

How the migration will happen from CVS to CVSNT - the technicalities, the
problems
the troubles etc.? How should we go for this? Are the utility scripts
available readily,
for common tasks?
Michael Haggerty
2011-03-08 08:20:28 UTC
Permalink
Post by Pradeep Sharma
How the migration will happen from CVS to CVSNT - the technicalities, the
problems the troubles etc.?
The main trouble is that CVSNT is a closed solution. You will find less
support for it in the community (unless you pay the vendor) and less
support from the free tools. For example, the open-source cvs2svn
migration tool that I work on can easily migrate content from CVS to
Subversion, git, Mercurial, or Bazaar, but it does not support all of
the peculiarities of CVSNT. So before you put your precious data in
CVSNT, consider: what if you ever want to get it back out again?

If you are trying to get past some of CVS's shortcomings, there are many
truly free alternatives to CVS with much better community support, no
vendor lock-in, and an easy migration path from CVS.

If you nevertheless decide to migrate to CVSNT, you should direct your
questions to the company developing CVSNT. This mailing list is for
discussions of CVS, not CVSNT (though, admittedly, Arthur Barrett's
frequent inappropriate use of this mailing list to promote CVSNT can
sometimes be confusing).

Michael
--
Michael Haggerty
***@alum.mit.edu
http://softwareswirl.blogspot.com/
Arthur Barrett
2011-03-08 22:48:52 UTC
Permalink
Pradeep/Michael,

CVSNT is NoT CVS - please direct questions about CVSNT to the authors.
The guide included with CVSNT gives plenty of contact information.

The migration is extremely straightforward (usually just a drop in
replacement will do, any conversions necessary happen on the fly, but in
your case you will need to use 'cvs chacl' to create the ACL's in a
format that CVSNT understands).

Since Michael has publicly listed a bunch of criticisms of CVSNT I
assert that I have the right to also reply publicly, though since this
is now well and truly off topic I will not be replying publicly further
to this thread.
Post by Michael Haggerty
The main trouble is that CVSNT is a closed solution.
CVSNT is free, open source software, we publish the source code. CVSNT
uses open protocols to communicate between client and server. I cannot
find anywhere a definition of 'closed solution' that fits, but if
Michael can supply a reference to one I'll happily read it. Definition
of free software:
http://www.gnu.org/philosophy/free-sw.html

In the very latest preview edition we do keep 5% of the non-core
non-business-process code proprietary to assist particular customers
resolve some legal problems that prevented them contributing under the
old model (eg: the sources to cvsmanager, bugzilla_trigger and
workspacemanager). Customers who cannot use this new model can choose
other stable and supported releases that will still offer that have 100%
open source CVSNT (eg: CVS Suite 2008).
Post by Michael Haggerty
You will find less support for it in the community
There is more than a single community in the world. There is a very
active CVSNT community of thousands of people - but it is not the CVS
one. The members of the CVSNT community are all direct contributors to
the project (either financially through purchasing CVS Suite or through
other contributions), and therefore very committed and active.
Post by Michael Haggerty
So before you put your precious data in
CVSNT, consider: what if you ever want to get it back out again?
CVSNT uses the standard RCS file format to store the version history.
The standard RCS file format can be read by many many tools.

Within the RCS file format there is room to store data in a variety of
ways (eg: diff formats, compressions) and the source code for all of
this in CVSNT is Free and Open Source Software and the CVSNT project
even provide a Free and Open Source RCS distribution (for windows) that
supports all these changes. ClearCase and many other vendors offer
tools to migrate from CVSNT.

Finally: if any customer requests a particular export format I've
previously gone on record as saying I'll happily support that in the
software (under our pay-for-feature terms). To date, not a single
customer has asked for this feature or even requested a quote.
Post by Michael Haggerty
If you are trying to get past some of CVS's shortcomings,
Here you and I disagree. I do not think CVS has shortcomings - it has
design decisions.

Whether those decisions help you or hinder you is a factor of your SCCM
methodology. SCCM is a process, you should design an SCCM process to
support your business objectives, then look for tools to help automate
that process. CVS/SVN has certain features, CVSNT others, Git different
ones, EVS, ClearCase, PVCS, TeamSystem others too.

If the tools Pradeep are using do not support his process then he should
switch tools (or processes).

I believe that Free Open Source Software has more likelihood of being
able to fit your process, because you can infinitely customise it - that
is why I am passionate about Free Open Source Software and CVS (and
CVSNT).
Post by Michael Haggerty
This mailing list is for discussions of CVS, not CVSNT (though,
admittedly, Arthur Barrett's frequent inappropriate use of this
mailing list to promote CVSNT can sometimes be confusing).
I diligintly support the CVS project and give direct answers about CVS,
I am very careful to make my personal preferences clear and distinct
from any discussion about the features and ability of CVS.

In this case I answered Pradeep's question and also mentioned my
preference - this has interested him enough to follow up on. He was in
fact already using CVSNT (on the client) and didn't know it (and
therefore didn't state it).

Changing software systems has a substantial cost associated with it.
Many people who are using CVS are very interested in CVSNT particularly
because it is NOT really chaning the underlying software system:
* it is still free/open soruce software
* it has commercial support
* it is a direct fork from CVS 1.11
* in most cases it is a drop in replacement keeping existing investment
in commitlog scripts etc
* it adds features that often drive a company to a prorietary solution
eg: failsafe audit, change sets, access-control, optional reserved
methodology
* it includes additional secuity support like chroot jail, sserver
protocol
* it contains an integrated suite of tools for windows/mac plus
server/command line support for linux/unix
* it contains integrated active directory authentication/encryption
(sspi) for password-free SSO


I think this is now well and truly off topic and I will not be replying
publicly further to this thread.

Anyone can contact me directly (e-mail address below).

Regards,


Arthur Barrett
Email: ***@march-hare.com
Michael Haggerty
2011-03-09 04:07:45 UTC
Permalink
Post by Arthur Barrett
Post by Michael Haggerty
The main trouble is that CVSNT is a closed solution.
CVSNT is free, open source software, we publish the source code. CVSNT
uses open protocols to communicate between client and server. I cannot
find anywhere a definition of 'closed solution' that fits, but if
Michael can supply a reference to one I'll happily read it. Definition
http://www.gnu.org/philosophy/free-sw.html
I am aware of this, and purposely did not claim that CVSNT is not "free
software" or not "open source software". AFAIK CVSNT abides by the
letter of those definitions. I am referring to the following types of
"closedness", all AFAIK:

* The vendor only makes available the source code of the most recent
version of CVSNT to paid customers.

* CVSNT is not developed in the open, with a publicly available source
code repository or public mailing lists.

In no way do I dispute the right of Arthur's company to develop and
distribute CVSNT in the manner that they have chosen. But it is
important for potential users to understand that the closed nature of
CVSNT development implies certain disadvantages for CVSNT users, in
particular the lack of a vigorous community comparable to those
organized around CVS or other "truly open" software projects and a
resulting poverty of community-contributed tools.
Post by Arthur Barrett
CVSNT uses the standard RCS file format to store the version history.
The standard RCS file format can be read by many many tools.
The RCS file format is analogous to XML, in that it is a very extensible
generic format. CVSNT indeed uses the RCS format, but (1) its "schema"
includes components that are alien to standard RCS or CVS and (2) it
stores some data (e.g., the contents of some binary file revisions)
outside of the RCS-format files.

Michael
--
Michael Haggerty
***@alum.mit.edu
http://softwareswirl.blogspot.com/
Loading...