Re: [Openvds-devel] Control Panel for OpenVDS-2

[Eje Gustafsson]

Hmm now doesn't that sounds bitching.. How can I help out making this
happen ?
Also something to keep in mind probably is that one probably want to
keep somewhat access over apache/sendmail so that you don't sell a
$99/mo virtual server and someone setup and in their turn sell
shitload of virtual domains.

My first freevsd server is live since a while back and I'm moving the
remaining of my linux domains on this machine.  Today I miss a good
control panel. I setup vsdadm so the customers that is on it can add
users and fix virtual domains easier.
But as for my admin part of it there is a ton of things to do to just
add 1 domain. First add the domain. Then bevs into the virtual server
set password, fix mysql db password, fix phpmyadmin, fix this and
that. So getting ready to write myself something to automate a lot of
these tasks. But I hate to see it being "wasted" development time for
something that will not be used in 2-3 months or something like that.
I don't know much php or perl. However I written asp and C/C++ stuff
before. I worked a bit with mysql (repairing databases, importing
databases, and lot of adminsitrative tasks like that and doing so I
also learned quite a bit of sql commands to create tables/update
tables select specific items from tables not to mention you need today
to do pure sql commands to add users and domains to vsdadm).

However I decided if I was going to maybe start do something here I
better learn php so I picked up a book about it the other day. And off
I go.. -lol-
I have one wish that is that webmin used php because php is SOOO much
faster then perl. (ever seen the difference between vbb and ubb ? or
anything else that is written in php respectivly perl).

Monday, January 14, 2002, 00:54:02 AM, you wrote:

>> What is the status. Who's in "charge" of the openvds project?

DC> Currently I'm the only active developer. OpenVDS-2 is still a concept more
DC> than a real thing, but the basic pieces of it are working. It's a matter of
DC> placing everything together.

DC> So far, it seems possible to have a real root user in each VDS (instead of
DC> the pseudo-root admin) and what is better, no patches will be required for
DC> the packages installed in the VDS. Furter, apart from the kernel which is
DC> shared between the virtuals, all other software can be completely
DC> personalized. This will allow to run a debian image in one virtual and a
DC> redhat clone in the other and furter, it allows to update packages in the
DC> virtuals separately. It's possible to hard-link some files to save space at
DC> the expense of freedom to the virtual-root user, but there won't be anything
DC> like the skel in version 1. I'm thinking more of a collection of rpm's which
DC> represent a functional server and which are installed on each new virtual
DC> automatically (something very similar to a kickstart installation).

DC> Still the administrator of the hosting server has enough control to limit
DC> the root's of the virtuals from taking down the system of from binding the
DC> wrong ip addresses or using too much CPU resources.

DC> But all this is RAW power and needs to be implemented properly via control
DC> tools and possibly with a centralized control like svsdadm can be. In fact,
DC> apart from the authentication and encryption layers and some of the freevsd
DC> protocol, the rest of the source from FreeVSD appear outdated and useless
DC> and most of it will have to be rewriten. For example, there's no need for
DC> the hosting server to manipulate the configuration files of the virtuals
DC> directly, nor this is possible given the huge variety of packages and
DC> software that can be installed in a virtual (this is why I think the
DC> administrator of the virtual needs a webmin-like pannel to operate more
DC> easily).

DC> OpenVDS will give you VDS which will be as similar to a real servers as it
DC> gets. This can be good or bad, depending on your point of view ;-)

DC> Dave.