help with checking presence of multiple file resources in profile manifest.

36 views
Skip to first unread message

Jason McMahan

unread,
Nov 17, 2016, 9:02:32 AM11/17/16
to Puppet Users
Good day,
I am attempting to create a profile manifest for installation of one of our windows applications.
The application upon install creates multiple services and equivalent exe.
The current structure we use is as shown below

class profile::application {
## Install application package
  package { 'application':
    ensure => installed,
    source => //server/share/application.msi,
  } ->
  file {'C:/Program Files (x86)/application/app1.exe':
    ensure => present,
  } ~>
  service {'app1':
    ensure => 'running',
    enable => true,
  }
}

This is our normal, however since this application creates multiple exe and services I need to ensure all are present and running. But want to ensure all files are present before moving to the service.


class profile::application {
## Install application package
  package { 'application':
    ensure => installed,
    source => //server/share/application.msi,
  } ->
  file {'C:/Program Files (x86)/application/app1.exe':
    ensure => present,
  } 
  file {'C:/Program Files (x86)/application/app2.exe':
    ensure => present,
  } ~>
  service {'app1':
    ensure => 'running',
    enable => true,
  }
  service {'app2':
    ensure => 'running',
    enable => true,
  }
}

If I were to do it the way above will it ensure all files are present then move to service validation or ensure app2.exe is present then move to services?

Any help or guidance is appreciated. Thank you

Nick Miller

unread,
Nov 17, 2016, 9:18:24 AM11/17/16
to puppet...@googlegroups.com
Jason,

You can try the install => config => service layout as implemented in the puppetlabs-ntp module.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fd7208e9-d711-4600-9b49-41742e03065f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

OnyxPoint-logo-symbol-primary.png

Nicholas Miller
Consultant | Onyx Point, Inc.

7050 Hi Tech Drive, Suite 102

Hanover, MD. 21076
e: nick....@onyxpoint.com
w: 443-655-3675

copmany.pngcareers.pngproduct.pngmeetups.pngblog.png

Akai

unread,
Nov 23, 2016, 4:21:58 PM11/23/16
to Puppet Users
Maybe i understand you wrong, because my English is not the best:

You want to make sure, that your files are ensured before your service running up?
You can use a simple require to make that sure

service { 'app1':
     
...
     
require => [ File['C:/Program Files (x86)/application/app1.exe'] ],
}


if you want your service restarts when your file is changed during the process (helpful sometimes for .ini or config files)
you can you "subscribe" instead of "require". This to metatypes works with the most resources in puppet. For example, if you want that some WindowsFeatures and specific applications are installed, before the installation of another package starts, you can handle this on this way.


James_P

unread,
Dec 1, 2016, 3:31:44 PM12/1/16
to Puppet Users
Not sure if you got an answer that made sense, but here is my take on what you may be seeking. You can refer to https://docs.puppet.com/puppet/latest/lang_relationships.html for a better explanation than I can give here. 

Now I haven't worked with Puppet on Windows, but this is how I have setup similar 


class profile::application {
## Install application package
  package { 'application':
    ensure => installed,
    source => //server/share/application.msi,
  } ->
  file {'C:/Program Files (x86)/application/app1.exe':
    ensure => present,
    require => Package['application'],     # Make sure that the application.msi ran before checking for the apps.
  } 
  file {'C:/Program Files (x86)/application/app2.exe':
    ensure => present,
    require => Package['application'],      # Make sure that the application.msi ran before checking for the apps.
  } ~>
  service {'app1':
    ensure => 'running',
    enable => true,
    require => File['C:/Program Files (x86)/application/app1.exe'],   #Make sure app exists before trying to start 
  }
  service {'app2':
    ensure => 'running',
    enable => true,
    require => File['C:/Program Files (x86)/application/app2.exe'],   #Make sure app exists before trying to start 
  }
}


Another way you do the file / service blocks would be to try the below. It will make sure the .msi file was run first and after it checks for the file it would tell the service to do the setup.


file {'<path to file for app X>': 
   ensure => present,
   require => Package['application'],
   notify => Service['<app>']
}

service {'app': 
   ensure => 'running',
   enabled => 'true",
}

You may also want to look at the Metaparameter Reference pages at https://docs.puppet.com/puppet/4.8/metaparameter.html as it talks about the various ones I used above as well as many others. They are very good at doing workflow. 

If you are feeling really adventurous you might want to look at coding a custom fact (which can be written in any language that returns key=>value pairs in the format puppet wants) that would parse through your //server/share/application.msi file and run a for look on each "app" it find in there.  You could use variables to simplify your manifest a lot. Look at https://docs.puppet.com/puppet/latest/lang_iteration.html.  The custom fact would be pushed to your Windows server and run before the catalog is compiled on the Puppet master. 

So using the example Puppet gives for declaring resources and a custom fact that returns the fact apps_to_install=[ 'app1', 'app2', ...., 'appX' ], you could try to do: 

$app_to_install.each |String $my_app| {
   package {'$my_app': 
   ... 
   }
   file {'C:/Program Files (x86)/application/$my_app':
   ...
    require => Package['$my_app'],     
    notify => Serice['$my_app'],
   }

   service {'$my_app': 
      ...
   }

Hopefully something in my ramblings made some sense and helped you figure out what to do to get this working. 





Reply all
Reply to author
Forward
0 new messages