Re: [Puppet Users] puppetlabs/concat Problem on Windows
On 03/13/2015 03:40 PM, Fraser Goffin wrote: > I am attempting to use the puppetlabs/concat module on Windows, but > having some problems. I just found out that Richard has made an alternative that explicitly does support Windows: https://forge.puppetlabs.com/ispavailability/file_concat -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55155487.5020604%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Problem with order and ensure_resource.
On Thursday, March 26, 2015 at 8:52:39 AM UTC-5, Shawn Sterling wrote:
>
> Using:
> puppetserver-1.0.2-1.el7.noarch
> puppet-3.7.4-1.el7.noarch
>
> Doing roles and profiles. Have a define setup to add 'includepkgs' items
> to different yum repos (for security reasons).
>
> In my redis profile if I do this:
>
> $epel_packages = ['redis', 'jemalloc']
> repo::epel::add { $epel_packages: } ->
> package { $epel_packages:
> ensure => installed,
> }
>
> The resource chaining works as expected.
>
> If I try to chain an ensure_resource:
>
> repo::epel::add { $epel_packages: } ->
> ensure_resource('package', $epel_packages, {
> 'ensure' => 'present',
> })
>
> This gives Error 400 on SERVER: Syntax error at '}' at line x
>
> If I get rid of the "->" the 400 goes away, but we need 2 puppet runs
> because the package install attempt happens before the package is added to
> the includepkgs
>
>
ensure_resource() is not a resource declaration; it is a function call that
under some circumstances causes a resource to be declared. It does not
return a value, and therefore cannot be valid operand for the chain
operators.
> What I'm really trying to do is, use the define and then call an external
> module after. Ideally:
>
> repo::epel::add { $epel_packages: } ->
> class { '::redis':
> manage_repo => false,
> }
>
> But this requires 2 puppet runs because arioch's puppet-redis module uses
> ensure_resource which seams to ignores chaining and other attempts to
> ensure order in the profile such as:
>
> repo::epel::add { $epel_packages: }
> class { '::redis':
> manage_repo => false,
> require => Repo::Epel::Add[$epel_packages],
> }
>
> # or
>
> repo::epel::add { $epel_packages: }
> class { '::redis':
> manage_repo => false,
> }
> Repo::Epel::Add[$epel_packages] -> Class['::redis']
>
> # or
>
> repo::epel::add { $epel_packages:
> before => Class['::redis'],
> }
> class { '::redis':
> manage_repo => false,
> }
>
> Which none of the 3 work. Each requires 2 puppet runs, the first full of
> errors.
>
Those are all perfectly reasonable approaches. If they don't work then I'm
inclined to conclude that class 'redis' does not properly contain the
resources it declares. This may be a result of declaring them via
ensure_resource()
-- especially if the affected resources are first declarded elsewhere -- or
it may be a classic case of failing to contain other classes.
>
> You could tell me to not use ensure_resources, but I'm not. I'm using
> someone else's module and trying to enforce order at the profile level.
>
And I *do* tell you not to use ensure_resources(), whether in your own code
or indirectly via someone else's modules. The only way ensure_resources()
works correctly and reliably is if every resource it governs is declared
*only* via one or more ensure_resources() calls, with the same parameters
and relevant in-scope resource defaults at the site of every such call.
Even then, "correctly" does not extend to containment, and cannot do so
without creating a grave risk of dependency cycles. The ensure_resources()
function is not a correct -- nor even a reasonable -- solution to *any*
problem. That a third party module uses it is enough reason for me to
avoid that module.
> I could modify the redis module, or maybe send him a pull request to get
> rid of the ensure_resource (which word on the street says ensure_resources
> are as bad as using evals); but I'm guessing there is a puppety way to
> handle this that I'm not finding; or maybe it's a bug that ensure_resource
> ignores all (of my) attempts to assign order?
>
>
I don't think it's correct to say that ensure_resources() is ignoring your
attempts. It's most likely that the combined effect of all your manifests
together is that at least one resource that is subject to an
ensure_resource() call ends up not being contained by class redis. That
might be normal for ensure_resources(), or it might be a consequence of
that resource first being declared elsewhere, so that calling
ensure_resources() for it is a no-op. Relationships with Class['redis']
would have no effect on the order of application of such resources.
The redis module likely uses ensure_resources() to try to avoid module
incompatibility problems arising from duplicate resource declarations.
That is, after all, the function's intended purpose. The module can be
forgiven (but not excused) because general module compatibility is a hard
problem. There was at least one proposal for Puppet 4 that would have made
things a lot easier, but I don't think it made it in. If you can find a
way to replace ensure_resources() with something better, then I would hope
the maintainer would accept it; if he didn't, that's enough of an
improvement to consider forking over.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, sen
[Puppet Users] adding new users to /etc/sudoers
Help needed!!
I am trying to add 2 users to /ect/sudoers john.smith and jane.may granting
privileges to all servers
*step 1. **modules/user/manifests/init.pp *
class user {
user { 'john.smith':
ensure => present,
comment => 'john.smith',
home => '/home/john.smith',
managehome => true
}
}
*Step 2 manifests/site.pp*
/etc/puppet/manifests/site.pp
node 'mydomain.local.org'
{ include user }
*step 3 :* sudo mkdir -p modules/sudoers/manifests
*Step 4* sudo mkdir -p modules/sudoers/files
step 5
Create the file modules/sudoers/manifests/init.pp
# Manage the sudoers file
class sudoers {
file { '/etc/sudoers':
source => 'puppet:///modules/sudoers/sudoers'
mode => '0440',
owner => 'root',
group => 'root',
}
}
*Step 6 *Check the syntax of the sudoers file
visudo -c -f modules/sudoers/files/sudoers modules/sudoers/files/sudoers
*output*:
usage: visudo [-chqsV] [-f sudoers]
step 7:
back in manifests/site.pp
node 'mydomain.local.org' {
include user
include sudoers
}
step 8
puppet$ sudo puppet agent --test
does respond
I finally tried:
node 'mydomain.local.org' {
class { 'sudo': }
sudo::conf { 'john.smith':
priority => 10,
source => 'puppet:///files/etc/sudoers.d/users/john.smith',
}
}
still the agent doesn't respond
can someone point me to the right direction please
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/288911f6-185e-4073-b494-6a83fa0948a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Problem with order and ensure_resource.
On Friday, March 27, 2015 at 6:45:05 AM UTC-7, jcbollinger wrote: > > ensure_resource() is not a resource declaration; it is a function call > that under some circumstances causes a resource to be declared. It does > not return a value, and therefore cannot be valid operand for the chain > operators. > Okay, makes sense. > Those are all perfectly reasonable approaches. If they don't work then > I'm inclined to conclude that class 'redis' does not properly contain the > resources it declares. This may be a result of declaring them via > ensure_resource() > -- especially if the affected resources are first declarded elsewhere -- > or it may be a classic case of failing to contain other classes. > Glad I'm not loosing my mind. :) > You could tell me to not use ensure_resources, but I'm not. I'm using >> someone else's module and trying to enforce order at the profile level. >> > > And I *do* tell you not to use ensure_resources(), whether in your own > code or indirectly via someone else's modules. The only way > ensure_resources() works correctly and reliably is if every resource it > governs is declared *only* via one or more ensure_resources() calls, with > the same parameters and relevant in-scope resource defaults at the site of > every such call. Even then, "correctly" does not extend to containment, > and cannot do so without creating a grave risk of dependency cycles. The > ensure_resources() function is not a correct -- nor even a reasonable -- > solution to *any* problem. That a third party module uses it is enough > reason for me to avoid that module. > I will avoid any module that uses ensure_resources from this point on. The redis module likely uses ensure_resources() to try to avoid module > incompatibility problems arising from duplicate resource declarations. > That is, after all, the function's intended purpose. The module can be > forgiven (but not excused) because general module compatibility is a hard > problem. There was at least one proposal for Puppet 4 that would have made > things a lot easier, but I don't think it made it in. If you can find a > way to replace ensure_resources() with something better, then I would > hope the maintainer would accept it; if he didn't, that's enough of an > improvement to consider forking over. > I'm going to work with the module owner to see if we can't find another solution or I'll use a different module. Thank you very much for the reply. I do appreciate it. Have a great weekend. -Shawn -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/745eaa48-9764-40de-b40b-44d21846fedb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
