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

[Urivan Saaib]

Hi Dave (and all of the subscribers of the list),

> I hope you spent some enjoyable time in the past days.

Oh yes, full house ! idem !

> The idea is to make it easy to provide additional software (not included in
> the skel) for openvds and to make it easy for the end user (i.e. the virtual
> server owner or the domain owner) to install such software easily in the
> space of the virtual server, without the intervention of the physical server
> owner (i.e. us).

Thats good ! I was thinking already on something like the Slackware package
management (tgz) but including items from rpm such pre, post, etc, quota
checking and privileges to install the software.

> By packading everything as add-ons, it would be easier to maintain skels

Plus, the admin will be relief from such tasks and be ableto focus on
other server/system issues.

> (i.e. we could have a single stripped-down skel) and the availability of
> many add-ons to personalize the skel. I could think of a system which will
> be very similar to the way normal packages (i.e. rpm) work in a standard
> linux server.

If this takes off, i can see the basic skel sized around 80-100 Megs, which
could be a big benefit for users that are not willing to have anything
they don't need and the hosting company don't want to include by default
(i.e. those who want to charge by number of running process or memory)

> 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).

If something like the pre,post, etc is included in this package management
system, then thats already solved (/etc/FDQN)

> 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.
> 
> The add-ons could be uploaded in a specific directory of the hosting
> server/virtual server where they could be found. Maybe we could have
> sub-directories in this main dir for the categories.

Creating/Using an XML based categorization of available packages to install
could be a very good way to go.

> The installation could be as simple as untarring the add-on in a /tmp
> directory and running the install/upgrade script which would in turn unpack
> the necessary files and modify the relevant system configuration files.

Yeah ! :)

> Another option we have would be the use of the rpm system from redhat. This
> will require us to have an updated packages database and vds-specific rpms.
> I can immagine that we'll have to modify the rpm manager so, writing a new
> and simple one could be a better choice.

We'll have to modify rpm to check for UID, quotas and privileges
from whoever is trying to install the package.

> PS: Please note the format of the subject. I think that it will be easier to
> follow discussions if we all follow this format when introducing new
> concepts.

I'm a little behind the current email discussions, probably there are
already some answers to this email, but hey, hollidays ! :)

Regards,
_______________________________________________________
Urivan Saaib
Presidente
CiberNET Mexico 
Email: address@hidden
Tel/Fax: +52 (646) 1757195