Perry E. Metzger wrote: > Dave Love <[EMAIL PROTECTED]> writes: >>> We'd prefer to steer clear of Kerberos, it introduces >>> arbitrary job limitations through ticket lives that >>> are not tolerable for HPC work. > > Which of course isn't true. If Wall Street firms, which really cannot > afford to have their trading systems go down even for a second, can > happily use kerberos in servers, so can anyone. > >>> Say you submit a job that is in the queue for a week >>> and then will run for 3 months - we don't know if the >>> AD admins will permit the creation of a 4 month ticket >>> "just in case".. >> Why do you need to re-authenticate, and if you do, surely you need to >> stash a credential somewhere however you do it? > > Indeed, and if you have stashed your key appropriately you can just > have a cron job kinit as often as you like. The kinit man page > gives the command line flag for requesting credentials using a key > taken from a file, ans also lists the flag for setting your ticket > expiry time. All you do is put one line in a crontab with kinit and > those two options, say every 24 hours.
Isn't stashing a bunch of user keys on a single system a major security risk? One could argue that the cluster should be on a private, secured network so it's okay, but then I'll argue that the node storing the keys will most likely be the master node, which is often on a "public" network so users can access it to submit jobs. I can't imagine an arrangement like this passing the scrutiny of the local information security officer. And if you're going to use a key stored on a disk, why not just use SSH keys? > > I keep seeing these messages go by over and over making it sound like > this is difficult. It is not difficult. I've seen people say "I have > seen no document with a recipe for how to do it", perhaps because a > single kinit command in a cron job is too simple for a HOWTO. Isn't stashing a bunch of user keys on a single system a major security risk? One could argue that the cluster should be on a private, secured network so it's okay, but then I'll argue that the node storing the keys will most likely be the master node, which is often on a "public" network so users can access it to submit jobs. I can't imagine an arrangement like this passing the scrutiny of the local information security officer. And if you're going to use a key stored on a disk, why not just use SSH keys? > > Maybe some sort of strange myth has been going by so long on this that > people refuse to believe that the ticket refresh is a single easy > command? Maybe you're not reading the questions correctly. In my original question about how to do this, I asked how to do this using the queuing system to refresh the keys -- I was asking for an integrated solution. Above, you describe doing it with a cron job, which does not answer my question. -- Prentice Bisbal Linux Software Support Specialist/System Administrator School of Natural Sciences Institute for Advanced Study Princeton, NJ _______________________________________________ Beowulf mailing list, [email protected] To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
