[Savannah-hackers-public] Re: GNU Rush 1.6

[Sylvain Beucler]

(cc'ing savannah-hackers-public)

On Wed, Feb 11, 2009 at 10:57:17PM +0200, Sergey Poznyakoff wrote:
> > > At Puszcza, we use rush instead of sv_membersh.
> > Interesting. What do this permit you to do?
> 
> Compared to sv_membersh it has several advantages:
> 
> 1. It is written in C, and therefore it eats much less resources and
> works considerably faster; 

Hmm, I'll be skeptical.

Savannah gets less than 1 SSH connection per minute for
CVS/SVN/Git/Hg, so it doesn't sound like something that needs
optimization. Meanwhile writing software in C is usually more tedious.
Is there a noticeable difference?


> 2. Its configuration file is very flexible and allows to create complex
> execution rules;
> 3. It allows to limit consumption of the system resources on per-user
> and per-group basis (similar to /etc/limits, but does not require
> involvement of /bin/login and is more flexible);

This reminds me: I saw in the last SourceForge announcement that
they're providing unrestricted shell access limited to 4h with limited
view on the system, which they claim to be based on "virtualization".
Any idea on what this is based on?

"Our new shell service has been designed specifically to place
limitations solely around system resource usage while permitting all
legitimate use cases.

The new Interactive Shell service makes extensive use of
virtualization as a means of compartmentalizing users. When a user
accesses the shell environment, we spin up a dedicated shell
environment specifically for that user. Within the shell, we provide
access to the data for that user and for any projects they have access
to [...]"

http://sourceforge.net/community/forum/topic.php?id=3953&page&replies=1


> 4. It allows to execute programs in chdir-ed environment. This feature,
> among others, is used when executing `cvs server'. This allows to limit
> access to a single root directory. It is also used when handling
> uploads of files for distribution from download.gnu.org.ua (see
> below);

(chdir'd or chroot'd?)

chdir is nice, it's used by Mercurial at Savannah to drop the
'/srv/hg/' from the SSH paths, making it consistent with other read-only paths.

I tend to distrust chroot'd environment: they are likely to introduce
breakages.  At Savannah the overzealous usage of chroot and sanitizing
in early 2004 made CVS register 'uidXXXX' instead of the actual user
name, ruining the history. For sftp, I wouldn't be surprised if the
lack of /etc/passwd or more generally getent(2) support would make the
output of the 'ls' command all-numerical :/


> 5. It logs all accesses and provides two utilities for examining
> them. The rushwho utility shows a listing of current accesses, and the
> rushlast utility displays a history of user accesses. For example,
> here's what the latter shows right now:
> 
> Login      Rule         Start            Stop      Time   Command
> sergiusz   git          Wed Feb 11 20:28 Wed 20:28 00:00  /usr/bin/git-upload-
> andy_shev  svn          Wed Feb 11 19:05 Wed 19:05 00:00  /usr/bin/svnserve -r
> gray       sftp-upload  Wed Feb 11 18:00 Wed 18:01 00:01  /bin/sftp-server

It sounds interesting to produce stats out of these logs :)


> To illustrate (4), here's how file uploads are handled. Puszcza implements
> the GNU automatic upload protocol as described in [1]. Stable
> releases are distributed from ftp://download.gnu.org.ua/pub/release and
> pre-releases from ftp://download.gnu.org.ua/pub/alpha. To place his
> files to one of these sites, the user uploads them to
> 
> download.gnu.org.ua/ftp/PROJECT
> or
> download.gnu.org.ua/alpha/PROJECT
> 
> (where PROJECT stands for the project system name). Uploads go via
> scp or sftp. The following configuration rule instructs Rush how to
> handle scp uploads:
> 
> rule scp
>   # This rule is executed if the requested command line matches this regex:
>   command ^scp (-[dv] )?(-[dv] )?-t (alpha|ftp)/
>   # ... and the user belongs to the svusers group.
>   group svusers
>   # This statement replaces argv[0] with /bin/scp:
>   set[0] /bin/scp
>   # This one enforces the new root directory:
>   chroot /var/spool/sftp-upload
>   # And, finally, this changes to the subdirectory:
>   chdir /incoming
>   # This instructs rush to notify listener on this URL after the command
>   # is executed[2]:
>   post-socket inet://127.0.0.1
> 
> A similar rule is implemented for sftp accesses. After the upload is
> finished, rush sends a notification to localhost port
> 1 (tcpmux), which triggers execution of `wydawca'[3], a special
> utility which verifies and handles automatic updates.
> 
> Rush documentation[4] includes some examples of what it allows to
> do. These are mostly taken (with slight modifications) from our
> working configuration.
> 
> Regards,
> Sergey
> 
> [1] http://www.gnu.org/prep/maintain/html_node/Automated-Upload-Procedure.html
> [2] http://puszcza.gnu.org.ua/software/rush/manual/html_node/Notification.html
> [3] http://www.gnu.org.ua/software/wydawca
> [4] 
> http://puszcza.gnu.org.ua/software/rush/manual/html_section/Usage-Tips.html

post-socket is a nice concept.
Do you know how interrupted connections are handled?

Cheers!

-- 
Sylvain