Mailing List ArchivesPublic Access |
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesPublic Access |
|
Whoops. I didn't think to check your platform before recommending GCB.
Unfortunately, GCB is currently only supported by Condor running under
Linux. This explains why your nodes are still advertising the private
network addresses.
--Dan
Nicholas Lavigne wrote:
> I am still running into this problem, where the submit and execute
> nodes are matched but the job does not start (when the execute node is
> on the private network). I have configured GCB exactly as described
> in the networking section of the manual, and seems to be working
> correctly.
>
> Now, the manual mentions that the private nodes should advertise
> themselves as all having the IP address of the broker, but on unique
> ports. Looking at the IP addresses of the pool (condor_status -l |
> grep StartdIp), the private nodes still are showing "StartIpAddr" as
> the address on the private network, instead of the broker's address.
> Could this be the problem? If so how can I correct this?
>
> Also, the Condor pool is almost exclusively Win. XP, should GCB have a
> problem with this?
>
> -Nicholas
>
>
> On 7/19/07, *Dan Bradley* < dan@xxxxxxxxxxxx
> <mailto:dan@xxxxxxxxxxxx >> wrote:
>
>
> Condor requires bidirectional connectivity between the submit node
> and
> the execute node. In other words, Condor must be able to open up
> network connections to the execute machine from the submit machine and
> also to the submit machine from the execute machine.
>
> If connections can only be made in one direction in your network (
> e.g.
> from private to public), then you can configure condor to use GCB to
> broker connections in the reverse direction. There's a section in the
> manual about that:
>
> http://www.cs.wisc.edu/condor/manual/v6.8/3_7Networking.html#SECTION00473000000000000000
>
> --Dan
>
> Nicholas Lavigne wrote:
>
> > Thanks for the reply. I now have all of the machines appearing
> in the
> > pool (as reported by condor_status) but I have a new problem. I
> > *think* I understand the problem, but as of yet the solution is
> > evading me....
> >
> > Our network is mostly Windows and so the vanilla universe is my
> > primary concern. Now, submitting a job from the public network, the
> > central manager is able to match the job to a machine on the private
> > network, but the job does not run, presumably because Condor's file
> > transfer mechanism does not know how to transfer the file from the
> > public network to the private network.
> >
> > I know that other pools are using a similar type of setup and so
> there
> > must be a solution to this problem. I am not currently using a
> > network file system, could this be the answer?
> >
> > -Nicholas
> >
> >
> > On 7/18/07, *Tomas Grigera* <tgrigera@xxxxxxxxxxxxxxxxxx
> <mailto: tgrigera@xxxxxxxxxxxxxxxxxx>
> > <mailto: tgrigera@xxxxxxxxxxxxxxxxxx
> <mailto: tgrigera@xxxxxxxxxxxxxxxxxx>>> wrote:
> >
> > Hi,
> >
> > I use a similar setup. I have
> >
> > BIND_ALL_INTERFACES = TRUE
> >
> >
> > But you must make sure the server name resolves to the
> public IP also
> > for the internal machines.
> >
> > Tomas
> >
> > On 7/17/07, Nicholas Lavigne < condor.list@xxxxxxxxxxxxxx
> <mailto:condor.list@xxxxxxxxxxxxxx >
> > <mailto:condor.list@xxxxxxxxxxxxxx
> <mailto:condor.list@xxxxxxxxxxxxxx>>> wrote:
> > > Due to a shortage of allocated IP addresses on our
> university's
> > network, we
> > > have decided to use the central manager machine (running
> Debian)
> > as a
> > > gateway with two network interfaces and place some compute
> nodes
> > on a
> > > sub-network behind it. The router is doing its job correctly,
> > but the
> > > machines on the subnet do not seem to appear in the Condor
> pool.
> > >
> > > Are there any general rules for having Condor listen on
> two network
> > > interfaces? Maybe some modification to the HOSTALLOW_READ and
> > > HOSTALLOW_WRITE variables on the central manager? Currently,
> > >
> > > HOSTALLOW_READ = *
> > > HOSTALLOW_WRITE = 134.95.*
> > >
> > > But I would like Condor to listen on the 192.168.10.*
> subnet as
> > well.
> > >
> > > Any suggestions?
> > >
> > >
> > > Thanks,
> > > Nicholas Lavigne
> > > University of Cologne
> > > Graduiertenkolleg Risikomanagement
> > >
> > >
> > > _______________________________________________
> > > Condor-users mailing list
> > > To unsubscribe, send a message to
> > > condor-users-request@xxxxxxxxxxx
> <mailto:condor-users-request@xxxxxxxxxxx>
> > <mailto: condor-users-request@xxxxxxxxxxx
> <mailto: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/
> <https://lists.cs.wisc.edu/archive/condor-users/ >
> > >
> > >
> > _______________________________________________
> > Condor-users mailing list
> > To unsubscribe, send a message to
> condor-users-request@xxxxxxxxxxx
> <mailto:condor-users-request@xxxxxxxxxxx>
> > <mailto: condor-users-request@xxxxxxxxxxx
> <mailto: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
> <mailto: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
> <mailto: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/
>
>
_______________________________________________
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/