Subdomain setup for CalDAV plugin

Hi Guys,

I have just installed a third party roundcube plugin to enable caldav server functionalities. I successfully installed it as well as many others, however I have been asked to create a new subdomain and point it to a specific sub-directory under the folder related to this plugin for my roundcube (point 1 of this KB article)

I know I can’t ask you for any support as this is not a plugin nor a piece of software you developed, however I would appreciate if you could explain how to do it.

Thanks.

For 1 domain you will be able to add the configuration in /etc/nginx/conf.d/ folder

If is for more every domain it is more work and it needs to be all automatic. It will be harder and with out changes to Hestia probally impossible.

Hi @eris,

Thanks for your quick response (as usual). This is highly appreciated!

I believe you refer to the NGINX web domain configuration file whose symlink is located under the “/etc/nginx/conf.d/domains” folder. If so, I opened it and I can see the root variable I could modify (I understand this is a tweak which has to be reset after a new update/upgrade is released and installed :blush:):

However, I didn’t try that yet but I’m fairly sure that can be done from within the Custom document root section located in the Edit Web Domain GUI section:

image

I see this feature was introduced back on Aug 17th, 2020 with release version 1.3, however the minute I used it and click on Save I receive the following error message:

image

Please note that the caldav subdirectory in the root folder is a symlink to the subfolder of my Roundcube plugin:

Any idea?

You need to create a special caldav template that sets the docroot to /var/lib/roundcube

For security reason you can use symlinks out of the home dir …

You need to create a special caldav template that sets the docroot to /var/lib/roundcube
Can you point me to the part of the documentation which explains how to do that?

For security reason you can use symlinks out of the home dir …
Do you mean can’t or can?

You can’t do what you want

You need to create a special caldav template that sets the docroot to /var/lib/roundcube

Can you point me to the part of the documentation which explains how to do that?

Hi @eris,

I read every single possible post in this forum about templates as well as the documentation at this link however I need your help as it’s still not clear to me.

As you advised, I’m trying to build a template which will allow me to have a web domain to serve this folder:

/var/lib/roundcube/plugins/xcalendar/caldav

As you know in HestiaCP I can choose a template in each one of the following 3 categories:

  • Web Template APACHE2
  • Backend Template PHP-FPM
  • Proxy Template (NGINX)

According to the documentation they reside respectively in these folders:

  • /usr/local/hestia/data/templates/web/apache2/php-fpm
  • /usr/local/hestia/data/templates/web/php-fpm
  • /usr/local/hestia/data/templates/web/nginx

I believe I am supposed to copy and modify one of the Apache2 web templates. Here are the steps I followed:

  1. Made a copy of the default templates:
cd /usr/local/hestia/data/templates/web/apache2/php-fpm
cp default.tpl apache2stocazzo.tpl
cp default.stpl apache2stocazzo.stpl
  1. Replaced DocumentRoot %docroot% by DocumentRoot /var/lib/roundcube/plugins/xcalendar/caldav/ in both apache2stocazzo.tpl and apache2stocazzo.stpl

  2. Restarted the apache2 service

  3. From the GUI I changed the value of Web Template APACHE2 from default to apache2stocazzo:

image

image

However, when I try to load this web domain I get the following error message:

The Custom document root section still shows the old directory path:

image

What am I missing?

You can’t use the custom docroot for this function is doesn’t allow to go outside the /home/user directory of the user.

You need to setup the path your self in the template.

I’m sorry but it’s not clear how to set the path in the template.

Which template? the one that I copied? The apache2stocazzo.tpl or the apache2stocazzo.stpl as well?

Can you please explain?

Check your logs…

Hi @eris,

  1. I always try to ask questions in this forum politely
  2. I always try to provide as many details as possible with logs, examples and screenshots

The above is to be in compliance with the rules of this forum as well as in sign of respect towards whoever is willing to help as the more precise and descriptive I am, the less is the time whoever helps needs to take to help me

If I’m still here asking for more assistance is because I need help but honestly I don’t know what else I should do to make that clear. My issue still stands and answers like “Check your logs…” are too generic and do not help.

The funny thing is that I made a donation two weeks ago and this is the way I get paid back.

Have a nice day!

First of all…

They reason why I ask to check the logs because it provides information that is more useful then a screenshot. It will probally show that er is an issue with php openbasedir. But before I waste your time last few lines of logs will provide the answer or not…

I think what is possible wrong but the logs will simple verify and probably help you with finding the errors.

If you don’t like to basic debugging on on your server and ask for help for everything what goes wrong. Hestia is not the right tool for you. And even with such special changes there are probably a few users who are can help you with it.

I can give you the shortest answer every time or at least I can teach you how to solve similar issues in the future.

If you want the shortest answer hire me or somebody for a reasonable commercial rate and you get quick answers. It is still done in my own time. And I still not getting paid for it.

Also donations are always appreciated but doesn’t come with any kind of guarantee for support (At least yet)

1 Like

u want to have a refund?

No thanks. Overall I’m happy with HestiaCP.

And what information did the logs provide?

I assume it is openbasedir restriction

You need to create php-fpm template Web domains and SSL Certicates — Hestia Control Panel documentation

And allow in openbasedir the folder /usr/share/roundcube

Hi @eris ,

After digging I managed to have the /var/lib/roundcube/xcalendar/caldav directory served by the subdomain caldav.example.com. However, when loading the index.php from the plugin I received 500 error and after checking the logs (as I usually do :wink:) I found the following:

[Sun Jan 15 19:11:55.298436 2023] [core:alert] [pid 24729:tid 281473211625664] [client XXX.XXX.XXX.XXX:0] /var/lib/roundcube/.htaccess: <IfModule not allowed here

The above occurred despite the fact that the AllowOverride All directive was already entered in the new root directory section within the newly created apache template.

After that I deselected the customized Apache template previously in place from the GUI and created two new templates:

  • /usr/local/hestia/data/templates/web/php-fpm/caldav-PHP-8_0.tpl
  • /usr/local/hestia/data/templates/web/nginx/caldavnginx.stpl and /usr/local/hestia/data/templates/web/nginx/caldavnginx.tpl

At this point the logs reported the warning message restriction about open_basedir (as per your comment):

[Sun Jan 15 19:48:15.169849 2023] [proxy_fcgi:error] [pid 49028:tid 281473046933696] [client 84.203.3.161:0] AH01071: Got error 'PHP message: PHP Warning:  require_once(): open_basedir restriction in effect. File(/home/ivanobuffa/vendor/autoload.php) is not within the allowed path(s): (/home/ivanobuffa/.composer:/home/ivanobuffa/web/caldav.example.com/public_html:/home/ivanobuffa/web/caldav.example.com/private:/home/ivanobuffa/web/caldav.example.com/public_shtml:/home/ivanobuffa/tmp:/tmp:/bin:/usr/bin:/usr/local/bin:/usr/share:/opt) in /var/lib/roundcube/plugins/xcalendar/caldav/index.php on line 11PHP message: PHP Warning:  require_once(/home/ivanobuffa/vendor/autoload.php): Failed to open stream: Operation not permitted in /var/lib/roundcube/plugins/xcalendar/caldav/index.php on line 11PHP message

After that I modified the PHP script from the purchased plugin by replacing this:

defined("RCUBE_INSTALL_PATH") || define("RCUBE_INSTALL_PATH", dirname(dirname(dirname(dirname($_SERVER["SCRIPT_FILENAME"])))) . "/");

with this:

define("RCUBE_INSTALL_PATH","/var/lib/roundcube/");

and created another web php-fpm template setting the php_admin_value[open_basedir] to none (I understand this is not safe).

As of now the plugin works fine with the following templates in place:

image

Where:

  1. The file /usr/local/hestia/data/templates/web/php-fpm/caldav-PHP-8_0_no_base_dir.tpl contains the following:
; origin-src: deb/php-fpm/multiphp.tpl

[%domain%]
listen = /run/php/php%backend_version%-fpm-%domain%.sock
listen.owner = %user%
listen.group = www-data
listen.mode = 0660

user = %user%
group = %user%

pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s
pm.status_path = /status

php_admin_value[upload_tmp_dir] = /home/%user%/tmp
php_admin_value[session.save_path] = /home/%user%/tmp
php_admin_value[open_basedir] = none
php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f [email protected]%domain%

env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /home/%user%/tmp
env[TMPDIR] = /home/%user%/tmp
env[TEMP] = /home/%user%/tmp
  1. The file /usr/local/hestia/data/templates/web/nginx/caldavnginx.stpl contains the following:
#=========================================================================#
# Default Web Domain Template                                             #
# DO NOT MODIFY THIS FILE! CHANGES WILL BE LOST WHEN REBUILDING DOMAINS   #
# https://docs.hestiacp.com/admin_docs/web.html#how-do-web-templates-work #
#=========================================================================#

server {
    listen      %ip%:%proxy_ssl_port% ssl http2;
    server_name %domain_idn% %alias_idn%;
    ssl_certificate      %ssl_pem%;
    ssl_certificate_key  %ssl_key%;
    ssl_stapling on;
    ssl_stapling_verify on;
    error_log  /var/log/%web_system%/domains/%domain%.error.log error;

    include %home%/%user%/conf/web/%domain%/nginx.hsts.conf*;

    location / {
        proxy_pass      https://%ip%:%web_ssl_port%;
        location ~* ^.+\.(%proxy_extensions%)$ {
            root           /var/lib/roundcube/plugins/xcalendar/caldav/;
            access_log     /var/log/%web_system%/domains/%domain%.log combined;
            access_log     /var/log/%web_system%/domains/%domain%.bytes bytes;
            expires        max;
            try_files      $uri @fallback;
        }
    }

    location /error/ {
        alias   %home%/%user%/web/%domain%/document_errors/;
    }

    location @fallback {
        proxy_pass      https://%ip%:%web_ssl_port%;
    }

    location ~ /\.(?!well-known\/|file) {
       deny all;
       return 404;
    }

    proxy_hide_header Upgrade;

    include %home%/%user%/conf/web/%domain%/nginx.ssl.conf_*;
}
  1. The file /usr/local/hestia/data/templates/web/nginx/caldavnginx.tpl contains the following:
#=========================================================================#
# Default Web Domain Template                                             #
# DO NOT MODIFY THIS FILE! CHANGES WILL BE LOST WHEN REBUILDING DOMAINS   #
# https://docs.hestiacp.com/admin_docs/web.html#how-do-web-templates-work #
#=========================================================================#

server {
    listen      %ip%:%proxy_port%;
    server_name %domain_idn% %alias_idn%;

    include %home%/%user%/conf/web/%domain%/nginx.forcessl.conf*;

    location / {
        proxy_pass      http://%ip%:%web_port%;
        location ~* ^.+\.(%proxy_extensions%)$ {
            root           /var/lib/roundcube/plugins/xcalendar/caldav/;
            access_log     /var/log/%web_system%/domains/%domain%.log combined;
            access_log     /var/log/%web_system%/domains/%domain%.bytes bytes;
            expires        max;
            try_files      $uri @fallback;
        }
    }

    location /error/ {
        alias   %home%/%user%/web/%domain%/document_errors/;
    }

    location @fallback {
        proxy_pass      http://%ip%:%web_port%;
    }

    location ~ /\.(?!well-known\/|file) {
       deny all;
       return 404;
    }

    include %home%/%user%/conf/web/%domain%/nginx.conf_*;
}

As of now logs do not report any error message. I might consider the above procedure as a valid solution but I’m wondering if the variable php_admin_value[open_basedir] must be set to /usr/share/roundcube.

Any idea?

Note: the fragments of logs reported above have been filtered for privacy reason!

Yes … Probally create a new template follow the instructions above
or replace:
php_admin_value[open_basedir] = none;
with

php_admin_value[open_basedir] = /