Re: Framework for web control panel.
Thomas Goirand wrote:
I read about this motivation many times, however, there are very rare
cases where the load makes it a real need. In such case, you typically
run a single website, and then using a control panel isn't really
justified, as you would run only apache and a single vhost per server,
and maybe a reverse proxy like HAProxy to do the balancing. In all other
cases, running all on the same server reduces so much complexity that
it's the best choice to make.
Unless you've got enough hosting customers that one physical machine
can't handle all those sites, never mind the added memory load of a
leaky hog like BIND, plus the load of dealing with all the spam that
inevitably comes in to the one customer who *insists* on using a
catchall account. (Never mind the mail load for the other 999 customers.)
I've done this dance of trying to wedge everything into one box. Even
on a very small scale (~40 domains, at a time when spam was only ~10% -
if that - of the overall mail volume), it works for a while, but sooner
or later something will blow up and *all* services for a bunch of
customers will go down. (Give them a pile of hemp strands, and some
customers *will* industriously go about making a rope to hang themselves
with... and in a fully shared-hosting all-in-one environment, they may
well take a lot of others with them.)
- Running a MySQL service over network adds a lot of latencies and
issues, will load your switch, etc. (the one that will pretend that
running over Ethernet is faster than a Unix socket is just plain wrong).
So you want to avoid this if possible, especially if you don't have
enough load to need lets say 3/4 MySQL servers is master/slave mode.
I'd say GigE latency is not an issue compared to running the server into
swap because someone fired off a messy query. Ethernet might not be
faster than a Unix socket, but running your database traffic to the next
machine down the rack over the second gigabit port on a private (V)LAN
reserved for just such traffic is really unlikely to be slower than
trying to share out RAM sanely between your database processes and web
traffic.
- Then you may say you want to run DNS on another server as well, but
you will also have to run a DNS server on the apache and mail server to
speed-up resolving (caching name server).
Mmm, not quite IME. A caching server is different from an authoritative
server, and most best-practice documents I've seen say you shouldn't mix
the two.
Which means your authoritative zones shouldn't be local to the DNS cache
on the web server. There's also the issue of distributing the
authoritative data to a second machine anyway - no DNS system I've used
knows how to distribute new zones to another server automagically. (I
know there *are* a few, but IIRC the overhead is far greater than you'd
gain by running full DNS on every box.... and most rely on, yep, an SQL
database backend.)
FWIW, here we seem to getting along fine with our servers (10 that I can
think of offhand that *need* responsive DNS service) all using the same
two dnscache servers as our connectivity customers (dialup, DSL, cable,
fibre, wireless, and various copper loop services). Two of our four
authoritative tinydns servers happen to be on the same physical machines
as the caches (largely due to power capacity issues, IIRC), but they
could just as well be separate machines; the caches don't have any
special knowledge about the authoritative zones.
- You will also be running a mail server on all of your servers to at
least receive mail for root.
mmmnope. nullmailer forwarding everything to a proper role account
mailbox (or alias) is all you need (although nullmailer needs to be
kicked once in a while IME). You *really* don't want to have to log
into every single box to receive cronspam and other administrivia.
(I've been there. It doesn't scale well beyond two or three machines.)
Further, load spikes on one service can affect any others; if you have
physically separate boxes for different services, your authoritative DNS
won't stall out when you get a flood of spam coming in, and a sudden
order-of-magnitude spike in web traffic to one site (linked from eg
slashdot) won't kill your POP mail service (and SMTP, and webmail...).
I think you are really under-estimating the programming work here.
There's nothing really complicated, just YEARS of work, literally. Be
prepared to having half of the needed functions in 2 or 3 years of time.
In the past, I heard so many people pretending that they would write
such a panel, but at the end, only a handful ended with something that
practically does what it is supposed to be, because its just too much work.
I have to agree with this. I wrote a simple set of scripts to manage
virtual hosting at one time, but the interface was pretty simpleminded.
It was functional enough for a small ISP (~1500 dialup customers and a
bit of domain hosting), and I opened the email management for domains to
customers (add, remove, change password, change forwarding), but it
still lacked a few things on the internal side (delete domain, make
changes of any kind to DNS after initial domain addition), and never got
integrated with any of the billing.
Our current billing system has been in use for a couple of years, after
several years in development (and, IIRC, one false release some time
before it really got put into full use), but it's *still* under active
development - of course, it has to cope with all the new services we
keep adding on as we buy smaller ISPs. <G>
On the other hand, it's only in the last 6 months or so that it's had
any visibility into email accounts for hosted domains.
And this is with a more or less dedicated group all working on various
aspects of the billing/recordkeeping side of the system - and another
few people working on automation and scripting on the mail servers.
-kgd
Reply to: