CiviCRM Community Forums (archive)

The root issue is that the extension downloader relies on php-curl to perform downloads, but php-curl has a limitation: php-curl does not support HTTP redirects ("CURLOPT_FOLLOWLOCATION") when PHP safe_mode/open_basedir is active. (This is, of course, a bizarre limitation in PHP.) safe_mode/open_basedir are not used by default on most systems, but some sysadmins prefer to use them.

This is an issue because many extensions are distributed through github.com; unfortunately, the download service on github.com generates HTTP redirects. Thus, many extensions cannot be downloaded if a system has PHP safe_mode/open_basedir.

Civi 4.5 attempts to detect this situation and generate semi-relevant messages. Specifically, it includes a test to see if a redirection is supported; if that test fails, then it will display warnings and avoid any attempts at redirection.

https://github.com/civicrm/civicrm-core/blob/4.5/CRM/Utils/HttpClient.php#L219
https://github.com/civicrm/civicrm-core/blob/4.5/CRM/Utils/HttpClient.php#L203

It's possible that your PHP runtime doesn't support redirects -- but you never had problems in 4.4 b/c you didn't download anything which actually required a redirect. It's also possible that isRedirectSupported() produces a false-negative on your system. The only way to figure out which is inspecting/hacking/experimenting with the conditionals in isRedirectSupported() on your particular system.

Ideally, one could make the whole problem go away by removing the reliance on php-curl's flaky CURLOPT_FOLLOWLOCATION. It's possible to write some PHP code which does the same thing as CURLOPT_FOLLOWLOCATION. (One might write a patch for CRM_Utils_HttpClient or bring in an alternative client like https://github.com/guzzle/guzzle ) But no one has had time/incentive to do the write+QA that.

(Related: https://issues.civicrm.org/jira/browse/CRM-14126 )

You can generally edit the php.ini for your webserver to disable open_basedir/safe_mode. The file location varies, so you might do a search like this (for most Linux distros):

grep -r safe_mode /etc/php* /etc/nginx* /etc/apache* /etc/http*
grep -r open_basedir /etc/php* /etc/nginx* /etc/apache* /etc/http*

Disabling safe_mode/open_basedir shouldn't break any functionality. However, it could have other consequences -- so it's good to understand what it is before disabling it.

http://php.net/manual/en/ini.sect.safe-mode.php#ini.safe-mode
http://php.net/manual/en/ini.core.php#ini.open-basedir

safe_mode/open_basedir is a security mechanism which puts PHP code in a sandbox. It was designed for shared-hosting (i.e. one webserver, one Unix user, but many different web/PHP applications which should not be allowed to interfere with each other) and may have some security benefit in other cases. But it's a hassle. Now-a-days, most people prefer other sandboxing techniques (virtualization, containers, mod_itk, fastcgi-with-different-users, AppArmor, etc) which are more comprehensive *and* less hassle. That doesn't make safe_mode pointless... if you need sandboxing and don't have anything else, then you might want to keep it around. But it is deprecated in PHP 5.3.

Couldn't agree more. However this was never the case with CiviCRM in the past and I am not sure when or why it started.

Interestingly Drupal seems happy enough to download modules without coming up against this issue. I wonder why CivicRM doesn't use the same approach?

Ideally, one could make the whole problem go away by removing the reliance on php-curl's flaky CURLOPT_FOLLOWLOCATION. It's possible to write some PHP code which does the same thing as CURLOPT_FOLLOWLOCATION. (One might write a patch for CRM_Utils_HttpClient or bring in an alternative client like https://github.com/guzzle/guzzle ) But no one has had time/incentive to do the write+QA that.

Drupal does what I've suggested above -- they don't rely on php-curl (which is flaky and has this bug with open_basedir+FOLLOWLOCATION). Specifically, D4-D7 takes the first path: they wrote their own code to do the same thing ("drupal_http_request"). D8 takes the second path: it brings in an alternative client (Guzzle). It would be great for Civi to do either of these. We just need someone to do the legwork.

re: docker: Agree that it looks pretty promising. It's a particularly nice idea to have a standard baseline vis-a-vis PHP versions/configurations/libraries so that we don't have to deal with edge-cases like this one, and so far Docker seems like the most vendor-neutral way to accomplish that. (You can run Docker on Debian/Ubuntu/Redhat; on a local machine, a dedicated server, and most public clouds; with puppet or chef or salt or nothing. The main gap -- OSX+Win support are weird.)