[Condor-users] Xen VM-based machine suddenly being rejected by collector

[Ian Chesal <ICHESAL@xxxxxxxxxx>]

I have a Xen VM set to run jobs. Last week it was connected up to my
pool without any problems. Today it's being rejected by my collector
with:

6/29 12:36:19 DaemonCore: PERMISSION DENIED to unknown user from host
<137.57.174.68:45472> for command 2 (UPDATE_MASTER_AD), access level
ADVERTISE_MASTER
6/29 12:36:19 Got QUERY_STARTD_ADS
6/29 12:36:19 (Sending 758 ads in response to query)
6/29 12:36:23 DaemonCore: PERMISSION DENIED to unknown user from host
<137.57.174.68:59677> for command 0 (UPDATE_STARTD_AD), access level
ADVERTISE_STARTD
6/29 12:36:24 Got QUERY_SUBMITTOR_ADS
6/29 12:36:24 (Sending 10 ads in response to query)
6/29 12:36:24 DaemonCore: PERMISSION DENIED to unknown user from host
<137.57.174.68:49270> for command 0 (UPDATE_STARTD_AD), access level
ADVERTISE_STARTD

The odd thing is at my collector I have:

> /opt/condor/bin/condor_config_val HOSTALLOW_WRITE
*
> /opt/condor/bin/condor_config_val SEC_CLIENT_AUTHENTICATION_METHODS
CLAIMTOBE, ANONYMOUS

Nothing has changed in the configs for the collector for a very long
time. Nor have the configs for the Xen VM changed.

I'm not sure what else to check here. The VM looks to be in the
.altera.com domain and IP <<->> hostname resolution is working
correctly. The rest of my security settings are:

FILESYSTEM_DOMAIN = altera.com
HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST), $(FULL_HOSTNAME)
#HOSTDENY_ADMINISTRATOR = *
HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_ADMINISTRATOR)
HOSTALLOW_READ = *
HOSTALLOW_WRITE = *
HOSTALLOW_NEGOTIATOR = $(NEGOTIATOR_HOST)
HOSTALLOW_NEGOTIATOR_SCHEDD = $(NEGOTIATOR_HOST),
$(FLOCK_NEGOTIATOR_HOSTS)
HOSTALLOW_CONFIG = $(HOSTALLOW_OWNER)
HOSTALLOW_WRITE_COLLECTOR = $(HOSTALLOW_WRITE), $(FLOCK_FROM)
HOSTALLOW_WRITE_STARTD    = $(HOSTALLOW_WRITE), $(FLOCK_FROM)
HOSTALLOW_READ_COLLECTOR  = $(HOSTALLOW_READ), $(FLOCK_FROM)
HOSTALLOW_READ_STARTD     = $(HOSTALLOW_READ), $(FLOCK_FROM)
#TRUST_UID_DOMAIN = False
SEC_DEFAULT_NEGOTIATION    = OPTIONAL
SEC_DEFAULT_AUTHENTICATION = OPTIONAL
SEC_DEFAULT_ENCRYPTION     = OPTIONAL
SEC_DEFAULT_INTEGRITY      = OPTIONAL
SEC_CLIENT_AUTHENTICATION_METHODS = CLAIMTOBE, ANONYMOUS
SEC_DEFAULT_AUTHENTICATION_METHODS =
$(SEC_CLIENT_AUTHENTICATION_METHODS)
QUEUE_ALL_USERS_TRUSTED = True

That's pretty darn open. Although now I'm wondering if it's
TRUST_UID_DOMAIN being left at its default. Funny it worked for a while
though.

No other machine in my pool is experiencing troubles connecting. It's
something to do with the Xen image. I just can't put my finger on what
exactly.

- 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.