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

[Clint Nelissen]

Dave,
The idea is great. I have been saying something like this should be done
for a while now.. (read some of my earlier posts).

Sphera has the same idea in place and it works very very well. Each VDS
gets copied as just a base skel.. no apps in it at all. Then the site
owner can tweak out his VDS to his specs. You have to remember that not
everyone is going to be using the VDS for website hosting... they may
want one for an email server, or a nameserver or just an FTP server...
Hell you never know what people want to do. But the bottom line is, you
have to let your customers decide what options are best for them. This
is the absolute best way to do that.

Lets do it.

Clint Nelissen - Web/Systems Technician
Digital Internet Services Corporation
Phone - 760-776-0800 x 300
Fax - 760-776-0076
http://www.dis.net
 


-----Original Message-----
From: Dave Cost [mailto:address@hidden 
Sent: Friday, December 28, 2001 10:20 AM
To: Openvds-Devel
Subject: [Openvds-devel] RFC-OpenVDS-0001, Ideas for the future
(software packages)


Hi all ;-)

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

This is an "official" request for comments on an openvds feature that
has
been in my mind for some time.

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

For example:

I would package/download a "webalizer" add-on which will be made
available
somehow for installation. The VDS owner (or the domain owner) will have
a
"push-button" interface to install this package on it's server. Once
installed, the add-on will start functioning immediately in the virtual
server as if it was there from the beginning.

By packading everything as add-ons, it would be easier to maintain skels
(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.

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

Further, upgrading an add-on will not require a complete rebuild of a
new
skel, and a migration of the whole virtual server. It will be just an
upgrade of the sindle add-on with no downtime if not necessary (i.e. a
webalizer upgrade will not require to stop the whole server, and re-link
it
to a new skel).

I can think of other advantages, like:

*) Distribution of general-purpose *small* skels ready to run
*) Distribution of stand-alone add-ons (servers, software, control
pannels
etc)
*) Development of add-ons with no synchronization between developers.
*) Easier installation of new software and maintenance of existing
virtual
servers.

I understand that I'm targething the hosting industry here, but I think
this
is what we all need right now.

-- How to make it --

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.

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.

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.

Comments welcome.

Dave

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.


_______________________________________________
Openvds-devel mailing list
address@hidden
http://mail.freesoftware.fsf.org/mailman/listinfo/openvds-devel