Run install.sh with non-root user

[jamesmontalvo3]

This should work with the following, but it did not work on the first attempt:

sudo bash install.sh

But it should be confirmed prior to attempting to deploy on Meza1 Server (#67).

[jamesmontalvo3]

To create a non-root user with sudo:

adduser <james>
passwd <james>
    choose password
    confirm password
visudo
    below line: root    ALL=(ALL)       ALL
    add line:   <james>     ALL=(ALL)       ALL

[jamesmontalvo3]

Second run failed in same manner. Couldn't tell what the issue was in the first run (last night). Inspecting again.

[jamesmontalvo3]

The issue is this:

mediawiki-quick.sh: line 98: composer: command not found
extensions.sh: line 10: composer: command not found

For some reason it's not finding composer, which is installed at /usr/local/bin/composer in mediawiki-quick.sh. There is no issue when this is installed with root, but with a sudo-user it failed. After the script failed it was confirmed that composer was installed in /usr/local/bin/composer, though after leaving the script the PATH variable did not stay updated, so PHP was not in PATH, and therefore running composer --version failed, however it does not say "composer: command not found". It says:

/usr/bin/env: php: No such file or directory

This is a totally different error, due to the fact that the top of the /usr/local/bin/composer file has a shebang:

#!/usr/bin/env php

This is telling the env command to find PHP, but at this point (after script complete, before reloading shell) PHP is not in the PATH so it cannot find anything. Adding PHP to the PATH allows composer --version to run, as does running php /usr/local/bin/composer --version.

So this is particularly annoying that it's giving a totally different error. During running the script it acts like it can't find composer, even though composer is clearly at /usr/local/bin/composer. After the script it acts like PHP is the problem. During the script it appears to have no issue finding PHP, since just before the install.sh script dies there's a PHP error (due to the missing composer items):

PHP Fatal error:  Call to undefined function enableSemantics() in /var/www/meza1/htdocs/wiki/LocalSettings.php on line 130

The fact that this error is produced indicates that the script is successfully running PHP, else there would be a "php not found" error.

It seems as though the quickest solution to this would be to replace all calls to composer with either /usr/local/bin/composer or php /usr/local/bin/composer. However, there are several files that user composer, and all logic suggests that we should simply call composer and not the full path. It's highly likely that this will be an issue down the road (when someone forgetfully just attempts to run composer in the initial setup). Note that this is only an issue in the initial setup, and future calls to composer will work just fine.

Another solution may be to make a symlink from /usr/bin/php to the php command rather than updating PATH at all, since it this has caused other issues. However, lack of ability to reach PHP does not appear to be the issue here, so this may do nothing. However, perhaps the way /usr/bin/env gets its PATH variable is different from other methods, so using a symlink may resolve it. Since this is the cleaner possible solution I'm trying this one first.

[jamesmontalvo3]

I tried the symlink method above. No joy. I tried the php /usr/local/bin/composer method. No joy. Sigh.

[jamesmontalvo3]

I worked around this issue by instead of moving the composer.phar into /usr/local/bin, instead I copied it there and left behind the composer.phar file in ~/sources. Then, all calls to composer <commands> within install.sh or any child-script must now be in the form:

php ~/sources/composer.phar <commands>

Install is still running, but composer steps appear to have worked. I will need to run this straight through from the beginning to verify any intermediate steps.

[jamesmontalvo3]

npm failed for similar reasons. Going to try exec npm <command>.

[jamesmontalvo3]

Didn't work. Trying:

node /usr/local/lib/node_modules/npm/bin/npm-cli.js install

[jamesmontalvo3]

That alone didn't work, stating that it couldn't find node. What the? So, based on the composer experience and the fact that I symlinked PHP, I tried following Node's make install with:

sudo ln -s /usr/local/bin/node /usr/bin/node

Thus, I symlinked from node from /usr/bin/node. This doesn't make sense, since both of these locations are in PATH by default, but it did work. Why does this make it possible?

I did get some errors in the install, so it needs some work, but VE functions.

[jamesmontalvo3]

This issue is resolved through hackish measures, but needs to be investigated further. A Stack Overflow question should be submitted. Since this issue is to get a non-root user to be able to install, and that is "resolved", this issue will be closed shortly. A separate issue, #90, has been opened for the specific problems with node, npm and composer.

[jamesmontalvo3]

Ran successfully from start to finish except some errors which don't appear to be hurting functionality. See here for full output of install:

https://gist.githubusercontent.com/jamesmontalvo3/639da97c7d9e83cef5f1/raw/non-root.txt

[jamesmontalvo3]

Stack Overflow question posted: http://stackoverflow.com/questions/31332886/long-install-script-successful-as-root-npm-and-composer-not-found-as-non-root-s

[jamesmontalvo3]

This appears to be resolved by the addition to install.sh which makes sure the PATH is appropriately updated.

if [[ $PATH != *"/usr/local/bin"* ]]; then
  PATH="/usr/local/bin:$PATH"
fi

See https://github.com/enterprisemediawiki/Meza1/blob/script-titles/client_files/install.sh#L12

[jamesmontalvo3]

Closed with #79