[Top][All Lists]
[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