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

Re: [Condor-users] Understanding Credd

Thank you Tammy.

I still don't have credd working, :) but this opened my eyes to other possibilities that have gotten the ball rolling again. I'm running condor as another user now, which is a good solution for the time being.


On 10/29/07, Chin, Tammy <chint@xxxxxxx> wrote:
There was a great presentation given at the 2006 CONDOR week by Greg Quinn on how to correctly implement CREDD. I still refer back to it  when I mess up my pool.
See the Condor on Windows talk at this link
Hope this helps,
-----Original Message-----
From: condor-users-bounces@xxxxxxxxxxx [mailto:condor-users-bounces@xxxxxxxxxxx]On Behalf Of Chip Collier
Sent: October 27, 2007 4:11 PM
To: Condor-Users Mail List
Subject: Re: [Condor-users] Understanding Credd

Ok, so at least part of my problem was related to reverse DNS. Cleaning up some stale entries fixed my issues with jobs not running as owner on linux when submitted from my windows test machine.
However, I guess I still need some kind of breakdown here on the most basic scenario in order to have jobs run as owner on windows.
If I submit a job now from a linux or windows machine it will run as the owner on linux machines in our pool but as the condor-resuse users on windows.
Is there a step-by-step guide for this? Is there anyone out there using Credd? I'm starting to think that it would be easier to store and encrypt account information myself rather than use Condor for this.

I'm kind of going crazy here and trying to learn a lot all at once (some of it condor, some of it related to the software our animators use), but I've been told that if this doesn't come together in the next couple of days, the project will be shelved. :(


On 10/24/07, Chip Collier <chip@xxxxxxxxxxxxxx> wrote:
I guess I am confused about what you are trying to do...

 I apologize. End of the day brain rot is terrible for explaining things. :) 

Do you want:
a) submit jobs from windows that will run on linux machines
b) submit jobs from windows that will run on windows machines
c) both a and b

I'm looking to be able to do 'c'. In the future hopefully users will be submitting from both linux and windows, but for the moment linux is only running on the backend so for now I'm working on a scenario where users will be starting jobs on windows workstations to a pool that consists of both Linux and Windows machines.

In all cases you want the job to run as the user who submitted the job,

This is correct. I'm considering work arounds for my proof-of-concept, but ultimately jobs will need access of an nfs share as the user who submitted the job. We are using the hummingbird nfs client which maps our windows usernames to our ldap information (uid and such is correctly handled in this case then). Our windows domains are syncronized with our unix accounts which use ldap. We have hooks in place when accounts are created and when users change their passwords so that usernames and passwords are the same regardless of the kind of computer you choose to login to. We rely on the nfs client to handle any UID and GID issues on the windows side when nfs is concerned.

If the answer is (c), you then need the credd for part (b).

So this means that submitting my job from windows should by default run as owner under linux? If so, then I assume then some other aspect of my windows configuration is incorrect as well. :)
Pardon me if I jump ahead here for a second. Would this mean also that Credd should only be run on windows machines? I ask because our central manager is a linux machine and I have been attempting to run credd on it as CREDD_HOST.

I can try to help more once you clarify what you are trying to do ....

Thanks for your patience.



This e-mail, and any attachments, may contain information that
is confidential, subject to copyright, or exempt from disclosure.
Any unauthorized review, disclosure, retransmission, 
dissemination or other use of or reliance on this information 
may be unlawful and is strictly prohibited.  


Le présent courriel, et toute pièce jointe, peut contenir de 
l'information qui est confidentielle, régie par les droits 
d'auteur, ou interdite de divulgation. Tout examen, 
divulgation, retransmission, diffusion ou autres utilisations 
non autorisées de l'information ou dépendance non autorisée 
envers celle-ci peut être illégale et est strictement interdite.

Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting

The archives can be found at: