Search results

Thanks. I see that Apache will patch the client_ip bug today. One step closer for the reverse_proxy to being a viable option :).

Has the setup been tested with alternative protocols such as DAV and WBXML? Do settings like these need to be ported to the NGINX config? Order Allow,Deny Allow from all

I agree. Even though I've removed htscanner (it's just not the right way to do things in 2014), I've updated my templates since that // might generate other, hidden issues.

Thanks! \o/

Good find. Because of this, I think it might be a documentation error and the trailing slash doesn't matter And I see that you've reported it :) https://bugs.php.net/bug.php?id=67998 And there is a new patch for mod_proxy_fcgi...

Yep, // everywhere... Did you track down the bug on php.net?

Just like .htaccess files, .user.ini files need to be protected so that they can't be read through the browser. This needs to be added somewhere when PHP-FPM is turned on in CB. # # The following lines prevent ..user.ini files from being # viewed by Web clients. # <Files ".user.ini"> Require...

In your case, you might want to simply add your setting to a .user.ini file as I'm sure you don't want to enable the very unsafe register_globals setting for all the domains.

I support this request, although there are some caveats since only ONE cert can be checked at a time, so it won't be really useful until this is implemented https://www.rfc-editor.org/info/rfc6961. CB could add a new function which simply adds this to httpd-ssl.conf for Apache and I'm sure it's...

OK, it worked. Regarding the tooltip, I think the title should go on the td, not the tr. Another title could be added to the "User" td to indicate that clicking on the user link will show the details for that user. While we're there, the page should be renamed as well, "PHP Safe mode" does not...

Aaah :) thanks for the detailed explanation. So, yes, the DAV scripts triggers a recursion, but not the WBXML one. The strange thing is that this wasn't happening with proxypassmatch iirc. EDIT: I've read the doc and checked the code and default_docroot is only used as a fallback, but still...

Yeah, it's normal that it can't read these paths (and it shows up in my logs as open_basedir restrictions ;)), but I don't think it's the intention of the app. I think it's trying to read there because it does not get the proper full path to the .htaccess file. It's trying to read...

Ah, apologies, I underestimated the power of update.sh and didn't run it, because no changes were made to it :eek:. So now that it's working, I see a small problem. I have a main domain set to OFF, but the other domains belonging to the same user are set to ON. Note: I like the filter by user...

I'm having an issue with the template for /var/www/html. It seems some paths are not read properly by PHP and I see a lot of errors regarding PHP trying to access .htaccess in locations outside of the root. Paths like this /.htaccess or //.htaccess /var/www/.htaccess Any idea what would be...

I did, but there is no installation or configuration steps. Config: Apache + PHP-FPM1 + PHP-FPM2 All check boxes in the interface can still be used.

It's not working for me. Interface looks the same. What is DA looking for, in which config file in order to turn this on? # ./directadmin o Compiled on 'FreeBSD 9.1 64-bit' Compile time: Sep 7 2014 at 19:57:40 Compiled with IPv6

Thanks! :)

FreeBSD offers a very easy to use resource controller which could be configured from the GUI: RCTL Can be applied at the user or jail level

I wished we could get the same level of support for FreeBSD jails and rctl ;)

When using PHP-FPM, open_basedir is set per user, not per domain. When looking at the interface (CMD_PHP_SAFE_MODE), the on/off flags will mostly be wrong and any change to a domain will trigger a change in php-fpm.conf. I understand that the system wants to keep a per domain setting, in case...