Re: [Openvds-devel] RFC-OpenVDS-0001, Ideas for the future (software packages)

[Paul Sladen]

On Fri, 28 Dec 2001, Dave Cost wrote:

> I could immagine that each add-on will be contained in a single "tar"
> archive with specific files inside (i.e. install/uninstall/upgrade script, a
> version information, a tar archive with the other files) much like the .deb
> packages.

I was waiting for you say this... :)   I don't think there is any point in
duplicating effort;  Installation in this style would be as simple as adding
something like:

  deb http://package-serve.isp.com/vdebs vsd/premium main
  deb http://package-serve.isp.com/vdebs vsd/default main

Your `vs20' customers might only get the second option, but the default
installation for your premium customers might give extra access to the magic
of Chilisoft, or an Apache package with FP extensions.  Which can then be
`click' installed.

It should be pretty easy to take APT, empty all it's prior knowledge and
drop it into the system with a fresh and empty Package Database;  *If* the
question of how to make APT execute within the hosting-server (and modify
all skels) when required, and how to make it only execute chroot()ed within
the VS when installing local packages like MySQL/vs Postgres.

Synopsis;  yes, I like it;  yes, I think apt would be a good base.

-*- -*- -*-

<Off-Topic>

> The difference between real rpms and the add-ons for openvds would be that
> the add-ons should be openvds-aware (i.e. they will been to be bounded to
> the ip address of the virtual server at installation time).

I've been considering the possiblity of hacking around such that bind(2)ing
to `0.0.0.0' is interpreted as only binding to VS's IP;  the problem comes
when the /hosting/ server wants to bind to `0.0.0.0'; and for that matter
how the kernel is supposed to know who pushed it the request.

Ideas?

</Off-Topic>

        -Paul
-- 
Nottingham, GB