Re: [Puppet Users] powershell detect then install nonexistent or replace existing custom service

[Rob Reynolds]

On Wed, Nov 4, 2015 at 2:11 PM, Aaron  wrote:

> blech - nevermind.  still throws horrible errors when the service has not
> been installed yet and puppet runs (such as on a new VM).
>
> Is there any way to have it see that there is an error during the
> uninstall and then run an ELSE and move onto the Install portion without
> getting hung up on not being able to uninstall first?  this is the step I
> can't seem to figure out.
>

Shift that install command to a file or script that can do error handling
and have it ignore specific errors.



>
>
> Aaron
>
>
> On Wednesday, November 4, 2015 at 2:58:46 PM UTC-5, Aaron wrote:
>>
>> Thanks Rob!
>>
>> This appears to work well after looking into your suggestions...I tried
>> to include an "unless" statement at the end of the Install New FooService
>> Service" block for a little extra security, but it didn't seem to like that
>> so I removed it - I'm not sure of the reason for that, however.
>> The refreshonly is there to make sure this doesn't just randomly
>> uninstall and install the service but only does it when new code has been
>> dropped into place or a file has been altered against policy and the
>> service may be corrupted.
>>
>> class FooService::install {
>>
>>
>>   if $::osfamily == 'windows' {
>> File { source_permissions => ignore }
>>   }
>>
>>
>>   file { 'C:\\Services\\Win\\FooServiceConsumerSvc\\':
>> ensure  => present,
>> source  => 'puppet:///modules/FooService/FooService',
>> recurse => true,
>> purge   => true,
>> force   => true,
>>   }
>>
>>
>>   exec { 'Uninstall Old FooService Service':
>> command => 
>> 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe
>> /Logfile= /InstallStateDir="C:\Services\Logs\Win" /uninstall
>> "C:\Services\Win\FooServiceConsumerSvc\FooService.exe"',
>> provider=> powershell,
>> subscribe   => File['C:\\Services\\Win\\FooServiceConsumerSvc\\'],
>> onlyif  => 'if ((Get-Service -name "FooService") -ne $null)',
>>
>

You could probably convert this to simply onlyif='Get-Service -name
"FooService"' - it's going to throw an error if there is no service by the
name you are asking for.


>
>> refreshonly => true,
>> notify  => Exec['Install New FooService Service'],
>>   }
>>
>>
>>   exec { 'Install New FooService Service':
>> command => 
>> 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe
>> /username=AD\user /password=password /Logfile=
>> /InstallStateDir="C:\Services\Logs\Win"
>>  "C:\Services\Win\FooServiceConsumerSvc\FooService.exe"',
>> provider=> powershell,
>> refreshonly => true,
>>   }
>>
>>
>> }
>>
>>
>> On Tuesday, November 3, 2015 at 10:44:03 AM UTC-5, Rob Reynolds wrote:
>>>
>>>
>>>
>>> On Fri, Oct 30, 2015 at 8:50 AM, Aaron  wrote:
>>>
 I have a question and hopefully someone can help me resolve it -

 In windows, I have custom services that I need to manage.  I've been
 running this code for a while, and it works well for several custom Windows
 services, but the problem is I cannot run it on a bare server without
 manual intervention (i.e. manually running the installer powershell script
 to create the Service before puppet will complete successfully after
 that).  It will fail because the Detect does not see the service, so the
 Uninstall cannot succeed.  I am trying to figure out how to use an ELSE off
 of the Detect Exec block, but am not sure how to make that work.  And I am
 unsure if there is anything clever I can do with the NOTIFY in the detect
 block.

 Can anyone offer some assistance?

 FYI I do not have installers, I have the bare files that are moved into
 place in the first File block, and then the Detect runs if any changes are
 made to any files in the service.  Hopefully that remains clear in my
 attempt to make this generic.

 class FooService::install {

   if $::osfamily == 'windows' {
 File { source_permissions => ignore }
   }

   file { 'C:\\Services\\Win\\FooServiceConsumerSvc\\':
 ensure  => present,
 source  => 'puppet:///modules/FooService/FooService',
 recurse => true,
 purge   => true,
 force   => true,
   }

   exec { 'Detect FooService Service':
 command => 'if ((Get-Service -name "FooService") -ne $null)',

>>>
>>> You could add more to the command to run here.
>>>
>>>
>>>
 provider=> powershell,
 subscribe   => File['C:\\Services\\Win\\FooServiceConsumerSvc\\'],
 refreshonly => true,
 notify  => Exec['Uninstall Old FooService Service'],
 returns => 0,
   }

   exec { 'Uninstall Old FooService Service':
 command =>
 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe /Logfile=
 /InstallStateDir="C:\Services\Logs\Win" /uninstall
 

[Puppet Users] Announce: puppet-agent 1.3.1 available.

[Eric Sorenson]

Puppet Agent 1.3.1 is now available. This is a bugfix release of the 
all-in-one agent, which bundles up Ruby, Puppet, Facter, and other components 
into a single package.


This release includes the following updates:

* Facter 3.1.3 fixes a regression where the `puppetversion` fact was not
  reported.
* Puppet 4.3.1 fixes a bug where variables like `calling_module` were not
  available in hiera.
* pxp-agent 1.0.1 fixes an internal race condition between the completion of
  an action command and the corresponding metadata file being updated.

You can see links to the full release notes for puppet-agent and individual 
components here:


http://docs.puppetlabs.com/puppet/4.3/reference/about_agent.html

To install or upgrade puppet-agent, follow the getting started directions:

http://docs.puppetlabs.com/puppet/4.3/reference/index.html

Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles

--
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/alpine.OSX.2.20.1511301353230.91886%40fermium.corp.puppetlabs.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Forge ACL Module 1.1.1 on Windows 7 x64 SP1

[Rob Reynolds]

On Tue, Nov 10, 2015 at 7:22 AM, jmp242  wrote:

> Ok, well, it was on one test computer. On others it's giving the same
> error, but I think the parameter issue is actually specific to the existing
> file / permissions. I moved the file and re-ran puppet, which as part of
> the manifest re-created the file and could set permissions fine. It seems
> like there is some issue with a certain permissions set that causes me
> issues with ACL module. Specifically, the original file doesn't have any
> user permissions set. I'm wondering if that is the issue?
>

That's an interesting one and probably worth capturing as a ticket. Can you
expand on that one just a bit more? Like icacls reports no permissions at
all? Or right clicking, selecting Properties, and going to the Security tab
is completely empty?

Or just that Puppet wouldn't have permissions to the file?


>
>
> On Monday, November 9, 2015 at 3:22:11 PM UTC-5, jmp242 wrote:
>
>> Ok, sorry everyone for a false alarm. I finally figured this out -
>> something I thought wouldn't be relevant at all, hence my failure to
>> mention, but what happened is this. I have a module that is applied via the
>> Forman ENC. It uses the acl module as a "puppet feature extension" (I don't
>> know the official term for these sorts of forge modules). The ACL module is
>> never applied to a host group or host via the Foreman "puppet classes". So
>> I hadn't imported it into Foreman. This apparently is a problem. I was
>> building a new module today, and happened to say "why not import the acl
>> module while I'm here?" and did. Bam, ACL module now works.
>>
>> I apparently still don't totally understand how the ENC -> Puppet works
>> wrt modules that aren't directly applied. Now in my notes for the future!
>>
>> On Wednesday, November 4, 2015 at 1:32:07 PM UTC-5, Rob Reynolds wrote:
>>
>>
>>
>> On Mon, Oct 19, 2015 at 10:10 AM, jmp242  wrote:
>>
>> Hmm, so on one test computer, the upgrade to puppet 3.8.3 fixed the
>> issue. On the second test computer, it didn't - everything remains the
>> same, but getting the same repeated ACE...
>>
>>
>> What does 'cacls *folderlocation*' return?
>>
>>
>>
>>
>> On Thursday, October 15, 2015 at 12:27:34 AM UTC-4, Rob Reynolds wrote:
>>
>>
>>
>> On Thu, Oct 1, 2015 at 8:09 AM, jmp242  wrote:
>>
>> Puppet 3.8.1 on Windows currently. puppet module list doesn't return
>> anything for me. I'm downloading the zip file and unzipping the module into
>> a folder. I then copy the folder into my local dev modules directory using
>> Geppeto, and doing the same for any dependencies. I then check into our SVN
>> the modules, and tag them with the version they are from forge if public,
>> or an internal version for our custom modules. I then check out the tag or
>> svn switch to the latest tag on the puppet server dev module directory.
>>
>>
>> Ah okay. I'm wondering what might cause issues surrounding 3.8.1 and ACL
>> provider. An ACE with the same structure 142 times though, I'm wondering if
>> there is a memory issue there.
>>
>>
>>
>> On Wednesday, September 30, 2015 at 3:38:49 PM UTC-4, Rob Reynolds wrote:
>>
>> Thanks. I'm surprised that a 'puppet agent --trace --debug --verbose'
>> didn't turn up any more information about the error.
>>
>> Can you remind me again what version of Puppet you have installed?
>>
>> And the modules, `puppet module list`. How are you installing these
>> modules by the way?
>>
>> On Tue, Sep 29, 2015 at 2:43 PM, jmp242  wrote:
>>
>> Sure, that's perhaps misleading a little - our internal custom puppet
>> module is called yum as it was created for EL6 first. When we got a package
>> manager on Windows, i.e. chocolatey, it seemed to make sense to put it in
>> the Windows section of the yum module. By that I mean we have a switch on
>> kernel in our modules. Here's the complete module:
>> class yum ($choco_repo_url, $choco_repo_name) {
>>   schedule { 'monday_updates':
>> range   => '22:00 - 12:00',
>> weekday => 'Monday',
>>   }
>>
>>   schedule { 'tuesday_updates':
>> range   => '10:00 - 12:00',
>> weekday => 'Tuesday',
>>   }
>>
>>   schedule { 'daily_updates':
>> period => daily,
>> range  => '22:00-3:00',
>>   }
>>
>>   define repo {
>> file { "${title}":
>>   path   => "/etc/yum.repos.d/${title}",
>>   source => "puppet:///modules/${caller_module_name}/${title}",
>>   ensure => 'present',
>>   owner  => root,
>>   group  => root,
>>   mode   => "644",
>>   notify => Exec["yum-clean-all"],
>> }
>>
>>   }
>>
>>   case $kernel {
>> 'linux'   : {
>>   package { 'yum': ensure => present, }
>>
>>   package { 'yum-autoupdate': ensure => present, }
>>
>>   repo { "sl-classe.repo": }
>>
>>   file { "sl-classe-testing":
>> content => template('yum/sl-classe-testing.repo.erb'),
>> path=> "/etc/yum.repos.d/sl-classe-testing.repo",
>> owner   => root,

Re: [Puppet Users] Puppet 4: default value of a parameter in a module and dependency

[Martin Alfke]

Hi Francois,

On 30 Nov 2015, at 05:09, Francois Lafont  
wrote:

> Hi,
> 
> I'm using Puppet 4 and I'm wondering if this (see below) is possible.
> 
> I have 2 Puppet modules, moda and modb. We can imagine that theses modules
> have just one class init.pp. The class ::moda has a parameter "param" with
> the default value defined in the code of "./moda/functions/data.pp". The
> module modb depends on the module moda (the dependency is indicated in
> ./modb/metadata.json) and the class ::modb have the parameter "param" too.
> 
> I would like to define the default value of the parameter ::modb::param
> to ensure that it is equal to the value of ::moda::param, ie I would like
> to have this:
> 
> a) If the value of ::moda::param is defined in hiera or in environment.conf
> with "moda::param: ", then the default value of ::modb::param is  too.

define modb with an explicit heira lookup and set a default:

class  ‘modb’ (
  param => hiera(‘moda::param’, ‘default’)
){
  …
}

I am unsure on how to achieve this with data in modules.

> 
> b) If the value of ::moda::param is not defined at all (in hiera, in 
> environment.conf
> etc.), then the default value of ::modb::param is moda::data()['moda::param’].

same pattern, just set the default accordingly.

Best,
Martin

> 
> Is there a proper way to do that with Puppet 4?
> Thanks in advance for your help.
> 
> François Lafont
> 
> -- 
> 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/565BCBE4.9090008%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/55CA02DC-7CB3-41DE-8BA3-205AD3742783%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppet calling systemctl instead of /etc/init.d/xxx even when told to use debian provider

[Ghislain]

I understand your dissatisfaction, but I feel obligated to observe 
that Puppet isn't forcing you to do anything. *Because of 
peculiarities in Debian*, Puppet cannot properly manage services on 
some versions of that distro via straight sysV initscripts.  This in 
no way forces you to install systemd; you also have the alternative of 
not managing services via Puppet in this quirky environment.


Inasmuch as this particular characteristic apparently affects only 
newer versions of Debian (and Debian-derived Ubuntu), I'm inclined to 
suppose that it arises in part because of a shift in Debian away from 
SysV init infrastructure, which indeed seems to have become quite the 
thing to do in the last few years.  If you want to complain about 
someone driving you toward systemd, I suggest you focus on your distro 
itself.



John



hi,

 i am sorry that you take it that way, i am not here to argue with you 
if you think debian is a quirky distribution, that may be the case but 
this is the one we use so  that's why i found this issue.


 The fact is that  debian has 2 system of init to chosse, sysV and the 
systemd ecosystem that do init but also so many other thing that it 
cannot be used in a lot of chroot like scenario.


  Right now until this particular push of new code all was working as 
intended for us, but this code was added in the service sysV init 
provider a check of systemD  in the sysvinit part. So you can be an 
advocate  of systemd and there is no problem on that but sytemd cannot 
work on a lot of situations and i do not see the point of calling it 
inside a sysvinit part without any way to ovveride  this choice :) If 
people install systemd they will use the systemd provider not the 
sysvinit one.


 Debian offer me the choise between systemd and sysinit and the 
modification to the service provider simply make things hard and 
increase surface of problems as even with sysvinti system we must now 
install the systemd packages and all the dependency hell (and even the 
wrapper install daemon cgroup crtl script and a bunch of thing 
unneeded). Your solution on maintening my own system instead of running 
puppet is rather an unexpected  answer.


 the problem you refers to should be the distro problem to fix the 
init.d script that do not behave like you want them (ie return reliable 
value on status), i do not think you should break ascended compatibility 
to ack that some script do not respond like puppet want. I know that a 
lot of sysvinit script return unreliable values but this was, is, and 
will be the case.  Why break the compatibility for this ? For all 
services ? Best case scenario people fix the scripts, worst case it goes 
away in debian9 as we will all move to freeBSD or use systemd anyway. 
Also i assume it should not be that hard to test for the systemd package 
to be present to allow this test or not and therefor make ascended 
compatibility work as it was before this code change :)



best regards,
Ghislain.

--
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/565C7684.205%40aqueos.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] SELinux context warnings, how-to fix ?

[Remy]

Hi,

We moved from 3.1 to 3.8 and we faced some warnings regarding SELinux all 
of the sudden:

Nov 30 14:48:22 nodename puppet-agent[9865]: Failed to set SELinux context 
system_u:object_r:usr_t:s0 on /usr/sap/home/username
Nov 30 14:48:22 nodename puppet-agent[9865]: 
(/File[/usr/sap/home/username]/seltype) seltype changed 'nfs_t' to 'usr_t'

[root@nodename ~]# facter -p  | grep selinux
selinux => true
selinux_config_mode => permissive
selinux_config_policy => targeted
selinux_current_mode => permissive
selinux_enforced => false
selinux_policyversion => 28

Any ideas how-to fix ?
We haven't had this issues in 3.1...


Regards

-- 
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/8f09cb3c-1572-42a4-9700-4f8279d4961f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet 4: default value of a parameter in a module and dependency

[jcbollinger]

On Sunday, November 29, 2015 at 10:09:20 PM UTC-6, François Lafont wrote:
>
> Hi, 
>
> I'm using Puppet 4 and I'm wondering if this (see below) is possible. 
>
> I have 2 Puppet modules, moda and modb. We can imagine that theses modules 
> have just one class init.pp.



"init.pp" is the name of a manifest file, not of a class.  Moreover, 
although it's poor form, such a manifest could contain definitions for more 
than one class.  Moreover, in 

 

> The class ::moda has a parameter "param" with 
> the default value defined in the code of "./moda/functions/data.pp".



"./moda/functions/data.pp" appears to be the name of another manifest 
file.  I suppose it's instead supposed to be a Ruby (.rb) file defining a 
custom function, and although I can speculate based on its name what it 
might do, the details matter, and you have not provided them.


The 
> module modb depends on the module moda (the dependency is indicated in 
> ./modb/metadata.json) and the class ::modb have the parameter "param" too. 
>
> I would like to define the default value of the parameter ::modb::param 
> to ensure that it is equal to the value of ::moda::param, ie I would like 
> to have this: 
>
> a) If the value of ::moda::param is defined in hiera or in 
> environment.conf 
> with "moda::param: ", then the default value of ::modb::param is  
> too. 
>
> b) If the value of ::moda::param is not defined at all (in hiera, in 
> environment.conf 
> etc.), then the default value of ::modb::param is 
> moda::data()['moda::param']. 
>
>
$::moda::param *has no value* until and unless class ::moda is declared, 
and there is no reliable way to anticipate what value that parameter would 
have if its class were declared.  (You might anticipate and emulate some of 
the ways in which a value could be bound to that parameter, but there are 
others that simply cannot be anticipated.)  Once the class is declared, on 
the other hand, the only reasonable way to get the value of any of its 
parameters is to do so directly (i.e. as $::moda::param).

 

> Is there a proper way to do that with Puppet 4? 
>


I'm inclined to doubt that what you suggest is proper at all.  It seems 
like an awfully tight coupling between modules.  If class ::modb depends on 
class ::moda to be applied to to the target node (as opposed to depending 
only on data and maybe functions provided by module moda) then you can hack 
it together this way:

class modb inherits ::moda ($param = $::moda::param) {
  # ...
}

That's a variation on the "params class" pattern, which has been slowly 
falling out of favor.  You could also interpose a genuine params class 
(modb::params) between classes ::moda and ::modb.  In any event, this 
(anti?)pattern relies on a side effect of class inheritance to ensure that 
the parent class is evaluated before the child class, which in your case 
you need to ensure in order for one of moda's parameter values to be used 
directly as a default value of one of modb's parameters.  This does give 
you increased exposure to the general Puppet constraint that if you ever 
use the resource-like syntax for a class declaration (i.e. of class ::moda) 
then that must be the first declaration of that class that is evaluated.

If you want to use $::moda::param in class ::modb in pretty much any other 
way than as a class parameter default, then you don't need and should not 
use class inheritance.  For instance, this is an old-school approach that 
might be useful to you:

class modb inherits ::moda ($param = 'NOT GIVEN') {
  include '::moda'

  $real_param = $param ? {
'NOT GIVEN' => $::moda::param,
default => $param
  }

  # use $real_param in what follows ...
}


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, 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/dc64420a-e732-4689-b3b5-6b35b091353f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppet calling systemctl instead of /etc/init.d/xxx even when told to use debian provider

[jcbollinger]

On Monday, November 30, 2015 at 11:16:17 AM UTC-6, Aqueos Aqueos wrote:
>
>
>
>
>
> I understand your dissatisfaction, but I feel obligated to observe that 
> Puppet isn't forcing you to do anything.  *Because of peculiarities in 
> Debian*, Puppet cannot properly manage services on some versions of that 
> distro via straight sysV initscripts.  This in no way forces you to install 
> systemd; you also have the alternative of not managing services via Puppet 
> in this quirky environment.
>
> Inasmuch as this particular characteristic apparently affects only newer 
> versions of Debian (and Debian-derived Ubuntu), I'm inclined to suppose 
> that it arises in part because of a shift in Debian away from SysV init 
> infrastructure, which indeed seems to have become quite the thing to do in 
> the last few years.  If you want to complain about someone driving you 
> toward systemd, I suggest you focus on your distro itself.
>
>
> John
>
>
>
> hi,
>
>  i am sorry that you take it that way, i am not here to argue with you if 
> you think debian is a quirky distribution, that may be the case but this is 
> the one we use so  that's why i found this issue.
>


Please allow me to clarify that I have no particular objection to nor 
animosity for Debian 8 "Jessie", or any earlier version of Debian.  
Nevertheless, Jessie absolutely is "quirky" in the objectively measurable 
sense that under some circumstances, the "status" command of its SysV init 
scripts returns 0 when the LSB specifications dictate a different return 
value.  Others less generous than I might instead characterize that as a 
"flaw", or even a "bug".  This particular quirk presents a problem for 
Puppet, and therefore for you.

 

>
>  The fact is that  debian has 2 system of init to chosse, sysV and the 
> systemd ecosystem that do init but also so many other thing that it cannot 
> be used in a lot of chroot like scenario. 
>


Debian 8 moves from SysV as the default init system (and systemd available 
as a technology preview) to systemd as the default init system and SysV as 
a backwards-compatibility alternative.  IIRC, it also provides other 
alternatives, including at least upstart.  Although it is not exactly wrong 
to describe that as "[D]ebian has 2 system of init to chosse[sic]", doing 
so doesn't really present an accurate picture.

 

>
>   Right now until this particular push of new code all was working as 
> intended for us, but this code was added in the service sysV init provider 
> a check of systemD  in the sysvinit part. So you can be an advocate  of 
> systemd and there is no problem on that but sytemd cannot work on a lot of 
> situations and i do not see the point of calling it inside a sysvinit part 
> without any way to ovveride  this choice :) If people install systemd they 
> will use the systemd provider not the sysvinit one.
>
>

I am not advocating for systemd.  I am simply observing that Debian seems 
to have embarked on a switch to it, inasmuch as systemd is not just an 
alternative init system but the *default* init system for Jessie.  
Correlated with that switch, the behavior of the Debian SysV initscripts 
has changed so that the whole subsystem is no longer LSB-compliant.  As a 
result, the approach Puppet takes to managing services on earlier versions 
of Debian *does not work reliably* on Jessie.  Using the old system for 
Jessie was not a viable option.

 

>  Debian offer me the choise between systemd and sysinit and the 
> modification to the service provider simply make things hard and increase 
> surface of problems as even with sysvinti system we must now install the 
> systemd packages and all the dependency hell (and even the wrapper install 
> daemon cgroup crtl script and a bunch of thing unneeded). Your solution on 
> maintening my own system instead of running puppet is rather an unexpected  
> answer.
>
>

Debian seems not to offer quite the choice you think it does, as opting for 
sysvinit on Jessie is subtly inequivalent to using sysvinit by default on 
earlier Debians.  As for packages, I have to take your word for what and 
how many packages are required, and for how much trouble that is.  I 
confess, however, that I had supposed Apt to be a lot more capable and 
convenient than you seem to imply, and Debian's package collections -- even 
"unstable" -- to be more internally consistent.

In any event, if the Puppet changes necessitated by the sysvinit changes in 
Jessie cause Puppet to cease to be advantageous for service management for 
you, then why would you continue using Puppet for that purpose?  I hardly 
think it should be surprising to suggest preferring an alternative that is 
easier for you.  I *do*, however, object to the assertion that Puppet 
forces you to do anything, as if you had no choice in the matter.

With that said, you can perhaps adapt to the changes by supplying explicit 
'status' commands for your Service resources, overriding the systemctl 
command Puppet uses on 

Re: [Puppet Users] Re: puppet calling systemctl instead of /etc/init.d/xxx even when told to use debian provider

[Will Hopper]

Hey Ghislain!
 

>   Right now until this particular push of new code all was working as 
> intended for us, but this code was added in the service sysV init provider 
> a check of systemD  in the sysvinit part. So you can be an advocate  of 
> systemd and there is no problem on that but sytemd cannot work on a lot of 
> situations and i do not see the point of calling it inside a sysvinit part 
> without any way to ovveride  this choice :) If people install systemd they 
> will use the systemd provider not the sysvinit one.
>
>
Indeed, the code block you pointed out was added recently to deal with the 
peculiarities of the systemd / init compatibility layer. Namely, as you 
mentioned, init script return values are inconsistent in Debian 8 / Ubuntu 
15.04 and are not consistent with systemd's status reports. This fix works 
fine on standard installations which include systemd, and brings some 
consistency between systemd and init. However, the use case of a system 
which has had systemd removed or otherwise not present was not considered 
when originally making this change.
 

> Also i assume it should not be that hard to test for the systemd package 
> to be present to allow this test or not and therefor make ascended 
> compatibility work as it was before this code change :)
>

Correct - this is actually a pretty simple fix which I've got a pull 
request for up at https://github.com/puppetlabs/puppet/pull/4466 (see the 
ticket at https://tickets.puppetlabs.com/browse/PUP-5548). I fired up a 
Debian 8 box and followed the steps 
at 
http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation
 
to purge systemd and make sysvinit the main unit, and everything looked to 
be working correctly from puppet's perspective.

Feel free to leave comments on the pull request or ticket. Hopefully this 
minor change will be everything required to get you back up and running.

-- 
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/dcef8c9b-4375-46e1-b75a-e9f3745f388c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppet calling systemctl instead of /etc/init.d/xxx even when told to use debian provider

[Will Hopper]

Hey John!

Thanks for the responses and analysis of the situation! You're spot on in 
several areas which prompted this change in the first place. Comments 
inline:
 

> Please allow me to clarify that I have no particular objection to nor 
> animosity for Debian 8 "Jessie", or any earlier version of Debian.  
> Nevertheless, Jessie absolutely is "quirky" in the objectively measurable 
> sense that under some circumstances, the "status" command of its SysV init 
> scripts returns 0 when the LSB specifications dictate a different return 
> value.  Others less generous than I might instead characterize that as a 
> "flaw", or even a "bug".  This particular quirk presents a problem for 
> Puppet, and therefore for you.
>
 ...

> I am not advocating for systemd.  I am simply observing that Debian seems 
> to have embarked on a switch to it, inasmuch as systemd is not just an 
> alternative init system but the *default* init system for Jessie.  
> Correlated with that switch, the behavior of the Debian SysV initscripts 
> has changed so that the whole subsystem is no longer LSB-compliant.  As a 
> result, the approach Puppet takes to managing services on earlier versions 
> of Debian *does not work reliably* on Jessie.  Using the old system for 
> Jessie was not a viable option.
>
>
Yes - this is the exact issue which prompted us to use systemd to determine 
service status in Debian 8 / Ubuntu 15.04 and above. As you've mentioned 
below, this presented a very large dilemma for Puppet, as it could no 
longer properly manage these services through the systemd / sysvinit 
compatibility layer. It should be noted, however, that this only affects 
default installations which still include both the systemd and sysvinit 
bits.
 
 

>  
>
>>  Debian offer me the choise between systemd and sysinit and the 
>> modification to the service provider simply make things hard and increase 
>> surface of problems as even with sysvinti system we must now install the 
>> systemd packages and all the dependency hell (and even the wrapper install 
>> daemon cgroup crtl script and a bunch of thing unneeded). Your solution on 
>> maintening my own system instead of running puppet is rather an unexpected  
>> answer.
>>
>>
> Debian seems not to offer quite the choice you think it does, as opting 
> for sysvinit on Jessie is subtly inequivalent to using sysvinit by default 
> on earlier Debians.  As for packages, I have to take your word for what and 
> how many packages are required, and for how much trouble that is.  I 
> confess, however, that I had supposed Apt to be a lot more capable and 
> convenient than you seem to imply, and Debian's package collections -- even 
> "unstable" -- to be more internally consistent.
>
>
The key difference here, I believe, is that Ghislain (and probably others) 
have actively purged systemd from their Debian 8 systems, such as by 
following this 
guide: 
http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation.

When doing this, you are effectively reinstating sysvinit as the chief init 
system and more or less reverting to how things worked back in Debian 7. 
>From my brief tests around this, it seems that the old init scripts which 
were LSB compliant are brought back and used, meaning that Puppet can work 
properly.

All of this being said, I believe that the fix to use systemctl to 
determine service status is absolutely necessary on the default case of 
Debian 8 systems using the sysvinit / systemd compatibility layer (as is 
what you get upon a fresh installation). Not doing so breaks Puppet's 
ability to manage many services. However, I also think it's reasonable to 
check that systemctl is present on the system first, falling back to init 
scripts if it is not. This will allow use cases such as this one where 
systemd has been purged from the system.

-- 
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/6dd17998-3be4-429c-9ace-27fa8cf4a42d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Passing a generated variable inside a template...how?

[Dayton Jones]

Ah...nevermind, figured this out!

Sorting (well, reverse sorting so lo0 gets put first):
<% @interfaces.split(',').sort!{|x, y| y <=> x}.each do |int| if 
has_variable?("ipaddress_#{int}") -%>

Splitting:
<% fqdn =  Resolv.getname(scope["ipaddress_#{int}"]) -%>
<% name = (fqdn.split('.')) -%>
<%= scope["ipaddress_#{int}"] -%> <%= fqdn -%> <%= name.first %>


On Monday, November 30, 2015 at 8:52:00 AM UTC-6, Dayton Jones wrote:
>
> Ok... I switched tactics somewhat and have more or less what I wanted:
>
> === start ERB file ===
> <% @interfaces.split(',').each do |int| if 
> has_variable?("ipaddress_#{int}") -%>
> <%= scope["ipaddress_#{int}"] -%> <%= 
> Resolv.getname(scope["ipaddress_#{int}"]) -%>
> <% end -%>
> <% end -%>
> === end ERB file ===
>
> this will give the the IP and associated FQDN of all the interfaces but I 
> was wondering if the community could give me a little more help..
>
> 1) Once I have all the interfaces/names, how can I split the FQDN and get 
> the short name (myhost vs myhost.domain.com)
> 2) Is there a way to order the output (put 127.0.0.1 at the top, etc)?
>
>
> On Wednesday, November 25, 2015 at 2:25:22 PM UTC-6, Dayton Jones wrote:
>>
>> I'm writing a template to populate a file - easy enough...
>>
>> What I want is to to grab the list of interfaces, get the ip assigned to 
>> that interface and then do a lookup of the ip to get the dns name.
>>
>> I'm able to get the interfaces/ips just fine, but can't figure out how to 
>> then pass the IP to the function to do the lookup.  Any help is greatly 
>> appreciated...
>>
>> ===
>> start ERB
>>
>> <% scope.lookupvar('interfaces').split(",").each do |interface| %>
>> <% @int_ip = scope.lookupvar('ipaddress_'+interface) %>
>> <% @int_name = Resolv.new.getname @int_ip %>
>> ...
>> <% end %>
>>
>> end ERB
>> 
>>
>> @int_ip gets popluated and I can manipulate it as needed, but how do I 
>> properly pass it to 'Resolv.new.getname' to set the int_name string?
>>
>

-- 
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/8a361168-e034-475d-ac9b-898abcd04a10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Hiera Interpolation

[Matthew Ceroni]

I have been using variable interpolation within my Hiera data files for
sometime.

For instance I have Citrix NetScaler LB rules defined as such:

apache:
  name: "%{::cluster}-apache"
  ensure: 'present'
  service_type: 'HTTP'
  state: true
  lb_method: 'LEASTCONNECTION'

And based on the cluster the machine is in (cluster is a parameter set by
my ENC) it creates the rule accordingly.

However I know have a need to interpolate variables that might be be arrays
or hashes. Is there a way I can interpolate a hash key, value within a
hiera data file from a variable in the current scope?

I know within hiera I can reference other keys using hash and look-up based
on a key, but this data isn't another key within the data file, it is a
variable set by my ENC available in the current scope (just like cluster
was).

Thanks

-- 
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/CA%2BNsY5gE%3D5g_1OMU%3D4pKBh9BJ7V2fjynS2PC04%2BdXthwXPk21Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: how to trigger puppet run on agents remotely

[Christian Flamm]

Very simple, yet helpful: https://github.com/alcCapone/doll

-- 
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/a4772ecf-d499-4ac4-9f0a-025044ec166e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Cert generation messed up, fresh install

[jcbollinger]

On Wednesday, November 25, 2015 at 4:45:57 PM UTC-6, John Gateley wrote:
>
> Puppet 4.3.0
> Server Debian 7
> Client Debian 8
>
> I have verified the server is running and listening on port 8140
> The client has the puppet service started, but there are no certs to 
> verify on the server.
> This is the error I am seeing:
>
> root@puppetclient1:/opt/puppetlabs/puppet# puppet agent --test 
> 
> Error: Could not request certificate: SSL_connect SYSCALL returned=5 
> errno=0 state=SSLv2/v3 read server hello A
> Exiting; failed to retrieve certificate and waitforcert is disabled
>
>

It sounds like the agent is unable to connect to the server to deliver a 
certificate-signing request.  This is most likely because a firewall on one 
side or both refuses to pass the traffic through.  In particular, the 
server listening on port 8140 in no way guarantees that machine's firewall 
will let any traffic through to that port.  Make sure port 8140/tcp is open 
for all inbound traffic from all machines that should be able to request 
catalogs.


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, 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/c5c2833a-5712-4e69-81e3-5f2352fcddf7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] rspec for facts with multiple resolutions

[Fabien Wernli]

Hi,

I'm trying to write rspec tests for facts with multiple resolutions.

I know I can stub facts, and thus test all resolutions by targeting them 
using the stubbed facts.
But how do I test a given resolution if the previous fails?
Or how do I test a given resolution when it was given an explicit weight 
and no confine statements?

Example:


Facter.add(:foo) do
  has_weight 100
  setcode do
"bar"
  end
end

Facter.add(:foo) do
  has_weight 200
  setcode do
nil
  end
end


This fact should return "bar", but how do I test it in rspec?

-- 
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/859a353a-a892-4443-a6eb-a4b53a270468%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppet calling systemctl instead of /etc/init.d/xxx even when told to use debian provider

[jcbollinger]

On Wednesday, November 25, 2015 at 9:16:16 AM UTC-6, Aqueos Aqueos wrote:
>
> in 
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/service/debian.rb 
> the lines:
>
> if ((os == 'debian' && majversion >= 8) || (os == 'ubuntu' && 
> majversion >= 15))
>   # SysVInit scripts will always return '0' for status when the 
> service is masked,
>   # even if the service is actually stopped. Use the SysVInit-Systemd 
> compatibility
>   # layer to determine the actual status. This is only necessary when 
> the SysVInit
>   # version of a service is queried. I.e, 'ntp' instead of 
> 'ntp.service'.
>   (@resource[:hasstatus] == :true) && ["systemctl", "is-active", 
> @resource[:name]]
> else
>   super
> end
>
>
> this force people to install the systemd package where there is not any 
> need for it. I don't think puppet should force install of unecessary 
> package, if we want systemd we would not overide the default provider to 
> debian and let it to systemd therefor those lines are more a pain thn an 
> help for me.
>
>

I understand your dissatisfaction, but I feel obligated to observe that 
Puppet isn't forcing you to do anything.  *Because of peculiarities in 
Debian*, Puppet cannot properly manage services on some versions of that 
distro via straight sysV initscripts.  This in no way forces you to install 
systemd; you also have the alternative of not managing services via Puppet 
in this quirky environment.

Inasmuch as this particular characteristic apparently affects only newer 
versions of Debian (and Debian-derived Ubuntu), I'm inclined to suppose 
that it arises in part because of a shift in Debian away from SysV init 
infrastructure, which indeed seems to have become quite the thing to do in 
the last few years.  If you want to complain about someone driving you 
toward systemd, I suggest you focus on your distro itself.


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, 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/dec8a62f-82a8-44d4-b51c-410b1aa907d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: why does the create_resource functio not contain in local scope?

[jcbollinger]

On Thursday, November 26, 2015 at 9:34:37 PM UTC-6, Haani Niyaz wrote:
 

> As you can see in the output above server_packges will be executed again 
> after the execution of some_class:
> Notice: Class[some_class::Service]: Would have triggered 'refresh' from 2 
> events
> Notice: /Stage[main]/Server_packages/Package[mysql-devel.x86_64]/ensure: 
> current_value absent, should be present (noop)
>
>

No, I don't see that, nor any reason to suppose it.  The output you 
presented lists Package[mysql-devel.x86_64] exactly once.  Puppet chooses 
to manage it later in the run than it does other packages that (I presume) 
are managed via your Class[server-packages], including the related package 
Package[mysql.x86_64], but you have not shown any ordering constraints that 
would instruct Puppet to do otherwise.

 

>
> I came across the following which seems to highlight the problem but it 
> was fixed in an older version:
>
>
> *create_resources should contain native types in the local scope*
>
>
> https://projects.puppetlabs.com/issues/8032
>
>

That bug was reported against Puppet 2.7.0 and fixed in version 2.7.3.  
Nothing you have presented suggests a regression.

Probably you have a misunderstanding about the nature of Puppet classes.  
Although classes serve as logical containers for resources, Puppet does not 
inherently prevent application of different containers from overlapping, 
which is what you appear to be seeing -- application of resources from at 
least two different containers interleaved.  If you want to influence the 
order in which resources are applied then you must employ appropriate 
order-of-application constraints 
.


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, 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/98bc1a52-bff4-40a1-8709-0b538e4096e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Passing a generated variable inside a template...how?

[Dayton Jones]

Ok... I switched tactics somewhat and have more or less what I wanted:

=== start ERB file ===
<% @interfaces.split(',').each do |int| if 
has_variable?("ipaddress_#{int}") -%>
<%= scope["ipaddress_#{int}"] -%> <%= 
Resolv.getname(scope["ipaddress_#{int}"]) -%>
<% end -%>
<% end -%>
=== end ERB file ===

this will give the the IP and associated FQDN of all the interfaces but I 
was wondering if the community could give me a little more help..

1) Once I have all the interfaces/names, how can I split the FQDN and get 
the short name (myhost vs myhost.domain.com)
2) Is there a way to order the output (put 127.0.0.1 at the top, etc)?


On Wednesday, November 25, 2015 at 2:25:22 PM UTC-6, Dayton Jones wrote:
>
> I'm writing a template to populate a file - easy enough...
>
> What I want is to to grab the list of interfaces, get the ip assigned to 
> that interface and then do a lookup of the ip to get the dns name.
>
> I'm able to get the interfaces/ips just fine, but can't figure out how to 
> then pass the IP to the function to do the lookup.  Any help is greatly 
> appreciated...
>
> ===
> start ERB
>
> <% scope.lookupvar('interfaces').split(",").each do |interface| %>
> <% @int_ip = scope.lookupvar('ipaddress_'+interface) %>
> <% @int_name = Resolv.new.getname @int_ip %>
> ...
> <% end %>
>
> end ERB
> 
>
> @int_ip gets popluated and I can manipulate it as needed, but how do I 
> properly pass it to 'Resolv.new.getname' to set the int_name string?
>

-- 
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/3a83c101-2ad4-4ca4-ba3a-c8fe2295a7bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.