Re: FSFS repo on a network share

Hi James,

I prefer the svn+ssh method through a single account method, as
described in The Fine Manual. Let's say the account is called
'svnuser' and the host I'll access on is 'svnhost'. Joe User's name
and email is first.m.last_at_mycompany.com

1) Each user sets up an access key. I have them do this:

   umask 077

   mkdir -p ~/.ssh

   chmod 700 ~/.ssh
   
   ssh-keygen -b 4096 -t rsa \
   -C first.m.last_at_mycompany.com \
   -f $HOME/.ssh/first.m.last_svnuser

   <Carriage Return 2X for no-passphrase access>

2) The user sends me their public key via some secure channel
   (encrypted attachment or maybe transports it physically via thumb
   drive).

   Alternatively, you can generate the key for them yourself and then
   transmit it to them and have them install it in the proper place.

3) I install the public key in the ~svnuser/.ssh/authorized_keys file,
   using something like this:

   svnuser_at_svnhost% umask 077

   svnuser_at_svnhost% mkdir .ssh ; cd .ssh

   svnuser_at_svnhost% echo "command=\"$HOME/bin/svnserve_wrapper
   first.m.last\",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
   | cat - first.m.last_svnuser.pub >> authorized_keys

4) Setup ~svnuser/bin/svnserve_wrapper:

,----
| #!/bin/bash
| # This is a wrapper for the svnserve command.
| #
| # Adjust parameters here
| SVNHOST="svnhost.mycompany.com"
| SVNPATH=/path/to/CollabNet_Subversion/bin
| SVNROOT=/path/to/repos
| #
| # Here's why we're running svnserve via a wrapper:
| # It allows us to
| # * Make changes in a single location instead of having to
| # edit ~svnuser/.ssh/authorized_keys
| # * Enforce access through a single host
| # * Set up corrrect umask
| # * Change PATH to find correct version of svnserve
| # * Set up path to svn repository
| # * Log subversion access
| #
| # Enforce single host:
| [[ "$(/bin/hostname)" = "$SVNHOST" ]] || {
| echo "Unauthorized host: svn+ssh access permitted only through $SVNHOST"
| exit 1
| }
|
| umask 077
| export PATH=$SVNPATH:$PATH
|
| # Do rudimentary logging
| # Format is YYYY-MM-DD-HH:MM:SS userid svn-args
| echo $(date -u '+%F-%X') "$@" "$SSH_CLIENT" >>/home/svnuser/logs/`date "+%Y-%m"`
|
| # extract the user id
| userid=$1
| shift
|
| # execute svnserve in correct format
| exec svnserve -t --tunnel-user=$userid -r $SVNROOT ${1+"$@"}
`----

Note that this means your svn log entries now show a human-readable
name instead of some complex account name! I like this, since our
company mandates user IDs that resemble secure passwords.

On the user side, they can create an ssh Host stanza to alias the
complicated access settings:

   Host svnuser_svnroot
      User svnuser
      Hostname svnhost.mycompany.com
      Protocol 2
      IdentityFile ~/.ssh/first.m.last_svnuser
      StrictHostKeyChecking no

For your needs, the nice thing about this is that once they are set
up, their svn access key doesn't change every time their account
password changes.

Another benefit of svn+ssh is that you don't have to involve the IT
admins to take care of Apache stuff. All you need is user-level
access.

Then they access the repository using this:

     svn ls svn+ssh://svnuser_svnroot/project

Pretty compact, eh? And if you need to change the path to the
repository, it is transparent to the user. That's all handled by the
svnuser account.

Ted

-- 
 Frango ut patefaciam -- I break so that I may reveal
On 26 Feb 2009 10:26:18 -0800, James An wrote:
>
> Thanks guys.
>
> I was thinking about just using file:// since it would greatly simplify
> everything, but worried about the consequences.
>
> Currently, the setup I've implemented is clumsy. Because of the
> confidentiality of work between researchers, they currently run a
> local Apache service (logged in as them through the network to get
> the right privileges to access the repo).  The service authenticates
> against the Windows authentication (Active Directory?), which
> svnserve can't do (easily). So access to repos are by HTTP requests
> to the local workstation.
>
> It works, but it's clumsy because:
>
>   * there's a bunch of local Apache services running, when it should really be
>     centralized at the server where the repos are stored,
>   * user passwords are regularly changed and the researchers have to re-input
>     their passwords for the local Apache service to continue to log in as them
>     (to get the correct privileges to access the repo), and
>   * the local workstation where the service is run has to be on (and logged
>     in?) in order for the manager (the only other person accessing the repos)
>     to access the remote repo
>
> Am I circumventing the safety measures by having the SVN server retrieve the
> repo over the network?
>
> I don't have full access to the server that stores all these repos as I'm a
> researcher myself. The IT folks don't want to maintain a collection of research
> repos, so I'm looking for a work-around that is not as clumsy. -_-
>
> James
>
> On Tue, Feb 24, 2009 at 11:51 AM, <Ullrich.Jans_at_elektrobit.com> wrote:
>
>     Hi,
>     ??
>     to throw in my two cents:
>     ??
>     why not use svnadmin hotcopy to copy it over???AFAIK, that's what it's
>     meant for...
>     ??
>     Cheers,
>     ??
>     Ulli
>
>         ---------------------------------------------------------------------- 
>         From: Bolstridge, Andrew [mailto:andy.bolstridge_at_intergraph.com]
>         Sent: Tuesday, February 24, 2009 12:25 PM
>        
>         To: users_at_subversion.tigris.org
>         Subject: RE: FSFS repo on a network share
>
>         The best option is to host your filesystem SVN repository on the local
>         drive and regularly copy it to the network share. Then you have a ???
>         online backup???, and an ???offline??? backup as the IT guys do their
>         thing.
>        
>         ??
>        
>         I???d set up a nightly copy using rsync, or xcopy to copy the data
>         across. Obviously you may need to consider your options carefully if
>         the DB is very large as all those little files can introduce quite a
>         lot of network latency. If you have a very large number, it might be
>         better to zip them all up and copy the zip file (or use svnadmin dump
>         and copy the dump file)
>        
>         ??
>        
>         ??
>        
>         ??
>        
>         From: James An [mailto:james_at_jamesan.ca]
>         Sent: Monday, February 23, 2009 5:29 PM
>         To: users_at_subversion.tigris.org
>         Subject: FSFS repo on a network share
>        
>         ??
>        
>         Hi,
>        
>         I've created an FSFS repository and would like to put it in a remote
>         network location that is regularly backed-up.
>        
>         I've read that it's poor practice to directly access repos over a
>         network and that I should set up svnserve or Apache. The SVN book
>         mentions that network shares are bad for BDB repos, but doesn't really
>         comment on its use for FSFS ones. Some people say there are potential
>         problems for network repos that are accessible by multiple users.
>        
>         If the FSFS repo (on a network share) is restricted so only a single
>         user can access it, are there any risks to directly accessing the repo
>         with an SVN client? If I extend the permissions so that multiple users
>         can read-only access the repo, but only one user can write to it, are
>         there any additional risks? If so, is there any way to mitigate those
>         risks without a local SVN server at that location?
>        
>         Thanks,
>         James
>        
>     ----------------------------------------------------------------
>     Please note: This e-mail may contain confidential information
>     intended solely for the addressee. If you have received this
>     e-mail in error, please do not disclose it to anyone, notify
>     the sender promptly, and delete the message from your system.
>     Thank you.
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1234643
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].