[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] CCB private address
- Date: Wed, 3 Aug 2022 16:17:51 -0500 (CDT)
- From: Todd L Miller <tlmiller@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] CCB private address
$ condor_status -collector -l
MyAddress = "<192.168.56.1:9618?PrivAddr=%3c172.20.0.2:9618%3fsock%3dcollector%3e&PrivNet=docker_cm&addrs=192.168.56.1-9618&alias=cm.cobaldtardis&noUDP&sock=collector>"
$ condor_status -negotiator -l
And the scheduler advertises the CCB, but not the private address:
$ condor_status -schedd -l
MyAddress = "<192.168.56.3:9619?CCBID=192.168.56.1:9618%3fPrivNet%3ddocker_cm%26addrs%3d192.168.56.1-9618%26alias%3dcm.cobaldtardis%26noUDP%26sock%3dcollector#111&PrivAddr=%3c172.18.0.2:9619%3fsock%3dschedd_11_1fa1%3e&PrivNet=docker&addrs=192.168.56.3-9619&alias=sub.cobaldtardis&noUDP&sock=schedd_11_1fa1>"
I'm not sure why your schedd is on port 9619. Was that deliberate
for some reason?
On my test setup I can allow incoming connections and leave out the CCB. If I
do that, everything works perfectly. Just adding the CCB breaks the setup.
So, my question is: shouldn't the private address of the CCB be advertised?
And if this behavior is intended, why is 'PrivNet' included at all?
The private network address is included so that daemons which are
on the same private network can bypass CCB and talk to each other
directly. There should never be a reason to contact a CCB on its private
network address; by definition, its public address is reachable from
anyone who wants to use it as a broker. (The code removes the private
network address on purpose; not removing the private network name is just
a confusing oversight.)
I can't tell from the log fragment you posted, but if the
negotiator can't connect to its own public IP, you'll just need to fix
that (or use TCP_FORWARDING_HOST to choose an IP everyone in your pool can