savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sylvain Beucler
Subject: Re: [Savannah-hackers-public] Re: GNU Rush 1.6
Date: Fri, 13 Feb 2009 20:10:24 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

> > 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?
> 
> Interesting. I can't say right now how that can be achieved (putting
> aside chrooted implementation). Let me think.

Technically they *could* start a UML or a VServer/Xen/whatever using
efficients I/Os such as copy-on-write or some LVM magic, then
NFS-mount or bind-mount only the necessary directories.

OpenSUSE has something similar to instanciate a Xen domU for you to
request a .rpm build. The domU is trashed once that's done (though
this case is simple, as there's only volatile data, except for the
build result).

I also remember a website that started a minimal UML for each user so
they could play with a live Unix system, with a Javascript interface
to dialog with the bash prompt.

This sounds like a non-trivial development though, so either they
wrote it all internally, either they based their work on something
existing that I don't know, either they used a smart combination of
technologies which we need to find :)

I probably should try it first-hand instead of elaborating.


> > I tend to distrust chroot'd environment: they are likely to introduce
> > breakages.
> 
> Their use simply requires a very careful attention to details (such as
> needed libraries, devices, etc.).

That's what I said, yes ;)

Btw, do you have techniques to manage upgrades?


> > > 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 :)
> 
> It is possible. Any idea what to include in these statistics?

I think it would be nice to present:

- what commands were used the most; possibly grouping them by topic
  (e.g. Git, sftp/scp)

- connection rate and peaks


> > post-socket is a nice concept.
> > Do you know how interrupted connections are handled?
> 
> They are handled by the wydawca utility. When started, it collects
> information about triplets (tarball.directory.asc, tarball,
> tarball.sig). Any complete triplets (i.e. ones that contain all three
> components and ones that contain a lone self-sufficient directory file
> of v.1.1) are processed immediately. Incomplete triplets are held on
> quarantine for a certain time, in the hope that submitter will supply
> missing parts some time in the future. If he does not, such dangling
> incomplete triplets are removed after the timeout expires.

OK. Btw we ran a copy of ftp-upload.gnu.org's script at Savannah a
while ago, it used 'lsof' to monitor active downloads but I don't
remember the details.

My question though was rather: if a connection is interrupted
(e.g. the SSH connection eventually times out or is reset), how is it
handled? Is there a notification in that case?


Cheers,

-- 
Sylvain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]