Re: [Openvds-clients] RE: [Openvds-devel] Control Panels

[Joe Cooper]

Paul Marshall wrote:

> Hi Joe, At 06:18 PM 12/10/01, you wrote:
>
>> Paul Marshall wrote:
>>
>>
>>> 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.
>>>
>>I'm curious why you would want to do that (run Webmin under Apache)? 
There are a lot of good reasons not to, but I don't know of any good 
reasons for doing so...
>>
>
> There are two reasons to use Apache over miniserv.pl.
> The first reason is to conserve memory resources. I'm not positive, 
but I believe Webmin uses about 5MB of RAM. If Webmin is installed on 
all of your VSs, then that can consume an unnecessary amount of RAM. If 
Webmin can run on one only a few machines and still control multiple 
servers then, that would be fine. Nick and I were discussing this 
offline today, and I know it has been discussed in the past by others.


Perl takes 5MB (maybe--I'm just guessing about what you're seeing take 
5MB when running Webmin).  miniserv.pl is tiny.  Perl has to be in 
shared memory anyway for the administration scripts, and for any client 
CGI that is using perl...so several miniservs will not take 5MB 
each--perl will take 5MB and each additional miniserv will tack on a few 
KB.  Looks like well under 300K for each additional client instance of 
Webmin.

> The second reason is so that you don't have two web servers running. 
Why run two webservers when 99% of all Virtual Servers will be running 
Apache anyway?  Why run an additional webserver that is only used for 
administration?

Because it has to run as root.  You'll have to run either two Apaches, 
or Apache+miniserv.pl

I won't run clients websites on a webserver running as root.  Will you? 
 Imagine--arbitrary cgi scripts and more running under a webserver with 
root access...shudder.

Perhaps if we alter the root requirement of Webmin, and have it operate 
as independent 'admin' users in each VDS, we may find it necessary to 
switch to Apache (I'm still not convinced of this!  Users can share 
processes in shared memory, including the perl interpreter.  I don't 
think anything in VDS changes that.)

>>The good reasons for using the Webmin miniserv.pl webserver instead 
of Apache, since I'm sure someone is asking:
>>
>>Small and easily audited for security.  Has proven quite secure and 
robust in its ~three years of heavy use all over the world.  Webmin 
overall has a quite good security record, and miniserv.pl has been 
flawless in the two+ years that I've been using it.
>>
>
> I don't doubt that. I think it works fine for individual servers. 
However, I feel that running an instance of miniserv.pl on each VS will 
consume too much RAM. Not that RAM isn't cheap now, but we have all seen 
it skyrocket in the past.

Almost certainly not an issue, as described above.  A few hundred 
miniservs /might/ be a concern (since miniserv requires one process per 
client, much like Apache on many architectures), but I don't think it is 
any more a relevant concern than having hundreds of Apache threads or 
processes.

Also, how many well-populated webservers do not have perl running most 
of the time?  I suspect that's pretty much a given on most servers--so 
no gain in trying to eliminate Webmin's use of it (which is 
impossible--perl has to run for every module, so there has to be enough 
memory to pull perl in regardless of what webserver is run).

>>That's not to say that Apache isn't secure, because it is, but the 
environment is so much larger and easier to misconfigure--I don't like 
the idea of a misconfiguration so easily leading to an exploit.  Apache 
would have to run as root and outside of a chroot jail.  I prefer a tiny 
perl webserver that I can study thoroughly in a couple of hours to 
Apache which would take years to fully understand and audit.
>>
>
> But Apache is already installed. Any Webmin configuration in 
httpd.conf could be blocked off with comments to indicate that that code 
should not be modified. That won't prevent malicious misconfiguration, 
but it should prevent accidental misconfiguration. You'll have to 
correct me if I am wrong, but even if the webserver is small, Perl has 
to remain loaded into memory which is where the resource consumption 
comes from. You probably know this better than I, so correct me if I am 
wrong.

Yes, perl does have to remain loaded--but it can be shared.  I'm not 
sure if we can share it among multiple independent VDSs (but I'm not 
convinced running a separate Webmin in every VDS is needed or 
ideal--you're making assumptions about my plans for using Webmin--I 
don't picture Webmin in every virt).

Perhaps if every virt has to have it's own Webmin we'll benefit from a 
move to Apache (but I still have my doubts--someone should test it if 
they're really worried about it=-I'll test in a couple of weeks if it 
hasn't already been done).

>>It's fast enough.  Using Apache will not speed up Webmin in any 
useful fashion.  With an appropriately designed module hierarchy 
(client->reseller->server owner->cluster administrator) there's no way 
to overload the miniserv webserver.  Administration is not a high load 
environment.
>>
>
> Speed is not the issue.

Ok, good.  Two problems with miniserv down (I think).

>>Provides additional ACLs that Apache can't without quite a lot of 
additional tweaking and configuration.  miniserv.pl can provide IP level 
access controls in addition to other cool stuff, like SSL certificate 
authentication.  Sure, you can do these things with Apache, but why not 
point and click your way there in about 20 seconds?
>>
>
> I agree, these are cool features of miniserv.pl, however, I would to 
see the IP level access and SSL cert support for Apache. Again, so you 
only have to run one webserver.

You can.  It just isn't automatically handled by Webmin.  But creating a 
set of modules for VDS is going to be a lot more work than these two 
tiny little issues (and they are tiny compared to the monumental task 
ahead for the GUI creators).  You'll have to implement these features 
from scratch if you opt not to use Webmin--they just have to be ported 
to Apache if you start with Webmin.

>> At least IP level ACLs can be configured.  I'm not sure how SSL 
certificate logins are handled (I don't mean https connections...I'm 
talking automatic logins using no password, just a certificate).
>>
>
> These are definitely nice features and only minor hurdles.

Yep.  Agreed.

>>Anyway, I /strongly/ urge not switching from miniserv to Apache.  It 
just doesn't make sense to add more complexity to a beautifully simple 
setup (for anyone who has ever installed Webmin, you know that given the 
complexity of the tasks it tries to address it is amazingly simple). Ok, 
so I'm a long time Webmin bigot...I love everything about it, and I 
don't want to change a thing.  ;-)
>>
>
> I know you probably have more experience with this than any of us, so 
tell us how we can do this without consuming all the resources. 
Unfortunately, I don't think Webmin will work without some modification, 
however, I don't feel that it will be major. I think it will be much 
easier to modify Webmin to work with XVDS than it will to create a brand 
new admin utility.

Oh, Webmin definitely won't work without modifications as a complete 
management tool.  Right now, it is built on the idea that it runs as 
root and can do anything.  If you want one in every VDS, you've already 
got your work cut out for you without even adding features specific to 
OpenVDS.  I suspect a stripped package (removing or patching the parts 
that are root specific or useless to a VSD--like disk and network 
configuration, etc.--that runs with admin permissions rather than root 
will answer some of the needs, but is probably too advanced and complex 
for all but the reseller of domains.  Even they probably want something 
a lot simpler.  The webserver owner (whether thats the hosting company 
or a smaller fish) will already have a root Webmin of their own.

As I said, I don't picture giving every VDS a private Webmin.  I would 
grant them their own modules suitable for their service level, which in 
some cases will borrow heavily from the standard modules but generally 
will be simplified for mass use.  It might be appropriate to clone 
modules for each client's Apache/Sendmail/etc...None of these things 
requires a Webmin for every VDS.  Note that I'm not avoiding a Webmin in 
every VDS because I expect them to eat up too much RAM (though they 
might), but because it adds a level of complexity and security concerns 
that seems unwieldy and probably unnecessary.

Then again, I might be wrong-headed in my approach.  I haven't done the 
research or the experimentation needed to know.

Which is why I keep wanting to shut up until I begin coding on this 
project (which can't happen for a couple of weeks due to other obligations).

But we're mostly agreed here.  Webmin is a great starting point 
regardless of where the ending point is.  Either as a framework (for 
OpenVDS specific modules), or as the end in itself (for a Webmin in 
every VDS).  Both might be appropriate, and neither is at all 
difficult--it's just a lot of grunt work and experimentation.

I'm really done talking this time.  Really.  I'll talk more about 
Webmin, and a web based interface for OpenVDS in a few weeks when I can 
spend time on making it happen.  Until then, it's all speculation.

Everyone else, of course, is free to chat all you like.  I'm only 
conserving my own steam for actual work.  So I'll be back into lurker 
mode for a while.

BTW-If someone does start a Webmin module set for OpenVDS, I will help 
out as needed, even now, with advice and code.  But I can't devote 
full-time to it, so I'm holding off until I can.
--
Joe Cooper <address@hidden>
http://www.swelltech.com
Web Caching Appliances and Support