launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #08755
Re: Getting rid of Ubuntu archive admin shell access
On Monday, January 09, 2012 02:52:12 AM Colin Watson wrote:
> Hi folks,
>
> The fact that Ubuntu archive admins require shell access to ftpmaster to
> get their work done has been a wart for as long as I can remember
> (although I'll admit it was a while before I was persuaded that it was
> an actual problem). Since the Launchpad API was created, we've chipped
> around the edges of the problem a bit, and some big chunks were dealt
> with as part of the derivation project by Julian's team, but we haven't
> really sat down to enumerate all the remaining things we need shell
> access for and to make a concerted effort to fix them. There's still
> plenty of work required both in Launchpad itself and on the Ubuntu side.
>
> In a fit of enthusiasm, I've been working on setting down both the
> rationale and as many details as I can manage in
> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-replace-archive-
> admin-shell-access, and (if my manager is still willing in a few months'
> time) I'm
> interested in spending some time extending the Launchpad API and fixing
> Ubuntu archive admin processes in the Q cycle, aiming for all archive
> admin work to be possible without ftpmaster shell access by the end of
> that cycle. I'd welcome feedback on this in advance. Things where I
> could particularly use feedback include:
>
> * Have I missed anything that archive admins use cocoplum for
> (disregarding manual inspection of the archive that could just as
> well be done on a mirror such as lillypilly)?
>
> * Have I missed instances of APIs that are broken or that we sometimes
> have to work around using shell commands, as opposed to features that
> are missing? I'm assuming that on the whole the API is less
> susceptible to timeout bugs than the UI because its responses are
> simpler, but I know we still run into the odd API timeout as well.
>
> * Is there anything that might be vastly more complicated than I think?
> I'm pretty confident that I can deal with API extensions and the
> like, and with all the client-side work, but (say) things that
> involve serious remodelling would take rather longer.
>
> * Is there anything that we use sufficiently infrequently that we could
> just ask webops to run things for us rather than spending lots of
> time on APIs? For instance (without meaning to disparage Matthias,
> who's probably the main user of this), if populate-archive.py were
> the only remaining thing we needed direct ftpmaster access for, then
> it might be a reasonable tradeoff to terminate our shell access and
> handle that by means of webops requests.
>
> * Am I stepping on anyone's toes with any of this?
I agree it's a security wart that needs fixing.
I probably haven't kept up with everything that can be done through the API,
but when I'm doing New processing (since I don't have shell access), I'm doing
it through the web U/I. One thing this lacks is the ability to override
section, component, or priority differently for different binary packages in the
same upload. This means one can't accept kernels through the web U/I and
there are other issues as well (usually it involves needing to override a new
binary into Main where some packages are (and should be) in Universe.
Scott K
Follow ups
References