On Wed, 23 Sep 2009, Martin Pitt wrote:

> Can you please fix these lintian warnings? Should be quite easy.
>
> Also, some init scripts use echo instead of the lsb_* functions. This
> really ought to be fixed first.

I'll look into fixing those warnings.  The rightscale-init script was a
source of 3 of them, so we'll figure something out there.

> debian/ec2-init.rightscale-init.init looks questionable and also has some security issues:

I think a little background information on ec2 and rightscale might be
useful.  ec2-init is a packaged intended to run only inside of ec2 or an
ec2-compatible "cloud".

A. Amazon's ec2 provides a "cloud" to run instances of virtual machines.
B. Each instance of a virtual machine is a brand new "install" from a
  registered image.
C. Ubuntu builds and registers "official ubuntu images" and makes them
  available for download (uec-images.ubuntu.com).  The images are created
  by vm-builder and largely represent a "fresh install from media".  These
  images can be used as-is, or can be modified, re-bundled, and
  re-registered with amazon. rebundling is both time consuming and implies
  heavier maintenance compared to using a "off the shelf image".
D. The user is able to pass 64k of "user data" to the instance when they
  start it.  This user data gives information to the instance on what to
  do, largely to customize the generic image above.  The ec2-init init
  script will execute user-data if it begins with '#!/bin/sh'.  Thus, the
  user has the ability to hook into init and install additional packages,
  grab additional software ... all the kinds of things someone would do
  after a fresh install from media.
E. ec2-init only runs user-data "once-per-ami".  What this means is that
   it will only run it on first boot.

There is a open bug (bug 434181) to replace the rightscale init script.
It still has issues some of the issues you mention, but the wget
of a ruby gem is removed.

I will agree that the rightscale-init script is somewhat of a wart, and
will look into seeing if we can't find a way for rightscale to feed this
script in via the more generic user-data hook for ec2-init above.

A little background information, though, on the purpose of
rightscale-init.

When users launch new ec2-images from the rightscale interface or tools,
Rightscale utilizes the user-data to pass some rightscale info to script.
This user data is ignored by ec2-init.  The user data is seen by the
rightscale-init script, and it acts on it, configuring the system to
do what the rightscale user wants it to do.

The rightscale-init can largely be viewed here as a "post-install" or
"first-boot" script for a full OS install.  Rightscale users then (with aid
of rightscale) utilize this hook to turn the generic image into a
functioning LAMP stack, MySQL server or whatever they want.  The idea is
that the image comes up, and configures itself and starts doing something
useful all completely automated.

>  - Uses static file names without further checks in /tmp, allowing symlink attacks
>  - Calls apt-get update/install in an init script, which is really not the way things work: please just make those dependencies
>  - wgets and installs third-party software (http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz) without any further checks (signatures, checksums, etc.)
>  - uses /opt/ which distro packages must not touch
>  - calls lsb_release without depending on it
>  - changes apt sources without further checks or questions
>  - assumes that there is an "ubuntu"  user and mucks around in /home. Ubuntu packages must not touch /home.
>
> By and large, this is totally inappropriate as an init script. Setup
> should be run in postinst, Ubuntu packages should be pulled in as
> dependencies, and automatically installing third-party packages subverts
> our trust chain and packaging policy. Please just package the gem and
> depend on it.

Just to be clear, it is not possible to run these as a post-install
script, or to depend on any set of packages at image-build (installation
time).

> Likewise, ./ec2-init calls regenerate_ssh_host_keys() if ec2-wait-for-
> meta-data-service() succeeds. Can the latter ever succeed on a non-ec
> setup? It must not ever, ever, ever change host keys on a normal system.
>
> Packages shuold be installable on a normal system without wreaking
> havoc. Especially those which have a totally inconspicuous package
> description like ec2-init. Please at least change the package
> description to say "THIS IS NOT THE PACKAGE YOU WANT!!!!11!!!", or
> (preferably)  make it inert on a normal system.

We have been discussing a way for the ec2-init to make the ec2-init
package inert if it believes that it is not running on a ec2 compatible
cloud.

I agree that that should be fixed.