Puppet users - Dec 2010 - design advice on coding my first type / provider

I just wondered if anyone has experience of this kind of problem, and
what approaches they''ve
found to work best.

I''m writing my first type/provider (on pupet 0.25.x) to automatically
setup RabbitMQ.

The basic approach I''m taking is to wrap the rabbitmqctl command
(which  lets you create vhosts, users and ACLs that let the users do
things on the vhosts).

Creating / deleting vhosts is simple, I just tag the Type as
''ensurable'' and
fill in the create / destroy / exists? in the Provider.

(Thanks to @kartar for the great quickstart article at
http://www.kartar.net/2010/02/puppet-types-and-providers-are-easy/ , by the way)

That works great, but I''m a bit stumped on how to create a user type.
Ideally I''d like something that worked as:

rabbitmq_user { "username":
   password => "sekrit",
   ensure     => "present"
}

The problem is I won''t be able to check the current password,
since there''s the nothing like a ''rabbitmqctl show_password
username'' command.

My options are either:

1. write something low-level to hash the password attribute and
compare it against
something in RabbitMQs internals.
2. always set the password (i.e. have exists? always return false)
"rabbitmqctl change_password username sekrit"
3. don''t bother trying to manage a password, just set it if the user
isn''t there and
    create them with the password specified in the puppet manifest.
    If they already exist, don''t attempt to change the password.

1. is a fair bit of work, and probably quite brittle
2. is going to do unnecessary work (and I''ll have to create the user
if they don''t exist anyway)
3. is the easiest to code, so I''ll probably end up doing that.
    That wil let me get on and finish my last requirement (creating
acls to map users to vhosts)
    Then i can tidy up the code, drop it on github and hope a smarter
coder comes along...

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Can you follow the path our user providers use and simply provide the
internal hash in the manifest? Can you verify that client side?

On Sat, Dec 11, 2010 at 6:48 AM, Dick Davies
<rasputnik@hellooperator.net> wrote:
> I just wondered if anyone has experience of this kind of problem, and
> what approaches they''ve
> found to work best.
>
> I''m writing my first type/provider (on pupet 0.25.x) to
automatically
> setup RabbitMQ.
>
> The basic approach I''m taking is to wrap the rabbitmqctl command
> (which  lets you create vhosts, users and ACLs that let the users do
> things on the vhosts).
>
> Creating / deleting vhosts is simple, I just tag the Type as
''ensurable'' and
> fill in the create / destroy / exists? in the Provider.
>
> (Thanks to @kartar for the great quickstart article at
> http://www.kartar.net/2010/02/puppet-types-and-providers-are-easy/ , by the
way)
>
> That works great, but I''m a bit stumped on how to create a user
type.
> Ideally I''d like something that worked as:
>
> rabbitmq_user { "username":
>   password => "sekrit",
>   ensure     => "present"
> }
>
> The problem is I won''t be able to check the current password,
> since there''s the nothing like a ''rabbitmqctl
show_password username'' command.
>
> My options are either:
>
> 1. write something low-level to hash the password attribute and
> compare it against
> something in RabbitMQs internals.
> 2. always set the password (i.e. have exists? always return false)
> "rabbitmqctl change_password username sekrit"
> 3. don''t bother trying to manage a password, just set it if the
user
> isn''t there and
>    create them with the password specified in the puppet manifest.
>    If they already exist, don''t attempt to change the password.
>
> 1. is a fair bit of work, and probably quite brittle
> 2. is going to do unnecessary work (and I''ll have to create the
user
> if they don''t exist anyway)
> 3. is the easiest to code, so I''ll probably end up doing that.
>    That wil let me get on and finish my last requirement (creating
> acls to map users to vhosts)
>    Then i can tidy up the code, drop it on github and hope a smarter
> coder comes along...
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

That''d essentially be option 1 then.
I think it''d be doable (have seen that work well in e.g. camptocamps
mysql
module) but I''d need to call into Erlang somehow to find the hashed
password.
In the mysql case, it''s just a straight select out of the mysql.user
table.

One other idea I had was to write a RabbitMQ plugin for PAM
and then something like pam_userdb (that worked well for ejabberd).

On Sat, Dec 11, 2010 at 3:55 PM, Nigel Kersten <nigel@puppetlabs.com>
wrote:
> Can you follow the path our user providers use and simply provide the
> internal hash in the manifest? Can you verify that client side?
>
> On Sat, Dec 11, 2010 at 6:48 AM, Dick Davies
> <rasputnik@hellooperator.net> wrote:
>> I just wondered if anyone has experience of this kind of problem, and
>> what approaches they''ve
>> found to work best.
>>
>> I''m writing my first type/provider (on pupet 0.25.x) to
automatically
>> setup RabbitMQ.
>>
>> The basic approach I''m taking is to wrap the rabbitmqctl
command
>> (which  lets you create vhosts, users and ACLs that let the users do
>> things on the vhosts).
>>
>> Creating / deleting vhosts is simple, I just tag the Type as
''ensurable'' and
>> fill in the create / destroy / exists? in the Provider.
>>
>> (Thanks to @kartar for the great quickstart article at
>> http://www.kartar.net/2010/02/puppet-types-and-providers-are-easy/ , by
the way)
>>
>> That works great, but I''m a bit stumped on how to create a
user type.
>> Ideally I''d like something that worked as:
>>
>> rabbitmq_user { "username":
>>   password => "sekrit",
>>   ensure     => "present"
>> }
>>
>> The problem is I won''t be able to check the current password,
>> since there''s the nothing like a ''rabbitmqctl
show_password username'' command.
>>
>> My options are either:
>>
>> 1. write something low-level to hash the password attribute and
>> compare it against
>> something in RabbitMQs internals.
>> 2. always set the password (i.e. have exists? always return false)
>> "rabbitmqctl change_password username sekrit"
>> 3. don''t bother trying to manage a password, just set it if
the user
>> isn''t there and
>>    create them with the password specified in the puppet manifest.
>>    If they already exist, don''t attempt to change the
password.
>>
>> 1. is a fair bit of work, and probably quite brittle
>> 2. is going to do unnecessary work (and I''ll have to create
the user
>> if they don''t exist anyway)
>> 3. is the easiest to code, so I''ll probably end up doing that.
>>    That wil let me get on and finish my last requirement (creating
>> acls to map users to vhosts)
>>    Then i can tidy up the code, drop it on github and hope a smarter
>> coder comes along...
>>
>> --
>> You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
>> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>
>
>
> --
> Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> 2. is going to do unnecessary work (and I''ll have to create the
user
> if they don''t exist anyway)
I''ve written types that do this with great success.  Be careful that
performing that repetitive action isn''t expensive or otherwise
degrading to normal operation.  If it creates any kind of race
condition or nasty blocking behavior, you may be best off with option
3.

Rich

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.