Hi again Ian:
I'm running version 7.6.1. I think the relevant permissions settings in condor_config are below. If I change them, will I need to restart everything?
Thanks!
Mike
##--------------------------------------------------------------------
## Host/IP access levels
##--------------------------------------------------------------------
## Please see the administrator's manual for details on these
## settings, what they're for, and how to use them.
## What machines have administrative rights for your pool? This
## defaults to your central manager. You should set it to the
## machine(s) where whoever is the condor administrator(s) works
## (assuming you trust all the users who log into that/those
## machine(s), since this is machine-wide access you're granting).
ALLOW_ADMINISTRATOR=$(IP_ADDRESS)
## If there are no machines that should have administrative access
## to your pool (for example, there's no machine where only trusted
## users have accounts), you can uncomment this setting.
## Unfortunately, this will mean that administering your pool will
## be more difficult.
#DENY_ADMINISTRATOR = *
## What machines should have "owner" access to your machines, meaning
## they can issue commands that a machine owner should be able to
## issue to their own machine (like condor_vacate). This defaults to
## machines with administrator access, and the local machine. This
## is probably what you want.
ALLOW_OWNER = $(FULL_HOSTNAME), $(ALLOW_ADMINISTRATOR)
## Read access. Machines listed as allow (and/or not listed as deny)
## can view the status of your pool, but cannot join your pool
## or run jobs.
## NOTE: By default, without these entries customized, you
## are granting read access to the whole world. You may want to
## restrict that to hosts in your domain. If possible, please also
## grant read access to "*.cs.wisc.edu", so the Condor developers
## will be able to view the status of your pool and more easily help
## you install, configure or debug your Condor installation.
## It is important to have this defined.
ALLOW_READ=*
#ALLOW_READ = *.your.domain, *.cs.wisc.edu
#DENY_READ = *.bad.subnet, bad-machine.your.domain, 144.77.88.*
## Write access. Machines listed here can join your pool, submit
## jobs, etc. Note: Any machine which has WRITE access must
## also be granted READ access. Granting WRITE access below does
## not also automatically grant READ access; you must change
## ALLOW_READ above as well.
##
## You must set this to something else before Condor will run.
## This most simple option is:
## ALLOW_WRITE = *
## but note that this will allow anyone to submit jobs or add
## machines to your pool and is a serious security risk.
ALLOW_WRITE = $(FULL_HOSTNAME), $(IP_ADDRESS)
#ALLOW_WRITE = *.your.domain, your-friend's-machine.other.domain
#DENY_WRITE = bad-machine.your.domain
## Are you upgrading to a new version of Condor and confused about
## why the above ALLOW_WRITE setting is causing Condor to refuse to
## start up? If you are upgrading from a configuration that uses
## HOSTALLOW/HOSTDENY instead of ALLOW/DENY we recommend that you
## convert all uses of the former to the latter. The syntax of the
## authorization settings is identical. They both support
## unauthenticated IP-based authorization as well as authenticated
## user-based authorization. To avoid confusion, the use of
## HOSTALLOW/HOSTDENY is discouraged. Support for it may be removed
## in the future.
## Negotiator access. Machines listed here are trusted central
## managers. You should normally not have to change this.
ALLOW_NEGOTIATOR = $(CONDOR_HOST)
## Now, with flocking we need to let the SCHEDD trust the other
## negotiators we are flocking with as well. You should normally
## not have to change this either.
ALLOW_NEGOTIATOR_SCHEDD = $(CONDOR_HOST), $(FLOCK_NEGOTIATOR_HOSTS)
## Config access. Machines listed here can use the condor_config_val
## tool to modify all daemon configurations. This level of host-wide
## access should only be granted with extreme caution. By default,
## config access is denied from all hosts.
#ALLOW_CONFIG = trusted-host.your.domain
## Flocking Configs. These are the real things that Condor looks at,
## but we set them from the FLOCK_FROM/TO macros above. It is safe
## to leave these unchanged.
ALLOW_WRITE_COLLECTOR = $(ALLOW_WRITE), $(FLOCK_FROM)
ALLOW_WRITE_STARTD = $(ALLOW_WRITE), $(FLOCK_FROM)
ALLOW_READ_COLLECTOR = $(ALLOW_READ), $(FLOCK_FROM)
ALLOW_READ_STARTD = $(ALLOW_READ), $(FLOCK_FROM)
On Feb 1, 2012, at 6:06 PM, Ian Chesal wrote:
What are your admin settings now? If you're using the old style permission settings, wide open is:
HOSTALLOW_ADMIN = *
Regards,
- Ian
Ian
Thanks tons! That's getting me closer.....
I tried running:
and got the following output:
02/01/12 17:55:13 Locale: English_United States.1252
02/01/12 17:55:13 condor_read() failed: recv() returned -1, errno = 10054 , read
02/01/12 17:55:13 IO: Failed to read packet header
Couldn't fetch log: permission denied.
Is there a way for me to elevate permissions? I'm running with admin rights on all the machines.....
Thanks,
Mike
On Feb 1, 2012, at 5:49 PM, Ian Chesal wrote:
You bet:
$(LOG)/StarterLog.slot#
It'll have the full cluster.proc in the file as well as the remote working directory for the job. Which contains the PID of the starter process for the job encoded in the directory name.
You can get the contents remotely with the condor_fetchlog tool.
Regards,
- Ian
Hi All
I asked a question earlier about trying to link job number with physical running location on Windows. This has led me to a refined question:
Is there a log file that records both the PID and the condor job number in a way that I can link the two together? For debugging purposes, it is important for me to be able to physically locate certain jobs submitted through Condor, but unfortunately this is not straightforward. Condor_ssh_to_job is a fantastic resource for this on Linux, but of course, no dice in Windows.
Many thanks!
Cheers,
Mike
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Michael Fienen, Ph. D.
Research Hydrologist, Groundwater Specialist
United States Geological Survey
Wisconsin Water Science Center
_______________________________________________
Condor-users mailing list
subject: Unsubscribe
You can also unsubscribe by visiting
The archives can be found at:
_______________________________________________
Condor-users mailing list
subject: Unsubscribe
You can also unsubscribe by visiting
The archives can be found at:
_______________________________________________
Condor-users mailing list
subject: Unsubscribe
You can also unsubscribe by visiting
The archives can be found at:
_______________________________________________
Condor-users mailing list
subject: Unsubscribe
You can also unsubscribe by visiting
The archives can be found at:
_______________________________________________
Condor-users mailing list
subject: Unsubscribe
You can also unsubscribe by visiting
The archives can be found at:
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}