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
Received on Fri Jan 21 2011 - 12:00:03 PST
