Re: own cloud task in tasksel?
Hi all,
Let me try to summarise, but first here are a few quotes for the context.
Le Wed, Mar 09, 2016 at 04:53:59PM +0100, Marco d'Itri a écrit :
>
> I am very interested in working on reducing the footprint of a minimal
> install: we risk losing mindshare on the containers market.
Le Thu, Mar 10, 2016 at 09:14:01AM +0100, Martin Zobel-Helas a écrit :
>
> What are the minimal set of of packages then that should be installed in
> every cloud image?
>
> debootstrap --variant=minbase?
> debootstrap --variant=scratchbox?
>
> We should define this, and work on a policy then so we can publish that
> policy enough in time for cloud providers to react for the stretch
> release.
Le Thu, Mar 10, 2016 at 10:03:33AM +0100, Marco d'Itri a écrit :
> On Mar 10, Martin Zobel-Helas <zobel@debian.org> wrote:
>
> > What are the minimal set of of packages then that should be installed in
> > every cloud image?
>
> Whatever is needed to boot it and let someone or something ssh on it.
Le Fri, Mar 11, 2016 at 12:24:50AM +0800, James Bromberger a écrit :
>
> All of what people generally want installed in their EC2 instances can
> be achieved with a suitable boot time UserData section that Cloud-init
> installs. So long as the base image has enough base packages to fetch &
> install additional packages at boot; which means it has enough base
> packages to be configured to make a request to a Debian repo by some
> means (socks, or explicitly defined proxy, or private repository, or
> direct) with simple configuration, then that's easy. So, for example, in
> an EC2 metadata environment, setting the UserData to:
>
> #!/bin/sh
> apt-get update && apt-get install -y less unattended-updates
> ....
> One item of note that we have included in the AWS EC2 base images is the
> apt-transport-https package, purely that, in environments where the
> (customer organisational) security policy forbids the use of outgoing
> HTTP from an instance, but permits (limited?) HTTPS, then permitting a
> simple re-configuration of the base image sources.list file makes this
> possible without being a chicken-and-egg problem.
As far as I know, all cloud images and probably all container images are using
debootstrap at one moment or another. And as far as I understand, deboostrap
installs by default all packages of priority Important or higher, but can be
called with variant "minbase", wich causes it to only install packages of
priority "Required", plus apt. (The variant "scratchbox" would not be useful
since it installs build-essential as well).
The Debian images on the Amazon cloud are of the "minbase" variant, and extra
packages are added. (James, I lost track on where to find this information in
the source code of bootstrap-vz, or on the Debian wiki, can you remind me the
information ?) For the other cloud images, I am not familiar enough to be sure
if they also use debootstrap's minbase variant or not. They will also install
extra packages, some platform-specific, and some common with the other images.
Part of the discussion was about making cloud and container images slimmer.
Here, I think that the obvious next step is to make concrete proposals of which
package should have their priority reduced to "Important".
Part of the discussion was about what packages should be guaranteed to be
present on every Debian cloud image. This is a more difficult question. Given
the current discussion, I wonder if a list of common packages is really needed.
Are there examples of problematic discrepancies ? (By the way, if the EC2
image would use a https mirror, then debootstrap would automatically install
apt-transport-https.)
Lastly, since packages of priority Important are not installed by default,
I wonder what would be the easiest way to install them on the first boot,
without having to grep /var/lib/apt/lists/*_Packages. Are there suggestions
for a one-line command that would make a good self-documented UserData for
cloud-init ?
Have a nice week-end,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: