How to Create Manifest file to manage Windows Nodes - puppet

I am new to Puppet and so I am totally confused about how to create a Manifest that can deploy any application on Windows Nodes. I have successfully configured the Open-source Puppet Server on Centos 7 Machine and I am using Windows 10 machine as a Puppet Client. I am also done with the certificate exchange between Server and Client.
So can you please suggest me some point so that I can create my manifest file to manage the windows Nodes.

The easiest way to start writing a new module is to use the pdk. It runs on Windows, Mac and Linux.
If you're on Windows then in powershell you'd run pdk new module <module name> and then cd <module name> and pdk new class <module name> . That will give you the basic construction of a module that you can push up to your git repo. It also contains an rspec testing framework etc.
The Puppet forge has some great examples of code.
You probably want to look at using Chocolatey it's a package manager similar to Yum.
Some example code for your manifest, in /manifests/init.pp
class <module name> {
require chocolatey # forge module
Package { provider => chocolatey, }
package { 'git':
ensure => installed,
}
user { 'testuser':
ensure => present,
groups => 'testgroup',
comment => 'Test user',
}
file { 'C:\Program Files\testuser':
ensure => directory,
owner => 'testuser',
group => 'testgroup',
}
acl { 'C:\Program Files\testuser':
permissions => [
{ identity => 'testuser', rights => ['full']},
{ identity => 'testgroup', rights => ['read']}
],
}
}

Related

Provider npm does not support features install_options

I am trying to install a node package globally via package provider of puppet. Unforturnately it doesn't support install_options. I am getting the following error.
Debug: /Package[npm-http-server]: Provider npm does not support features install_options; not managing attribute install_option
Debug: /Package[npm-http-server]: Provider npm does not support features virtual_packages; not managing attribute allow_virtual
My manifest looks like below
class profiles::app::base::nodejs {
class { 'nodejs':
target_dir => '/bin',
version => 'v8.9.4',
}
package { 'npm-http-server':
name => 'http-server',
provider => 'npm',
install_options => ['-g', { '--prefix' => '/'}],
require => Class['nodejs']
}
}
Operating System : Centos 7 (with vagrant on windows 10)
User : Admin
Module version : mod 'willdurand-nodejs', '2.0.2'
Puppet : Masterless puppet version 4.10.12
My aim is to install the module globally in /lib/node-modules/ folder and to create symlinks in /bin folder.
Am i doing it in wrong way? Any workaround /fix?

How to provide a startup service file in Puppet

We have RedHat 7.2 Linux OS and use puppet to perform our tasks. I am using puppet to install some software, which has worked fine and now the final step is to create an OS level service. In earlier versions of RHEL, we used chkconfig but that has been replaced with systemctl. Of course, the recommended way of performing this task is using a service. Since this is a custom software, I have my own startup script that I usually copy over to /etc/init.d, run chkconfig and then startup the service. How do I perform these tasks via Puppet for RedHat 7.2 OS ? I only want to create the service (not start it up or anything). This way, when the server reboots, the service will startup the app.
EDIT :
#redstonemercury for RHEL 7 I would think the following would be required. But your suggestion definitely helps as I was thinking along the same lines.
https://serverfault.com/questions/814611/puppet-generated-systemd-unit-files
file { '/lib/systemd/system/myservice.service':
mode => '0644',
owner => 'root',
group => 'root',
content => template('modulename/myservice.systemd.erb'),
}~>
exec { 'myservice-systemd-reload':
command => 'systemctl daemon-reload',
path => [ '/usr/bin', '/bin', '/usr/sbin' ],
refreshonly => true,
}
In puppet, use a package resource to install the package (assuming it's in repos that you're declaring already), then use a file resource to declare the /etc/init.d file, and put require => Package[<package_resource_name>] as a parameter in the file declaration to ensure the custom file gets created after the package has installed (so doesn't potentially get overwritten by the package's /etc/init.d file). E.g.:
package { 'mypackage':
ensure => present,
}
file { '/etc/init.d/mypackage':
ensure => present,
content => template('mypackage/myinitd'),
require => Package['mypackage'],
}
This is if you want to use a template. For a file, instead of content use source: source => puppet://modules/mypackage/myinitd

Running a command once after a group of packages is installed

I have an existing puppet manifest which installs a bunch of php5 packages and only after being installed restarts apache. The simplified manifest is something like
package { 'apache-php':
name => $modules,
ensure => installed
}
exec {'enable-mod-php':
command => $enable_cmd,
refreshonly => true
}
Package['apache-php'] ~> Exec['enable-mod-php'] ~> Service['apache']
After a system upgrade catalog runs have started failing with the following error message:
Error: Failed to apply catalog: Parameter name failed on Package[apache-php]: Name must be a String not Array at /etc/puppet/modules/apache/manifests/php.pp:22
I found out that I was using an undocumented feature/bug: Puppet 3.4.0 name as an array in package.
However, I'm having a hard time finding out how to redo my setup after the upgrade. How can I rewrite this manifest so that it works with more recent puppet versions?
Instead of using an arbitrary title for the package define in your example. (eg. apache-php) and using a name parameter, you can do the following:
$modules = ['foo','bar','baz']
package { $modules:
ensure => present
notify => Exec['enable-mod-php']
}
exec {'enable-mod-php':
command => $enable_cmd,
refreshonly => true,
notify => Service['apache']
}
service { 'apache':
# your apache params
}
I haven't looked at the code for the package provider, but can verify that the above works. You should also note that chaining arrows are all well and good, but according to the Puppet style guide, metaparameters are preferred.
Hope this helps.

Augeas support on my Vagrant machine?

I'm trying to getting support for augeas on my Vagrant machine.
I tried to install some package with these directives:
package { "augeas-tools": ensure => installed }
package { "libaugeas-dev": ensure => installed }
package { "libaugeas-ruby": ensure => installed }
When i try to use augeas on my manifests, after the vm boot i receive this error:
err: Could not find a suitable provider for augeas
I'm using the precise32 official box with Vagrant 1.0.3.
Vagrant 1.0.3 has ruby 1.8.7 and puppet 2.7.14
$ ruby -v
$ ruby 1.8.7 (2011-06-30 patchlevel 352) [i686-linux]
$ puppet help
$ Puppet v2.7.14
This is my little manifest with php class, included after apache class, mysql and other classes tested separately.
All things works correctly excepting for the augeas command.
class php {
exec { "apt-update":
command => "/usr/bin/apt-get update",
refreshonly => true;
}
package { "augeas-tools": ensure => installed }
package { "libaugeas-dev": ensure => installed }
package { "libaugeas-ruby": ensure => installed }
package { "php5": ensure => installed }
package { "php5-cli": ensure => installed }
package { "php5-xdebug": ensure => installed }
package { "php5-curl": ensure => installed }
package { "php5-intl": ensure => installed }
package { "php5-imap": ensure => installed }
package { "php5-mcrypt": ensure => installed }
package { "php5-imagick": ensure => installed }
package { "php5-sqlite": ensure => installed }
package { "php5-gd": ensure => installed }
package { "php-apc": ensure => installed }
package {
"libapache2-mod-php5" :
ensure => installed,
require => Package["php5"]
}
augeas { "php-cli":
require => [
Package["php5"],
Package["augeas-tools"],
Package["libaugeas-dev"],
Package["libaugeas-ruby"],
],
context => "/etc/php5/cli/php.ini",
changes => [
"set date.timezone Europe/Rome",
"set short_open_tag Off",
];
}
augeas { "php-apache":
require => [
Package["php5"],
Package["augeas-tools"],
Package["libaugeas-dev"],
Package["libaugeas-ruby"],
],
context => "/etc/php5/apache2/php.ini",
changes => [
"set date.timezone Europe/Rome",
"set short_open_tag Off",
];
}
}
After installation of packages, logging in the vagrant machine with "vagrant ssh", i launch:
vagrant#precise32:~$ ruby -raugeas -e "puts Augeas.open"
#<Augeas:0xb77a3598>
Thanks in advance!
I added the following to my Vagrantfile and it augeas started working.
Before declaring puppet provisioner add the following line, if on ubuntu:
config.vm.provision :shell, :inline => "sudo apt-get update && sudo apt-get install puppet -y"
This will update your apt packages and then update puppet client whose latest version already has a fix.
It turns out that this wasn't fixed in bug #6907 that I referenced in my other answer. That fix only worked for Puppet providers that depended on commands that were then supplied during the run.
For the Augeas provider, it uses an internal Puppet called "features" to check if the ruby-augeas library is available or not. Features are only being checked once and the results cached, so even after installing the library, this meant the feature still evaluated to false.
I filed this upstream as bug #14822 and have sent a pull request with a fix. Testing with the patch, I now get this successful run:
notice: /Stage[main]//Package[ruby-augeas]/ensure: created
notice: /Stage[main]//Augeas[test]/returns: executed successfully
I'm not familiar with Vagrant, but I think you'll need to find a workaround to install the libaugeas-ruby package before the Puppet run in the meantime.
On Puppet 2.7.14, this should work as the dependencies for providers will only be evaluated when they're needed - i.e. when Puppet needs to run those Augeas resources.
Without the full Puppet log file to confirm, I suspect that it's because you're missing explicit dependencies between the Augeas package(s) and the Augeas resources that need them. Remember, listing the resources in the manifest in that order doesn't mean Puppet executes it that way.
You could either add requires parameters to every Augeas resource:
augeas { "php-cli":
require => [ Package["php5"], Package["libaugeas-ruby"] ],
# ...
}
Or use the chaining syntax to automatically make every Augeas resource depend on a package. Add this on a line inside the class, but not inside any resource:
Package["libaugeas-ruby"] -> Augeas <| |>
After reading answer from #m0dlx I inspect /home/vagrant/postinstall.sh file and found that Vagrant uses own copy of Ruby:
# The base path to the Ruby used for the Chef and Puppet gems ruby_home="/opt/vagrant_ruby"
After that I find file augeas.rb at /opt/vagrant_ruby/lib/ruby/gems/1.8/gems/puppet-2.7.19/lib/puppet/provider/augeas/augeas.rb and edit it, by changing line
confine :true => Puppet.features.augeas?
to
confine :true => :augeas
(Shortly speaking I partially apply patch from #m0dlx.)
After that this error is gone.

Puppet User ID value and Package

I am trying to do the following using Puppet on an Ubuntu 10.04:
Copy a file that I have to a specific directory which will be owned by a specific user / group that does not exists yet since the package has not been installed
Install the package where it will not remove the directory and file that I created
To accomplish item #1, I basically tell Puppet to create a user and group first before copying the file. But the problem is that if I do not give a specific uid for Puppet, it will randomly pick a number like a number for user and not a number for system package.
So, how do I tell Puppet to choose a uid anything more than 1000?
If this is not possible, how do I tell Puppet not to start the package when it installs it. So I would just let Puppet install the package, but do not start the service, then copy my file, then I will start the service.
The user type has a parameter of system => which defaults to false, but can be set to true. This will generate the user with a UID below 500. Which seems to be what you want.
Ultimately what you'll want to do in my opinion is manage the config directory and the config via puppet as well.
This gives you the ability to do things like such:
package { foo: ensure => present }
file {
fooconfdir:
path => '/path/to/fooconfdir',
ensure => directory,
user => whatev,
group => alsowhatev,
require => Package[foo],
mode => morewhatev;
fooconf:
path => '/path/to/fooconfdir/fooconf',
ensure => present,
user => whatev,
content => template('whatev');
}
service { foo: ensure => running, enable => true, subscribe => File[fooconf] }
What that will do , is install your package then manage the config, then restart the service which will use your new config obviously on restart.

Resources