Saturday, October 4, 2008

Control panel progress

I've officially started on my hosting control panel. Still not sure what I want to call it yet. I want something generic but good. Look at cpanel, its as generic as you can get as far as a name, but that's how it's remembered and known. I have a few list of rather interesting names, some of which the .com is not yet taken and show low results in Google, so I got some possible winners.

I have a decent logging system going on already, and the data/class organization is starting to come together. Sample log entry:


DEBUG: [date] Starting the program...
DEBUG: [date] Checking for config file...
DEBUG: [date] Config file found. Initializing...
DEBUG: [date] Using Apache2 module
DEBUG: [date] Loading core...
DEBUG: [date] Loading modules [2]...
DEBUG: [date] Modload: apache2
DEBUG: [date] Modload: generic
DEBUG: [date] Error Loading modules:Error loading module [generic], did you forget to inherit ConfigModule::Load()?
DEBUG: [date] Error loading core: Error loading module [generic], did you forget to inherit ConfigModule::Load()?


My plan is to have each server component be a module of the control panel. So in a typical hosting environment you'd want to have the apache module, mysql module, php module (though that would maybe be built into apache as a setting to turn on/off) a dns module, postfix module, dovecot module etc....

When enabled, users would see the module as a menu entry in the control panel and be able to configure settings based on their access level (aka, their own account). Each module would be responsible for storing the settings, and retrieving those settings, as well as applying them to their respectful program.

This setup enables me to later on add more modules, so say I want this control panel to also support sendmail, well I add a sendmail module.

When this program is first started it looks for the startup config file, if it can't find it, it starts the setup wizard which is where you choose to enable/disable modules.

So far I think I got a nice framework going on. Still a lot of core stuff go do though, like I still need to make a date/time class and what not, and still debating on if the settings will be stored in a mysql database, or if I want to use flatfiles. The beauty of flatfiles is the simplicity. If I later on add non webhosting features to this then maybe I don't want mysql to be running, or even installed. So its one dependency less to worry about. Also this program wont be storing all that much data so I can probably serialize everything into files or come up with a basic built in DB system. Server migration will be easier too, just copy and paste the files, and done.

No comments: