On Fri, Feb 5, 2016 at 6:51 AM, Joseph Baker <bakerj.tcnj.edu> wrote:
> Hi Jason,
>
> Thanks for the info. I actually do run as root by first using su to become
> root and not with sudo. This must be specific to the Exxact setup for my
> particular machine configuration then (one main fileserver machine that
> exports its amber install directories to my other machines), as the
> update_amber_installation.x script that I pasted in the previous email that
> is used to run update_amber, configure and make has these instructions
>
> #This script will update the Exxact AMBER 14 installation for the latest
> patches.
>
> #It needs to be run as root.
>
This is poor advice IMO. If you *can* chown the directory (permissions
are not as straightforward on shared filesystems), I would highly recommend
doing that and then never running their update_amber_installation.x script
as root again. I would also recommend putting "set -e" at the top of that
script so that it exits as soon as it hits a command that "fails". Because
as it's written now, if any of those commands fail, it will happily move on
to the next one and pretend like everything's fine (and unless you comb
through the output of that script, you may be hard-pressed to even notice).
As a general rule, I avoid sudo like the plague with precious few
exceptions. In fact, I chown /usr/local to my own username (or to a
separate "installer" user if I don't want to risk breaking anything there
in my main user account) specifically to avoid needing to use sudo to
install *anything* that I'm compiling by hand. Or I install it to a
separate directory that I'll create with root and immediately chown to the
installing user. The only installations I ever do as root come from the
package manager -- apt-get, yum, port, or in my case, emerge. "sudo" can
be an easy band-aid, but it's nearly impossible to break or corrupt your OS
with a command that doesn't use it.
But even so, as long as $AMBERHOME/lib/python2.6 contains the MMPBSA_mods
package (with the same contents as are in
$AMBERHOME/AmberTools/src/mmpbsa_py/MMPBSA_mods + some .pyc files), and
amber.sh is sourced and puts $AMBERHOME/lib/python2.6 into $PYTHONPATH,
everything should work fine.
If the standard install *doesn't* work, and those modules are not in that
directory, then more investigation is required to determine what happened
to it. Did the installation fail somewhere before MMPBSA.py and the
setup.py script never get executed? Did some environment variables get
bungled and the setup.py script accidentally dump the package somewhere
else like /lib/python2.6/site-packages?
Since you have a workaround that seems to work for you, that may be good
enough, but in the interest of making future upgrades easier and
alleviating these issues for future users, it would be nice to figure out
what was going wrong in the first place.
All the best,
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 - 05:30:04 PST
