1. php.ini is imposible to edit in GUI, because we must restart Apache to apply changes. If we do it by cron, users will fuck our brains "Why server is crashing during upload at midnight?"
IMHO with php running via f(ast)cgi(d) it should be enough to kill the php processes of the customer (who changes the php.ini).
With mod-php of course - you need to reload or restart the whole apache.
/J
ok, I try to repeat...
domain creation -> gui puts data for dns, web and the default mail adresses into the db -> the daemons on the respective servers are trying to setup the respective services (dns, web, mail) - if one fails (eg. web) then the daemon on the webserver needs to tell this to the central/control server (put in the db) and the other daemons need to roll back.
So... how do the other daemons know what was the configuration was before the creation (ok, that's easy - but on a change, then the satus before is relevant) - maybe it's an option if there's a sort of daemon on the central/control server which "knows" the status of "before" and can through another setup/clean/etc command to the daemons which need to rollback... so the main "intelligence" is centralized....
If all three servers (in this example) are giving the feedback "ok/successfully done" then the central daemon can recycle the rollback infos...
Now, maybe the central database may also have two sides: one of the actual state of the whole system (a dns table, a mail table etc) and one (maybe only one table) with all the todos/jobs, in a queue or so... - if a job has been finished the central daemon puts the info in the correct tables so the gui also "knows" about the changes (so: the gui does not see a domain until it's really created - but it should show the state that the creation is in progress..)...
There are pros and cons about a job-queue...
pro: the daemon does not need to check several tables, maybe easier to rollback
con: the gui need to add the info of e.g. "domain creation in progress" from this separate table...
hm...
The todo/job queue table needs to be very flexible (eg. a big text field with XML infos) because we do not know what sort of commands may come (with external modules)...
just some thoughts....
Joxi
killburn - right:
we should think about this - but we do not need to start with this scenario...
/J
Hi nuxi and sci2tech
great you like the idea... I wanted to separate the things since a long time but with the multiple server thing it's now more interesting and makes more sense... 
I don't understand this part:
Quote
<nuxwin> but ok, still the problem of SQL users linked to the databases
<nuxwin> BTW, we should fin a way to link user to customers databases
<nuxwin> but you got the idea ?
<nuxwin> by doing like this, for example, if one user want not use the daemon at all, h ecan!
what do you mean with "link users to customers database" or "if a user don't want to use the daemon, he can"... ?
let's start to make some drafts... maybe the wiki has a place where we could discuss this in a written way...
/Joxi
As soon as i-MSCP runs on another Server than the services (the *MS*) then all the direct mechanisms of the actual ispcp are useless.
so we have to do it via daemon (or something which replaces the daemon...) which runs on every of the controlled server...
That's also why the productive mail-users need to be in a separate DB (not on the i-MSCP-Server but on the Mailserver...)
Seems that we need a good communication between the gui->daemon->servers... etc
and we need to think different than before...
/Joxi
Right killburn. Maybe it's possible to create such a ftp user with each domain or with each user (depending on the system users and permissions) - and then also configure the ftp server to only accept theese userlogins from "localhost" (or from the adminpanel-Server).
/J
app installer - if possible for a already existing package format - eg. apsstandard.org (I know it's from parallels - but it seems to be an open thing...)
/J
yes yes yes!!!!!!!!!!
