Installing the SDK via PEAR places the files in /usr/share/pear/AWSSDKforPHP
; config-sample.inc.php
is under this folder.
If you look at php -i | grep include_path
(or the output of phpinfo()
) you should find something like the following: .:/usr/share/pear:/usr/share/php
This indicates that the path the SDK was installed to is available in your includes (i.e. falls below /usr/share/pear
).
You will note that ownership of the SDK files is set to root
- with 0644
permissions. The user Apache is running as is presumably neither root, nor in the root group. It should therefore be able to read the files, but not modify them.
/root
is the home directory of the user root. The getenv()
and setenv()
functions are PHP, and need to go in a PHP file - not an INI file.
You don't need to use the environment variables for the method above. However, if you place your configuration in your HOME directory (as per method 2), then PHP needs to know your home directory in order to read the file (there are potentially other issues with this, in that many installations will restrict access to certain folders only, e.g. using open_basedir
).
Using the second approach, you will need to verify that PHP can determine your HOME directory. You can create a PHP file and test the getenv()
function. If all is well (i.e. you get the correct HOME path - the directory containing your configuration file), then you don't need to use that or the setenv()
function at all.
If, on the other hand, the path is incorrect, then you will need to set the correct home path at the top of your script (i.e. the one using the SDK, before you reference it). Essentially, you are exporting the path to the directory containing the .aws folder that you have your configuration in - whenever you call the SDK that variable will need to be set.
As for the response you got (i.e. /root
) - if you run the php script from the command line as root, then the response was expected. If you ran it through a web browser, then something isn't quite right. Apache is typically set up as its own user (UID=48), with its home directory set to /var/www
- regardless, Apache should not be running as root. Typically, Apache is started as root and then changes to the user specified in your httpd.conf file. If you are running suPHP or php-fpm then there is a good chance that PHP is not running as the same user as the web server. Note that you can run the same script as different users, and will get a different response each time - run it under the conditions you expect it to be run as (i.e. if the script it intended to be accessed via a browser, do so; if it will be a shell script then run it as such).
Best Answer
An alternate solution is to keep your current server and use a different Let's Encrypt client. I use Acmetool, I have a tutorial here - though it might be a little out of date.
Amazon Linux makes installing quite a few packages difficult, and the AWS repositories aren't particularly up to date.