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.
Joe
On Thu, Feb 4, 2016, 10:23 PM Jason Swails <jason.swails.gmail.com> wrote:
> On Thu, Feb 4, 2016 at 5:50 PM, David A Case <david.case.rutgers.edu>
> wrote:
>
> > On Thu, Feb 04, 2016, Joseph Baker wrote:
> >
> > > I looked in the config.h in my amber directory, and I did not see the
> > > PYTHON_INSTALL variable in there. The PYTHON path in config.h is
> > >
> > > #Python interpreter we are using
> > > PYTHON=/usr/bin/python2.6
> >
> > OK: my fault. The PYTHON_INSTALL variable has been added since
> > AmberTools15
> > was released.
> >
> > > So I just execute that as root and it runs ./update_amber and the
> > > ./configure script and make commands to compile everything. I still had
> > to
> > > do the manual make_install inside of the MMPBSA directory to get that
> to
> > > update.
> >
> > This is odd, since I think no one has reported this problem before.
> There
> > is
> > a possibility that the Exxact configuration is odd in some subtle way.
> Or
> > there is something else wrong.
> >
> > Since your problem seems have been fixed (by you), and since the way in
> > which
> > we handle python will be very different in the upcoming release, I'm
> > inclined
> > to wait to see if others report the same problem. (Jason may have some
> > ideas
> > here.)
> >
>
> I added something to the Makefile which forces install targets to be
> overwritten, but I don't think that's what's happening here. I have a
> suspicion and it boils down, perhaps not surprisingly, to "installing as
> root". Of course it depends on how you install as root -- are you doing
> something like "su -" and running commands as the user root, or using
> "sudo" to dispatch commands one by one? It's a very important distinction
> (described below). The Makefile in AmberTools 15 has this rule
>
> install: $(BINDIR)/mmpbsa_py_nabnmode$(SFX)
> $(BINDIR)/mmpbsa_py_energy$(SFX)
> $(PYTHON) setup.py install --prefix=$(AMBERHOME)
> --install-scripts=$(BINDIR)
>
> I suspect what may be happening here is a misunderstanding of the rocky
> relationship between sudo and environment variables. In this Makefile,
> BINDIR and SFX are inherited from config.h, but AMBERHOME is inherited from
> the environment.
>
> I'll walk through a demo (in bash) and explanation of shell variables,
> environment variables, and sudo with the hope that it helps people
> understand what may be happening. Let's start with what makes environment
> variables special. You can set something as either an environment variable
> or a shell variable and access it with the "$" operator. So far, shell and
> environment variables look the same:
>
> > export ENVVAR='environment var'
> > SHELLVAR='shell var'
> > echo $ENVVAR
> environment var
> > echo $SHELLVAR
> shell var
>
> But environment variables are "stickier". If you launch a new shell, that
> shell will inherit all of the environment variables of its calling shell,
> but none of the shell variables (environment variables have "global" scope
> in programming parlance). For example, "bash -c cmd" runs "cmd" in a new
> shell and the use of single-quotes here is important [1]:
>
> > bash -c 'echo $SHELLVAR'
>
>
> > bash -c 'echo $ENVVAR'
> environment var
>
> So you see, shell variables do not get inherited by calling shells. But
> sudo is special. By default (which is an important security setting), the
> environment of the calling shell is NOT passed on to called shells. This
> is not entirely obvious -- see this misleading behavior:
>
> >
>
> sudo echo $ENVVAR
> environment var
> > sudo echo $SHELLVAR
> shell var
>
> But ENVVAR and SHELLVAR are expanded from the current shell session. We
> need to use the "bash -c" trick to make sure that the sudo command actually
> launches another shell. In that case, we can see that the shells we launch
> with sudo do not inherit environment variables or shell variables:
>
> >
> sudo bash -c 'echo $ENVVAR'
>
> >
> sudo bash -c 'echo $SHELLVAR'
>
> You can use "sudo -E" to explicitly inherit the environment:
>
> >
> sudo -E bash -c 'echo $SHELLVAR'
>
>
>
> >
> sudo -E bash -c 'echo $ENVVAR'
> environment var
>
> So if you "installed as root" using "sudo" without "sudo -E", then the
> MMPBSA.py install line would get interpreted as
>
> /usr/bin/python2.6 setup.py install --prefix=
> --install-scripts=/share/apps/amber14/bin
>
> In which case, the modules get installed to /lib/python2.6/site-packages,
> and Python never looks there which would fully explain this error. You can
> check for the existence of this directory -- if /lib/python2.6 exists, then
> it must have been created by the above command (since it doesn't exist in
> "standard" CentOS installs).
>
> Which comes back to advice that I give every time I see someone installing
> Amber as root: don't do that. If you want to install in a place you don't
> have privileges, use root to change the ownership of $AMBERHOME and then
> install as a regular user. Our Makefiles could be more robust and avoid
> using environment variables (Amber 16 will not have this dependence on
> AMBERHOME in the Python Makefiles), but installing/using Amber without
> AMBERHOME installed is not supported, nor is the behavior well-defined. If
> you do this as root, then anything that would have been a permission error
> suddenly "just happens". And some of the clean rules remove files. What
> happens if "rm -fr $(AMBERHOME)/bin/*" gets executed as root with AMBERHOME
> undefined?... I don't think this could possibly happen in Amber right now,
> but I almost never test installing as root so I simply don't know, and
> probably can't guarantee that nobody will add something like that in the
> future without realizing the potential consequences of running as root.
>
> So maybe it's time to run "sudo chown -R `whoami` /share/apps/amber14" so
> you don't have to run any Amber updating/installing as root anymore...
>
> HTH,
> Jason
>
> [1] Single-quotes are important to use because double-quotes will tell the
> current shell to expand the variable *before* launching the "bash"
> program. So the command
>
> > bash -c "echo $SHELLVAR"
>
> will get processed by the shell as
>
> > bash -c "echo shell var"
>
> and the new bash process will happily print the contents of $SHELLVAR,
> (mis)leading you to believe that the shell variable is inherited by the
> child shell when it's really not. Single quotes prevents this expansion
> and sends the string "echo $SHELLVAR" to the new bash process, which is
> then responsible for substituting the value of that variable (which is not
> defined since shell variables are not inherited).
>
> Whew!
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Feb 05 2016 - 04:00:03 PST
