How to run an OVA + OVF appliance inside of AWS EC2

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).

As a general rule for a domain joined Windows machine, you shouldn't clone it as is. You should remove it from the domain and use sysprep. Then you can use this as a template/base AMI. Each new clone will be joined using a new SID, name, IP to the domain, making a new computer account in the AD.