• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

open_basedir short codes

eworksmedia

New Pleskian
Where can I see a full list of available short codes for the open_basedir value?

{DOCROOT}
{WEBSPACEROOT}
{TMP}
.... what others?
 
Thanks, I have a few more questions about this. Is this just the way Media Temple configured the servers or is this how Plesk works in general in that it stores the AWStats logs under /var/www/vhosts/system/domain_name and the httpdocs is under /var/www/vhosts/domain_name? If this is just how Plesk works, can you tell me how to allow each subscription access to its own "system" vhost directory through open_basedir?

{WEBSPACEROOT}{:}{TMP}{/}{:}{WEBSPACEROOT}/statistics

Doesn't work because the logs are actually under /var/www/vhosts/system rather than just using the webspaceroot..
 
Hi eworksmedia,

please have a closer look to the configuration files, located at: /var/www/vhosts/system/YOUR_DOMAIN.COM/conf

As you can see, the "statistic paths" are already configured like

for apache:
Code:
        Alias /webstat /var/www/vhosts/system/YOUR_DOMAIN.com/statistics/webstat
        Alias /webstat-ssl /var/www/vhosts/system/YOUR_DOMAIN.com/statistics/webstat-ssl
        Alias /ftpstat /var/www/vhosts/system/YOUR_DOMAIN.com/statistics/ftpstat
        Alias /anon_ftpstat /var/www/vhosts/system/YOUR_DOMAIN.com/statistics/anon_ftpstat
        Alias /awstats-icon /usr/share/awstats/icon
There is no need to configure anything more, which you should see, if you open the URL "http://www.YOUR_DOMAIN.COM/webstat/". The content is restricted and can be reached after the authentification ( domain_user / domain_user_password ) and only after at least one day after the domain creation to the next daily statistic creation, or a manual statistic creation over the command line.


If you still would like to configure the domains-specific paths for your domain-specific PHP.ini's, please be aware, that a "7" is configured as "{/}" over the Plesk panel in combination with shortcuts... or you define the whole path, beginning from the system root, as transported from the Plesk - Control - Panel to the PHP.ini's.

Examples:
{WEBSPACEROOT}{/}{:}{TMP}{/} => will result in the PHP.ini configuration: "/var/www/vhosts/YOUR_DOMAIN.COM/:/tmp/"

{WEBSPACEROOT}{/}{:}{TMP}{/}{:}{WEBSPACEROOT}{/}logs => will result in the PHP.ini configuration: "/var/www/vhosts/YOUR_DOMAIN.COM/:/tmp/:/var/www/vhosts/YOUR_DOMAIN.COM/logs"​


The mentioned paths "/var/www/vhosts/YOUR_DOMAIN.COM/" and "/var/www/vhosts/system/YOUR_DOMAIN.COM/" are Plesk-specific configurations.
 
Hi, yea, those are aliased for web access but I want to file_get_contents on them but am blocked due to open_basedir...
 
Hi eworksmedia,

please post the code you use and include the depending errors from the log - file(s) - ( apache and/or nginx, please ), because it is unclear, WHAT you would like to do / WHICH script you would like to use.
 
file_get_contents('/var/www/vhosts/system/DOMAIN_NAME/statistics/webstat/awstats032015.DOMAIN_NAME-http.txt');

Warning: file_get_contents(): open_basedir restriction in effect. File(/var/www/vhosts/system/DOMAIN_NAME/statistics/webstat/awstats032015.DOMAIN_NAME-http.txt) is not within the allowed path(s): (/var/www/vhosts/DOMAIN_NAME:/tmp/:/var/www/vhosts/DOMAIN_NAME/statistics)

open_basedir value is: {WEBSPACEROOT}{:}{TMP}{/}{:}{WEBSPACEROOT}{/}statistics
 
file_get_contents('/var/www/vhosts/system/DOMAIN_NAME/statistics/webstat/awstats032015.DOMAIN_NAME-http.txt');

Warning: file_get_contents(): open_basedir restriction in effect. File(/var/www/vhosts/system/DOMAIN_NAME/statistics/webstat/awstats032015.DOMAIN_NAME-http.txt) is not within the allowed path(s): (/var/www/vhosts/DOMAIN_NAME:/tmp/:/var/www/vhosts/DOMAIN_NAME/statistics) <= and where is the used path "/var/www/vhosts/system/DOMAIN_NAME/statistics/webstat/" ?
open_basedir value is: {WEBSPACEROOT}{:}{TMP}{/}{:}{WEBSPACEROOT}{/}statistics

You just copied my examples, huh? ^^

Another example:
{WEBSPACEROOT}{/}{:}{TMP}{/}{:}/var/www/vhosts/system/YOUR_DOMAIN.COM/statistics/webstat => will result in the PHP.ini configuration: "/var/www/vhosts/YOUR_DOMAIN.COM/:/tmp/:/var/www/vhosts/system/YOUR_DOMAIN.COM/statistics/webstat"​
 
No, we've had that value for open_basedir for a long time - years. We've been polling the web accessible version until now I'm trying to pull the data locally instead. I personally don't think we even need the /statistics entry because we already allow WEBSPACEROOT, and according to PHP documentation "When you want to restrict access to only the specified directory, end with a slash." So not ending with a slash should include all subdirectories. I updated the value to

{WEBSPACEROOT}{:}{TMP}{/}{:}{WEBSPACEROOT}{/}statistics{:}{WEBSPACEROOT}{/}statistics{/}webstat

Now the error is

file_get_contents(): open_basedir restriction in effect. File(/var/www/vhosts/system/DOMAIN_NAME/statistics/webstat/awstats032015.DOMAIN_NAME-http.txt) is not within the allowed path(s): (/var/www/vhosts/DOMAIN_NAME:/tmp/:/var/www/vhosts/DOMAIN_NAME/statistics:/var/www/vhosts/DOMAIN_NAME/statistics/webstat)
 
Hi eworksmedia,

could you please check again your typo? You seem to miss, that with

{WEBSPACEROOT} => /var/www/vhosts/YOUR_DOMAIN.COM

and

/var/www/vhosts/system/YOUR_DOMAIN.COM =>
/var/www/vhosts/system/YOUR_DOMAIN.COM

/var/www/vhosts/system/* is NOT included, when you define {WEBSPACEROOT} or manual set /var/www/vhosts/YOUR_DOMAIN.COM

Please always COMPARE the allowed paths, as stated in the error - message.
 
Ahh I see, but the problem with that is I'd have to manually add that for every subscription on the server, of which there are many and it's always in flux. I was looking for a way to do this globally, which is why I was hoping for something like a {DOMAINNAME} short code.. Is there a way to set this up so that it works for all current and future subscriptions?
 
Hi eworksmedia,

you could use the event-handler to update your custom php.ini's on domain creation ( untested, so please blame me, if this doesn't work as expected ^^ ):

vim /root/open_base_directory_definition

Define your definitions inside that file, like:​

open_basedir = {WEBSPACEROOT}{/}{:}{TMP}{/}{:}/var/www/vhosts/system/<new_domain_name>/statistics/webstat
save and exit vim.​


Create a new event-handler ( Tools & Settings > Event-Handler ) for the user "root", choose the value "domain creation" and use the command:

/usr/local/psa/bin/subscription_settings --update <new_domain_name> --update-php-settings -settings /root/open_base_directory_definition
 
Hi eworksmedia,

for your understanding, the definition "<new_domain_name>" will only work, for the event-handler, because the event-handler should replace the definition "<new_domain_name>" with the value you set in the newly created event ( in this example: "domain created" ). If you use the command on a manual basis without the event-handler and it's value, you have to replace the "<new_domain_name>" with your very own domain name, because the subscription-settings - utility doesn't know where to get the definition "<new_domain_name>" from.
 
I switched it up to this:

/usr/local/psa/bin/subscription --update-php-settings <new_domain_name> -settings /path/to/my/open_base_directory_definition

And that's half working except it makes the open_basedir value

/var/www/vhosts/DOMAIN_NAME:/tmp/:/var/www/vhosts/system/<new_domain_name>

Instead of replacing the <new_domain_name> it's just leaving that in there :)
 
Oh okay so that would solve the last issue I had except it's not firing the event when a new subscription is created so that's never happening. What priority should it have? I left it at default "lowest (0)
 
Hi eworksmedia,

hm... well... sorry... my fault for the wrong utility... but as you see, the manual command works as expected ( "<new_domain_name>" can only be used with the event-handler and the desired definition output from the used value ).


Lowest (0) is fine and should you suit your needs... :)
 
It's strange, that event doesn't ever fire. If I change the event to "Physical hosting created" it actually fires but it won't replace the <new_domain_name> directive so directly after creating a new subscription:

grep "open_basedir" /var/www/vhosts/system/DOMAIN_NAME/conf/httpd.conf

Reveals:

php_admin_value open_basedir "/var/www/vhosts/DOMAIN_NAME:/tmp/:/var/www/vhosts/system/<new_domain_name>"

The contents of the open_base_directory_definition is:

open_basedir = {WEBSPACEROOT}{:}{TMP}{/}{:}{/}var{/}www{/}vhosts{/}system{/}<new_domain_name>

Have any ideas? The command for the event is:

/usr/local/psa/bin/subscription --update-php-settings <new_domain_name> -settings /path/to/my/open_base_directory_definition
 
Hi eworksmedia,

if this doesn't work, it is always a good idea to wait for a "Parallels Team" - member to answer the question, or wait for some other suggestions. ^^
 
Alright I switched this up a bit. We already have a custom event handler + extension tied to Physical Hosting Created so I just modified that to also generate the open_basedir definition file on-the-fly and call the update-php-settings using that file during the rest of the work it does. That seems to be working just fine. Thanks
 
Back
Top