openvds-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Openvds-devel] RFC-OpenVDS-0001, Ideas for the future (software pac


From: Dave Cost
Subject: RE: [Openvds-devel] RFC-OpenVDS-0001, Ideas for the future (software packages)
Date: Sun, 6 Jan 2002 11:23:15 -0800

> Urivan Saaib

You're not behind at all :) There's been only approvals and an open job for
doing it.

I've been thinking on the way to implement things without breaking the
mod_***** conventions and the svsdadm utilities. The thing is that openvds
pretends to know way too much about the configuration files of apache,
sendmail etc.

So, the only thing we can do now, is to remove from the skel anything but:

        *) Apache
        *) sendmail
        *) proftpd
        *) others?

whose configuration files are directly managed by the vds daemon.

We will need to implement a mod_package module for vds which will have some
basic functionality like:

        *) query for available packages
        *) install/remove a package
        *) check package dependencies
        *) package depended configurations.

The last point is somewhat more complicated, but i can break it down in:

        *) package specific variables (i.e. configuration options)
        *) datatypes for each variable (i.e. numbers, ip/hostnames)
        *) datarange for each variable (number range, prefedined choices)

So, given any package, it will contain a description of the necessary things
the user shall provide before installing it. This way we can force some
variables like the binding address and/or port to be something specific to
the virtual server rather than being user-specified.

Information about available packages could be kept in a database or easier
in a text file which will be vds-managed on the virtual server. This way you
can customize the packages available to each customer and be able to create
"service plans". Obviously, the package files will be hardlinked from a
central repository available to all virtuals (which packages to link can be
decided later based on the plan).

All this is conceptually simple, but will require some coding.

I'm lending to using the existing RPM manager with no modifications
whatsoever, for some simple reasons:

        *) Quota is automatically checked by the system
        *) Uid check is not necessary as all will be done trough the mod_package
module in vds
        *) Package configuration can be performed in the %post phase with simple
sed/awk/perl scripts which will replace predefined variables in the config
files with the user-supplied values (the same way #HOSTADDR# and #BINDADDR#
work now in /etc at vds creation).
        *) We could take standard SRPMS packages and relocate them in /usr/local
with simple steps:
                -) Change the config files to include the #VARIABLE# parts
                -) Change the ./configure in the %prep state to compile in 
/usr/local
                -) Change the %post sections to replace #VARIABLE# with usable 
values
                -) include a descriptor file (vdspackage-config) which will 
list the
variables that are to be specified for installation.

        *) We could use the standard /etc/rc.d/init.d/xxxx startup scripts
        *) All this would be more compatible with third party utilities like 
webmin

Hmmm.... am I givig out too much ideas to P-r-o-VSD?

Dave.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]