Re: [Openvds-devel] Control Panels

[Paul Marshall]

Hi,

I mentioned that I would make a post on control panels so I figured, Clint's 
post was a good place to start. 

At 09:45 AM 12/10/01, you wrote:
>There is already a great groundwork laid out for the control panels in
>the VSD protocol, that I believe can be used to develop a set of very
>useful administration scripts to be used by both network administrators,
>system administrators, and end users alike. I think we should try to use
>this protocol wherever possible. 

I agree. The only problem with the protocol is that program locations are hard 
coded and not flexible. This can create problems for people who install from 
source or use different installation directories. Apache is a perfect example. 
FreeVSD assumes that Apache is in one of the default Red Hat locations. It 
doesn't check for the default locations of an Apache source install. As a 
result, I either have to patch FreeVSD or the web commands don't work. Since 
the existing WebAdmin scripts use the protocol to execute commands, the web 
commands don't work there either. I think that any programs that are used by 
the protocol, should have configurable locations. This will make the system 
much more flexible. 

>Now, there are many many ways to go
>about doing so, we can do them in the form of a CLI, which has already
>been done and works great, the only downfall being that not everyone is
>comfortable with CLI, nor does everyone want their clients to have
>telnet/SSH access to their machines. There has also been talks of doing
>some kind of Windows App for administration, the only problem with this
>being that not everyone runs Windows, and there are always problems with
>the systems that you are running them on, such as version conflicts and
>the like. A web-based solution is the only feasible solution that gives
>you the functionality you need as well as staying platform independent.

The fact that there can be many interfaces is nice. Users have different needs 
and experience levels. Most administrators could do without any interface but 
the command line. I am much faster at that than pointing and clicking. However 
end users, may have trouble with a web-based control panel. Some will have 
trouble not matter what you give them. 

iServer, a Virtual Server pioneer, had a CLI, a web-based control panel, and a 
Java-based desktop control panel. They had something for everyone. Each 
organization has different needs. None should be locked into any one interface. 

>In my opinion we need to create a unified and "official" control panel
>system to be used with OpenVSD, that is automatically generated with the
>installation of the scripts. 

I strongly disagree. I believe that the only supported interface should be the 
CLI and protocol. This allows the system to remain modular. Again, no one 
should be forced or even directed to particular interface. I think that the 
interfaces should remain separate projects. The control panel is how hosting 
companies differentiate themselves. That is where they get their value. If 
everyone uses the same control panel with the same features, then the only way 
to differentiate your self is on price. I don't want to be forced to compete on 
price alone. Everyone is going to have different ideas about what features they 
want to offer and how much they want their customers to control. Interfaces 
should be developed as separate projects. No one should be discouraged from 
creating an interface because only 1 is supported. If someone  wants to create 
a desktop-based interface in VB or Delphi, great. They obviously see a need for 
it in their organization which means others may find it useful as well. If he 
wants to create it as open source, great! If he wants to sell it as a 
commercial product, that's great too! He should receive our support and we 
should have a product flexible enough for him to integrate with. That is good 
software design. 

>The benefits of creating one supported
>control panel are as follows:
>
>1 - You only have to support one codebase. Anyone who contributes or
>wants to contribute is only working with one model and not several. Also
>supporting the scripts is alot easier if you know that everyone is
>dealing with the same model.

If the interface is a separate project, we don't have to worry about 
maintaining or supporting any interface. If we design a flexible, documented 
API, then designing any interface will be a lot easier.


>2 - Documentation for the scripts becomes easier as there is only one
>control panel to write documentation for.

Once again, if this was a separate project, the that team would be responsible 
for writing the documentation for it. Clint, I would think that you might be a 
good person to lead that project. 


>3 - Through the use of web-based scripts, many features and
>functionality can be worked in to make the product more appealing to end
>users, such as a web-based telnet/ssh client as found in webmin, as well
>as a web-based file manager so end users can administer their sites from
>anywhere with an Internet connection. This functionality does not then
>have to be migrated to another medium, such as if we were developing
>several types of interfaces.

I agree with this. Any open source interface needs to be flexible and contain 
modules or plugins such as Webmin. However, these features need to be setup so 
that they can be enabled or disabled. You don't want a MySQL control panel 
showing up if you don't have MySQL installed. 

>4 - Many users of other systems are already accustomed to using
>web-based scripts, so companies migrating from another solution (such as
>Ensim, or Cobalt) do not have problems with their end-users not being
>able to administer their sites.

This will depend on the organization. If the end-user is coming from Verio, 
they may be acustomed to the Java-based Ace that was originally distributed by 
iServer.

>5 - Web-based administration scripts can use functionality beyond the
>scope of the VSD protocol, such as Java applications, DHTML
>applications, CGI and Perl applications, as well as any third party
>modules that someone wants to add to them. For instance, if someone
>wants to add a bulletin board plug-in to their skel, they can easily
>integrate the UBB control panels into the VSD control panel for a
>unified customer control panel.

I agree with most of this. I definitely think that a web-based administration 
utility needs to have module/plugin support as webmin. However, I think that if 
someone writes a plugin, it should be written to conform to the format of the 
existing admin script. The interface needs to have a certain level of 
consistency. People need to be able to expect things to work the same way in 
one area as they do in another. For instance, you don't want your interface to 
be a container for existing control panels. While that would be the easiest 
solution, I think it would look sloppy. Webmin has a great system.

>There is no reason to redefine the research that many companies have
>already done. Large companies such as Cobalt, Sphera, Ensim, and even
>Idaya have integrated a web-based solution because it is the easiest to
>work with as well as being the easiest to support and develop. We would
>be fools to think that there is any other platform that will satisfy all
>of these needs as efficiently.

I am a big advocate of not reinventing the wheel. However, I think we would be 
fools to think that one interface will fit everyone's situation. In addition, 
we would be fools to think that web-based solution is the right one and worthy 
of any support. 

>Here is what I propose. Let us make up a team of developers, which I
>would like to volunteer for, to create an official set of administration
>scripts to be included in the next version. These scripts will be the
>only scripts supported by the OpenVSD project (as far as documentation
>and mailing list support). Other people are more than welcome to create
>some other types of applications to serve a particular need if they so
>choose, but maintaining their codebase is their responsibility. This
>will make the development of the control panels more efficient and in
>the end more useful and user-friendly.

While I don't think that the project should be part of the OpenVSD project, I 
do support building a team to develop an open-source web-based interface. I 
also do not think that this should be the only supported interface. Suggesting 
that only messages regarding this interface should be accepted on this list is 
a bit elitist, don't you think?

>I would like to hear your criticism on the proposed idea, as well as
>anyone that would like to volunteer for it.

My suggestion would be to base an open source solution on Webmin. There is no 
sense in reinventing the wheel. It would take years to develop a system as 
comprehensive as Webmin. I have used it and installed it on my virtual servers 
for testing. While I don't like the fact that uses it's own webserver which 
chews up resources, it can be setup to use Apache, but it affects the security. 
I would also like to see it support storing the users and ACL info in a 
database. 

So... There are a couple of options here. 

1. Use Webmin as it is, and simply create a few plugins to deal with VSD 
functions, such as users, quotas, privileges, etc. 

2. Rewrite the container portion of Webmin to use Apache while maintaining the 
user-level security and the ability to store this in a database. This system 
could be written in either PHP or Perl, I would suggest PHP, one, because it 
has a quicker development time, and two, because you could design it to support 
either PHP plugins or the native Webmin plugins. There are hundreds of Webmin 
plugins for controlling just about anything.

If that is the direction you choose to go, I would be happy help out. 

Take care,

Paul



>Thank you.
>
>Clint Nelissen - Technician
>Digital Internet Services Corporation
>Phone - 760-776-0800 x 300
>Fax - 760-776-0076
>http://www.dis.net
> 
>
>_______________________________________________
>Openvds-devel mailing list
>address@hidden
>http://mail.freesoftware.fsf.org/mailman/listinfo/openvds-devel

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