There are some problems with local repositories ( you mean
CVSROOT=/var/cvs style right? ) because of local file
permissions. Often the web user does not have permissions
to the CVS root on the local filesystem.
I'm afraid I'm not familiar with :ext: repositories...
Feel free to enlighten me, or add a patch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it would be good if one could force the repository,
without the tests.
Some systems might not allow the webserver read access to
a local repository, but that shouldn't lock it out for those
which can.
:ext: looks at the environment CVS_RSH, and allows access
to a repository by rsh or ssh (perhaps others aswell?). I
modified cvsmonitor.pl to set up the environment (you could
put this in the apache startup I suppose), and had
CVSMonitor::MetaData::Repository return the :ext: repository
without tests, and it works fine.
OK, that doesn't look like to much of a big change.
Is there any way to check whether the ssh identity stuff is set
up correctly? It would be nice to provide some feedback on
whether it's set up correctly or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the easiest would be to check the return code for `cvs
co -c` or some such; if it's > 0, echo the error to the user.
That way you don't need to know about the local
implementation. (ssh checks are pretty detailed and way
beyond the scope of cvsmonitor I think)
If it's :ext: using ssh, and ssh isn't setup with an authorized
key, it's going to prompt for a password. And if the host is not
yet in known_hosts, it will ask to add it. I'm not sure what ssh
will do when there's no tty attached. Perhaps it would be best
to print a few newlines after opening a pipe to the cvs
command, then close it and check $?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
------------
Obviously the web sever user needs to have an ssh identity
and authorized key set up.
------------
The web server user is nobody, then how can one get those
setup? Any new thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm leaving this for the moment, until I get 0.6.2 out the
door, as it has a bunch of good things and significant fixes
that shouldn't get held up.
I have some ideas for a more generalised backend
abstraction, which I'll start on for 0.7, to follow 0.6.2 ( or at
least to branch ). The idea will be to move everything
backend related into a single class, in this case
CVSMonitor::Backend::pserver.pm, inheriting from the
more generic CVSMonitor::Backend::CVS.pm. It should
mean we can provide a different set of 'New Repository'
forms, which can be customised with the relative
information for admins setting it up. Also, after 0.7.X, we
need to start thinking more seriously about Subversion
support. Subversion should be close enough in use ( it's
designed that way ) that once we have gotten comfortable
with the generalised backend for 0.7, we can add
CVSMonitor::Backend::Subversion.pm. After the release of
0.6.2, there will be a while to just hunt everything down and
pull it out ( for example the current CVSMonitor::MetaData::
(Module|File|Version) constructors will have to go. Once
I'm comfortable with the class layout and have
Backend::pserver.pm working, I'll add local and ext
support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At this point, it's looking like 0.7.0 will be a "get it our
the door as soon as everything is stable again" release.
pserver CVS and perforce are probably the only backend.
0.7.1 should hopefully add :local (with massive danger
warnings), :ext and subversion (if the people that
volunteered to write it come through).
There has been the odd hack appear... I don't have it in
patch form though. Mostly it involves doing really nasty
things like running CVS Monitor using their personal user,
which I would expect means that cvsmon has theoretical write
mode to the repository. And I'm against that sort of thing.
What really needs to happen is I need to chase down the CVS
or ssh developers and grill them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=153576
There are some problems with local repositories ( you mean
CVSROOT=/var/cvs style right? ) because of local file
permissions. Often the web user does not have permissions
to the CVS root on the local filesystem.
I'm afraid I'm not familiar with :ext: repositories...
Feel free to enlighten me, or add a patch.
Logged In: YES
user_id=153576
Moving to feature request
Logged In: YES
user_id=661742
I think it would be good if one could force the repository,
without the tests.
Some systems might not allow the webserver read access to
a local repository, but that shouldn't lock it out for those
which can.
:ext: looks at the environment CVS_RSH, and allows access
to a repository by rsh or ssh (perhaps others aswell?). I
modified cvsmonitor.pl to set up the environment (you could
put this in the apache startup I suppose), and had
CVSMonitor::MetaData::Repository return the :ext: repository
without tests, and it works fine.
Eg:
$ENV{'CVS_RSH'} = 'ssh';
return ':ext:username@cvs.server:/cvs/repository/';
Obviously the web sever user needs to have an ssh identity
and authorized key set up.
Logged In: YES
user_id=153576
OK, that doesn't look like to much of a big change.
Is there any way to check whether the ssh identity stuff is set
up correctly? It would be nice to provide some feedback on
whether it's set up correctly or not.
Logged In: YES
user_id=661742
I think the easiest would be to check the return code for `cvs
co -c` or some such; if it's > 0, echo the error to the user.
That way you don't need to know about the local
implementation. (ssh checks are pretty detailed and way
beyond the scope of cvsmonitor I think)
If it's :ext: using ssh, and ssh isn't setup with an authorized
key, it's going to prompt for a password. And if the host is not
yet in known_hosts, it will ask to add it. I'm not sure what ssh
will do when there's no tty attached. Perhaps it would be best
to print a few newlines after opening a pipe to the cvs
command, then close it and check $?
Logged In: NO
------------
Obviously the web sever user needs to have an ssh identity
and authorized key set up.
------------
The web server user is nobody, then how can one get those
setup? Any new thoughts?
Logged In: YES
user_id=153576
I'm leaving this for the moment, until I get 0.6.2 out the
door, as it has a bunch of good things and significant fixes
that shouldn't get held up.
I have some ideas for a more generalised backend
abstraction, which I'll start on for 0.7, to follow 0.6.2 ( or at
least to branch ). The idea will be to move everything
backend related into a single class, in this case
CVSMonitor::Backend::pserver.pm, inheriting from the
more generic CVSMonitor::Backend::CVS.pm. It should
mean we can provide a different set of 'New Repository'
forms, which can be customised with the relative
information for admins setting it up. Also, after 0.7.X, we
need to start thinking more seriously about Subversion
support. Subversion should be close enough in use ( it's
designed that way ) that once we have gotten comfortable
with the generalised backend for 0.7, we can add
CVSMonitor::Backend::Subversion.pm. After the release of
0.6.2, there will be a while to just hunt everything down and
pull it out ( for example the current CVSMonitor::MetaData::
(Module|File|Version) constructors will have to go. Once
I'm comfortable with the class layout and have
Backend::pserver.pm working, I'll add local and ext
support.
Logged In: NO
Hi,
has support for non-pserver repositories been add to 0.7?
Also, does anybody have a patch (even a nasty one) for
adding support for :ext: ssh repositories, for 0.6.3 (or
something similar)?
Thanks,
Ian.
Logged In: YES
user_id=153576
At this point, it's looking like 0.7.0 will be a "get it our
the door as soon as everything is stable again" release.
pserver CVS and perforce are probably the only backend.
0.7.1 should hopefully add :local (with massive danger
warnings), :ext and subversion (if the people that
volunteered to write it come through).
There has been the odd hack appear... I don't have it in
patch form though. Mostly it involves doing really nasty
things like running CVS Monitor using their personal user,
which I would expect means that cvsmon has theoretical write
mode to the repository. And I'm against that sort of thing.
What really needs to happen is I need to chase down the CVS
or ssh developers and grill them.