Things are getting stranger.

First of all, I can't edit the hacks into the php files because they're already there, it all has made it into trunk meanwhile.

Then I discovered that it's nigh-impossible to change the PATH variable on a Qnap NAS in a way that it persists beyond reboot. Not that it matters, though, because ~friendica makes no use of root's environment variables defined in /root/.profile or /root/.bash_profile anyway. You can edit yourself silly on these files, you can export whatever you want, but ~friendica ignores it, and after the next reboot, all your edits are gone, and everything's back to vanilla.

So I'm still stuck with the very same errors described in that thread.

I guess all I need to do is tell Friendica a) where the PHP executable is located and b) where openssl.cnf is located. Maybe I'll try some SetEnv lines in Apache config files later.

@Simon: An ARM-based Qnap NAS has got very little in common with a regular x86-based web server running Debian GNU/Linux. You don't sudo on these machines because all you can is ssh into them as admin and run commands with full root rights. Also, things tend to be located in the weirdest places and act weirdly. For example, you find much of your Apache and php stuff (including config files) in /mnt/ext/opt/apache/bin, and neither /root/.profile nor /root/.bash_profile persist beyond reboot, they're auto-replaced by vanilla versions from 2004.

echo $PATH put out the following:

/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/sbin


My next attempt was to teach ~friendica where my files are in that out-of-whack file structure of a Qnap NAS (when you come from GNU/Linux, you won't find anything). So I added the following lines to the .htaccess file:

SetEnv PATH ${PATH}:/mnt/ext/opt/apache/bin
SetEnv OPENSSL_CONF /etc/ssl/openssl.cnf

Didn't work. Same errors as before.


Next trick: Environment variable file. /mnt/ext/opt/apache/bin/envvars is it. I added

PATH="/mnt/ext/opt/apache/bin:$PATH"
export $PATH

OPENSSL_CONF="/etc/ssl/openssl.cnf"
export OPENSSL_CONF

and restarted Apache. Didn't work either. Still the same errors as before.

However, as far as Apache is concerned, I think I'm completely out of luck. Qnap's build of Apache 2.2.14 (two and a half years old, older than even Mistpark) which comes with the current 3.6.1 firmware for the TS-x19 series lacks mod_env.so which is required for changing environment variables in Apache. Other Qnap users can look for themselves in /mnt/ext/opt/apache/modules.

I discovered a little error in the test script linked two posts above, namely the wrong location of openssl.conf. After fixing it, OpenSSL happily created a certificate for me. So OpenSSL itself works fine. However, it still doesn't work for ~friendica .

I can't tell ~friendica the location of php by editing htconfig.php either. Even then it complains that it can't find the php executable.


Conclusions:

In php's case, the problem is that the location of the php executable is not communicated between the Qnap's Apache web server and ~friendica . a) It is near-impossible to add the php path to root's PATH variable persistantly beyond reboot. b) Even if the php path is part of PATH, ~friendica doesn't find it because ~friendica doesn't parse root's PATH variable.

In OpenSSL's case, the problem might be similar, namely that ~friendica can't find openssl.cnf because it doesn't parse root's OPENSSL_CONF variable. However, I cannot prove this. It is quite likely that this is the case (because why should ~friendica find a non-standard OPENSSL_CONF if it doesn't find a non-standard PATH either), but I don't have 100% rock-solid proof. It might just as well be an issue with the very contents of openssl.cnf itself. Still, the environment variable problem is the most likely by far.

As said above, the problem is quite likely that the Apache server on a Qnap TS-x19 is unable to change environment variables. So it's not ~friendica that's looking in non-Qnap-compliant places, it's Apache that's unable to tell ~friendica where to look.