Re: [Puppet Users] intermodule dependency

[Jos Houtman]

>
>
> In this case, the link between the differring blocks should be
> externalized from your ldap module (e.g. the ldap module should care
> about stuff related to ldap.. not about relations to other modules).
>
> You could put the order declaration in a "node type" or "node role" kind
> of class that you include in your node.
> say:
>
> class mysql_server_role {
>  include ldap_authentication_role # which declares whatever is needed
>   # for ldap support
>  include mysql
>
>  Class['Ldap'] -> Class['Mysql']
> }
>

I see your point and we allready have this role setup in place.
But also maintaining ordering declarations for every module that we include
is gonna be a painfull, especially if you have, as we, widespread use of
common defines that also impose their own ordering.

A system simular to stages, but with the ability to assign stages to more
then just a class

This would allow me to do the following:

define portage_useflag_override() {
  File{ "":
 stage => useflag
  }
}

define hyves_package($category) {
   package{ "":
 stage => package
   }
}

Class portage {
  exec {"emerge --sync": }
}

Class ldap {
   hyves_package{'nss-switch':
}

   notify{"done ldap": }
}

Stage['portage-setup'] -> Stage['useflag'] -> Stage['package'] ->
Stage['ldap'] -> Stage['main']

Class{"portage": stage => portage-setup; }
Class{"ldap": stage => ldap; }

portage_useflag_override{"test":}

And have an execution order like this one:

exec['emerge --sync'] -> portage_useflag_override["test"] ->
hyves_package["nss-switch"] -> notify["done ldap"]


The two foremost gains with such an approach would be that cross-module
ordering could worked out using stages.
While the few modules that deliver common services used by other modules,
through defines, can work without complicated, possibly cross-stage,
dependency chains.

Regards,

Jos
 and not dependency chains that would need to cross stages.


>
> --
> Gabriel Filion
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Mining hash field out of the /etc/shadow shadow file

[Olivier]

Hello

in James Loope's book (called Managing Infrastructure with Puppet), he
writes on page23: "The password hash can either be mined out of a
shadow file or generated with the mkpasswd utility." My question is:
how can the hash field be mined out of the shadow field. I tried to
use the generate function to execute the following command:
grep username /etc/shadow | cut -d: -f2
but that did not work. It seems that the generate function does not
like the | pipe command.

My question is: how can I extract that hash value and store it in a
Puppet variable?

Thank you

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Mining hash field out of the /etc/shadow shadow file

[Stefan Schulte]

On Sun, Jan 29, 2012 at 07:26:13AM -0800, Olivier wrote:
> Hello
> 
> in James Loope's book (called Managing Infrastructure with Puppet), he
> writes on page23: "The password hash can either be mined out of a
> shadow file or generated with the mkpasswd utility." My question is:
> how can the hash field be mined out of the shadow field. I tried to
> use the generate function to execute the following command:
> grep username /etc/shadow | cut -d: -f2
> but that did not work. It seems that the generate function does not
> like the | pipe command.
> 
> My question is: how can I extract that hash value and store it in a
> Puppet variable?
> 
> Thank you
> 

The question is what are you trying to accomplish?

The generate function executes on your puppet master which is most
certainly not what you want.

If you want to have the root passwordhash on your node to be available
as a variable you have write a custom fact [1] but be aware of the
possible security implications.

If you just want to create a useraccount and set a login password or you
want to make sure that a certain user has a certain login password you
can already do so with the user type [2]

like

user { 'root':
  ensure   => present,
  uid  => 0,
  password => 'my hashed password',
}


[1] http://docs.puppetlabs.com/guides/custom_facts.html
[2] http://docs.puppetlabs.com/references/2.7.9/type.html#user

-Stefan


pgpHHeUPB8zbS.pgp
Description: PGP signature

Re: [Puppet Users] Mining hash field out of the /etc/shadow shadow file

[Stefan Schulte]

On Sun, Jan 29, 2012 at 11:39:46PM +0100, Stefan Schulte wrote:
> On Sun, Jan 29, 2012 at 07:26:13AM -0800, Olivier wrote:
> > Hello
> > 
> > in James Loope's book (called Managing Infrastructure with Puppet), he
> > writes on page23: "The password hash can either be mined out of a
> > shadow file or generated with the mkpasswd utility." My question is:
> > how can the hash field be mined out of the shadow field. I tried to
> > use the generate function to execute the following command:
> > grep username /etc/shadow | cut -d: -f2
> > but that did not work. It seems that the generate function does not
> > like the | pipe command.
> > 
> > My question is: how can I extract that hash value and store it in a
> > Puppet variable?
> > 
> > Thank you
> > 
> 
> The question is what are you trying to accomplish?
> 

Searched the book online. This is what he is trying to say:

You can make sure that a user has a certain login password with the
`password` property of the user resource. But you have to supply the
hashed password as it would be stored in the /etc/shadow file.

But in general you just know the clear text password. An easy way to get
the hash value for your clear text password is to set the clear text
password with passwd and then lookup the hash in the /etc/shadow file
or use the mkpasswd utility (with which I am not familiar)

Once you have the hashed value of your desired clear text password
you can copy&paste that in the user definition.

-Stefan


pgpvWSYCL4KDE.pgp
Description: PGP signature

[Puppet Users] Re: Mining hash field out of the /etc/shadow shadow file

[Olivier]

 and then lookup the hash in the /etc/shadow file
> or use the mkpasswd utility (with which I am not familiar)
>
> Once you have the hashed value of your desired clear text password
> you can copy&paste that in the user definition.
>
> -Stefan
>

your answer is just the text of my original question. So the question
still stands: how do I get the hashed value from /etc/shadow?

Here is the background of my problem. I have 40 puppet clients and one
master. The password of each user expires after 90 days. Instead of
changing their password manually on 40 different servers by logging
into each server,each user will have to change his/her password on the
puppet server only and Puppet will replicate the hash value on each
puppet client. Obviously I will never know the user's password and am
not interested in replicating the root password. NIS and LDAP are not
an option.

Thank you.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Mining hash field out of the /etc/shadow shadow file

[Jeff McCune]

On Sun, Jan 29, 2012 at 6:18 PM, Olivier  wrote:
[snip]
>
> your answer is just the text of my original question. So the question
> still stands: how do I get the hashed value from /etc/shadow?

Are you trying to get a value from /etc/shadow on a managed node or
from the puppet master system itself?

Remember functions in the Puppet DSL are only ever executed when
compiling the catalog, so that means the Puppet Master (in a client /
server setup) or the stand alone puppet apply application.

If you're looking to get the value from a managed node and then use in
manifests on the master, you'll need to use a custom fact.

If you're looking to use the value in a resource you're managing
you'll likely want to build it into a custom type and provider.

> Here is the background of my problem. I have 40 puppet clients and one
> master. The password of each user expires after 90 days. Instead of
> changing their password manually on 40 different servers by logging
> into each server,each user will have to change his/her password on the
> puppet server only and Puppet will replicate the hash value on each
> puppet client. Obviously I will never know the user's password and am
> not interested in replicating the root password. NIS and LDAP are not
> an option.

For this use case a custom function that reads the file will work
fine.  You could even use generate() and a shell one-liner.

Are you running into a standard filesystem permissions issue?
/etc/shadow is locked down pretty hard and the Puppet Master usually
runs with lower privileges using a service account.

-- 
Jeff McCune

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Mining hash field out of the /etc/shadow shadow file

[Aaron Grewell]

Since it's the shell redirection that Puppet seems not to like, why not
wrap the commands in a shell script and use generate on that?
On Jan 29, 2012 6:18 PM, "Olivier"  wrote:

>  and then lookup the hash in the /etc/shadow file
> > or use the mkpasswd utility (with which I am not familiar)
> >
> > Once you have the hashed value of your desired clear text password
> > you can copy&paste that in the user definition.
> >
> > -Stefan
> >
>
> your answer is just the text of my original question. So the question
> still stands: how do I get the hashed value from /etc/shadow?
>
> Here is the background of my problem. I have 40 puppet clients and one
> master. The password of each user expires after 90 days. Instead of
> changing their password manually on 40 different servers by logging
> into each server,each user will have to change his/her password on the
> puppet server only and Puppet will replicate the hash value on each
> puppet client. Obviously I will never know the user's password and am
> not interested in replicating the root password. NIS and LDAP are not
> an option.
>
> Thank you.
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] intermodule dependency

[Jeff McCune]

On Mon, Jan 23, 2012 at 1:45 AM, Jos Houtman  wrote:
> I am looking for advice/best-practices on how to handle inter module 
> dependency's.

In general, I try and think of module dependencies and organization as
a matter of composition.  Discrete modules themselves should avoid
establishing relationships with other modules.  A module should,
however, be diligent about managing the internal relationships of the
classes and resources it defines.

Ideally, Puppet itself would be more opinionated about the
relationship of modules, and we're moving in that direction.  Kelsey
Alexander is working with Matt Robinson on things like #11979 [1]
which gets us on the path to managing dependencies automatically.  In
the meantime, I document and leave it up to the end user to create
another class that composes modules together.  With your example, I'd
do something like this as the end user.  As the module author, I'd try
and write mysql and ldap as if the other didn't exist.

node www1 {
  include site::dbserver
}

# /site/manifests/dbserver.pp
# This is what it means to be a database at the Acme.com site.
class site::dbserver {
  class { ldap: }
  -> class { mysql: }
}

[snip]


> Without stages we tried three ways of doing this:
> Creating a dependency chain between classes.
> Class['Ldap'] -> Class['Mysql'].
> This is very easy to do, but doesn't work if we inherit from Ldap,  say:
>  class ldap::server inherits ldap

In this situation I'd update the composition in the site module.  I'd
also avoid inheritance if at all possible, but that's another story
for another thread.

node www1 {
  include site::dbserver2
}

# /site/manifests/dbserver2.pp
# This is what it means to be a database at the Acme.com site.
class site::dbserver2 {
  class { 'ldap::server': }
  -> class { mysql: }
}

> The ordering between ldap::server and Mysql is not guaranteed.
> It also requires the maintainer of the ldap module to know about all modules
> that depend on ldap and update them if he decides to inherit. A task that is
> likely to be forgotten.

For these reasons I try and think of the whole thing as a composition
problem.  The things being composed, modules, should try and avoid
knowing implementation details about each other.

> Creating a dependency chains between resources in the modules, f.e.
> notify's.
> Every module that is part of an dependency defines an  notify{ 'endpoint': }
> and makes sure that everything within the module is executed before the
> notify.

This sounds a lot like the Anchor pattern [2].  Are you trying to
accomplish the same goal of classes encapsulating other classes in the
dependency graph?

> If we inherit from the base class, the overriding class is responsible for
> making sure that endpoint is still the last thing executed in this module.
> Making it more likely that the ordering of events will remain as we want it
> after a continued year of development.

Yep, really sounds like the anchor pattern [2].

> So after this rather longer email explaining our problem and some of the
> options we explored, how do you guys handle these kind of complex
> inter-module dependencies?

Not easily.  =)  The anchor pattern is a bug, certainly, and so is the
UX of having to manage dependencies so carefully and painfully.  The
good news is that we're actively working on it.  If you could update
any of the following bugs with your user stories and desires it will
help shape the solution.  11832, 12243, 12246, 12249, 12250, 12251,
12253, 12255, 12256, 12257, 12258, 12259, 12260,

[1] http://projects.puppetlabs.com/issues/11979
[2] http://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern

-- 
Jeff McCune

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Cross-module dependencies

[Jeff McCune]

On Fri, Jan 27, 2012 at 5:20 AM, Felix Frank
 wrote:
> Jeff has made a strong point against using virtual resources in modules
> at all, causing me to shift my own views as well.
> If I understand him correctly, one of the chief problems is the high
> probability of accidental collection/realisation of such resources by
> the end user's manifest.

Yep, that's it.

-Jeff

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Cross-module dependencies

[Brian Gupta]

Nigel,

I just wanted to add, if we do go this route, we should work to support
private "forges" (module repos) as well.

Cheers,
Brian

On Sun, Jan 29, 2012 at 1:39 AM, Brian Gupta wrote:

> Nigel,
>
> It frightens me a bit that I think the "correct" solution, will be to
> replicate what the distros are doing in Puppetforge. Basically turning
> puppetforge into a massive cross distro metadata repo, with very strict
> contribution standards and rules. This would involve strong rules for
> curated modules that would require manpower to vet (and to contribute the
> modules).
>
> Maybe, we might want to extend modules so that there are two namespaces,
> one for curated forge modules and another for local modules. (Making the
> "local module" namespace the default for backwards compatibility.) One
> example of a potential rule would be to require that official modules
> support a mandatory set of popular OSes. Don't allow more than one official
> module per package. e.g.: In the curated section of forge there will be one
> MySQL module. (not to get too ahead of the cart, but I envision a time when
> you can instantiate a MySQL service by just telling puppet to use the Forge
> MySQL module, puppet handles downloading and installing the module and
> figuring out what OS you are running and with the help of the native
> package management, installs and configures the basic MySQL service.) The
> official modules will be curated such that if there is a a common resource
> they need to manage that resource will be split into a separate singular
> dependency module, that incorporates the requirements of
> all dependent forge modules. (Not a bag of common resources in a single
> module, but rather a separate module for each shared resource.)
>
> Maybe, I am overthinking this, but I think this is the "right" solution,
> that may require more resources to implement than the community has
> available.
>
> That leaves us what to do about "defined". (Or was that a different
> thread?) In the case of defined, my group has only ever used it once in
> almost 4 years, but it seems from the discussions that there are others
> still using it. Maybe the answer is provide a real alternative first, and
> then go about deprecating it? We wouldn't miss it, but I could see the
> challenges of rewriting a codebase that depends on it, and I wouldn't want
> that rewrite enforced on me, without a solid alternative.
>
> Cheers,
> Brian
>
> P.S. - No one is going to really love this solution, including myself, but
> that doesn't necessarily mean it shouldn't be done.
>
>
> On Sat, Jan 28, 2012 at 9:18 PM, Nigel Kersten wrote:
>
>> I just wanted to post to this thread to primarily encourage you all to
>> keep brainstorming, and to make it clear that I'm paying close attention. :)
>>
>>
>>
>> --
>> Nigel Kersten
>> Product Manager, Puppet Labs
>>
>>
>>
>>  --
>> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.