On Thu, Aug 14, 2014 at 8:29 PM, Michael Lasevich
<mlasev...@lasevich.net> wrote:
> I appreciate it. Maybe I did not read it close enough, but it seemed to send
> the admin password to every client, which is what I am trying to avoid.
Oh no!! Definitely not :) I went to great pains to specifically avoid
this actually. If you're interested in how the DM and admin passwords
are managed, read:

If you're interested in how the clients auth, they do so via
getkeytab, and in order for that to work, puppet passes a temporary
one-time password to the client, uses it, and verifies that _that_
client auth-ed. If the password isn't used by that client, then a new
OTP is generated, and the original is discarded (as it was probably
used by the wrong client, or maliciously in that rare scenario).

All of this to say, that this was quite complex to write, so I would
consider using the module as is (and even extending it as needed!).
Secondly, I'd like to point out that I'm not doing any orchestration,
only config management. Which means this can actually scale!

> I will take a closer look, maybe I can bite the bullet and implement the few
> lines of code that are required to make this work in Salt (it would take way
> too much work and be generally counterproductive to switch to Puppet).

Of course I can only help with the puppet case, but if you don't
switch (this module is a winning module, in the same way that rails
saved ruby, so I would take a closer look) you can at least use it as
a reference architecture when writing a salt module. That;s the beauty
of Free Software!

Good luck! HTH,

Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to