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

[Paul Marshall]

Hi,

I have been looking for a truck the last few weeks, so I haven't been following 
along, however, I have a comment regarding Apache in the skel. I would like to 
either see Apache removed from the skel or we need to make it more flexible in 
where it looks for Apache. For instance, I compile most everything from scratch 
including Apache. Since I install in /usr/local/apache, or the original, 
/usr/local/etc/httpd. As a result, none of the Apache commands work, because it 
isn't where freevsd expects it. There are plenty of tools for administering 
Apache. This also breaks WebAdmin, since it uses the freevsd commands. 

Another reason to pull Apache out of the skel is that some people may want to 
run different versions of apache, such as 2.0. In fact, the only thing that 
should be included in the skel is sendmail. Everything else should be installed 
into the individual skels.

Take care,

Paul

At 11:23 AM 1/6/02, you wrote:
>> 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.
>
>
>_______________________________________________
>Openvds-devel mailing list
>address@hidden
>http://mail.freesoftware.fsf.org/mailman/listinfo/openvds-devel

Paul Marshall -- President, Senior Consultant
Protelligence
Internet Consulting, Programming, and Marketing
http://www.protelligence.com  415-721-0123