Hey,
I was stumbeling about this thread, because I had the same whishes to do this.
For me it worked to edit the regarding templates in "/usr/local/vesta/data/templates/web/apache2" (Debian Distro).
I just created another Virtualhost, pointing to the Maildirectory. Of course I deleted the roundcube.conf from
/etc/apache2/conf.d
and took the content to make the template from it.
Just add this code into your template file (e.g.: /usr/local/vesta/data/templates/web/apache2/phpfcgid.tpl).
For https support you have to modify the code a bit, similar to the the *.stpl files.
Code: Select all
# email subdomain support for each user
<VirtualHost %ip%:%web_port%>
ServerName mail.%domain_idn%
ServerAdmin %email%
DocumentRoot /var/lib/roundcube
ScriptAlias /cgi-bin/ %home%/%user%/web/%domain%/cgi-bin/
Alias /vstats/ %home%/%user%/web/%domain%/stats/
Alias /error/ %home%/%user%/web/%domain%/document_errors/
CustomLog /var/log/%web_system%/domains/%domain%.bytes bytes
CustomLog /var/log/%web_system%/domains/%domain%.log combined
ErrorLog /var/log/%web_system%/domains/%domain%.error.log
Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
Alias /roundcube /var/lib/roundcube
# Access to tinymce files
<Directory "/usr/share/tinymce/www/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order allow,deny
allow from all
</Directory>
<Directory /var/lib/roundcube/>
Options +FollowSymLinks
# This is needed to parse /var/lib/roundcube/.htaccess. See its
# content before setting AllowOverride to None.
AllowOverride All
order allow,deny
allow from all
</Directory>
# Protecting basic directories:
<Directory /var/lib/roundcube/config>
Options -FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/lib/roundcube/temp>
Options -FollowSymLinks
AllowOverride None
Order allow,deny
Deny from all
</Directory>
<Directory /var/lib/roundcube/logs>
Options -FollowSymLinks
AllowOverride None
Order allow,deny
Deny from all
</Directory>
</VirtualHost>
After creating the templates, you have to rebuild the user Apache2 config files. To do that run the following in terminal:
for just one single user or
Code: Select all
for user in $(v-list-sys-users plain); do v-rebuild-web-domains $user; done
for each user in your vestacp system.
Ah! Of course you can setup the VirtualHost with fcgi! So every client get it's own process instance based on the user account while accessing the subdomain.
I just disabled it as a workarround to get the possibility of using roundcubes password plugin to change email passwords.
I guess while running an update, the templatefiles gonna reset to default. Also v-update-webtemplates *username* does. You should store a copy of your templates in case of an update somewhere.
Currently I don't really get the way vesta is creating these templates. However, in a way it's just a workarround. I'm looking forward for better solutions.
Best regards,
Kalle