[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] how to ask an execute machine "stop after this job" ?

Nicolas GUIOT wrote:
I tried that,
> 5/15 17:52:51 DaemonCore: PERMISSION DENIED to unknown user from host <> for command 484 (DAEMONS_OFF_PEACEFUL) > 5/15 17:57:30 DaemonCore: Command received via TCP from host <>

You mean condor_off -peaceful <name>  ?

That most definitely should work and is what you want. Realize you must do it from a machine and/or user authorized for ADMINISTRATOR access.

From your logs it says denied to

But your condor_config says administrator commands from
   io.lbt.ibpc.fr, localhost

And DNS says
C:\home\tannenba\ws_v68-branch\src\condor_daemon_core.V6>nslookup io.lbt.ibpc.fr

Server:  dns4.cs.wisc.edu

Non-authoritative answer:
Name:    io.lbt.ibpc.fr

Since !=, the command was denied.
Does your central manager have multiple interfaces? If so, then you may want to add the other interface names or addresses into HOSTALLOW_ADMINISTRATOR.

BTW - note this email group has archives publically available on the web, so depending on your level of paranoia, I don't know if you wanna be listing actual IP addrs and hostnames in your messages....

and also "condor_config_val -rset START=False", and it gives me the following in the MasterLog :
> 5/15 17:57:30 DaemonCore: received command 60002 (DC_CONFIG_PERSIST), calling handler (handle_config())
> 5/15 17:57:30 WARNING: Someone at is trying to modify "START"
> 5/15 17:57:30 WARNING: Potential security problem, request refused

As it should. Doing remote condor_config_val commands requires CONFIG level access, which is above and beyond ADMINISTRATOR. So you'd need to edit ALLOW_CONFIG (or HOSTALLOW_CONFIG) and also edit either ENABLE_RUNTIME_CONFIG and/or ENABLE_PERSISTENT_CONFIG to True to enable configuration over the wire at all.

Also see the SETTABLE_ATTRS_[ADMINISTRATOR|OWNER|CONFIG] settings that control what config attributes can be changed remotely.

So you may ask why is why is remote config access so protected, and why is it disabled by default (requiring the admin to explicitly enable it)? Because it is so powerful - much more powerful than just typical ADMINISTRATOR access for bringing Condor up and down on nodes, etc. Think about it - if you are starting the condor_master as root, and the config setting DAEMON_LIST tells the master what to launch as root... you can connect the dots. ;).

Hope the above is helpful