[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Openvds-devel] Control Panels
From: |
Paul Marshall |
Subject: |
RE: [Openvds-devel] Control Panels |
Date: |
Mon, 10 Dec 2001 17:39:33 -0800 |
At 04:23 PM 12/10/01, you wrote:
>I like the ideas.. but I think the layout could be a bit different.. Too
>Ensimish. Think about this for a second...
>
>
> Rack Manager - Doesnt get installed to any one location, rather
>it sits on all of the hosting servers (physical servers)... meaning that
>you can access the rack manager from any one of the servers by going to
>a specific address. i.e. www.physicalserver.com/admin. This would allow
>for an unlimited number of levels for parenting. Each server would hold
>a variable for a parent server. The parent server would hold all of the
>data for the network and each child server would pull that data when it
>needs to. This allows you to offer more reseller type accounts without
>giving away where your central database is. For instance, say you have a
>reseller who has 100+ accounts. You could do one of a few things, you
>could give him a reseller account and allow him to add up to 100
>accounts, or you could sell him a dedicated server with the reseller
>option enabled. He would have full access to that one server and would
>be able to add/remove/modify VDS's as he chooses. Kind of like wholesale
>hosting. Now the parent server would only allow him access to that one
>server, but he would be able to login to his own control panel, thus not
>giving away details about your network hierarchy.
I like this idea.
> Skel Manager - Almost like the idea.. but I feel like the skels
>may be a bad way to go all together. I think that we could improve on
>this idea as a whole rather than trying to invent new ways to do it. My
>idea is to have one general skel, that is, a directory tree. This is all
>that will get copied to each VDS when it is created. No applications get
>installed at initial installation. The customer would then have to login
>to their control panel, to your proposed 'Application Manager' and
>install the necessary applications. Such as Apache, MySQL, ProFTPD,
>whatever THEY need. What this enables the customer to do is start with a
>blank template and create the ideal hosting solution for them. This
>allows ISP's to sell Virtual Nameservers.. a MySQL database server.. a
>News Server.. a Mailserver... each without sacrifising the CPU and
>memory that comes with the overhead of a default install as it stands
>now. You have to think, not everyone wants to install a MySQL databse,
>or PHP, or even a webserver for that matter. Why dont we leave it up to
>the customer to decide what they want?
I like this idea as well, however, I don't think that each server should be
configured from scratch. This was the idea behind the skels. While I like the
idea of leaving a very lean skel and installing everything else into each VS. I
think that there should be some default settings that can be customized.
Setting up skels this way would be easy since you only have one repository for
the packages and the different skels are simply a different list of packages.
For instance, when you at the configuration form, you have the opportunity to
select from the following skels.
Apache,Perl
Apache,Perl,PHP
Apache,Perl,PHP,MySQL
Apache,Perl,PHP,PostgreSQL
Custom
The custom option would give you full control of the packages on the server
allowing any package to be enabled or disabled. The other options would start
with the listed applications and their dependancies and then allow you to add
additional packages.
By the way, regarding the Webmin, I am not opposed to using the existing ACL
system as long as we can modify the security settings so that you get the same
results when you use Apache instead of the native web server.
Take care,
Paul
Paul Marshall -- President, Senior Consultant
Protelligence
Internet Consulting and Marketing
http://www.protelligence.com 415-721-0123