Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
| "Alas, Alex [FEDI]"
<aalas@xxxxxxxxxxxxx>
17.12.2008 16:05 |
|
| "Alas, Alex [FEDI]"
<aalas@xxxxxxxxxxxxx> Gesendet von: condor-users-bounces@xxxxxxxxxxx 17.12.2008 15:22
|
|
| Greg Quinn <gquinn@xxxxxxxxxxx>
Gesendet von: condor-users-bounces@xxxxxxxxxxx 16.12.2008 17:07
|
|
Hi all,
Many discussions on this list surround folks having trouble getting the
Windows "run_as_owner" feature working by setting up a CredD.
I have
just finished rewriting the related section of our manual to give more
of a self-contained HOWTO style introduction. I'm hoping it will make it
easier for people to get the CredD set up in the future.
The new text will be in the some-to-be-released 7.2.0 version of the
manual, but in the mean time I've placed a 2-page PDF with the relevant
section (6.2.4) here:
http://pages.cs.wisc.edu/~gquinn/run_as_owner.pdf
Please, check it out if you're a user of Condor on Windows. I'm happy to
incorporate suggestions.
Thanks!
Greg Quinn
Condor Team
> Hello everybody,
>
> I want to use condor to get the Power of the HighThroughputComputing.
> But it seems very hard to get Condor running.
>
> Actually all Condor machines are installed, I can submit jobs, but
the jobs will never be
> executed. I think it depends on an wrong configuration because i want
to use network access
> and try to run the jobs under the submitted user.
>
> I want to use condor in a windows domain, and I started to set up
following machines:
> -1 condor controller machine
> -1 condor submitter machine
> -1 condor execution machine
>
> I use condor version 7.0.5.
> I want to use run the jobs under an "real" user account,
to get access to special network files on an
> File Server.
>
> I used the help from site http://ben.versionzero.org/wiki/Condor_Authentication
> and the Presentation called "quinn_windows_tutorial.ppt"
to get the condor setup working, but without
> success.
>
> Have someone a idea, what's going wrong here ?
> Where can I look next to get more information, to find the mistake?
>
> When i installed condor, i put on every machine the pool password,
with the commands
>
> condor_store_cred add -c -n executionmachine.test.mydomain.com
> condor_store_cred add -c -n submitmachine.test.mydomain.com
> condor_store_cred add -c -n controller.test.mydomain.com
>
> I Used here the password "xyz" which is no domain password.
>
> after that i was on the submit machine and typed
>
> "condor_store_cred add" where condor ask after an Passsword
for User@test
> I typed in my password, and that was all. (This password was my domian
password)
>
> After that i submitted my job.sub File which was tested on an default
Condor installation
> (without execute as submit user)(this worked...)
>
> job.sub:
> ========
>
> Universe = vanilla
> Executable = job.bat
> Arguments = 4 12
> Log = simple.log.txt
> Output = simple.out.txt
> Error = simple.err.txt
>
> run_as_owner = true
>
> Queue
>
>
>
> But nothing happend. This means, when i check the status with condor_q
> i will see the job in the queue, but they will be idle.
>
> Did I made some configuration wrong?
> Or did I set up some passwords wrong?
>
> It would be great, if someone has an idea, what i have to to to get
condor running.
>
> Thank you very much for your help.
> Every advice would be helpfull.
>
> Robert
>
>
>
>
>
> Here are my configurations:
>
> The condor_config File of the Controller has following changes to
the original:
> ========================================================
>
> LOCAL_CONFIG_FILE = $(LOCAL_DIR)/condor_config.local \
>
$(LOCAL_DIR)/condor_config.local.credd
>
> HOSTALLOW_CONFIG = Submitmachine.test.mydomain.com
>
> And the condor_config.local.credd of the Controller looks like this:
> ================================================
> ######################################################################
> ##
> ## condor_config.credd
> ##
> ## This is the default local configuration file for the machine
> ## running the condor_credd. You should copy this file
to the
> ## appropriate location and customize it for your needs.
> ##
> ######################################################################
>
> ## Note: The following settings will need to be present in your
> ## global config file:
> ##
> ## CREDD_HOST = my-credd.cs.wisc.edu
> ## STARTER_ALLOW_RUNAS_OWNER = True
> ## CREDD_CACHE_LOCALLY = True
> ##
> ## You'll also need to ensure that clients are configured to use
> ## PASSWORD authentication on any machine that can run jobs as the
> ## submitting user. For example,
> ##
> ## SEC_CLIENT_AUTHENTICATION_METHODS = NTSSPI, PASSWORD
>
> ## CREDD_SETTINGS
>
> ## CREDD logging settings
> ## Customize these if you wish.
> CREDD_LOG = $(LOG)/CreddLog
> CREDD_DEBUG = D_COMMAND
> MAX_CREDD_LOG = 50000000
>
> #################################################
> ## CREDD Expert settings
> ## Everyting below is for the UBER-KNOWLEDGEABLE only!
> ## Do not change these unless you know what you do!
> #################################################
>
>
> DAEMON_LIST = $(DAEMON_LIST), CREDD
> #DC_DAEMON_LIST = \
> #MASTER, STARTD, SCHEDD, KBDD, COLLECTOR, NEGOTIATOR, EVENTD, \
> #VIEW_SERVER, CONDOR_VIEW, VIEW_COLLECTOR, HAWKEYE, CREDD, HAD, \
> #QUILL
>
> CREDD = $(SBIN)/condor_credd.exe
>
> # Timeout session quickly since we normally only get contacted
> # once per starter
> SEC_CREDD_SESSION_TIMEOUT = 10
>
>
> # Set security settings so that full security to the credd is required
> CREDD.SEC_DEFAULT_AUTHENTICATION =REQUIRED
> CREDD.SEC_DEFAULT_ENCRYPTION = REQUIRED
> CREDD.SEC_DEFAULT_INTEGRITY = REQUIRED
> CREDD.SEC_DEFAULT_NEGOTIATION = REQUIRED
>
> # Require PASSWORD auth for password fetching
> CREDD.SEC_DAEMON_AUTHENTICATION_METHODS = PASSWORD
>
> # Only honor password fetch requests to the trusted "condor_pool"
user
> CREDD.ALLOW_DAEMON = condor_pool@$(UID_DOMAIN)
>
> # Require NTSSPI for storing credentials
> CREDD.SEC_DEFAULT_AUTHENTICATION_METHODS = NTSSPI
>
> The Submit machine has following condor_config:
> ====================================
> LOCAL_CONFIG_FILE = $(LOCAL_DIR)/condor_config.local \
>
$(LOCAL_DIR)/condor_config.local.submit.execute
>
> HOSTALLOW_CONFIG = Submitmachine.test.mydomain.com
>
> CREDD_HOST = $(CONDOR_HOST):$(CREDD_PORT)
>
> The file condor_config.local.submit.execute File from the Submit machine
looks like:
> =============================================================
>
> ######################################################################
> ##
> ## condor_config.local.submit.execute
> ##
> ## This is the default local configuration file for the submit
machine
> ## and execute machine.
> ##
> ######################################################################
>
> ## Note: The following settings will need to be present in your
> ## global config file:
> STARTER_ALLOW_RUNAS_OWNER = True
> CREDD_CACHE_LOCALLY = True
> ##
> ## You'll also need to ensure that clients are configured to use
> ## PASSWORD authentication on any machine that can run jobs as the
> ## submitting user. For example,
> ##
> SEC_CLIENT_AUTHENTICATION_METHODS = NTSSPI, PASSWORD
>
> And the condor_config File from the Execution machine looks like:
> =================================================
>
> LOCAL_CONFIG_FILE = $(LOCAL_DIR)/condor_config.local \
>
$(LOCAL_DIR)/condor_config.local.submit.execute
>
> HOSTALLOW_CONFIG = Submitmachine.test.mydomain.com
>
> CREDD_HOST = $(CONDOR_HOST):$(CREDD_PORT)
>
> And the condor_config.local.submit.execute File from the
> Execution machine is the same file like this one from the Submitmachine.
_______________________________________________
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/
###################################################################### ###################################################################### ## ## ###### ##### ## # # ## ##### ##### # # ## # # # # # # # # ## ###### # # # # # ##### ## # ###### ##### # # ## # # # # # # # ## # # # # # # ####### ## ## Part 2: Settings you may want to customize: ## (it is generally safe to leave these untouched) ###################################################################### ###################################################################### ###-------------------------------------------------------------------- ## 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). HOSTALLOW_ADMINISTRATOR = $(FULL_HOSTNAME) ## 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. #HOSTDENY_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. HOSTALLOW_OWNER = $(FULL_HOSTNAME), $(HOSTALLOW_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. HOSTALLOW_READ = *.domain.com #HOSTALLOW_READ = *.your.domain, *.cs.wisc.edu #HOSTDENY_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 ## HOSTALLOW_READ above as well. ## ## You must set this to something else before Condor will run. ## This most simple option is: ## HOSTALLOW_WRITE = * ## but note that this will allow anyone to submit jobs or add ## machines to your pool and is serious security risk. HOSTALLOW_WRITE = $(FULL_HOSTNAME), *.domain.com #HOSTALLOW_WRITE = *.your.domain, your-friend's-machine.other.domain #HOSTDENY_WRITE = bad-machine.your.domain ## Negotiator access. Machines listed here are trusted central ## managers. You should normally not have to change this. HOSTALLOW_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. HOSTALLOW_NEGOTIATOR_SCHEDD = $(CONDOR_HOST), $(FLOCK_NEGOTIATOR_HOSTS) ## Config access. Machines listed here can use the condor_config_val ## tool to modify all daemon configurations except those specified in ## the condor_config.root file. This level of host-wide access ## should only be granted with extreme caution. By default, config ## access is denied from all hosts. #HOSTALLOW_CONFIG = trusted-host.your.domain 12/10/2008 HOSTALLOW_CONFIG = $(HOSTALLOW_ADMINISTRATOR) \ $(CONDOR_HOST) ALLOW_CONFIG = user1@xxxxxxxxxx/$(CONDOR_HOST) ## 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. HOSTALLOW_WRITE_COLLECTOR = $(HOSTALLOW_WRITE), $(FLOCK_FROM) HOSTALLOW_WRITE_STARTD = $(HOSTALLOW_WRITE), $(FLOCK_FROM) HOSTALLOW_READ_COLLECTOR = $(HOSTALLOW_READ), $(FLOCK_FROM) HOSTALLOW_READ_STARTD = $(HOSTALLOW_READ), $(FLOCK_FROM) ###################################################################### ###################################################################### ## ## ###### # ## # # ## ##### ##### # # ## # # # # # # # # # ## ###### # # # # # # # ## # ###### ##### # ####### ## # # # # # # # ## # # # # # # # ## ## Part 4: Settings you should probably leave alone: ## (unless you know what you're doing) ###################################################################### ###################################################################### ###################################################################### ## Daemon-wide settings: ###################################################################### ###################################################################### ## Daemon-specific settings: ###################################################################### ##-------------------------------------------------------------------- ## condor_master ##-------------------------------------------------------------------- ## Daemons you want the master to keep running for you: DAEMON_LIST = MASTER CREDD SCHEDD STARTD ## Which daemons use the Condor DaemonCore library (i.e., not the ## checkpoint server or custom user daemons)? #DC_DAEMON_LIST = \ #MASTER, STARTD, SCHEDD, KBDD, COLLECTOR, NEGOTIATOR, EVENTD, \ #VIEW_SERVER, CONDOR_VIEW, VIEW_COLLECTOR, HAWKEYE, CREDD, HAD, \ #DBMSD, QUILL ## Where are the binaries for these daemons? MASTER = $(SBIN)/condor_master.exe CREDD = $(SBIN)/condor_credd.exe STARTD = $(SBIN)/condor_startd.exe SCHEDD = $(SBIN)/condor_schedd.exe KBDD = $(SBIN)/condor_kbdd.exe NEGOTIATOR = $(SBIN)/condor_negotiator.exe COLLECTOR = $(SBIN)/condor_collector.exe STARTER_LOCAL = $(SBIN)/condor_starter.exe ## ##-------------------------------------------------------------------- ## condor_credd credential managment daemon ##-------------------------------------------------------------------- ## Where is the CredD binary installed? CREDD = $(SBIN)/condor_credd.exe ## When the credd starts up, it can place it's address (IP and port) ## into a file. This way, tools running on the local machine don't ## need an additional "-n host:port" command line option. This ## feature can be turned off by commenting out this setting. CREDD_ADDRESS_FILE = $(LOG)/.credd_address ## Specify a remote credd server here, #CREDD_HOST = $(CONDOR_HOST):$(CREDD_PORT) # In my case is the same central manager but you could use any other computer to be the condor_host server after including the condor_host configuration in the condor_config file. CREDD_HOST = condor_host_servername.domain.com ## CredD startup arguments ## Start the CredD on a well-known port. Uncomment to to simplify ## connecting to a remote CredD. Note: that this interface may change ## in a future release. CREDD_PORT = 9620 CREDD_ARGS = -p $(CREDD_PORT) -f ## Note: The following settings will need to be present in your ## global config file: ## ADDED 12/10/2008 ## CREDD_HOST = my-credd.cs.wisc.edu ## STARTER_ALLOW_RUNAS_OWNER = True ## CREDD_CACHE_LOCALLY = True STARTER_ALLOW_RUNAS_OWNER = True CREDD_CACHE_LOCALLY = True ## ## ## You'll also need to ensure that clients are configured to use ## PASSWORD authentication on any machine that can run jobs as the ## submitting user. For example, ## ADDED 12/10/2008 SEC_CLIENT_AUTHENTICATION_METHODS = NTSSPI, PASSWORD ## CredD daemon debugging log CREDD_LOG = $(LOG)/CredLog CREDD_DEBUG = D_FULLDEBUG MAX_CREDD_LOG = 4000000 ## The credential owner submits the credential. This list specififies ## other user who are also permitted to see all credentials. Defaults ## to root on Unix systems, and Administrator on Windows systems. CRED_SUPER_USERS = aalas@xxxxxxxxxx ## Credential storage location. This directory must exist ## prior to starting condor_credd. It is highly recommended to ## restrict access permissions to _only_ the directory owner. CRED_STORE_DIR = $(LOCAL_DIR)/cred_dir ## Index file path of saved credentials. ## This file will be automatically created if it does not exist. #CRED_INDEX_FILE = $(CRED_STORE_DIR/cred-index ## condor_credd will attempt to refresh credentials when their ## remaining lifespan is less than this value. Units = seconds. #DEFAULT_CRED_EXPIRE_THRESHOLD = 3600 ## condor-credd periodically checks remaining lifespan of stored ## credentials, at this interval. #CRED_CHECK_INTERVAL = 60 ##