[Puppet Users] Re: Problem with order and ensure_resource.
On Friday, March 27, 2015 at 5:49:54 PM UTC-7, Shawn Sterling wrote:
>
>
>
> 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. :)
>
Arioch's puppet-redis needs an anchor resource to wrap the classes declared
in the init.pp. You can establish a relationship if you specify an existing
class with resources (rather the the redis class which only contain
classes):
repo::epel::add { $epel_packages:
before => Class['::redis::preinstall'],
}
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.
>
Isn't that rather drastic, considering it's an issue with one module, and a
problem with class containment implementation of that module?
HTH,
Nan
--
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/9d42c317-4025-45f4-a08a-6c74f6aea667%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: adding new users to /etc/sudoers
First, the visudo check didn't work otherwise it would have given actual
feedback, not usage info.
Second, where is this sudo class / module come from. Nothing in the
command snippets creates it.
On Friday, March 27, 2015 at 3:24:58 PM UTC-4, manyi wrote:
>
> 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/f91cfc4d-9ab0-47d2-ad80-a338a1b7b4bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Am I seeing PUP-3863?
Also, if the future parser is not an option for you, the hiera_undef module provides hiera functions that return undef when no value is found in hiera: https://forge.puppetlabs.com/camptocamp/hiera_undef We used this write heavily to wrap puppet classes and emulate data bindings when migrating from puppet 2 to 3. Cheers, Raphaël -- 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/9f87c1ed-84cd-4115-8a88-a34353325901%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Augeas editing of fstab
Actually, the native mount type can also be used with an augeas-based provider
if you use the herculesteam/augeasproviders_mounttab module.
This brings the simplicity of a native module with the power and safety of
Augeas under the hood.
As for the original code by OP, there are Augeas errors in there. It is
possible to achieve this simple option change though, but the nodes in the tree
must be ordered properly.
augeas { 'fstabxfsnobarrier':
context => '/files/etc/fstab',
changes => [
'rm /*[vfstype="xfs"]/opt',
You're bypassing the context here by using an absolute path (starting with/).
That won't do anything.
'ins opt after vfstype="xfs"',
This syntax is erroneous. You probably mean to insert the opt node after the
vfstype node of the matching entry, which would be:
'ins opt after *[vfstype="xfs"]/vfstype
Raphaël
--
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/dc7217a1-88d3-4179-8700-d711aa224c1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
