On Fri, Feb 5, 2016 at 7:46 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> I cannot see the problem here.
>
Except that the OP ran this script and MMPBSA.py didn't work.
> su -
> cd /usr/local/amber14
>
> ./update_amber --update
>
> ./configure gnu
> make -j8 install
> make clean
> ./configure -mpi gnu
> make -j8 install
> make clean
> ./configure -cuda gnu
> make -j8 install
> make clean
> ./configure -cuda -mpi gnu
> make -j8 install
> make clean
>
> Is PERFECTLY valid. If it does not work then someone broke the AMBER
> install process and it should be fixed.
>
There are always machines and configurations that AMBER doesn't work on,
and it's possible to break the Amber build by breaking a component of your
system that AMBER depends on. And environment setups are so customizable
that it's impossible to test every possible setup a user might have.
Then there's the fact that the script above, as written, does NOTHING to
alert users to something that might have gone wrong. To the untrained eye,
output from that script where every command (except the "make clean"s)
failed is almost indistinguishable from the output of the script working
correctly. A simple "set -e" at the top fixes all that.
>
> Nothing wrong with doing this as root if it is going in a global directory
> (/usr/local - that is owned by root). Sure one can do it as a nonroot user
> that has write permission etc and make sure world permissions are right
> etc. But that just complicates things for an end user and doesn't really
> gain anything if one implicitly trusts the AMBER installer.
>
*I* don't trust the AMBER installer. And in its current incarnation, I've
written a large portion of it. My priorities when I hack on it are (1) get
it to work right (on my machines), (2) get it to work easily and simply for
users, (3) try not to make it super-obviously unsafe. So what I'm saying
is do not trust me enough to run Amber's install as root -- either with
sudo or su -. There's no guarantee that the build process catches invalid
environments before it tries to use them (which could result in undefined
and potentially destructive behavior).
And since Exaact is doing this setup, it's simple for them to set
permissions and ownership in a safer manner before shipping to the user.
To a user, there's no difference between running the command
su -
./update_amber_whatever
and
su - installer
./update_amber_whatever
Only in the latter incarnation, a borked environment or subtle issue with a
build scripts can't torpedo your whole OS. Running the Amber install as
root has a higher level of risk than many other packages because it's not a
simple canned CMake or autotools setup -- it's a series of custom scripts
and Makefiles cobbled together over decades by people like me.
If you want my advice: don't install as root. It makes it harder to spot
and debug problems, and riskier when they crop up. *Especially* if you
start doing stuff like running *parts* of the build process as root (since
that dramatically increases the chances that you'll bypass a security check
on your environment that would otherwise catch an error).
And it's so easy to simply avoid this that it's foolish to me to insist on
root installs.
HTH,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Feb 05 2016 - 19:00:03 PST
