Re: [Monotone-devel] Hosting multiple Monotone projects

[Sylvain Beucler]

After reading this, I actually asked myself what I would like for an
VCS' server-side part.

I spotted the following issues:


- Process model:

> OSes have all been optimized for apache's ol' process-per-connection
> anyway...

Well, technically Apache uses a pool of thread and now has a
multithreaded worker ;)

Anyway that's indeed the way CVS works now: either pserver spawn by
xinetd for each connection, either the 'cvs server' command ran
through a remote shell connection such as ssh. In each case, one
process per connection - though of course that's not a reason to use
the same design :)

> So my off-the-cuff suggestion for a more aesthetic setup would be to
> put a proxy on your "monotone port", tweak the netsync protocol to
> make sure that the first packet includes some sort of vhost parameter,
> and then teach the proxy how to spawn monotone processes on demand and
> forward traffic to them.

That could do the trick. From what I know starting a thread rather
than a process should be less resource consuming but I'm not an expert
here. Fork&exec might also be better than traffic forwarding, although
there may be issues with fork() under Windows.

The process model doesn't look like a critical feature though. Also
check the note about authentication below.


- Authentication and access control: with CVS, we use one Unix groups
per repository to give access to different repositories but:

* that's not fine-grained (unlike Monotone's per-branch read access)

* Unix groups have limitation, mainly the number of groups one user
  can belong to (usually 16 or 32).

* it should be possible to use ACLs and a bit of hacking to get rid of
  those limitations, though.

About granularity, I'm actually surprised that Monotone does not allow
per-branch repository write access. That's not symetric with the read
access control. Is there a reason for this?

I think it would be nice for a project admin to setup up different
branches in its project with different write access.


The authentication model has an impact to the process model: if the
server maps to OS users (and maybe groups), the server will usually
fork and setuid, one process per request. If the authentication is
done by the server (Apache-style), then the server needs only one
system uid, so it can use either thread or process-based request
handling. It will be able to access all repositories with the same uid
though.

There are security issues in both case: in the former, the OS may
permit unexpected authentications (cf. cvs pserver's security issues,
due to the combination of its own authentication system and the
delegation to /etc/passwd or PAM); in the later, if the server is
cracked, then all repositories on the system, not just the one, will
be at stake.

As far as I can see, both models can be implemented on top of SSH,
provided the remote shell is restricted, but I only saw the OS-mapping
style until now.


- Protecting the source code: usually, project admins don't want the
code to be removed by (mad/jealous/...) project members, and system
admins want to keep the history of the source code intact (in case the
project developers decide to switch from a free to a proprietary
softare license and remove any trace from the free version).

To avoid this, it would be nice to be able to prevent the 'kill'
monotone commands.  This is possible with CVS (by blocking the 'cvs
admin' commands), but it wasn't planned properly: doing so also blocks
other interesting features such as switching a file type
(text/binary).

Does it sound reasonable to make 'kill' commands blockable?


- Configuration at two level, system and project-wide (or at least
just project-wide). Currently, I guess the proxy server you mentioned
would need to set HOME for each monotone subprocess so it reads a
different configuration file. A command-line switch might be more
convenient. Then the proxy would set an extra rc file to read for the
system-wide configuration.


- Administration tools: one would need a simple way to manage access
control and per-repository hooks. That might be done using
configuration files processed by a specific set of ~/.monotone Lua
scripts.


- Server-side hooks: apparently Monotone does this already. Some VCS
do not have a server part and rely on the client's good will, for
example for commit notifications.


Thanks for your quick reply :)

-- 
Sylvain

On Wed, Aug 10, 2005 at 03:14:05AM -0700, Nathaniel Smith wrote:
> On Wed, Aug 10, 2005 at 01:43:02AM +0200, Sylvain Beucler wrote:
> > I recently studied Monotone, and I wonder if this is a VCS people
> > would like to host at platforms such as GNU Savannah
> > (http://savannah.gnu.org), and how.
> >
> > I would like to briefly discuss the how first: as far as I could see,
> > the current server implementation is meant to serve one Monotone
> > database/repository, with sequential access.
> 
> Concurrent access, actually, using one of them fancy no-threads
> event-loop designs (though it probably needs some work to scale to
> large repos + large numbers of concurrent connections, just because I
> don't know of anyone who's really pushed it).
> 
> > In the case of Savannah, we would need to support potentialy 2000
> > Monotone repositories, if possible with concurrent access (even if
> > access is sequential per repository, maybe), and if possible without
> > the need to run 2000 servers running on 2000 different ports :)
> > 
> > Is there something I missed, or is the current Monotone server not
> > meant for this kind of usage yet? Is it actually planned at all?
> 
> I'm very interested in this question, actually; I'd love for there to
> be an easy way for people to get some low-key monotone hosting.  As
> you point out, it's currently not completely trivial, and some work
> would be necessary to make it so; I'd definitely be behind any such
> efforts.
> 
> There are lots of different things that might make sense... the
> simplest thing to do, maybe suitable to get off the ground if anyone
> felt like starting such a hosting service right now, would just be to
> give each project a port and run one process per port.
> 
> This is unaesthetic in its use of ports, and means you have a bunch of
> processes cluttering your swap space, even when they're not in use.
> Teaching a single monotone process to access multiple dbs would be
> quite a pain, though, and not particularly helpful -- they don't share
> much state, what state they _do_ maintain (caches and so on) would be
> better kept separate -- and the OS can probably handle a
> process-per-db model, OSes have all been optimized for apache's ol'
> process-per-connection anyway...
> 
> So my off-the-cuff suggestion for a more aesthetic setup would be to
> put a proxy on your "monotone port", tweak the netsync protocol to
> make sure that the first packet includes some sort of vhost parameter,
> and then teach the proxy how to spawn monotone processes on demand and
> forward traffic to them.
> 
> Or perhaps that's insane, I'm open to other suggestions :-)
> 
> > Now, maybe, as a distributed VCS, using Monotone at centralized sites
> > like Savannah is of little interest. I find it difficult, though, to
> > publish a repository, be it because of a corporate firewall or a
> > hardly configurable xDSL router, so I think that's at least one
> > possible interesting use.
> 
> No, you're quite right; while p2p systems give you fantastic
> flexibility engineering-wise, you generally don't want to be using
> that flexibility day-to-day, because it's a pain in the butt to always
> be trying to figure out who's online and whether you can sync with
> them.  "Talking" is p2p too, but we still have bulletin boards and
> pubs and all that... it's _far_ better to have a central location
> that's always there, and where you know you can always get the latest
> updates.  Monotone's design make this much less of a _commitment_ than
> conventional systems, one host is as good as another... but you do
> want one.
> 
> > I should note that we don't plan to support Monotone right now (we're
> > working on other issues at the moment), but I though it would worth
> > asking in advance :)
> 
> Sure, understood.
> 
> Cheers,
> -- Nathaniel
> 
> -- 
> "...these, like all words, have single, decontextualized meanings: everyone
> knows what each of these words means, everyone knows what constitutes an
> instance of each of their referents.  Language is fixed.  Meaning is
> certain.  Santa Claus comes down the chimney at midnight on December 24."
>   -- The Language War, Robin Lakoff