Re: [Condor-users] jobs fail to run, with "Warning: Found no submitters"

[Zachary Miller <zmiller@xxxxxxxxxxx>]

On Wed, Aug 17, 2005 at 10:29:14AM -0500, Alain Roy wrote:
> 
> >Thanks so much for the help.  I really appreciate it.
> >
> >So I've tried all of these suggestions, and still I haven't been able to 
> >get a job to run yet.
> 
> >> >
> >> > 8/16 14:45:19 (Sending 15 ads in response to query)
> >> > 8/16 14:45:19 DaemonCore: PERMISSION DENIED to unknown user from host 
> ><10.32.47.10:45781> for command 10 (QUERY_STARTD_PVT_ADS)
> 
> I have a bet...
> 
> >>
> >> in this case, you should change your HOSTALLOW_ settings in the config
> >> file to allow IPs from both inside and outside:
> >>
> >> HOSTALLOW_READ = 10.32.47.10 10.0.0.*
> >> HOSTALLOW_WRITE = 10.32.47.10 10.0.0.*
> 
> I bet Zach was wrong--probably the HOSTALLOW variables were set to * 
> already, right? Or something sufficiently open anyway.

well, whatever.  the above settings certainly do no harm.  but i was wrong
about one thing... i didn't mean to just look at READ and WRITE level access.

what about your HOSTALLOW_NEGOTIATOR setting?  is it also set to '*'?
if not, is it also missing the 10.32.47.10 ip address?  see, the command
that is being denied (QUERY_STARTD_PVT_ADS) is actually in the NEGOTIATOR
command level, not READ or WRITE.  sorry about the confusion on that.

in any case, whatever ip address that command comes from needs to be in the
HOSTALLOW_NEGOTIATOR .


by the way, i noticed in a couple other (separate) issues in your previous
email.


> I have set the following variables in global condor_config:
> SEC_DEFAULT_AUTHENTICATION = NEVER
> SEC_CLIENT_AUTHENTICATION = NEVER
> SEC_DEFAULT_AUTHENTICATION_METHODS = CLAIMTOBE
> SEC_CLIENT_AUTHENTICATION_METHODS = CLAIMTOBE

you don't really want AUTHENTICATION set to NEVER.  leave that at OPTIONAL
(which was the default) and if you need to do remote submits set the methods to
CLAIMTOBE.  below i wrote out what i think you want for your security settings.


> In my cluster, all users submit jobs from the head node.

this is problematic when you are not using real authentication.  if someone
logs in to the head node to submit a job, they can probably do 'condor_off' as
well, since the HOSTALLOW_ADMINISTRATOR is likely set to the ip address of your
head/submit node.

if possible, it's best to use a separate machine from your central manager
for submitting jobs.  but here is a config snippet for security settings
that should work for you, assuming your forward/reverse DNS is working:

#### BEGINNING OF CONFIG

# delete any other SEC_* settings you have already and use the following:

HOSTALLOW_READ = 10.32.47.10 10.0.0.*
# or use HOSTALLOW_READ = * if you want that for some reason

HOSTALLOW_WRITE = 10.32.47.10 10.0.0.*
# or use HOSTALLOW_WRITE = * if you want that for some reason

HOSTALLOW_ADMINISTRATOR = condor@$(CONDOR_HOST)
HOSTALLOW_NEGOTIATOR = $(CONDOR_HOST)

SEC_DEFAULT_AUTHENTICATION_METHODS = CLAIMTOBE
SEC_ADMINISTRATOR_AUTHENTICATION = REQUIRED
SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = FS

#### END OF CONFIG


this should allow you to do remote submits using CLAIMTOBE authentication
(no real auth, just IP based essentially), fix your PERMISSION DENIED problem,
and also prevent users on the submit machine from running admin commands.

admin commands will require authentication using the filesystem.  in order to
run condor_off, condor_restart, etc, you will have to be logged in to the
submit machine as user 'condor'.


if we continue this discussion, perhaps we should take this off-line, or you
can open a ticket with condor-admin.  but please let me know how it works.


cheers,
-zach