DISCLAIMER: The following are ideas written by some users and contributors of DTC, nobody started to implement them
Hi all,
This is a place holder for those (George, rudd-o, Damien) that want to rewrite the panel from scratch. Feel free to write here.
'' I've started my own page with ideas and stuff in order to keep this place clean you can find it at:
Indivision --- D Meertins ''
- SQL backends and abstractions
- programming languages
- Object model
- Multi-server capabilities (using soap??? anything else?)
- Multi-IP with 1:1 NAT (currently not supported)
- IPv4/IPv6 (support multiple ips bound to same NIC ie `ip addr show`) and alias NICs eth0:0
- Setup script
- Multi language systems (gettext() is to me the way to go)
- Hooks support for simpler adding in of new functions.
- Plugins (as above line) to add new modules. ie Tomcat/etc.
- Firewall/Port support?
- full DNS management (so you can just add/edit A,CNAME,TXT,SPF records, don't need a mix hosts together in the front end not knowing which are vhosts and which are just DNS hosts).
- wildcard domain support
- administration logging
- Undo (if possible)
- disabling of sites without any loss of configuration etc. (maybe just a park to a "over limit/disabled" page???)
- template driven configuration files instead of hardcoded. ie /var/lib/dtc/etc/vhosts.conf
==Django?==
- straight forward domain aliasing. ie ServerAlias directive (also set max limits for it)
- full domain redirection. ie Rewrite /$ http://www.externalsite.com(approve sites) as an option.
- email template system ie. signup notifications,over quota emails, reset passwords, etc.
- custom error pages. allows clients to use their own error page templates (using ErrorDocument 400 /error/404.html etc)
- reseller/client message emails. ie. Notify Reseller (menu option). notify downtime,updates to all resellers etc.
Django (djangoproject.org) seems like a nice alternative:
- absurdly easy to use text-based templates
- complete SQL abstraction - no need to write SQL at all
- model/view abstraction - business logic goes in the views, models are separate
- works with SQLite (perfect for stateless servers, anyway the new DTC ideally wouldn't need too many SQL tables, preferring other storage types)
- Object oriented
- in Python (drawback? Python is easy to pick up if you have solid programming knowledge).
- remoteability capabilities via (at least) REST
- multi-IP can be done using Varnish - in essence making DTC run in its own private Web server with its own separate privileges instead of hijacking the system's Web server. You can run Django using lighttpd+fastcgi, its own Web server, or Apache+mod_python (lighty is, well, lighter than the rest)
- multi-language supported from the get-go
- we should aim not to need a setup script at all, make the system completely stateless should be a goal
- it's modular - you can bolt extra applications by installing a folder with files
- i18n fully built-in for both templates and code
==Pylons!==
(http://pylonshq.com/(approve sites))
- has all the advantages of Django
+ much more flexible - allow the choice of most suitable parts + adding new ones later
+ not limited to a small group of developpers - each part of framework has many alternatives
Maybe it'd be wise to separate DNS management from Web server management. Conceptually they are linked but implementing them in a single interface leads to a hodgepodge of config options in one screen that don't make sense either for Web server or for DNS. However, a wizard that does both tasks simultaneously, for beginners, is not an idea to rule out.
On another note, I discussed yesterday with Damien: we should think about making "DTC2" remote small scripts/modules that do jobs with privileges, so as to not make DTC2 require any additional privileges. anytime a service needs reconfig, restart, etcetera, that usually requires extra privileges, DTC2 would command one of the slave scripts to do the job, and the slave script would check that, in fact, is DTC2 who is "phoning home", then perform the requested task. More below.
We can combine this with either LDAP or PAM (this is somewhat hard to do, but doable) to provide a robust auth protocol that reuses UNIX accounts instead of creating a separate auth layer.
==Why NOT PHP==
Let's face it, PHP is lousy. Lousy as hell. Coding in PHP requires tons of SHIFT-key depresses.
Compare
function some_function($a,$b,$c) {
....
}
to
def some_function(a,b,c):
....
then multiply by ten thousand.
It's easy to "forget" validation of a variable, thus letting people throw wrenches into the machinery.
Error handling is practically nonexistent in PHP - it's only with PHP5 that exceptions are available and even so, they conflict with commonly used libraries. The only strategy of error handling that we could trust in a sensitive application like DTC is the famed "fail-fast": unhandled errors or problems should cause the program to complain loudly and stop on its tracks. PHP is anything but fail-fast, deciding to continue when a function raises a warning, and failing horribly when an error is raised, instead of printing a helpful traceback. One missed return code validation and you're dead. Very convenient for 10-line scripts, horribly unmanageable for a 50.000 LoC project.
PHP configuration is inconsistent across hosts. Some config stanzas (such as magic_quotes) cannot be altered at runtime, and were practically invented to mask sloppy programming, and introduce bugs of their own. Thus, Apache/PHP config needs to be tailored to DTC on each machine where it will be installed -- exactly what we should avoid.
The include() thing is a major security hole and all major PHP-based Web application packages have, at one time or other, been subject to compromises due to it. PHPNuke, IMP, Squirrelmail, you name it, it's been compromised by either include() bugs or their brethren.
There's no single "dtc_sanitize()" function that we could possibly write to properly sanitize all types of possibly malicious data, especially since some characters are allowed in certain vars, but not in others.
PHP performance is abysmal. It's a fatally awful memory hog, and it serves one tenth of the requests that either Ruby or Python serve. PHP is so slow, that to run my WP blog at an acceptable performance, I've had to resort to both static page caching and a Varnish HTTP accelerator proxy. I saw a jump from 6 req/s to 70 req/s after doing that "optimization".
About the only thing going on for PHP is its stateless nature, and the fact that it's widely deployed. But both RonR and Django have that, and are available as nice debian/RPM packages in all major distros now.
PHP has no enforcement of separation of concerns. You can, and usually do, mix up templates, strings and business logic in a single file, and the language doesn't make it easy.
Kill it with fire. Lots of fire.
==Why not daemons or cron jobs==
As for the daemons, I understand a daemon to be a long-running process, detached from the console, in the background, responding to RPC requests on UNIX/TCP/UDP sockets.
I don't oppose them on principle. I oppose them for practical reasons -- a daemon running with elevated privileges exposes an extra attack surface, it usually needs configuration (simple one-purpose commands like, say, useradd, they don't need configuration or usually their config methods are accepted, standardized and distributed with their containing packages), and it's one more service to run that we could avoid.
Ideally, I envision a DTC2 where DTC, in response to user actions, runs small one-purpose programs (SBox-like) that perform limited config changes or fail-fast if any unusual condition is detected. Yes, the one-purpose programs would need to be suid root unarguably, however since no one but DTC should be able to execute them, we're on the safe side. In theory, we could even afford to write the commands in bash or any language we're comfortable with. In practice, due to the batteries included philosophy in Python, I don't see why using shellscripts would be needed. Another thing to keep in mind, we can use program return codes to detect abnormal conditions and cast these to Python exceptions (thus completing the fail-fast circle).
Advantages of this scheme:
- config changes are applied *instantly* or they aren't applied and the user gets an immediate report on why the config change failed
- attack surface is much reduced
- one-purpose programs have much less probability of bugs or compromises
- both console and DTC users can alter config files and the config won't be hosed by DTC
- three less components to care for and feed daily (cron and its associated mailserver, plus the database)
- no long running daemon running as root
Disadvantages:
- programs would need to interpret config files, and maybe report a structured (serialized?) representation of the config file back to DTC -- this is somewhat hard to do if you have no experience with parsers/lexers/state machines, and extremely easy to do if you know your yacc.
- unavoidably, some configuration will need to sit on a real database; however we could use a self-contained SQLite DB for that.
