If you want I can send you a
document with the exact lines I changed in the configuration file of the
execute\submit machines to make it work. But if you want to know more
why the problem exist, and I know you would please refer to the
following e-mails in the condormail list:
1) On 7/9/2008, Matthew Farrellee wrote:
“When the condor_startd starts it launches a condor_starter with a
special argument (-classad). The condor_starter prints out a class ad
that the condor_startd then advertises. If the condor_credd starts after
the condor_starter -classad is run, you'll be missing the LocalCredd.
This could be fixed by having the condor_startd periodically run
condor_starter -classad, if that isn't already happening.”
2) On 12/11/2008 Cooper Thompson wrote:
The first step (based on your problem description) is to get localcredd
to show up in the classad of each of your machines. In my
configuration, we do this by running "condor_store_cred -c add
<password>" on each machine in the pool, then restarting the Condor
services (note that condor_credd.exe must be up and running on your CM
before condor_startd.exe comes up on your nodes, otherwise it won't pick
set localcredd).
3) On 12/16/2008 I wrote:
Cooper,
You pointed me in the right direction to follow. The step of entering
the condor_pool's password and user's password was done on all condor
machines as soon as I included the condor_cred configuration in the
condor_config file of all the computers but that wasn't enough to make
the jobs to run because the localcred setting was missing on all the
machines but one. So what I did to fix the problem (based on your
suggestion) was to rearrange the starting order of the daemons placing
condor_cred after condor_master and before condor_startd. By doing that
I reassured the localcredd's classad is submitted to all the
execute\submit machines. This action fixed my issue and jobs are been
executed on all the execute machines using the user's credentials.
Thanks lots for your help,
Alex
Alex
*From:* condor-users-bounces@xxxxxxxxxxx
[mailto:condor-users-bounces@xxxxxxxxxxx] *On Behalf Of *Robert Hecker
*Sent:* Wednesday, December 17, 2008 7:51 AM
*To:* Condor-Users Mail List
*Subject:* Re: [Condor-users] Windows Condor problems with credd and
executing jobs as submitting user
Hi Greg,
Thank you very much for the detailed Information inside the pdf File.
I had realy the problem that the condor _status -f .... command
listed my job_execution machine, and so i updated the pool passwords.
Anyway it's not working now.
If i use the condor_q -analyze command I will get the following output:
==========================================================================
-- Submitter: submitter.test.mydomain.com : <172.20.201.19:1078> :
submitter.test.
mydomain.com
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
---
016.000: Run analysis summary. Of 2 machines,
2 are rejected by your job's requirements
0 reject your job because of their own requirements
0 match but are serving users with a better priority in the pool
0 match but reject the job for unknown reasons
0 match but will not currently preempt their existing job
0 are available to run your job
No successful match recorded.
Last failed match: Wed Dec 17 13:35:58 2008
Reason for last match failure: no match found
WARNING: Be advised:
No resources matched request's constraints
Check the Requirements expression below:
Requirements = (Arch == "INTEL") && (OpSys == "WINNT51") && (Disk >=
DiskUsage)
&& ((Memory * 1024) >= ImageSize) && (HasFileTransfer) &&
(HasWindowsRunAsOwner
&& (LocalCredd =?= "jobcontroller:9620"))
1 jobs; 1 idle, 0 running, 0 held
============================================================================
When I updated the pool password on the execution machine, i recognized,
that
I'm able to set the password
=============================================================================
C:\condor\bin>condor_store_cred -c add
Account: condor_pool@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Enter password:
Operation succeeded.
==============================================================================
but if i want to query the password, it will not work:
==============================================================================
C:\condor\bin>condor_store_cred -c query
Account: condor_pool@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Operation failed.
Make sure your HOSTALLOW_WRITE setting includes this host.
==============================================================================
My Question now is, Where must the settings HOSTALLOW_WRITE done?
On the Jobexecutor, Submitter or Controller ?
I made the settings on all 3 machines like following:
HOSTALLOW_WRITE = *.test.mydomain.com
but it is not working. (I also restarted all 3 machines!)
Any help is welcome.
Robert
*Greg Quinn <gquinn@xxxxxxxxxxx>*
Gesendet von: condor-users-bounces@xxxxxxxxxxx
16.12.2008 17:07
Bitte antworten an
Condor-Users Mail List <condor-users@xxxxxxxxxxx>
An
Condor-Users Mail List <condor-users@xxxxxxxxxxx>
Kopie
Thema
Re: [Condor-users] Windows Condor problems with credd and executing jobs
as submitting user
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/
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}