On 07/20/2011 12:14 PM, Nico Kadel-Garcia wrote:
On Tue, Jul 19, 2011 at 10:30 PM, Andy Canfield
<andy.canfi...@pimco.mobi> wrote:
For example, I am on a Linux box named Lenny, logged in as 'andy'. I can ssh
to hk.pimco.mobi as user 'andy', password 'psuedo'. But I don't want to.
Instead, I would like to run the command:
svn ... http://hk.pimco.mobi/svn/RepoName --username=andy
--password=psuedo
Whoa there nelly. You're mixing apples and oranges and kumquats. Go
right over to the Red Book, and read the descriptions of *each* of
HTTP, svnservee, and svn+ssh. Keep them distinct.
Apparently I read the wrong "Red Book". I read the one for the old
version, not the "nightly build" Red Book. I shall download and install
and read the Nightly Build Book.
As far as I know 'svn' is the name of a client program, which can
communicate with any server, and 'svn' is also the name of a protocol
that the svn program uses to communicate with a server program named
"svnserve".
My impression was that there were three possible "servers", namely
Apache, svnserve, and direct (file) access, and that which server was in
use was controlled by the URL.
The example command:
* svn ... http://hk.pimco.mobi/svn/RepoName --username=andy*
is a valid client command. The URL starts with "http://"; so it is
expecting to talk to the Apache-based Subversion access channel, e.g.
mod-dav*.so, located on hk.pimco.mobi.
A similar command:
* svn ... svn://hk.pimco.mobi/svn/RepoName --username=andy
*is also a valid client command, where the URL starts with "svn://" so
it is expecting to talk to svnserve via port 3690 on hk.pimco.mobi.
The above two commands can run on any computer with a connection to
hk.pimco.mobi; i.e. any computer with an internet connection. Another
valid command, which can only run on the server itself, would be
* svn ... file:///var/svn/RepoName --username=andy*
You said that I'm mixing apples and oranges and kumquats. Well, the svn
client program is like my teeth, which can eat apples or oranges or
kumquats (three kinds of servers depending on the URL). I usually only
buy one kind of fruit at a time, and presumably we would only run one
kind of server at a time. Since we want to have net access, I expect
that we won't use direct (file://) access for anything except the
svnadmin program, which as I recall can only be run on the server
itself. So we are not yet decided on whether to use URLS that start with
http:// (talking to the server known as apache mod_dav*.so) or URLS that
start with svn:// (talking to the server known as svnserve).
IMHO the 'svn' program is the client program which requests actions on a
repository, and the Subversion server, either apache/mod_dav or
svnserve, contains the code which actually manipluates the contents of
the /var/svn repository directories.
One quirk is that if he URL specifies direct access, e.t. svn ...
file:///var/svn/RepoName, then where is the code which actually
manipulates the contents of the /var/svn/RepoName directory? It must be
hidden in svn itself, or perhaps svn forks a call to something like
svnserve as a subtask to get the manipulations done for it, since there
is no server program already running on the server computer.
I read The Book already, but apparently the conversion from your ideas
to those words to my eyes to my brain did not result in a replication of
your ideas.
I read the wrong version of "The Book", the featured but obsolete
version. I shall download the "Nightly Build" version ASAP.
Thank you very much.
But this does not match what you are telling me. Apparently my brain is
pointed 89 degrees off from the direction your brain is pointed. Please
point me in the right direction.
See the explanations at http://svnbook.red-bean.com/. They go into
much more depth than we can here.
Thank you.
The only well supported solution to this, so far, is to use SSH keys
for a shared account, and to use those keys to use a forced "command"
for that shared account, a "command" that enforces the user's name for
that particular svnserve instance.
I've previously tried, myself, to help set up a restricted shell for
just such access, starting with the "rssh" tool, but didn't get very
far. That would be a significant security improvement, and help
protect the rest of the OS from unauthorized access with valid
Subversion logins with Kerberized or other account access, rather than
SSH keys.
