Re: [Puppet Users] Manage but don't create resource

[Luke Bigum]

Hi Alan,

What OS / provider? At first guess I'd say it's a side affect of the
commands the provider is using to change user attributes (useradd
instead of usermod?). If you run puppet with --debug you might get
output from the provider to see what it's doing.

-Luke

On 31/05/12 17:25, GriffaA10 wrote:
> Hi,
>
> I have certain situations where I want to manage user attributes, if
> the user already exists on a system, but not actually create them if
> they are missing. Is there a way to do this?
>
> I tried removing the explicit "ensure => present", but this seems to
> have no effect (i.e. missing users still created).
>
> I am running 2.7.9.
>
> Thanks,
>
> Alan
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/_3XFEWaz7SQJ.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.


--
Luke Bigum

Information Systems
Ph: +44 (0) 20 3192 2520
luke....@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


FX and CFDs are leveraged products that can result in losses exceeding
your deposit. They are not suitable for everyone so please ensure you
fully understand the risks involved. The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.

The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

LMAX operates a multilateral trading facility. Authorised and regulated
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809).
Our registered address is Yellow Building, 1A Nicholas Road, London, W11
4AN.

[Luke Bigum]

On Fedora the behaviour between types is different. A file resource is
not created if it doesn't exist:

notice: Finished catalog run in 0.08 seconds
biguml@biguml-laptop:~$ ls -ld /tmp/woof
ls: cannot access /tmp/woof: No such file or directory

biguml@biguml-laptop:~$ cat test.pp
file { '/tmp/woof':
owner => 'biguml',
}

A user resource is created:

debug: User[woof](provider=useradd): Executing '/usr/sbin/useradd -s
/bin/false -M woof'
notice: /Stage[main]//User[woof]/ensure: created
notice: Finished catalog run in 0.42 seconds

biguml@biguml-laptop:~$ cat test.pp
user { 'woof':
shell => '/bin/false'
}

I'm not sure if this is a bug or feature.

As for trying to get the behaviour that you want, it's a bit difficult
without having Facts for all your existing users or using an Exec resource.

-Luke

[GriffaA10]

I'm on Centos 5 - which I assume would behave the same as Fedora. From my testing it would seem that the default behaviour for user type is to create if absent. I tried looking at the Puppet source to see if this behaviour can be easily modified, but as someone who doesn't know Ruby I couldn't get a handle on it.

>> puppet-users+unsubscribe@googlegroups.com.

[Dan White]

Use a virtual resource ?

It will not be created unless you explicitly realize it.

You can centrally manage a collection of virtual users on your Puppet Master,
creating only those you want on the nodes you want them on.

Does that satisfy your requirement ?

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

> > >> puppet-users...@googlegroups.com.

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

> To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/W52mIF64uKoJ.

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

> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

[GriffaA10]

The overhead of explicity realising the resources would be too great.

Specifically what I am trying to achive is disabling accounts on existing hosts, while preventing them from being created when new hosts are turned up. So when a user leaves the company the account would be disabled by locking the password and disabling the shell, and if new host was turned up tomorrow I would not want the account created there.

> > >> puppet-users+unsubscribe@googlegroups.com.

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

[Wil Cooley]

On Jun 1, 8:49 am, GriffaA10 <alan.griffi...@interoute.com> wrote:
> The overhead of explicity realising the resources would be too great.
>
> Specifically what I am trying to achive is disabling accounts on existing
> hosts, while preventing them from being created when new hosts are turned
> up. So when a user leaves the company the account would be disabled by
> locking the password and disabling the shell, and if new host was turned up
> tomorrow I would not want the account created there.

The only straightforward (but hackish) way I see to achieve this is
with an Exec
and onlyif (probably wrapped in a define):

define dead_user($username) {
exec { "remove-user-${username}":
onlyif => "/usr/bin/getent passwd ${username} >/dev/null",
command => "/usr/sbin/usermod ... ${username}",
}
}

Another possibility would be to make a fact that returns all of users
on a
system and do something with that--maybe returns a colon-delimited
list and
uses the 'split' function and the 'member' function from stdlib.

Wil