[Puppet Users] Ability to wait for dotnet to complete installation
Hi all,
Interesting timing challenge around installing dotnet on Windows 2008 R2
Data Cente.
In essence, when we run the following command, it appears to complete in a
few seconds. The reality is that it spawns multiple new msiexecs to install
and configure itself over the next 5 mins or so.
dotNetFx40_Full_x86_x64.exe /q /norestart
This causes an obvious issue if we need to install a bit of software with
dotnet as a dependancy, unless, we can wait until dotnet has finished
it's 5 min dance.
From command line, this issue is resolved by adding a start /wait to the
above command. The next challenge is how to get the correct syntax for my
exec statement;
command = start /wait
${dotnet::params::deployment_root}\\dotNetFx40_Full_x86_x64.exe
/q /norestart,
Without the start /wait, the above command works.
With the start /wait, it complains as follows...
/Stage[main]//Dotnet[dotnet45]/Exec[install-dotnet-45]/returns:
Error: start /wait
C:\ProgramData\PuppetLabs\puppet\etc\modules\dotnet\files\dotNetFx40_Full_x86_x64.exe
/q /norestart returned 1 instead of one of [0]
Short of writing a new function called go for a cup of tea feeding it
the required number of sleep seconds(!), does anybody have any experiences
or ideas around this one??
--
Regs,
Stephen J Wallace
M +61 (0)415 306731
http://au.linkedin.com/in/stephenwallace
--
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/CAFB-iqe4_v9wZO0vKSJkDabN5j3GRe-9fRqDkmpy7tPmL7dTrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Ability to wait for dotnet to complete installation
Am 04.06.2014 08:15, schrieb Stephen Wallace: Short of writing a new function called go for a cup of tea feeding it the required number of sleep seconds(!), does anybody have any experiences or ideas around this one?? There's a nice little wait_for resource available on Github https://github.com/basti1302/puppet-wait-for. HTH... Dirk -- *Dirk Heinrichs*, Senior Systems Engineer, Engineering Solutions *Recommind GmbH*, Von-Liebig-Straße 1, 53359 Rheinbach *Tel*: +49 2226 159 (Ansage) 1149 *Email*: d...@recommind.com mailto:d...@recommind.com *Skype*: dirk.heinrichs.recommind www.recommind.com http://www.recommind.com http://www.recommind.com -- 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/538EBA7D.3060804%40recommind.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Ability to wait for dotnet to complete installation
Oooh, shiny. Hadn't seen that one before. Thanks Dirk. Of course, it's also available from the more canonical https://forge.puppetlabs.com/basti1302/wait_for Cheers On 06/04/2014 08:19 AM, Dirk Heinrichs wrote: Short of writing a new function called go for a cup of tea feeding it the required number of sleep seconds(!), does anybody have any experiences or ideas around this one?? There's a nice little wait_for resource available on Github https://github.com/basti1302/puppet-wait-for. HTH... Dirk -- 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/538EEA3C.1060702%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Ability to wait for dotnet to complete installation
Did you try using the package resource over the exec resource? I install .NET
4.0 using the package resource and it works just fine on Windows 2008 R2
Enterprise Standard, though I haven’t tried on Data Center but I’m not sure
how different it would be. I’ve done something similar with .net 4.5. The
package resource allows the installation of .NET to be idempotent as it is
aware of packages installed/registered in Control Panel.
Here is one I use for .NET 4.5.1, but it’s the same pattern for 4.0 (I can’t
find the one I had for 4.0, but it was similar). Update the package name to
match the description as it appears in Control Panel as well as the version.
In my case I have a previous resource that I require that downloads the .exe to
a temp folder for local execution(Download_file). I also ensure that IIS is
installed (Windowsfeature)
package { 'Microsoft .NET Framework 4.5.1':
ensure = '4.5.50938',
source =
'D:\temp\NDP451-KB2858728-x86-x64-AllOS-ENU.exe',
install_options = ['/q','/norestart'],
require =
[Download_file['NDP451-KB2858728-x86-x64-AllOS-ENU.exe_download'],Windowsfeature['IIS']],
}
As I said I can’t find the 4.0 package def I had, but let here’s a crack at
what I remember.You’ll need to ensure that the source is updated to where
you have it. The source attribute works for local and UNC resources, but not
http urls. We use the download_file puppet resource type (from puppet forge)
to download files from an HTTP url.
package { 'Microsoft .NET Framework Extended':
ensure = '4.0.30319',
source =
'D:\temp\dotNetFx40_full_x86_x64.exe',
install_options = ['/q','/norestart'],
}
.NET 4.0 installs both extended and client profile. You *could* chain these
together, but I haven’t tried. Puppet will check that these are installed and
if they are, will not install them again. The first one would kick off and
install both, then when the Client Profile was checked it would see it was
installed. You could use this to ensure that both were installed – if someone
uninstalled the client profile but not extended, it would kick off the
installer again, but I’ve not tried a repair option. Perhaps .net would do a
full refresh, but I don’t know for sure.
package { 'Microsoft .NET Framework Extended':
ensure = '4.0.30319',
source =
'D:\temp\dotNetFx40_full_x86_x64.exe',
install_options = ['/q','/norestart'],
} -
package { 'Microsoft .NET Framework Client Profile':
ensure = '4.0.30319',
source =
'D:\temp\dotNetFx40_full_x86_x64.exe',
install_options = ['/q','/norestart'],
}
Hope this helps.
-Jim
From: Stephen Wallace
Sent: Wednesday, June 04, 2014 2:15 AM
To: puppet-users@googlegroups.com
Subject: [Puppet Users] Ability to wait for dotnet to complete installation
Hi all,
Interesting timing challenge around installing dotnet on Windows 2008 R2 Data
Cente.
In essence, when we run the following command, it appears to complete in a few
seconds. The reality is that it spawns multiple new msiexecs to install and
configure itself over the next 5 mins or so.
dotNetFx40_Full_x86_x64.exe /q /norestart
This causes an obvious issue if we need to install a bit of software with
dotnet as a dependancy, unless, we can wait until dotnet has finished it's 5
min dance.
From command line, this issue is resolved by adding a start /wait to the
above command. The next challenge is how to get the correct syntax for my exec
statement;
command = start /wait
${dotnet::params::deployment_root}\\dotNetFx40_Full_x86_x64.exe /q /norestart,
Without the start /wait, the above command works.
With the start /wait, it complains as follows...
/Stage[main]//Dotnet[dotnet45]/Exec[install-dotnet-45]/returns:
Error: start /wait
C:\ProgramData\PuppetLabs\puppet\etc\modules\dotnet\files\dotNetFx40_Full_x86_x64.exe
/q /norestart returned 1 instead of one of [0]
Short of writing a new function called go for a cup of tea feeding it the
required number of sleep seconds(!), does anybody have any experiences or ideas
around this one??
--
Regs,
Stephen J Wallace
M +61 (0)415 306731
http://au.linkedin.com/in/stephenwallace
--
You received this message because you are subscribed to the
Re: [Puppet Users] Ability to wait for dotnet to complete installation
On Wed, Jun 4, 2014 at 4:33 AM, Jim Ficarra jimfica...@gmail.com wrote:
Did you try using the package resource over the exec resource? I
install .NET 4.0 using the package resource and it works just fine on
Windows 2008 R2 Enterprise Standard, though I haven’t tried on Data
Center but I’m not sure how different it would be. I’ve done something
similar with .net 4.5. The package resource allows the installation of
.NET to be idempotent as it is aware of packages installed/registered in
Control Panel.
Here is one I use for .NET 4.5.1, but it’s the same pattern for 4.0 (I
can’t find the one I had for 4.0, but it was similar). Update the package
name to match the description as it appears in Control Panel as well as the
version. In my case I have a previous resource that I require that
downloads the .exe to a temp folder for local execution(Download_file). I
also ensure that IIS is installed (Windowsfeature)
package { 'Microsoft .NET Framework
4.5.1':
ensure = '4.5.50938',
source =
'D:\temp\NDP451-KB2858728-x86-x64-AllOS-ENU.exe',
install_options = ['/q','/norestart'],
require =
[Download_file['NDP451-KB2858728-x86-x64-AllOS-ENU.exe_download'],Windowsfeature['IIS']],
}
As I said I can’t find the 4.0 package def I had, but let here’s a crack
at what I remember.You’ll need to ensure that the source is updated to
where you have it. The source attribute works for local and UNC resources,
but not http urls. We use the download_file puppet resource type (from
puppet forge) to download files from an HTTP url.
package { 'Microsoft .NET Framework Extended':
ensure = '4.0.30319',
source =
'D:\temp\dotNetFx40_full_x86_x64.exe',
install_options = ['/q','/norestart'],
}
.NET 4.0 installs both extended and client profile. You *could* chain
these together, but I haven’t tried. Puppet will check that these are
installed and if they are, will not install them again. The first one
would kick off and install both, then when the Client Profile was checked
it would see it was installed. You could use this to ensure that both were
installed – if someone uninstalled the client profile but not extended, it
would kick off the installer again, but I’ve not tried a repair option.
Perhaps .net would do a full refresh, but I don’t know for sure.
package { 'Microsoft .NET Framework
Extended':
ensure = '4.0.30319',
source =
'D:\temp\dotNetFx40_full_x86_x64.exe',
install_options = ['/q','/norestart'],
} -
package { 'Microsoft .NET Framework Client
Profile':
ensure = '4.0.30319',
source =
'D:\temp\dotNetFx40_full_x86_x64.exe',
install_options = ['/q','/norestart'],
}
Hope this helps.
-Jim
*From:* Stephen Wallace whizbang.wall...@gmail.com
*Sent:* Wednesday, June 04, 2014 2:15 AM
*To:* puppet-users@googlegroups.com
*Subject:* [Puppet Users] Ability to wait for dotnet to complete
installation
Hi all,
Interesting timing challenge around installing dotnet on Windows 2008 R2
Data Cente.
In essence, when we run the following command, it appears to complete in a
few seconds. The reality is that it spawns multiple new msiexecs to install
and configure itself over the next 5 mins or so.
dotNetFx40_Full_x86_x64.exe /q /norestart
This causes an obvious issue if we need to install a bit of software with
dotnet as a dependancy, unless, we can wait until dotnet has finished
it's 5 min dance.
From command line, this issue is resolved by adding a start /wait to the
above command. The next challenge is how to get the correct syntax for my
exec statement;
command = start /wait
${dotnet::params::deployment_root}\\dotNetFx40_Full_x86_x64.exe
/q /norestart,
Without the start /wait, the above command works.
With the start /wait, it complains as follows...
/Stage[main]//Dotnet[dotnet45]/Exec[install-dotnet-45]/returns:
Error: start /wait
C:\ProgramData\PuppetLabs\puppet\etc\modules\dotnet\files\dotNetFx40_Full_x86_x64.exe
/q /norestart returned 1 instead of one of [0]
I don't recommend installing .NET using an exec, but wanted to mention that
`start` only makes sense in the context of cmd.exe. So you'd need to do
something like:
cmd.exe /c start /w
${dotnet::params::deployment_root}\\dotNetFx40_Full_x86_x64.exe /q
/norestart
We do something similar in the windows package provider:
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/windows/exe_package.rb#L44
We also need to supply a title to the
