Ability to "wait" for dotnet to complete installation

897 views
Skip to first unread message

Stephen Wallace

unread,
Jun 4, 2014, 2:15:24 AM6/4/14
to puppet...@googlegroups.com
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??

--

Dirk Heinrichs

unread,
Jun 4, 2014, 2:19:35 AM6/4/14
to puppet...@googlegroups.com
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.

HTH...

    Dirk
--

Dirk Heinrichs, Senior Systems Engineer, Engineering Solutions
Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
Tel: +49 2226 1596666 (Ansage) 1149
Email: d...@recommind.com
Skype: dirk.heinrichs.recommind
www.recommind.com

Felix Frank

unread,
Jun 4, 2014, 5:43:41 AM6/4/14
to puppet...@googlegroups.com
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

Jim Ficarra

unread,
Jun 4, 2014, 7:33:38 AM6/4/14
to puppet...@googlegroups.com
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
--
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 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.

Josh Cooper

unread,
Jun 4, 2014, 3:43:55 PM6/4/14
to puppet...@googlegroups.com
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:


We also need to supply a title to the start command, otherwise if the package source is quoted, e.g. 2003, the install will fail.

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??

--
--
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 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.

--
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.

For more options, visit https://groups.google.com/d/optout.

Josh

--
Josh Cooper
Developer, Puppet Labs

Join us at PuppetConf 2014September 20-24 in San Francisco
Register by June 5th to take advantage of the Early Adopter discount save $349!

Stephen Wallace

unread,
Jun 5, 2014, 5:47:02 AM6/5/14
to puppet...@googlegroups.com
Thank you all for the great suggestions.

Josh was right on the money with prepending "cmd.exe /c start /wait".

I also confess to being very lazy reusing someone else's brilliance with the Execs. We do know that Package resources are sweet, shiny, and will assure you def get through the Pearly Gates when your time arrives!

I think that They are right in saying that the longest way between two points, is usually the shortcut!

Anon :)
Reply all
Reply to author
Forward
0 new messages