hOn Fri, 20 Feb 2009, Rob wrote:
> Ian Chesal wrote:
>>
>> Don't put condor_status on the machines. You'll want it to be available
>> from a network location for debugging purposes but you don't need to
>> putit on the machines running jobs.
>
> This is a rather insecure solution. An evil person at a public library PC
> may reinstall the condor_status executable and query the pool of PCs....
>
> I was looking for a solution, which configures the central manager such that
> it permits condor status queries *ONLY* to by the central manager itself.
> I thought the HOSTALLOW_READ macro in the central manager's
> config file would control this; but that does not seem to work.
>
> Hence, is there then no way to configure the central manager in such
> a way that it does not give the full pool information to all the pool PCs?
>
> Thanks.
> Rob.
>
Probably, but it will take some kind of authentication within the pool,
for instance, by restricting CLIENT and READ access to only those
who have possession of some kerberos or SSL certificate.
A tricky business and there's no good documentation I have
ever found as to which activity is which authentication level.
(ADMINISTRATOR, OWNER, WRITE, READ, CLIENT, DAEMON
and I think there is one other one).
In general you have to let the condor daemons in the pool have
not only read but write to the collector, but that does not
necessarily mean that all users on the machine need have the
same rights.
Steve timm
--
------------------------------------------------------------------
Steven C. Timm, Ph.D (630) 840-8525
timm@xxxxxxxx http://home.fnal.gov/~timm/
Fermilab Computing Division, Scientific Computing Facilities,
Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}