Re: [HTCondor-users] Setting up HAD-enabled central Managers using IDTokens

[Todd L Miller <tlmiller@xxxxxxxxxxx>]

> I am not quite sure where to go from here.

	If I'm reading that log fragment correctly, this is the master 
attempting to advertise to collector B.  The CollectorLog on B should have 
more information about why IDTOKENS failed.  My guess is is that B's 
ALLOW_WRITE is set to condor@$(TRUST_DOMAIN), given what you said about 
how you installed things.  (You can check with `condor_config_val -raw
ALLOW_WRITE`.)

	When installed with get_htcondor, TRUST_DOMAIN defaults to 
$(CONDOR_HOST), which you've unset.  (You can verify this with 
`condor_config_val -v TRUST_DOMAIN`.)  You should set TRUST_DOMAIN to the 
same string on each machine in your (new) pool; it'll probably work best 
if the string doesn't have any spaces.

	The value of TRUST_DOMAIN at the time the token was issued is 
embedded in the token, and that embedded value must match the configured 
value*.  I have no idea what the tokens on your system(s) have embedded in 
them now (it should be in the output of `condor_token_list`), but you may 
need to re-issue your pool's tokens.**  (If the tokens in your pool were 
issued before you added your 99-spc-cm.config, they might have a sane 
value that you can set TRUST_DOMAIN to and avoid re-issuing tokens.)

	Once you've done that, since A and B have the same signing key 
(derived from the password you installed with), they should accept each 
other's token, granting them the identity 'condor@$(TRUST_DOMAIN)'.  So 
far, so good (hopefully).  This should also allow HAD to work -- IIRC,
HAD requires ADMINISTRATOR privileges, but 'condor@$(TRUST_DOMAIN)' should 
already be in ALLOW_ADMINISTRATOR.

-- ToddM

*: You can configure HTCondor to accept tokens from any trust domain you
   choose, but get_htcondor configures things to accept only tokens from
   $(TRUST_DOMAIN).
**: Using condor_token_create as root.