[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Framework for web control panel.

Sorry if I preach for my own church here, but I truly think you are
mislead herel! :)

Marc Aymerich wrote:
>>> Hi everyone,
>>> I'm planning to write a web control panel & billing system from
>>> scratch. The project is for a little NGO ISP that offer hosting, mail,
>>> VPS... Yeah, I know there are a lot of projects that do that, but
>>> really we need to develop our panel from scratch.
>> Why?
> Hi thomas,
> After checking a lot of panels (DTC, SysCP, ISPConfig, ...) I can say
> that the most important reason is that our members can use our domain
> and subdomains of it for his web pages. (Like this: user.ourdomain.org
> or ourdomain.org/user). This seems silly but breaks with the schemes
> of most panels.

Well, it does work with my panel (DTC) without any issue, I know many
hosts using this functionality. You just add subdomain.example.com as if
it was a domain like example.com and everything works as expected (like
emails@subdomain.example.com, etc.). There's even everything needed at
registration time so you can register the subdomain of example.com if
you like it this way.

> In the second place we need a web panel with billing system. This
> discard 70% of the panels.

Not DTC, it has it (customizable email reminders in multiple languages,
pdf invoices, multiple payment gateways, etc.).

> moreover we are a NGO and we have a
> membership quotas, exempt of taxes, that includes some services, but
> otherwise, some members require special services like VPS or a big
> development on his web page, in that case they have to pay with taxes.

Tweaking the billing system just for taxes reasons could be a nice
contribution, it's not an argument to start everything over from scratch
(unless you'd like to bill that NGO a lot of money for years of

In the case of EU NGO, I see no reason why what we did wouldn't fit,
they are subject to the same tax system as other entities (that is, VAT
is to be paid in the country of the payee if he has a VAT number). In
USA, there's no VAT on internet services. What is your case, I don't get it?

If it's for billing big developments, then you can use a "fake"
dedicated server, I do that often (or of course, make invoices by hand,
it wont kill you if it's few times a year for a very long dev. and big

> Finally, the most panels are designed for environments where all
> services are in the same server, we have the services spread over
> multiple servers.

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.

Lets consider this:
- 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.
- 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).
- You will also be running a mail server on all of your servers to at
least receive mail for root.

All together, this will NOT improve security, as all daemons (apart web)
will end up running on all servers anyway so this is not an argument. In
fact, you will just end up increasing complexity for no valid reason.

So what are your other arguments for running in multiple servers instead
of just one?

Anyway, with a very small modification to the cron job to run only
selected tasks, and an NFS mount for /var/www in your high performing
NAS, DTC can do that as well. Tweaking it so that it is really
implemented by default fully shouldn't take so long (and I'd be happy to
help you do that).

> Yes, I know that is possible take any of the
> existent panels and with some modifications we can adapt it to our
> system. but anyway the data migration, system adaptation and panel
> modifications sure that will take a lot of work.

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 think that we can
> invert this effort to do a good database and simple web interface, and
> slowly add the functionalities. Thats what I'd prefer as i enjoy doing
> this kind of things :)

If your only argument is that you will enjoy doing it, then great! I do
also love doing this programming. But otherwise, there's no rational
here, unless charging your customer for years of development.


Reply to: