[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] newbie - condor remote job submission problem



Hi,

Sorry for interrupting the discussion.

Since you are discussing about remote submission :)

Have you tried remote submit the jobs to a schedd which eventually submit
to the globus universe?

Thanks,
Carson

> Hi Krishna,
>
> If you are using NIS domain, you might want to define the UID_DOMAIN in
> your condor_config file. Besides, Ensure that you have individual
> directories under $(HOSTS) for log, execute. You can have same directory
>  for spool, but, since lock files are created in $(LOG), they often pose
>  these problems.
>
> Regards,
>
> Nitin
>
> krishnaprasad wrote:
>
>>Dear Zach
>>
>>	I have changed my condor_config file as you said. But still if iam
>>giving the remote submission command , the following error is coming
>>
>>	ERROR : Failed to connect to queue manager <machine name>
>>	AUTHENTICATE :1003 : Failed to authenticate with any method.
>>
>>
>>
>>Regards
>>
>>Krishnaprasad
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>On Mon, 2005-02-21 at 23:53, Zachary Miller wrote:
>>
>>
>>>On Mon, Feb 21, 2005 at 05:31:54PM +0530, krishnaprasad wrote:
>>>
>>>
>>>>Hai all
>>>>
>>>>Iam facing a problem in remote job submission. If Iam trying to do
>>>>
>>>>                condor_submit -r <machine name>  jobfile
>>>>
>>>>then the following error is coming: -
>>>>
>>>>    ERROR : Failed to connect to queue manager <machine name>
>>>>    AUTHENTICATE : 1003: Failed toauthenticate with any method
>>>>    [ more errors ]
>>>>
>>>>
>>>submitting a job requires that you authenticate yourself to the
>>> schedd. normally on a unix machine, when you submit to a schedd
>>> running on your local machine, this is accomplished using 'FS'
>>> authentication, which means filesystem.  the condor_submit process
>>> writes a file in /tmp, and the schedd looks at the owner of that file
>>> to see if you are who you say you are.  now, this method will
>>> obviously fail when submitting remotely because each machine has it's
>>> own /tmp.
>>>
>>>there are a number of things you can do:
>>>1) if you require real security, you can use KERBEROS (difficult to
>>> set up if you aren't already using it) or GSI which is slightly easier
>>> to set up.
>>>
>>>2) you can essentially disable the authentication by using the
>>> authentication method 'CLAIMTOBE'.  this isn't included in the default
>>> list because it is not secure, but it will always succeed.  to do
>>> this, add a line like this to your condor_config:
>>>  SEC_DEFAULT_AUTHENTICATION_METHODS = CLAIMTOBE
>>>
>>>3) it is possible, though not recommended at all, to use a shared
>>> filesystem like NFS for authentication.  then, instead of writing into
>>> /tmp, you can choose your own directory for condor to use for
>>> authentication.  if you then  choose a shared directory that both the
>>> submit machine and the machine with the schedd can access, you can use
>>> FS_REMOTE.  the downside of this is that it sometimes fails
>>> (especially under load) because the two sides do not sync properly.
>>> this will be addressed later in the 6.7.X series but for now the
>>> FS_REMOTE method should only be used for experimentation.
>>>
>>>let me know if i can help answer more questions.  for more info you
>>> can also read the security section of the manual here:
>>>  http://www.cs.wisc.edu/condor/manual/v6.6.8/3_7Security_In.html
>>>
>>>
>>>cheers,
>>>-zach
>>>
>>>_______________________________________________
>>>Condor-users mailing list
>>>Condor-users@xxxxxxxxxxx
>>>https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>>>
>>>
>>
>>_______________________________________________
>>Condor-users mailing list
>>Condor-users@xxxxxxxxxxx
>>https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>>
>>