RE: [Openvds-devel] Control Panels

[Clint Nelissen]

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.

        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?


As for the rest of the ideas... I like them all. So here is what we
would have.

www.physicalserver.com/admin (or /whatever) - Network and server
admins.. Options change based on login. Data gets pulled from the parent
server.
www.vds.com/admin - VDS Admins and users... Also based on logins, except
the data is pulled from a local database maybe even based on UID/GID
i.e. "if ($group = admin) { } else if ($group = user) { }". When an
admin logs in.. they get one screen and when a user logs in they get a
different screen. Easy enough to do.

Any thoughts?


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


-----Original Message-----
From: rick oneil [mailto:address@hidden 
Sent: Monday, December 10, 2001 2:24 PM
To: Openvds-Devel; Clint Nelissen
Subject: RE: [Openvds-devel] Control Panels


I think that the web based administration is the ticket as well.  We use
ensim technology now and I've become very imtimate with the technology.
This
will be obvious in theis email.

The webmin based product is ok, but the real solution is total
management
with what I propose as the openVDS "Rack Manager"

--------------
--------------
RACK   MANAGER
--------------
--------------

"RACK MANAGER" -  this, I propose, should be the chief system
administrators
interface for all openVDS hosting servers (i'll call then PHYSICAL
SERVERS
from this point on for clarity).  There will be no customer or reseller
access to the Rack Manager.  Best case scenerio is that it resides on a
different physical server then any used for VDSes.  System admins (SA's)
will log in to this much the way the webadmin 1.4.5 is setup, using
apache
mod_auth_mysql directives and the main user database being setup on
mysql.

        Top page of rack manager will list all physical servers, with
active
monitoring of selected services.
                click on a physical server, it expands to show all VDSes
on that physical
server
                        click on VDS link and it expands to show
applications installed on that
VDS
                                (also can get properties for that VDS
and get basic info on VDS,
customer information,  with links to launch VDS manager, User Manager,
etc.

------------

within the rack manager the following functionality should be present:

        USER MANAGER - this section is where the SA can assign other
SA's,
customers and resellers thier access levels and other information.  it
should include a phpMyAdmin type interface for the SA to add fields to
the
mysql database so the database can optionally be used for the ISP's
customer
database.

        SKEL MANAGER - here we can generate skels, connect to a central
skel
repository (public and/or private, SA's choice) where skels can be
stored,
with description of features, versions and installed applications.
                this skel manager can be used to deploy skels to
physical servers.
                the skel manager should be able to install rpms to skels
easily
                rename copy and delete skels
                have a mysql database table for skels for version
control, apps installed
and other comments

        PHYSICAL SERVER MANAGER - create new physical servers, act as
ftp or nfs
source for a new installation of a physical server, generate the boot
disks
for whatever os that the physical server is being installed on (Redhat
6.2,
Redhat 7.2, Redhat 8.0?, Debian, Freebsd...)
                choose the openVDS version to install
                setup openVDS openSSH specific port for communication
from rack Manager to
Physical Servers

        VDS MANAGER - create, modify, suspend and delete VDSes on
physical servers.
functionality should include modifying the following attributes on a VDS
                admin password for VDS
                ip address for VDS
                ip address quotas - (including ranges, subnets)
                name based domain quotas
                ip based domain quotas
                cpu quotas - percentage of available cpu resources
                memory quotas - percentage of available memory quotas
(including swap)
                process quotas - number


        APPLICATION MANAGER - featuring the instalation of applications
on VDSes
along with connection to a central application repository to store
openVDS
ready applications. These should be RPM's encapsulated in a openVDS
"wrapper" that includes openVDS specific setup information.  The
Application
manager should also be able to wrap the RPMS and additionally submit
them to
the repository.  An optional feature for the encouragement of commercial
vender development for openVDS is to offer an optional unlocking key for
the
openVDS wrapper.


        SIGNUP MANAGER - also, to facilitate further automation and
instant
provisioning, that RACK MANAGER should include a facility for accepting
posts from trusted hosts to
        1.)     create new customers and assign them to a pre-created
VDS, makeing the
account instantly available.
        2.)     create new customers and assign them to a general
hosting VDS for
single website sales
        3.)     add new services to existing customers

-----------------------------------------------------------
------------------
------------------
Reseller Interface
------------------
------------------

running on the same physical server as the rack manager is the Reseller
Interface.

when the customer(reseller) logs in, they see only, all the VDSes that
they
own.
much like the current webadmin logic, they can own multiple VDSes and
multiple people can have access to thier own list of VDSes.

when a selection to manages a certial VDS is made, then the Reseller
interface will simply send the user to the webmin based VDS Control
Panel
that is installed on each and every VDS.

------------------
------------------
VDS Control  Panel
------------------
------------------

on each VDS

http://vdsFQDN.com/admin - redirects to the VDS webmin for that entire
vds,
(SSL optional)
                this is where the "openVDS Webmin"  should go.

http://www.vdscustomerdomain.com/admin - site manager for virtual hosts,
or
the resellers customer login
        integrated stats, apache config, file manager with tar and
backup
facilities, email manager, majordomo, spam filters...
http://www.vdscustomerdomain.com/username       - user manager for each
virtual
domain


please comment on this proposal.

thanks,

Rick O'Neil
address@hidden