Thanks, glad to be a membership candidate!
This is actually making a whole lot of sense! And thanks for the user tip, saved me a lot of thinking!
Have a really nice weekend!
// Gustaf
Skickat från min iPhone
21 jan 2011 kl. 20:52 skrev "Jason Swails" <jason.swails.gmail.com>:
> On Fri, Jan 21, 2011 at 2:19 PM, Gustaf Olsson <gustaf.olsson.lnu.se> wrote:
>
>> Thank you Jason and David
>>
>> Yes it is slowly getting clearer for me. Some times I think I will end up
>> learning more about computers that chemistry during my studies : )
>>
>
> Welcome to the club ;).
>
>
>> Just one quickie? The login shell is not by default a root shell, and I
>> jumped from my default user bash shell to su. Does that still inherit env.
>> variables? Obviously it seems like it, since it's working, but I got a
>> little but confused. Su must have higher priority than my normal user shell,
>> and i did not export AMBERHOME in sudo this time, but in my own user shell.
>>
>
> I don't use su. In fact, Mac OS X makes the path to enabling the super user
> intentionally (?) convoluted (in an effort to dissuade people from doing
> it?). Instead of launching a root shell via su, you may consider "sudo -s".
> Or, as David pointed out, "sudo -E -s" to preserve the environment (thanks
> to David for pointing out this feature). I think sudo -s is a generally
> safer way of launching a root shell than "su" -- inasmuch as running around
> as root can be *safe*. Indeed, I try to set my permissions such that I
> rarely (if ever) even need sudo. A notable exception is running aptitude in
> Ubuntu, as it operates in /usr/bin and I certainly don't want to assume
> ownership of that. I'm OK with trusting OS-provided package managers,
> though.
>
>
>>
>> Your both correct regarding the risky use of su and sudo of course. I'll
>> look over my /sw and any /usr/local and set up different permissions. I
>> don't want any potential other users to be able to fiddle with what I have
>> stored there, but I'll be better of solving this in some other way then su
>> and sudo way or form.
>>
>
> Simple -- create a new user. Call her (or him, to avoid cries of sexism)
> "finkinstaller" or something, and give ownership of /usr/local and /sw to
> that user. That way, you can log in as finkinstaller to do work your
> install magic and prevent anyone else from mucking around there.
>
> I am not a system admin, though I like to pretend with my computers. I've
> found that my suggested protocols (some stolen from people like Lachele)
> work well for my system and seem to be extensible to multi-user systems in
> terms of safety and security. I will try and get around to modifying the
> installation documentation to warn of potential permission/ownership issues
> that arises when one tries to install in /usr/local and maybe provide a
> process that doesn't advocate installing in such a location.
>
> All the best,
> Jason
>
>
>> Best of regards to both!
>> And thank you both again
>>
>> // Gustaf
>>
>>
>>
>> On Jan 21, 2011, at 7: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).
>>>
>>> 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.
>>>
>>>
>>>>
>>>> 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
>>>
>>> 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
>>
>
>
>
> --
> 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 - 12:30:02 PST
