Re: [Condor-users] Permissioned denied error accessing NFS volume.

[Peter Doherty <doherty@xxxxxxxxxxxxxxxxxxx>]

All right, nevermind, I've tracked down the problem, my own little  
oversight.
In order to start condor at boot, I found a little wrapper script in  
the condor-users list archive.  For whatever reason, the person who  
wrote this script has it su to the condor user before starting  
condor_master, and that kept the jobs from being able to change to  
another uid when running.  It's confusing because whether you start  
condor_master as condor or as root, the output from ps shows it  
running as the condor user.
I hacked up the script to start condor as root.  Sometime I'll have to  
write  a proper launchd plist or script for the mac, because I don't  
see one currently.
Thanks for the advice, Ian and Matthew.


--Peter


On Apr 10, 2009, at 12:09 AM, Peter Doherty wrote:

> Okay, after further playing around, here's what I've determined.
> The jobs are running under my UID on the linux nodes, and under the
> condor user on the mac nodes.
> Both machines use the same condor_config file (from an NFS volume) and
> the condor_config.local is virtually empty, so that all values come
> from the master config.  The linux and mac condor_config.local looks
> the same to me except for different paths to the binaries.
> So....what did I miss here?  How do I get the macs to run the jobs
> with my UID?
> Thanks.
>
>
> --Peter
>
>
> On Apr 9, 2009, at 11:22 PM, Matthew Farrellee wrote:
>
> > Try out TRUST_UID_DOMAIN=TRUE in your configuration.
> >
> > Best,
> >
> >
> > matt
> >
> > Peter Doherty wrote:
> > > It's using automount, and the condor binaries are on the same NFS
> > > share as the files it's complaining about.
> > > The volume is mounted.
> > >
> > > Okay, I did a little more playing around, and I'm thinking the
> > > problem
> > > is in the UID_DOMAIN variable.  This is from the condor manual:
> > >
> > > Some gritty details for folks who want to know: If the submitting
> > > machine and the remote machine about to execute the job both have  
> > > the
> > > same login name in the passwd file for a given UID, and the
> > > UID_DOMAIN
> > > claimed by the submit machine is indeed found to be a subset of what
> > > an inverse lookup to a DNS (domain name server) reports as the fully
> > > qualified domain name for the submit machine's IP address (this
> > > security measure safeguards against the submit machine from simply
> > > lying), THEN the job will run with the same UID as the user who
> > > submitted the job. Otherwise it will run as user ``nobody''.
> > >
> > > The submit machine's DNS domain name matches the UID_DOMAIN, but the
> > > nodes don't.  And I don't really want to change this.  The submit
> > > node
> > > has a public IP, and everything else is on private IP space.  I  
> > > don't
> > > know how it worked before though, since the linux nodes never  
> > > matched
> > > the submit node...so maybe I'm way off base here.
> > >
> > > I tried changing the output file to /tmp/job.out and now I get this
> > > error:
> > >
> > > Hold reason: Error from starter on slot4@xxxxxxxxxxxxxxxxxx: Failed
> > > to
> > > execute '/opt/osg-shared/se/app/site/bin/
> > > condor_nfslite_job_wrapper.sh' with arguments 123845555: Permission
> > > denied
> > >
> > > so it still can't access the NFS share.  This file has perms that
> > > make
> > > it world readable, and the output file that it was complaining
> > > about I
> > > chmoded 777, and it still complained.  Perhaps OSX handles the  
> > > nobody
> > > account differently...
> > >
> > > --Peter
> > >
> > >
> > > On Apr 9, 2009, at 9:58 PM, Ian Chesal wrote:
> > >
> > > > > Any thoughts?
> > > > I'm guess here but: does OS X do per-user fstabs? Maybe your NFS
> > > > share
> > > > isn't mounted for the user running the job?
> > > >
> > > > - Ian
> > > >
> > > > Confidentiality Notice.
> > > > This message may contain information that is confidential or
> > > > otherwise protected from disclosure. If you are not the intended
> > > > recipient, you are hereby notified that any use, disclosure,
> > > > dissemination, distribution,  or copying  of this message, or any
> > > > attachments, is strictly prohibited.  If you have received this
> > > > message in error, please advise the sender by reply e-mail, and
> > > > delete the message and any attachments.  Thank you.
> > > >
> > > > _______________________________________________
> > > > Condor-users mailing list
> > > > To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx
> > > > with a
> > > > subject: Unsubscribe
> > > > You can also unsubscribe by visiting
> > > > https://lists.cs.wisc.edu/mailman/listinfo/condor-users
> > > >
> > > > The archives can be found at:
> > > > https://lists.cs.wisc.edu/archive/condor-users/
> > >
> > > _______________________________________________
> > > Condor-users mailing list
> > > To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx
> > > with a
> > > subject: Unsubscribe
> > > You can also unsubscribe by visiting
> > > https://lists.cs.wisc.edu/mailman/listinfo/condor-users
> > >
> > > The archives can be found at:
> > > https://lists.cs.wisc.edu/archive/condor-users/
> >
> > _______________________________________________
> > Condor-users mailing list
> > To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx
> > with a
> > subject: Unsubscribe
> > You can also unsubscribe by visiting
> > https://lists.cs.wisc.edu/mailman/listinfo/condor-users
> >
> > The archives can be found at:
> > https://lists.cs.wisc.edu/archive/condor-users/
>
> _______________________________________________
> Condor-users mailing list
> To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx  
> with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/condor-users/