Re: [Condor-users] condor_q -global error....

[Dan Bradley <dan@xxxxxxxxxxxx>]

Condor relies on a reverse DNS lookup to tell it the full hostname of 
the incoming connection.  In Robert's case, it sounds like the reverse 
DNS lookup yields a hostname without a domain.  Without a domain name in 
the results from the reverse DNS lookup, *.domain is useless in the 
authorization policy.

Can you verify that a reverse DNS lookup of the rejected IP address from 
the host that is rejecting the connection yields the same results 
reported by Condor?

As Cathrin pointed out, if it is problematic to reconfigure your DNS, 
you can phrase your authorization policy in terms of IP addresses 
instead of names.  But it would be nice to understand why the behavior 
has changed.

--Dan

Michael O'Donnell wrote:
> Robert,
>
> We are using Condor 7.4.2 on all XP SP3 clients and an XP SP3 central 
> manager, and we also found this problem. We were not able to use 
> *.domain name or some other combination. Instead we had to use *.* for 
> the allow entries. I thought it might of had to do with something we 
> had wrong in our configuration, but after hearing what you found, it 
> sounds like this might be tied to SP3 or Condor 7.4.x. I would be 
> interested in hearing whether others are having similar problems and 
> what a possible work around might be.
>
> mike
>
>
>
>
>
> From: 	Robert Mortensen <bobm@xxxxxxxxxxxxxxxxxxxx>
> To: 	Condor-Users Mail List <condor-users@xxxxxxxxxxx>
> Date: 	05/03/2010 07:52 PM
> Subject: 	[Condor-users] condor_q -global error....
> Sent by: 	condor-users-bounces@xxxxxxxxxxx
>
>
> ------------------------------------------------------------------------
>
>
>
> On one of our machines, <first-machine-name> (Windows 7, 64-bit, 
> condor 7.4.1), condor_q -global fails with the following error:
>  
> -- Failed to fetch ads from: <10.1.2.22:9686> : <second-machine-name>
>
> When looking at the SchedLog on <second-machine-name> (Windows XP, 
> 32-bit, condor 7.4.1) I find:
>  
> 05/03 17:29:53 (pid:4144) PERMISSION DENIED to unauthenticated user 
> from host 10.1.2.143 for command 1111 (QMGMT_CMD), access level READ: 
> reason: READ authorization policy contains no matching ALLOW entry for 
> this request; identifiers used for this host: 
> 10.1.2.143,<first-machine-name>
>
> and:
>
> 05/03 18:12:04 (pid:4144) PERMISSION DENIED to unauthenticated user 
> from host 10.1.2.143 for command 1111 (QMGMT_CMD), access level READ: 
> reason: cached result for READ; see first case for the full reason
>
> Both <first-machine-name> and <second-machine-name> have 
> ALLOW_READ/WRITE = *.<our-domain-name>. The curious thing is that in 
> the first message of the SchedLog from <second-machine-name>, the 
> <first-machine-name> does not contain <our-domain-name>. I think that 
> changing ALLOW_READ/WRITE to be "*" would solve the problem, but I 
> would rather not do that.
>
> We have other similarly configured machines that appear to be 
> OK._______________________________________________
> 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/
>