i dont want to reopen this issue of aegir installed alongside web hosting control panels but i have some potential work lined up with a clients migration to new servers and from another cms to drupal for running there cms hosting service.
as a touch of background they have got a shell script that works with plesk api's to be able to create plesk accounts with home directories which get symlinks in the drupal code base sites directory - eg /drupal/sites/domaina.com is actually a symlink to /sites/domaina.com which is the plesk accounts home folder in normal circumstances
the script also modifies (or custom creates) the apache vhost file so that the doc root is the actual drupal code base (rather than sites/domaina.com/httpdocs as normal), this allows the user to have ftp access to there sites folder (for file upload etc) so it works well
as much as i have reccomended to the user that its not a very good idea at all to try and run plesk and aegir on the same box i have still been asked to look into it
my question that is more related to aegir is: is it possible to effectively modify provision so that it can perform these functions upon site creation (ie create the plesk account and create/modify the apache vhost for plesk etc) and effectively bypass aegir's apache vhost creation section and neatly integrate aegir into plesk
obviously this would mean that they can only create aegir sites from aegir and not from plesk which would be wholly understandable, but would allow for other plesk accounts (serving other probably non drupal sites) to coexist and for plesk to think that all is well
i have yet to think about how symlinking would work in this scheme of things i am assuming that symlink creation would be handled by the provision side of things and permissions would possibly have to be bypassed or handled gracefully
does anyone have any thoughts on this other than the obvious dont do it (which in some respects i think is the best option!)
Comments
yes, everything is possible with aegir ;)
Yes, it's possible: you need to create a separate hook that implements something similar to what the apache backend module currently does. You would also just avoid to include the config/vhost.d in your apache configuration so that the default generated files would not be touched. You could also change the templates.
At this point, the backend is not modular enough that you can completely override the vhost generation.
thats understandable
thats understandable neglecting to add the include line would be workable
might take me a while to do though :)