On Jan 21, 2011, at 12:56 PM, Jason Swails wrote:
> On Fri, Jan 21, 2011 at 1:40 PM, Gustaf Olsson <gustaf.olsson.lnu.se> wrote:
>
>> Thank you SO much Ben!
>>
>> By running:
>>
>> cd /usr/local/amber11/test && ./test_amber_serial.sh
>>
>> as superuser, the tests begun and are rolling as we "speak". What I cannot
>> wrap my head around is how echo and evn | grep..... both returns all the
>> right info, but it still does not work?
>>
>
> This is explained by my previous post. The reason this is working *now* is
> because you are spawning a root shell from another root shell, so it
> inherits all environment variables. This is not true when you launch a root
> shell from a non-root shell (for security purposes, I'm sure).
>
To elaborate further on this point, it is possible to preserve the environment with "sudo -E [options] [commands]".
> It's dangerous, however, to be playing around in your system as root,
> especially when you're *trusting* that a 3rd-party package (that you didn't
> write) isn't going to do anything malicious (either by accident or
> intentionally). Who knows what test accidentally removes a file from
> ../../../bin instead of ../../bin (thereby potentially removing stuff from
> either /usr/local/bin or even /usr/bin instead of /usr/local/amber11/bin as
> it was supposed to!).
>
> My advice, adapted (or rather taken directly) from Lachele (another
> contributor to this list) is to give some default installation-user
> ownership of directories you intend to install software in (i.e. /usr/local
> or /opt/local if you're going to be using MacPorts, or /sw if you use Fink),
> and run all installation *without* using sudo or sudo -s.
>
In addition to this excellent advice, you may find it difficult to run the parallel tests as the superuser, especially if they use ssh to execute mpi commands (even to localhost). The only way around it is to allow the superuser to ssh in with passwordless ssh, among other things that are dangerous.
>
>>
>> I'm going to be forced to try running:
>>
>> cd $AMBERHOME/test && ./test_amber_serial.sh
>>
>> Just to se if that can circumvent this problem. I just cannot see the
>> problem, cd $AMBERHOME/test brings me to the exact same location as cd
>> /usr/local/amber11/test
>
>
>> Login shell in mac is by default bash, it says so on the window bar at the
>> top. But as far as I have been able to figure, Mac has its own version of
>> bash since running "bash" changes the prompt from VCN736:~ guolaa$ to
>> bash-3.2$.
>>
>
> When you type "bash", it executes that program, dropping you into a *new*
> bash shell session. You will see that it inherits all environment variables
> from your previous shell session (which is just another instance of bash).
> However, you can export new environment variables and the like, but as soon
> as you exit, it will drop you back to the parent shell session (the original
> one you typed bash from) and all changes you made in the *new* session will
> have died when you quit that shell.
>
> It is useful to understand the scope of local and environment variables
> within the shell context. I will not go into a treatise here.
>
>
>>
>> Based on this I have made some assumptions, see under root (/etc) there are
>> two "global" profile files, one called profile and one called bashrc. Of
>> these two, profile has priority.
>>
>
> This is true. But typically, if a .profile file exists, it will source
> ~/.bashrc either at the beginning or the end.
>
>
>>
>> In you user account ($HOME), you can just create .profile, .bashrc, .cshrc,
>> and so on... These are read at terminal startup and at shell-change, but
>> .profile has priority in bash over .bashrc and is read at startup of
>> terminal. So for all my software I set environment and PATH variables in
>> .profile in my $HOME. It has always worked perfectly, except for tests and
>> bugfix with AMBER.
>>
>
> Again, because you are launching a root shell, which has higher priority
> than a normal user shell, and as such will not inherit environment variables
> and such declared in the originating shell. To exemplify this, try the
> following:
>
> export TEST='listen to me'
> echo $TEST
> sudo -s
> echo $TEST
> exit
> echo $TEST
>
Again,
sudo -E -s
echo $TEST
exit
You will see that much (not all!) of the environment is preserved this way.
> You will see that the first and the third return "listen to me", but the
> second does not.
>
> I hope this helps clarify things.
>
> All the best,
> Jason
>
>
>> But thanks to you I can finally gets the job done
>>
>> Best regards
>> // Gustaf
>>
>> On Jan 21, 2011, at 7:18 PM, Ben Roberts wrote:
>>
>>> Hi Gustaf,
>>>
>>> On 21/1/2011, at 1:08 p.m., Gustaf Olsson wrote:
>>>
>>>> Thanks for you input Ben, sadly; no such luck.
>>>>
>>>> Both the echo and env grep presents AMBERHOME as set correctly, but test
>> still fails!
>>>>
>>>> /usr/local/amber11
>>>>
>> /usr/local/amber11/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>>>> VCN736:~ guolaa$ cd /usr/local/amber11/test/
>>>> VCN736:test guolaa$ env | grep PATH
>>>>
>> PATH=/usr/local/packmol:/usr/local/amber11/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>>>> VCN736:test guolaa$ env | grep AMBERHOME
>>>> AMBERHOME=/usr/local/amber11
>>>> VCN736:test guolaa$ sudo make test
>>>> (find . -name '*.dif' -o -name 'profile_mpi' | \
>>>> while read dif ;\
>>>> do \
>>>> rm -f $dif ;\
>>>> done ;\
>>>> )
>>>> rm -f TEST_FAILURES.diff
>>>> Error: AMBERHOME should be defined or else some tests will fail !
>>>> make: *** [is_amberhome_defined] Error 2
>>>> VCN736:test guolaa$
>>>>
>>>> Best regards Gustaf
>>>
>>> If you would, try running "cd /usr/local/amber11/test &&
>> ./test_amber_serial.sh". That will test $AMBERHOME first thing, and if the
>> latter is not defined it will fail.
>>>
>>> Also, where exactly are you setting $AMBERHOME? It may be that the test
>> is starting up as a non-login shell. If it's doing that, setting AMBERHOME
>> in bash_profile or its equivalent may be problematic; bash_profile files are
>> ignored for non-login shells (I think).
>>>
>>> --
>>> For greater security, I support S/MIME encryption.
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Graduate Student
> 352-392-4032
> _______________________________________________
> 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 Jan 21 2011 - 11:30:04 PST
