Windows Reboot

[jim]

Hi Guys

I'm using puppet for my windows configuration, and was wondering when installing / configuration something windowys, it requires a reboot, how does this effect the "puppet run"

e.g. join to domain ?

e.g. removing old version of software

e.g. host re-name

Is there options you can tell puppet its going to reboot and to finish that "puppet run"  upon restart ????

Regards

James

[ad]

James,

Not yet, see http://projects.puppetlabs.com/issues/19162.

My (ugly) approach for this now is a refreshonly exec with a delayed shutdown. I'd like to see a reboot => true or such for all resources that tell the agent to reboot after a run is complete when that resource is applied.

Adam

[Josh Cooper]

On Monday, March 11, 2013, ad wrote:

James,

Not yet, see http://projects.puppetlabs.com/issues/19162.

My (ugly) approach for this now is a refreshonly exec with a delayed shutdown. I'd like to see a reboot => true or such for all resources that tell the agent to reboot after a run is complete when that resource is applied.

I did something similar, reboot resource type that is only triggered via notify/subscribe relationship from another resource. See https://github.com/joshcooper/puppetlabs-reboot

Adam, I'm curious about the approach you're talking about also. If reboot was a metaparameter, I don't think it would be possible to specify the reboot message or reason code (for different resources) But perhaps that's not really important? 

Adam

On Monday, March 11, 2013 6:55:46 AM UTC-5, jim wrote:

Hi Guys

I'm using puppet for my windows configuration, and was wondering when installing / configuration something windowys, it requires a reboot, how does this effect the "puppet run"

e.g. join to domain ?

e.g. removing old version of software

e.g. host re-name

Is there options you can tell puppet its going to reboot and to finish that "puppet run"  upon restart ????

Regards

James

--
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...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Josh Cooper

Developer, Puppet Labs

[Rakesh Kathpal]

Dear James,

So how exactly can I use this resource while doing my operations..

Say.. I want to perform the operation in a following sequence

1) Puppet Run starts
2) Install MSI
3) Reboot
4) Apply another puppet manifest
5) Puppet Run Completes

Thanks a lot for your help.

Regards,

Rakesh K.

[Rich Siegel]

My idea on reboots is different. I don't think we should have puppet do the reboot. If we go down this road, we need autologon, credentials, runonce, and a subsequent puppet agent run among other things. Not ideal if a puppet agent service is running during business time. This is orchestration and not where puppet should not be trying to succeed.

Originally I thought I needed a facter fact to determine if a reboot pending state existed, but the problem is that the facts are determined upfront. So if a resource triggers a "state" where a reboot is needed the fact is busted.

I think we need a new embedded construct which can check the reboot state before processing every resource. It has to happen before it makes it to the provider since it should not be left to a provider author as it could apply to any resource. If this boolean goes true then every resource in that graph needs to be skipped.

A meta param can be added to say reboot => force which can force a resource to be processed _despite_ the boolean.

I also need way to stateful trigger reboot flag like a lockfile so I can do a bios upgrade.

Actually _rebooting_ with puppet I am leery of. I welcome all input on this.

[ad]

Hi Josh,

As you may recall, I'm the odd kid on the block using Puppet to manage many many embedded Windows 7 and XP devices, so my needs are probably not very representative of the Puppet community. I have no need for a reboot message/code. Most our devices already have a nightly scheduled reboot. I use run stages and a delayed shutdown to, for all practical purposes, ensure a resource that requires a reboot runs last and give the agent enough time to cleanly finish the run and send reports back. I also use a schedule resource to control when devices are allowed to apply a resource that requires a reboot.

I'll check out your reboot provider, thanks. I just use an exec currently.

Regards,

Adam

On Tuesday, March 19, 2013 11:42:19 PM UTC-5, Josh Cooper wrote:

On Monday, March 11, 2013, ad wrote:

James,

Not yet, see http://projects.puppetlabs.com/issues/19162.

My (ugly) approach for this now is a refreshonly exec with a delayed shutdown. I'd like to see a reboot => true or such for all resources that tell the agent to reboot after a run is complete when that resource is applied.

I did something similar, reboot resource type that is only triggered via notify/subscribe relationship from another resource. See https://github.com/joshcooper/puppetlabs-reboot

Adam, I'm curious about the approach you're talking about also. If reboot was a metaparameter, I don't think it would be possible to specify the reboot message or reason code (for different resources) But perhaps that's not really important? 

Adam

On Monday, March 11, 2013 6:55:46 AM UTC-5, jim wrote:

Hi Guys

I'm using puppet for my windows configuration, and was wondering when installing / configuration something windowys, it requires a reboot, how does this effect the "puppet run"

e.g. join to domain ?

e.g. removing old version of software

e.g. host re-name

Is there options you can tell puppet its going to reboot and to finish that "puppet run"  upon restart ????

Regards

James

--
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+unsubscribe@googlegroups.com.

To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[jim]

Hi Guys

The way I get around it now, is by using a powershell script that creates a text file and delete puppetlockd if exists and then reboots, and then puppet checks if  text file exists upon next run and ignores

e.g. Powershell

Add-Content "c:\Installs\Puppet_Confirmation\Joined_AD_domain.txt" "Windows has joined $domain"

$strFileName = "c:\ProgramData\PuppetLabs\Puppet Enterprise\var\state\puppetlockd"

IF (Test-Path $strFileName){

        Remove-Item $strFileName }

shutdown /r /t 60

e.g. Puppet manifest

exec { 'domain_join':

command       => 'C:/Windows\System32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy remotesigned -file C:\Installs\Scripts\domain_join.ps1',

creates       => 'C:\Installs\Puppet_Confirmation\Joined_AD_domain.txt',

This approach seems to work ok for me, as I can then control, how puppet works by using another script to delete the text file, I so it will re-run if required

(if that make sense)

regards

James

[Josh Cooper]

Hi Rich,

On Wed, Mar 20, 2013 at 5:54 AM, Rich Siegel <rism...@gmail.com> wrote:

My idea on reboots is different.  I don't think we should have puppet do the reboot.  If we go down this road, we need autologon, credentials, runonce, and a subsequent puppet agent run among other things.

Why do we need autologon and credentials?

Since puppet is typically running as an automatic windows service, it will run immediately after machine reboot, and re-apply the catalog, picking up where it left off (assuming the resources leading up the reboot are correctly idempotent).

If you don't run puppet as a service, then you're probably going to need an external orchestration process.

  Not ideal if a puppet agent service is running during business time.  This is orchestration and not where puppet should not be trying to succeed.

Sure, mcollective could be used to reboot en masse during a scheduled maintenance windows, e.g. reboot all hosts where the reboot_pending fact is true. But not everyone has or wants to setup mcollective, and reboots are a common requirement on windows.

Originally I thought I needed a facter fact to determine if a reboot pending state existed, but the problem is that the facts are determined upfront.  So if a resource triggers a "state" where a reboot is needed the fact is busted.

I think we need a new embedded construct which can check the reboot state before processing every resource.  It has to happen before it makes it to the provider since it should not be left to a provider author as it could apply to any resource.   If this boolean goes true then every resource in that graph needs to be skipped.

So suppose we added a metaparameter to check if a reboot is pending, and the metaparameter is set on a particular resource, e.g. package.

package { 'somepackage':

  source => 'some.msi',

  reboot_pending => check

}

Internally, that metaparameter could create an instance of a reboot_pending resource, and setup a before/require relationship:

reboot_pending { '...':

  before => Package['somepackage']

}

If the reboot_pending provider determines a reboot is necessary, then it would cancel the transaction loop, causing all remaining resources to be skipped. Puppet would remain in this state until the pending reboot is cleared.

I don't think both approaches are mutually exclusive, though I think they are modeling different things. The provider I created is about performing a reboot as a result of another resource being applied (in cases where you know a priori that a reboot will be necessary). Unfortunately, puppet doesn't have a general mechanism for sending different types of events, so all we know is the package was installed, but not whether it required a reboot as a result.

The other approach, e.g. reboot_pending, is about modeling the reboot pending state of the machine. This would be useful in cases where you don't know ahead of time if a reboot will be necessary, or in cases that require multiple reboots,

I think you could even combine them together in cases where you want puppet to both detect that a reboot is pending and do the reboot:

package { 'somepackage':

  source => 'some.msi',

  reboot_pending => check

}

reboot_pending { 'somepackage':

  before => Package['somepackage'],

}

reboot { 'now':

  subscribe => Reboot_pending['somepackage'],

}

A meta param can be added to say reboot => force which can force a resource to be processed _despite_ the boolean.

Isn't that the same as not specifying a reboot metaparameter? Or are you saying only apply that resource, and skip the rest?

 

I also need way to stateful trigger reboot flag like a lockfile so I can do a bios upgrade.

As a way of preventing puppet from applying changes? If so, you could add an entry to the registry to make the system think a reboot is necessary.

 

Actually _rebooting_ with puppet I am leery of.  I welcome all input on this.

--
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...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Josh