useradd: manages_passwords gone missing?

[David Schmitt]

Hi,

I just noticed that the useradd provider for the user type no longer
implements the "manages_passwords" feature. Using the Type
Reference[1][2][3][4], I was able to pinpoint that to the timeframe of the
2.7.1/2.6.9 releases, but the release notes[5] do not shed any light on
this. Due to local constraints I cannot trace it into the code.

Is this feature removal intentional?

Best Regards, David

[1] http://docs.puppetlabs.com/references/2.6.8/type.html#user
[2] http://docs.puppetlabs.com/references/2.6.9/type.html#user
[3] http://docs.puppetlabs.com/references/2.7.0/type.html#user
[4] http://docs.puppetlabs.com/references/2.7.1/type.html#user
[5] http://projects.puppetlabs.com/projects/1/wiki/Release_Notes

[Nick Lewis]

On Wednesday, June 27, 2012 at 9:57 AM, David Schmitt wrote:

Hi,

I just noticed that the useradd provider for the user type no longer

implements the "manages_passwords" feature. Using the Type

Reference[1][2][3][4], I was able to pinpoint that to the timeframe of the

2.7.1/2.6.9 releases, but the release notes[5] do not shed any light on

this. Due to local constraints I cannot trace it into the code.

Is this feature removal intentional?

Are you noticing this just in the type reference, or is it actually not working for you?

I checked the code, and it certainly seems to still be there. However, it only adds manages_passwords if you have the shadow feature. The type reference is autogenerated, so maybe the machine we generate the type reference on had shadow and doesn't anymore. In any case, if the type reference is wrong, that's something we should get straightened out.

Best Regards, David

[1] http://docs.puppetlabs.com/references/2.6.8/type.html#user

[2] http://docs.puppetlabs.com/references/2.6.9/type.html#user

[3] http://docs.puppetlabs.com/references/2.7.0/type.html#user

[4] http://docs.puppetlabs.com/references/2.7.1/type.html#user

[5] http://projects.puppetlabs.com/projects/1/wiki/Release_Notes

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

To post to this group, send email to puppe...@googlegroups.com.

To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

[Nick Fagerlund]

On Wednesday, June 27, 2012 10:33:12 AM UTC-7, Nick Lewis wrote:

...so maybe the machine we generate the type reference on had shadow and doesn't anymore. In any case, if the type reference is wrong, that's something we should get straightened out.

Haha ARGH, Nick has it right. That's frustrating, and the long-term fix for it is not obvious.

[Andrew Parker]

I imagine that the fix would have to work with the two purposes of generating the documentation that I'm seeing here: general docs expressing all possible features and when they are available, and more specific docs that express what is currently available on a particular system. I would guess that accurately doing the first might be more important than being able to also do the second, but I might be wrong.

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/Z6hXfpFDF4sJ.

[James Turnbull]

Andrew Parker wrote:
> I imagine that the fix would have to work with the two purposes of
> generating the documentation that I'm seeing here: general docs
> expressing all possible features and when they are available, and more
> specific docs that express what is currently available on a particular
> system. I would guess that accurately doing the first might be more
> important than being able to also do the second, but I might be wrong.

Agreed. This isn't the first time this has bitten us and we've indeed
conflated the docs generation and the feature checking.

Regards

James


--
James Turnbull
Puppet Labs
1-503-734-8571
To schedule a meeting with me: http://tungle.me/jamtur01

[Nick Fagerlund]

On Wednesday, June 27, 2012 12:48:16 PM UTC-7, James Turnbull wrote:

Agreed. This isn't the first time this has bitten us and we've indeed
conflated the docs generation and the feature checking.

The best part about having the documentation embedded in the types and providers is that it's expressed in a Turing-complete language, so we have to actually LOAD THE CODE to extract it.

Like I said, I'm not sure how to deal with that. :/ For manages_passwords we can just generate the reference on a linux VM with all the requisite extensions installed, but really there could be any number of things like this buried in there, and I bet some of them are mutually exclusive.

[Nick Fagerlund]

On Wednesday, June 27, 2012 1:47:32 PM UTC-7, Nick Fagerlund wrote:

Like I said, I'm not sure how to deal with that.

I should make clear that's not me just shrugging and moving on -- we actually have to solve this problem. For example, it's clear to me that the type reference needs to be a web app with access to the all of the types and providers in modules on the Forge; if we want to be able to do that, we're gonna need a more static way to extract doc info from the code.

[Luke Kanies]

What about some kind of override on the feature checking, so that when generating docs the features aren't checked?

-- 

Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199

[Ken Barber]

> The best part about having the documentation embedded in the types and
> providers is that it's expressed in a Turing-complete language, so we have
> to actually LOAD THE CODE to extract it.

Side issue but related: This also affects building packages for users
for the forge if we want least effort github integration for example -
whereby our systems build up the metadata.json on behalf of a user. I
believe Cloudsmith wrote a parser in Java for this stuff for Geppetto
for this kind of thing, and speaking to Tim Sharpe he had some
suggestions as well for parsing this outside of Puppet.

ken.

[Daniel Pittman]

Way back when the Faces documentation API was designed, part of the
expectation was that we would port it to other parts of the systems
(like types and providers), and then add similar mechanisms to what
the `help` face uses to extract documentation.

That would, indeed, be looking to have a way to load all providers
regardless of constraints, and generate a reference that covered all
the capabilities across all the platforms.

--
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

[David Schmitt]

On 27.06.2012 19:33, Nick Lewis wrote:
> On Wednesday, June 27, 2012 at 9:57 AM, David Schmitt wrote:
>> Hi,
>>
>> I just noticed that the useradd provider for the user type no longer
>> implements the "manages_passwords" feature. Using the Type
>> Reference[1][2][3][4], I was able to pinpoint that to the timeframe of the
>> 2.7.1/2.6.9 releases, but the release notes[5] do not shed any light on
>> this. Due to local constraints I cannot trace it into the code.
>>
>> Is this feature removal intentional?
>>
> Are you noticing this just in the type reference, or is it actually not
> working for you?

It is actually not working for me. But read on below for my epiphany.

> I checked the code, and it certainly seems to still be there. However,
> it only adds manages_passwords if you have the shadow feature. The type
> reference is autogenerated, so maybe the machine we generate the type
> reference on had shadow and doesn't anymore. In any case, if the type
> reference is wrong, that's something we should get straightened out.

Aha! This and the resulting discussion pointed me in the right direction
what's wrong with the machines I was looking at: they're missing
libshadow-ruby.

In regards to the discussion how to solve the problem of the missing "X"
in the documentation, I must say that just installing the required
dependencies to get as much "X" as possible cannot be the final
solution, as it doesn't tell the reader what she has to do to actually
activate the functionality.

In a related vein the "provider" meta-parameter should probably be
documented right next to the features table and not three pages down,
hidden in the list of other properties and parameters.




Best Regards, David

[Nigel Kersten]

On Thu, Jun 28, 2012 at 1:37 AM, David Schmitt <da...@dasz.at> wrote:

> Aha! This and the resulting discussion pointed me in the right direction
> what's wrong with the machines I was looking at: they're missing
> libshadow-ruby.

I'm starting to think we shouldn't bother consuming libshadow-ruby.

We only use it to pull out the hash, min_age and max_age from the user
records, and that's relatively easy to do manually...

[Nick Lewis]

In fact, we already do it manually in the user_role_add provider for Solaris...

[Nigel Kersten]

On Thu, Jun 28, 2012 at 5:00 PM, Nick Lewis <ni...@puppetlabs.com> wrote:
> On Thursday, June 28, 2012 at 4:57 PM, Nigel Kersten wrote:
>
> On Thu, Jun 28, 2012 at 1:37 AM, David Schmitt <da...@dasz.at> wrote:
>
> Aha! This and the resulting discussion pointed me in the right direction
> what's wrong with the machines I was looking at: they're missing
> libshadow-ruby.
>
>
> I'm starting to think we shouldn't bother consuming libshadow-ruby.
>
> We only use it to pull out the hash, min_age and max_age from the user
> records, and that's relatively easy to do manually...
>
> In fact, we already do it manually in the user_role_add provider for
> Solaris...

Doh! I know there was a wider discussion around not relying upon tools
like useradd at all on Linux for user management, and I think there
may have been a ticket on this already.

I'll hunt that down and we'll see if we can remove this annoying dependency.


--
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

[James Turnbull]

Nigel Kersten wrote:
>
> Doh! I know there was a wider discussion around not relying upon tools
> like useradd at all on Linux for user management, and I think there
> may have been a ticket on this already.

I remember the discussion but I don't think there was a ticket.

[Daniel Pittman]

On Thu, Jun 28, 2012 at 9:16 PM, Nigel Kersten <ni...@puppetlabs.com> wrote:
> On Thu, Jun 28, 2012 at 5:00 PM, Nick Lewis <ni...@puppetlabs.com> wrote:
>> On Thursday, June 28, 2012 at 4:57 PM, Nigel Kersten wrote:
>> On Thu, Jun 28, 2012 at 1:37 AM, David Schmitt <da...@dasz.at> wrote:
>>
>> Aha! This and the resulting discussion pointed me in the right direction
>> what's wrong with the machines I was looking at: they're missing
>> libshadow-ruby.
>>
>> I'm starting to think we shouldn't bother consuming libshadow-ruby.
>>
>> We only use it to pull out the hash, min_age and max_age from the user
>> records, and that's relatively easy to do manually...
>>
>> In fact, we already do it manually in the user_role_add provider for
>> Solaris...
>
> Doh! I know there was a wider discussion around not relying upon tools
> like useradd at all on Linux for user management, and I think there
> may have been a ticket on this already.

I think that would be a terrible mistake: it means that, for example,
on Debian we would not invoke the local user management hook that
useradd, etc, invoke. That would have messed with at least my
deployment in the past.

Avoiding platform tools also means avoiding any platform extension
points, which I don't think is a huge win.

[Trevor Vaughan]

Also, be aware that, on Red Hat and Fedora, etc... they're moving to
SSSD which wraps the tools in front of the SSSD database instead of
/etc/shadow, etc.. so delving the shadow file won't be of much use.

Trevor

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

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Nigel Kersten]

By "a ticket on this" I meant specifically the issue of not using
libshadow to parse out the /etc/shadow file.

Avoiding the platform tools for user management is a wider discussion.