cvs-nserver-devel Mailing List for CVS with rewritten network layer (Page 9)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Does anyone know the status of the ACL implementation?

What is left?  IMHO the community is in dire need of this feature.

I would be willing to help wrap this up.

-- 
Nick

=F7 =F0=CE=C4, 06.05.2002, =D7 14:44, Wang Jian =CE=C1=D0=C9=D3=C1=CC:
> AM> bottlenecks and so on). So my question is:
> AM> do we need these commands to have an, hmm, XML-like output? If yes,
> AM> what's the DTD? There're pros (we won't need an unique parser for eac=
h
> AM> command) and cons (the server code needs to be more complex, there wi=
ll
> AM> be greater output size and so on) so final decision should be careful=
ly
> AM> discussed.
> I don't think output of XML-like format is good. The pros doesn't buy
> cons.
Well, I'm also not sure that XML is the way to go. But current format of
lsacl makes me feel terrible. Smth definitely should be changed but
don't know how...

Technically speaking a carefully designed and well-defined XML DTD
doesn't give the server too much additional work. / and //
used now as separators will be changed to number of <> " etc...

Probably there's a better solution though... Any suugestions?

> AM> Now I'm going to commit cvs-create-repository and cvs-group
> AM> commands. Alex, where's the best place to put such things?
Well, we have discussed this in ICQ and decided that perl modules will
go to perl, web-interface will go to web/ or www/
and admin tools - to tools/. Tomorrow morning I'll start to commit
things so everyone is welcome to test and improve.
Particularly improvements will be needed for System::Account module
which helps to create system accounts (via call to
appropriate system tools like useradd). Different systems are supported
via in-module database which describes tools names and switches. I added
support for linux/redhat account tools (useradd and groupadd), support
for other system is still missing but hopefully easy to add.

Hello Alexey,

Saturday, May 04, 2002, 10:32:41 PM, you wrote:

AM> Well, yesterday I committed lsmodules subcommand so everyone are welcome
AM> to test it :-). Together w/ ls, lsacl and forthcoming lstags (Alex,
AM> don't shy as you said me a while ago, commit it please :-)) there's a
AM> complete (hopefully) bunch of commands that implements a kind of listing
AM> server (well, Michael, it's not completely 'httpd'-server as you asked
AM> but it's enough to build a remote web-frontend).

AM> I have already implemented a kind of such frontend based in CVS::Remote
AM> perl module and I hope I'll turn it eventually into viable replacement
AM> of the cvsweb and similar programs).

AM> There's an issue I want to discuss though. Current format of ls*
AM> commands are humanly readable and understandable but they can be more,
AM> hmm, formalized or smth (especially lsacl, but ls also has portability
AM> bottlenecks and so on). So my question is:
AM> do we need these commands to have an, hmm, XML-like output? If yes,
AM> what's the DTD? There're pros (we won't need an unique parser for each
AM> command) and cons (the server code needs to be more complex, there will
AM> be greater output size and so on) so final decision should be carefully
AM> discussed.

I don't think output of XML-like format is good. The pros doesn't buy
cons.

AM> Now I'm going to commit cvs-create-repository and cvs-group
AM> commands. Alex, where's the best place to put such things?

AM> A while ago my Novosoft bosses (actually it's Marod :-)) told that would
AM> be fine to have a workaround against one well-known cvs (librcs)
AM> bottleneck: when file processing time dramatically increases when
AM> there're long/complicated commit history. One possible solution for the
AM> problem is to implement (in a separated utility) a kind of purge/merge
AM> operation. This will allow us to remain compatible w/ stock cvs and
AM> solve some of the problems. The question: is there another, more
AM> convenient way? Or we should change the repository format instead and
AM> solve the problem completely?..

-- 
  lark

>>>>> "AD" == Alberto Dainotti <al...@ur...> writes:

 AD> Did you experience heavy performance degradations with ssl pserver
 AD> compared to pserver connections ?  

Whoa!  I didn't do any actual tests for that, but I believe this could be
true. 

 AD> For example it takes a lot of time
 AD> to checkout the cvs-nserver sources..  I've seen that files are
 AD> transferred at about 50kbyte/s instead of 1.2Mbyte/s while both client
 AD> and server cpu's are under 10% ..  Please let me know..

The hideous plan was to write a buffering-client.c which would handle the
buffering of input/output data and I think would greatly help both Zlib
compression performance and SSL performance.   Currently I believe there is
a lot of one-byte reads/writes, and I think they should hurt performance
badly in those cases.

Actually, the buffering-client.c is one of the things that is missing after
the switch from buffer.c thing.

I'll take a look into it.  We need to gather actual statistics about how
the network is handled (probably writing stat-client.c).

--alexm

>>>>> "AD" == Alberto Dainotti <al...@ur...> writes:

 >> > Don't you think it could be useful ?  Probably. Right now we're in
 >> process of creating of some kind of release of NCLI-1-11-1 as stable
 >> branch so Alex is busy on, hmm, bureaucratic tasks, such as updating
 >> docs, making future releases plans e.t.c.

 AD> If you want please tell me how can I help more on development..  For
 AD> example, I've found some errors in INSTALL-nserver but I don't know if
 AD> this file is going to disappear in favour of the admin guide or not..

Yes, it will disappear.  But the errors are still welcome.  Also, the
functionality of 'cvspasswd' utility would be extended to handle more than
one virtual repository, and its description in INSTALL-nserver is somewhat
irrelevant now.

 AD> I didn't know you were working on a release and updating docs, I
 AD> thought I would read it on this mailing list..  

I'll try to announce more of what I'm working on :)  Unfortunately current
situation is such that ongoing activity is mostly discussed in private
mails and IRC chats between me and Alex.

Particularly, that's one of the reasons I'm trying to move towards "making
a release": it would sum up of what was happening for past several months,
and extend the auditory a lot.  I think there is just no information around
that ACLs actually work in cvs-nserver :) 

 AD> I don't know what you are working on.. 

There were three main trends in cvs-nserver development:

- ACL support;

- helper sub-commands to better handle web-based repository
  administration/monitoring tools.  That's commands like 'cvs ls', cvs
  lstags', 'cvs lsmodules', and 'cvs lsacl'. 

- meta-repository support (this is what is going to be implemented in the
  next couple of months);  more details later;  in short: it is needed when
  you have a lot of mostly independeny software projects (like
  SourceForge), but you have a rather strict management of those projects
  (say when you're a commercial body-shop);

 AD> how much/who are the developers..  etc..

Currently Alex Morozov and I are "primary" developers.  There are
occasionally people, including you, throwing in a patch or two, but not
much.

--alexm

>>>>> "AD" == Alberto Dainotti <al...@ur...> writes:

 AD> Hello, I hope to not be annoying :-) 

Ouch!  How could that be? :) 

 AD> In src/ssl-client.c there are two
 AD> printf()'s which instead should use error() (it is annoying when
 AD> redirecting stdout, for example when using cvs rdiff). Attached there
 AD> is a patch.

Yes, applied.  AFAIK, that was just temporary debugging output which should
probably just be dumped (or moved to a SSL policy, because that's an
interesting information sometimes).

 AD> The same was for my proposed patch for self-signed certificates, there
 AD> was a wrong printf() too.  So I attached a new patch with the latest
 AD> corrections.

It is still unapplied :)

--alexm

>>>>> "AD" == Alberto Dainotti <al...@ur...> writes:

 AD> Hello, what about an env variable to allow connections to servers with
 AD> self signed certificates ?  A patch is attached.  Greets, Alberto.

As for the patch itself: I'm unsure currently.

Environment variables are not the way to go, though they are sure extremely
quick and dirty.

I do not remember, has the CVS client reached the point where we should
think about extending the ~/.cvsrc to a more generic configuration
facility, not only for the default command-line options?

If we'd push the issue towards the OpenSSL configuration -- that's fine.
Otherwise, we'd have to think about the more generic configuration.

Oh!  I know, I know!  If we'd introduce some kind of CVS client
configuration, we'd get rid of src/option.h abomination.

--alexm

>>>>> "AD" == Alberto Dainotti <al...@ur...> writes:

 AD> Hello, what about an env variable to allow connections to servers with
 AD> self signed certificates ?  A patch is attached.

Hello,

sorry for a pause with an answer: we had long holidays here, and I was
slightly fscked up for a week, so I blissfully ignored all the activity in
development lists :) (though I've read it all!)

I have meta-question that concerns almost every SSL client :) This question
is also two-fold, with second half concerning CVS SSL client.

As far as I can tell, there are several common situation which should be
handled by any SSL client, and some of them should have some kind of user
option for what to do with them:

- self-signed certificates;

- expired certificates;

- unknown CA; 

- maybe there's more which I don't remember now.

Browsers commonly allow to override decisions for each particular
situation, asking user about what to do with this: cancel or continue
connecting.

I believe that we would have to deal with this somehow earlier or later, so
let's try to preliminarily discuss it.

*** below goes some rough draft on that issue ***

There must be some common extendable facility provinding the
site-level/user-level SSL policy.  Each and every SSL client should consult
this facility and act accordingly. 

This could be done with a couple of configuration files, something like
/etc/ssl-policy.conf and ~/.ssl-policy.conf, containing lines like that:

   self-signed-certificates: allow
   expired-certificates: ask
   unknown-ca: deny

etc.  User-level configuration file could override the site-level
configuration file towards more strictness.

I think there should be some provisions for that in OpenSSL, but quick
glance over /etc/ssl/openssl.cnf didn't uncover any.  Maybe it should be
discussed with OpenSSL folks, cleaned up, and used consistently.

Oh lord I remember how I was subscribed to openssl-dev.  That was pain.
But something should be done about this.

Your thoughts?   I do not think that any short-cuts will suffice. 

--alexm

>>>>> "KW" == Karl Wallner <ext...@km...> writes:

 KW> Hi, i recently found a bug in cvs client (src/client.c) code.

 KW> OS: Linux 2.4.x with openafs 1.2.x

 KW> PROBLEM: The return code of the write call is not checked
 KW> correctly.  This is not problem on local fs, buf on network fs
 KW> (especially afs) it might be.

Hello,

thanks a lot for your patch.  I've applied it to development version
of cvs-nserver (1.1.5x).

--alexm

Well, yesterday I committed lsmodules subcommand so everyone are welcome
to test it :-). Together w/ ls, lsacl and forthcoming lstags (Alex,
don't shy as you said me a while ago, commit it please :-)) there's a
complete (hopefully) bunch of commands that implements a kind of listing
server (well, Michael, it's not completely 'httpd'-server as you asked
but it's enough to build a remote web-frontend).

I have already implemented a kind of such frontend based in CVS::Remote
perl module and I hope I'll turn it eventually into viable replacement
of the cvsweb and similar programs).

There's an issue I want to discuss though. Current format of ls*
commands are humanly readable and understandable but they can be more,
hmm, formalized or smth (especially lsacl, but ls also has portability
bottlenecks and so on). So my question is:
do we need these commands to have an, hmm, XML-like output? If yes,
what's the DTD? There're pros (we won't need an unique parser for each
command) and cons (the server code needs to be more complex, there will
be greater output size and so on) so final decision should be carefully
discussed.

Now I'm going to commit cvs-create-repository and cvs-group
commands. Alex, where's the best place to put such things?

A while ago my Novosoft bosses (actually it's Marod :-)) told that would
be fine to have a workaround against one well-known cvs (librcs)
bottleneck: when file processing time dramatically increases when
there're long/complicated commit history. One possible solution for the
problem is to implement (in a separated utility) a kind of purge/merge
operation. This will allow us to remain compatible w/ stock cvs and
solve some of the problems. The question: is there another, more
convenient way? Or we should change the repository format instead and
solve the problem completely?..

=F7 =F0=D4=CE, 26.04.2002, =D7 18:44, Alberto Dainotti =CE=C1=D0=C9=D3=C1=
=CC:
> If you want please tell me how can I help more on development..
> For example, I've found some errors in INSTALL-nserver but I don't know
> if this file is going to disappear in favour of the admin guide or not..
Well, this file often serves as source when we create a proper .texi
docs. So if you notice a mistake there, it would be nice if you tell us
about it.

> I didn't know you were working on a release and updating docs, I thought
> I would read it on this mailing list..
Hmm, there're some private talks (mostly in Russian as it out native
language) so there's not so much mails in the list.

> I don't know what you are working on.. how much/who are the developers..
> etc..

2Alex Mahotkin: Alex, let's publish our release schedule and some TODOs.
I think it would useful for the entire nCVS community :-).

Did you experience heavy performance degradations with ssl pserver
compared to pserver connections ?
For example it takes a lot of time to checkout the cvs-nserver sources..
I've seen that files are transferred at about 50kbyte/s instead of
1.2Mbyte/s while both client and server cpu's are under 10% ..
Please let me know..

Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

Hello, I hope to not be annoying :-)
In src/ssl-client.c there are two printf()'s which instead should
use error() (it is annoying when redirecting stdout, for example
when using cvs rdiff). Attached there is a patch.

The same was for my proposed patch for self-signed certificates,
there was a wrong printf() too.
So I attached a new patch with the latest corrections.

						Alberto.

Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

On Fri, 26 Apr 2002, Alexey Morozov wrote:

> On Fri, Apr 26, 2002 at 12:59:19PM +0200, Alberto Dainotti wrote:
> > Hello, I didn't receive any comments about this patch.
> We're sorry, really.

NP :-)

> > Don't you think it could be useful ?
> Probably. Right now we're in process of creating of some kind of release
> of NCLI-1-11-1 as stable branch so Alex is busy on, hmm, bureaucratic
> tasks, such as updating docs, making future releases plans e.t.c.

If you want please tell me how can I help more on development..
For example, I've found some errors in INSTALL-nserver but I don't know
if this file is going to disappear in favour of the admin guide or not..
I didn't know you were working on a release and updating docs, I thought
I would read it on this mailing list..
I don't know what you are working on.. how much/who are the developers..
etc..

Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

Hello, I didn't receive any comments about this patch.
Don't you think it could be useful ?
By the way, the patch as is doesn't compile.. I forgot
to add an #include "cvs.h" to ssl-client.c :-)
Greets,
				Alberto.

Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

Hello,
what about an env variable to allow connections to servers with self
signed certificates ?
A patch is attached.
Greets,
					Alberto.

Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

=F7 =F7=D3=CB, 21.04.2002, =D7 23:06, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC=
:
> Huh?  RedHat's .spec should be in cvs-nserver.spec.in in top directory.=20
It's outdated and dummy enough :-). I have a better one :-).

> Debian one will be in debian/ subdirectory (that's dpkg's requirement).
Ok...

Hello,

some of us will probably be extremely upset, but the sad truth is that
it seems like an upgrade to Autoconf 2.53 is needed for cvs-nserver
developers.

One of particular reasons for this is that cvs-nserver could not be
built under FreeBSD (with "argument to -V option is not specified"
diagnostics) because of Autoconf 2.52e bug.

I've seen this behaviour with checkpassword-pam, and it was completely
remedied after I've upgraded to Autoconf 2.53 (available from
ftp://ftp.gnu.org/pub/gnu/autoconf/).

The upgrade is scheduled within next two days.    Please prepare
accordingly.

NOTE: this of course does _not_ mean that end-users will have to
upgrade (or even install) Autoconf.

--alexm

>>>>> "AM" == Alexey Morozov <mo...@no...> writes:

 AM> Well, guys, I think it's time to provide good examples to build ncvs
 AM> package on various systems... Right now I can commit spec file(s) for
 AM> RH and ALT Linux systems, probably Alex has debian-style rules. The
 AM> question is where to commit such files?

Huh?  RedHat's .spec should be in cvs-nserver.spec.in in top directory. 

Debian one will be in debian/ subdirectory (that's dpkg's requirement).

All others probably could go to packaging/ subdirectory. 

You're welcome to commit. 

--alexm

Well, guys, I think it's time to provide good examples to build ncvs
package on various systems... Right now I can commit spec file(s) for RH
and ALT Linux systems, probably Alex has debian-style rules. The
question is where to commit such files? 

=F7 =F3=C2=D4, 20.04.2002, =D7 22:45, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC=
:
>  AM> 'security', 'normal', 'debug' levels and there would be a filter tha=
t
>  AM> specify how much information should go into logs. I think this would
>  AM> ease the setup, maintaince and incidents recovery processes.
> Maybe simply add GreatCircle Talkback support, a-la Netscape/Mozilla? ;)=20
"Who's the f**king Alice?". Shame on me, but I just heard about these
technologies and don't know much about all its goals, pros and cons...

>>>>> "AM" == Alexey Morozov <mo...@no...> writes:

 >> Given that the segfault is in free(), I don't think that would be easy
 >> to debug remotely...
 AM> Hmm, well we really need the proper logging facility.  BTW, Alex, did
 AM> you consider smth I call multilevel logging as it's done in repcheck
 AM> utility? I.e. when server logs every little step it does but w/
 AM> different logging level. At first look there could be 'fatal',
 AM> 'security', 'normal', 'debug' levels and there would be a filter that
 AM> specify how much information should go into logs. I think this would
 AM> ease the setup, maintaince and incidents recovery processes.

Maybe simply add GreatCircle Talkback support, a-la Netscape/Mozilla? ;) 

 >> I'll try to re-run the test...
 AM> Hmm... I also will, as soon as I complete maintainance utilities...

--alexm

>>>>> "AD" == Alberto Dainotti <al...@ur...> writes:

 AD> Here are the patches taken from modifications of OpenBSD team to cvs.
 AD> All code was taken from OpenBSD except for two lines of code that I
 AD> added to make the new "-t" option work also in pserver mode.

Thanks!

I think I'll commit most (or all) of it rather soon (somewhere in the
beginning of May).

 AD> Explantions follow:

 AD> fixes.patch: Minor fixes/improvements

"16" vs "16+1" is ultra-cool. :)

--alexm

I preliminarily schedule the transition to cvs-1.11.2 somewhere around
mid-May (unless someone could do it earlier).

The only thing that would be added ASAP is the following fix (taken
from the NEWS file):

	* A serious error that allowed read-only users to tag files has been
	corrected.

From: Derek Robert Price <ob...@um...>
To: ann...@cc..., inf...@gn..., bu...@gn...,
        de...@cc...
Subject:  CVS 1.11.2 Released!
Date: Wed, 17 Apr 2002 17:04:54 -0400

It's been almost a year since the last release, but CVS 1.11.2 has 
finally been released.  It has quite a few bug fixes and a few 
enhancements. We recommend an upgrade.  Take a look at the NEWS file 
<http://ccvs.cvshome.org/source/browse/ccvs/NEWS?rev=1.102&content-type=text/x-cvsweb-markup> 
from the source distribution or go directly to the downloads page 
<http://ccvs.cvshome.org/servlets/ProjectDownloadList>.

-- 
                *8^)

CVS Solutions Architect
Worldwide Information Technologies ( http://2-wit.com )
Email: ob...@al...
Public key available from www.keyserver.net - Key ID 5ECF1609
Fingerprint 511D DCD9 04CE 48A9 CC07  A421 BFBF 5CC2 56A6 AB0E
-- 
I will not skateboard in the halls.
I will not skateboard in the halls.
I will not skateboard in the halls...

          - Bart Simpson on chalkboard, _The Simpsons_

---------------------------------------------------------------------
To unsubscribe, e-mail: dev...@cc...
For additional commands, e-mail: dev...@cc...

Here are the patches taken from modifications of OpenBSD team to cvs.
All code was taken from OpenBSD except for two lines of code that I
added to make the new "-t" option work also in pserver mode.

Explantions follow:

fixes.patch:            Minor fixes/improvements

localid.patch:          This patch allows to specify a custom RCS
			identifier string to be used like the "Id"
			identifier.
                        It can be specified by command line on
			checkout/update/export or in CVSROOT/config file.
                        The explanation in the new manpage is:

------------------------------------------------------------------------------
-t id  Expand  the RCS identifier specified by the id argument in addi-
       tion to the default ``Id'' identifier.  -t is available with the
       checkout,  export,  and update commands.  If the identifier name
       is  specified  as  ``-'',  no  additional  identifiers  will be
       expanded.
------------------------------------------------------------------------------

readonly.patch:         Allows to set the cvs repository as readonly using
			the new "-R" global option.

newhostname.patch:      permit [] hostname formats in CVSROOT, for IPv6.

config.patch:           Allows to force cvs umask and resource limits from
                        CVSROOT/config file.

Bye,
						Alberto.

-------------------------------------------------------------------
Alberto Dainotti
URIZEN - Internetworking & Digital Security
al...@ur...
http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5
-------------------------------------------------------------------

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (25)	Sep (7)	Oct (10)	Nov (14)	Dec (6)
2002	Jan (4)	Feb (1)	Mar (3)	Apr (29)	May (41)	Jun (2)	Jul (2)	Aug (1)	Sep	Oct (1)	Nov	Dec
2003	Jan (3)	Feb (3)	Mar (3)	Apr (5)	May (12)	Jun (68)	Jul (75)	Aug (56)	Sep (9)	Oct	Nov	Dec

cvs-nserver-devel Mailing List for CVS with rewritten network layer (Page 9)

cvs-nserver-devel — Developers