I've just discovered VHCS/VHCS Omega and it has really attracted my interest because it's the first opensource control panel that worked well for me.
I wanted to learn some of it's internals before going further and using it at my company's production servers, so I've downloaded your SVN code and tried to get a basic picture of how the whole system works.
I'm a profficient php programmer with little perl skills and some solid C base, but it has proven as a bit challenging work. This is probably because there is no "out of code" documentation (or I've been unable to find it!), so I will post some things that I've managed to figure out, and some questions that I've been unable to answer.
The system is split in three very different "components":
- /gui: Written in php, it handles all the user interaction. Users actions are persisted on the vhcs database itself, but this part won't touch any system configuration directly.
Edit (thanks ephigenie): MySql databases/users and ftp accounts are managed directly by the GUI. This is because its configurations are only database-based so there are no extra privileges needed.
- /engine: This is the part responsible of updating system configurations to match what the vhcs database says.
- /tools/daemon: This is the daemon responsible of isolating the engine component from the gui one. This is necessary because the engine must run as root user (it has to change system-level preferences), but it would be a security risk doing the same with the gui part.
What is all of this "query license server" stuff?
Looking at the daemon code I've found a lot of references to a "license server" or somethin like this. Finally, I've figured out that there was once a moleSoftware owned license server that had to validate every "installation key". From my testings, this server isn't up anymore, so basically all license requests simply fail to connect, but the license is considered valid.
Code:
if((res = connect(sock, (struct sockaddr*)&saddr,sizeof(saddr))) == -1){
...
return (NO_ERROR);
}
My question is... will all this "license bloat stuff" get ripped? If so... what are you waiting for?
Edit: see below
Possible system locking problem
As far as I can see, the engine component uses a "lock file" to prevent multiple concurrent instances. Now suppose that it is running when a request for a new client (domain) is made. The request won't be processed until next rqst-mngr run, so as result the domain won't be really added to the system until another request is made from any user. Is this right?
Going a little further... what happens if somehow the engine manages to hang? Manual process killing/lockfile removing needed?
Apache configuration: divide and conquer?
Apache configuration for all hosts/virtualhosts is stored in a unique "vhcs2.conf" file. Is there any special reason to do this? I think it would be far more easier to manage a bunch of included domain-based config files than this big beast.
No SSL support
The panel deals with almost all passwords of the system but... it does it over http! This is for me a serious security flaw, not for "hosting company X" itself but for end users. I think that SSL support (at least for the panel itself) should have the highest priority.
Oh, I almost forgot to say... good job guys!