On Wed, Jun 4, 2014 at 4:33 AM, Jim Ficarra <[email protected]> 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 <[email protected]>
> *Sent:* Wednesday, June 04, 2014 2:15 AM
> *To:* [email protected]
> *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 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??
> --
>  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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAFB-iqe4_v9wZO0vKSJkDabN5j3GRe-9fRqDkmpy7tPmL7dTrg%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAFB-iqe4_v9wZO0vKSJkDabN5j3GRe-9fRqDkmpy7tPmL7dTrg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/65D4B90AE627478BA7881003C8AE2800%40JimHPPavilionG6
> <https://groups.google.com/d/msgid/puppet-users/65D4B90AE627478BA7881003C8AE2800%40JimHPPavilionG6?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

Josh

-- 
Josh Cooper
Developer, Puppet Labs

*Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September
20-24 in San Francisco*
*Register by June 5th to take advantage of the Early Adopter discount
<http://links.puppetlabs.com/puppetconf-early-adopter> **—**save $349!*

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2Bu97umohK0BTAoo4Sn_21vZU4Bzw8C-ykvObSkrLXAtSJMW_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to