Coder Social home page Coder Social logo

puppet-puppet's Introduction

Puppet Forge CI

Puppet module for installing the Puppet agent and server

Installs and configures the Puppet agent and optionally a Puppet server (when server is true). Part of the Foreman installer or to be used as a Puppet module.

Many puppet.conf options for agents, servers and other are parameterized, with class documentation provided at the top of the manifests. In addition, there are hash parameters for each configuration section that can be used to supply any options that are not explicitly supported.

Compatibility

See the module metadata for supported operating systems and compatible Puppet versions. The Puppetserver version should also match this.

Environments support

The module helps configure Puppet environments using directory environments. These are set up under /etc/puppetlabs/code/environments.

Git repo support

Environments can be backed by git by setting server_git_repo to true, which sets up /var/lib/puppet/puppet.git where each branch maps to one environment. Avoid using 'server' as this name isn't permitted. On each push to the repo, a hook updates /etc/puppet/environments with the contents of the branch.

Permissions can be controlled via the git_repo_{user,group,hook_mode,umask} parameters.

Requires puppetlabs/vcsrepo >= 5.2.0.

Foreman integration

The Foreman integration is optional, but on by default when server is true. It can be disabled by setting server_foreman to false.

Requires theforeman/puppetserver_foreman.

Since version 15.0.0 the integration bits depend on the standalone module where previously it depended on theforeman/foreman

There is also optional integration for katello/certs. This can be enabled via Hiera:

puppet::server::foreman::katello: true

Then the foreman_ssl_{ca,cert,key} parameters are ignored and certs::puppet is used as a source.

PuppetDB integration

The Puppet server can be configured to export catalogs and reports to a PuppetDB instance, using the puppetlabs/puppetdb module. Use its puppetdb::server class to install the PuppetDB server and this module to configure the Puppet server to connect to PuppetDB.

Requires puppetlabs/puppetdb

class { 'puppet':
  server              => true,
  server_reports      => 'puppetdb,foreman',
  server_storeconfigs => true,
}
class { 'puppet::server::puppetdb':
  server => 'mypuppetdb.example.com',
}

Above example manages Puppetserver + PuppetDB integration. It won't install the PuppetDB. To do so, you also need the puppetdb class

class { 'puppet':
  server              => true,
  server_reports      => 'puppetdb,foreman',
  server_storeconfigs => true,
}
include puppetdb
class { 'puppet::server::puppetdb':
  server => 'mypuppetdb.example.com',
}

Then the PuppetDB module will also configure postgresql and setup the database. If you want to manage postgresql installation on your own:

class { 'postgresql::globals':
  encoding            => 'UTF-8',
  locale              => 'en_US.UTF-8',
  version             => '15',
  manage_package_repo => true,
}
class { 'postgresql::server':
  listen_addresses => '127.0.0.1',
}
postgresql::server::extension { 'pg_trgm':
  database => 'puppetdb',
  require  => Postgresql::Server::Db['puppetdb'],
  before   => Service['puppetdb'],
}
class { 'puppetdb':
  manage_dbserver => false,
}
class { 'puppet::server::puppetdb':
  server => 'mypuppetdb.example.com',
}

Above code will install Puppetserver/PuppetDB/PostgreSQL on a single server. It will use the upstream postgresql repositories. It was tested on Ubuntu.

Please also make sure your puppetdb ciphers are compatible with your puppet server ciphers, ie that the two following parameters match:

puppet::server::cipher_suites
puppetdb::server::cipher_suites

Installation

Available from GitHub (via cloning or tarball), Puppet Forge or as part of the Foreman installer.

Usage

As a parameterized class, all the configurable options can be overridden from your wrapper classes or even your ENC (if it supports param classes). For example:

# Agent and cron (or daemon):
class { 'puppet': runmode => 'cron', agent_server_hostname => 'hostname' }

# Agent and puppetserver:
class { 'puppet': server => true }

# You want to use git?
class { 'puppet':
  server          => true
  server_git_repo => true
}

# Maybe you're using gitolite, new hooks, and a different port?
class { 'puppet':
  server                   => true
  server_port              => 8141,
  server_git_repo          => true,
  server_git_repo_path     => '/var/lib/gitolite/repositories/puppet.git',
  server_post_hook_name    => 'post-receive.puppet',
  server_post_hook_content => 'puppetserver/post-hook.puppet',
}

# Configure server without Foreman integration
class { 'puppet':
  server                => true,
  server_foreman        => false,
  server_reports        => 'store',
  server_external_nodes => '',
}

# Want to integrate with an existing PuppetDB?
class { 'puppet':
  server              => true,
  server_reports      => 'puppetdb,foreman',
  server_storeconfigs => true,
}
class { 'puppet::server::puppetdb':
  server => 'mypuppetdb.example.com',
}

Look in init.pp for what can be configured this way, see Contributing if anything doesn't work.

To use this in standalone mode, edit a file (e.g. install.pp), put in a class resource, as per the examples above, and the execute puppet apply e.g:

puppet apply --modulepath /path_to/extracted_tarball <<EOF
class { 'puppet': server => true }
EOF

Advanced scenarios

An HTTP (non-SSL) puppetserver instance can be set up (standalone or in addition to the SSL instance) by setting the server_http parameter to true. This is useful for reverse proxy or load balancer scenarios where the proxy/load balancer takes care of SSL termination. The HTTP puppetserver instance expects the X-Client-Verify, X-SSL-Client-DN and X-SSL-Subject HTTP headers to have been set on the front end server.

The listening port can be configured by setting server_http_port (which defaults to 8139).

For puppetserver, this HTTP instance accepts ALL connections and no further restrictions can be configured.

Note that running an HTTP puppetserver is a huge security risk when improperly configured. Allowed hosts should be tightly controlled; anyone with access to an allowed host can access all client catalogues and client certificates.

# Configure an HTTP puppetserver vhost in addition to the standard SSL vhost
class { '::puppet':
  server               => true,
  server_http          => true,
  server_http_port     => 8130, # default: 8139
}

Contributing

  • Fork the project
  • Commit and push until you are happy with your contribution

More info

See https://theforeman.org or at #theforeman irc channel on freenode

Copyright (c) 2010-2012 Ohad Levy

This program and entire repository is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see https://www.gnu.org/licenses/.

puppet-puppet's People

Contributors

agx avatar alexjfisher avatar ares avatar bastelfreak avatar baurmatt avatar brandonweeks avatar domcleal avatar ehelms avatar ekohl avatar evgeni avatar gregsutcliffe avatar jcharaoui avatar jcpunk avatar jhoblitt avatar lzap avatar mcanevet avatar mmckinst avatar mmoll avatar ohadlevy avatar pall-valmundsson avatar roidelapluie avatar sanyu avatar sathieu avatar timogoebel avatar treydock avatar vinzent avatar vstone avatar wbclark avatar westbywest avatar zordrak avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

puppet-puppet's Issues

File resources assume specific umask

There are a few file resources throughout the module that assume a permissive umask (e.g. 0022). Many security benchmarks suggest a more restrictive default umask (e.g. 0027). On such systems, this module will break with various files inaccessible by apache (e.g. /etc/puppet/rack and its contents).

Parameterize cron command

I would like to propose that the cron command be configurable as a param.

I am using masterless aka standalone Puppet and had to override the cron command to use puppet apply

As a workaround I used a resource collector:

  Cron <| title == 'puppet' |> {
    command => "/usr/bin/puppet apply /common/puppet/manifests/default.pp > /dev/null 2>&1",
  }

basemodulepath needed in puppet 3.5.0

My foreman upgraded to puppet 3.5.0 today and none of my client machines could find their puppet modules. To get things working I had to edit my /etc/puppet/puppet.conf manually adding basemodulepath to the [main] section

[main]
   basemodulepath =/usr/share/openstack-puppet/modules

The entire [development] and [production] sections of /etc/puppet/puppet.conf were removed. This got me back online

Changing owner

Notice: /Stage[main]/Puppet::Config/File[/etc/puppetlabs/puppet]/owner: owner changed 'root' to 'puppet'
Notice: /Stage[main]/Puppet::Config/File[/etc/puppetlabs/puppet]/group: group changed 'root' to 'puppet'

With the new AIO package.

Should we do this or keep the package default?

Passenger App root is in a non-standard location

Currently, the Passenger app root is configured to point to '$dir/rack', where $dir is set to '/etc/puppet' by default.

However the recommended location is '/usr/share/puppet/rack/puppetmasterd'.

Was it a concious decision to use '$dir/rack', or an oversight?

Choosable rack server

Hi, i've forked this module to make uwsgi compatible. In my test is working correctly but before pull request i would like to know what do you prefer?:

One variable like "$rack_server" and valid values "false", "passenger", "uwsgi", "unicorn"...
Or otherwise keep the former "$passenger = true" but adding some kind of "$uwsgi = true", "$unicorn = true"....

Thanks!

Problem with latest Puppet and puppetca command

Latest version of Puppet doesn't contain "puppetca" -command. Its replaced with "puppet cert".

In manifests/server/config.pp the old puppetca was used and to get it work with latest Puppet had to replace "puppetca --generate" with "puppet cert generate".

Don't know Puppet yet well enough to create proper fix so thats why I only report this issue without fix.

Install puppetmaster foreman-proxy without apache/passenger fails

If you want to install puppetmaster foreman-proxy without passenger with passing the option "--puppet-server-passenger=false", the install fails just after "preparing install".

If you comment out the line 66 of /usr/share/foreman-installer/modules/puppet/manifests/server/config.pp, the install works correctly.

Completeness over brevity?

I wanted to enable msgpack as the preferred_serialization_format on puppet agents, so I looked at this module. I didn't see it as a parameter, so I looked further into the template and noticed puppet::agent_additional_settings and master_additional_settings.

I wanted to ask if there was any desire to go the full route and describe all of the configuration settings (completeness) vs some of the most commonly-used ones. I realize that the settings variables accommodate this functionality without having them as class variables, but should we look at implementing more of this?

https://docs.puppetlabs.com/references/stable/configuration.html#configuration-reference

Puppet.conf changes with puppet server

We have a bit of an awkward issue using this module. We run on AWS EC2 and build AMI's with packer. This basically means we run puppet on a temporary box that then takes a machine image. The problem is once we spin up the real machine from this image the agent's puppet.conf still has the hostname of the previous temporary machine as it's value for certname e.g:
certname = some_old_temporary_machine

When the agent does a run by contacting the puppetserver the value for certname in puppet.conf does not change, even if we manually edit it ourselves and re-run puppet. However it does change if we do a standalone run on the agent.

Is there any way we could get the puppet agent to reassert the certname value in it's puppet.conf without doing a standalone run at launch time?

Solaris 10 works

Hi, I'm using your module in Solaris 10 and works as expected if you specify package and service names:

My conf:

class {'puppet':
listen => false,
runinterval => '3600',
runmode => 'cron',
service_name => 'svc:/network/cswpuppetd:default',
client_package => 'CSWpuppet3',
cron_cmd => '/usr/bin/env /opt/csw/bin/puppet agent --config /etc/puppet/puppet.conf --onetime --no-daemonize',
show_diff => true,
}

Use of puppet::server via ENC causes variable problems

This was originally raised as theforeman/puppet-foreman_proxy#44 but through testing it became clear that the issue is just with puppet::server

I was testing installation of foreman-proxy using another foreman server as ENC and also using the modules theforeman/puppet-apache, theforeman/puppet-foreman_proxy and theforeman/puppet-passenger

If you assign the class puppet::server to this new host you get the error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find template '' at /etc/puppet/environments/foreman/modules/puppet/manifests/config.pp:8 on node

and on the master would be:

(Scope(Class[Puppet::Config])) Could not look up qualified variable 'puppet::dir'; class puppet has not been evaluated

and

(Scope(Class[Puppet::Config])) Could not look up qualified variable 'puppet::agent_template'; class puppet has not been evaluated

This wasn't an issue on the foreman server as I had an explicit node config and chained from puppet -> puppet::master -> foreman -> foreman_proxy but this is not something you can do with an ENC.

Either puppet::server::config needs to not depend on puppet::config, instead using it's own variables, or it needs to depend on the whole puppet class.

Puppet server certificate generation improvements?

We have a multi-puppetmaster environment with a separate CA server and are running into some issues with the cert generation @ https://github.com/theforeman/puppet-puppet/blob/master/manifests/server/config.pp#L61

Specifically, we updated the module so that:

  • The certificate should only be generated if the host is a CA ($::puppet::server_ca is true). Currently, all puppet servers will generate a self-signed cert.
  • If a $::puppet::ca_server is specified, and it is not equal to $::fqdn, the certificate should be generated with a DNS alt name == $::puppet::ca_server.

What do you think?

Malformed dependency

Installing this module produces the following error messages:

Warning: Cannot consider release theforeman-puppet-2.0.0: Malformed dependency: puppetlabs/apache. Exception was: Inval
d 'version_range' field in metadata.json: Unparsable version range: "~> 0.10"

Warning: Cannot consider release theforeman-foreman-2.0.1: Malformed dependency: puppetlabs/apache. Exception was: Invaid 'version_range' field in metadata.json: Unparsable version range: "~> 0.10"

Warning: Cannot consider release theforeman-tftp-1.4.1: Malformed dependency: puppetlabs/xinetd. Exception was: Invalid'version_range' field in metadata.json: Unparsable version range: "~> 1.1"

passenger module config generation weirdness on Debian Jessie

Hi,

I'm trying to use your puppet module for my puppetmaster running Debian Jessie (without Foreman), with packages from the repos (puppet 3.7.2).

My puppetlabs-apache module is at version 1.5.0.

When applying this class declaration

# Puppet master profile
class profile::puppet::master {
  $puppetmaster = hiera('puppet::master::hostname')

  class { '::puppet':
    server                      => true,
    server_parser               => 'future',
    server_foreman              => false,
    server_environments         => [],
    server_passenger            => true,
    server_storeconfigs_backend => 'active_record',

    runmode                     => 'none',
    pluginsync                  => true,
    puppetmaster                => $puppetmaster,
  }
}

the run succeeds, but the file /etc/apache2/mods-available/zpassenger.load contains

LoadModule root /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

There seems to be some issue in scoping somewhere between the apache::mod class and the way the puppet module instantiates it.

Thanks for looking into it!
Nicolas

Impossible not to use ENC with future parser

I don't seem to be able to set $::puppet::server_external_nodes to a value that uses the plain terminus instead of exec. The puppet class checks that this value is a string, so I can't pass in false, but all strings in the future parser evaluate to true. Passing undef to puppet means the default param is used.

Could parameters that take a boolean be a bit more lenient about allowing actual booleans as well as strings that look like booleans?

Unable to install 1.2.0-rc3 via Puppet Forge

puppet module install theforeman/puppet fails because of an invalid symlink:

Error: No such file or directory - /common/puppet/modules/puppet/spec/fixtures/modules/puppet/files
Error: Try 'puppet help module install' for usage

The symlink is looking for a 'files' directory at the root of the module which does not exist.

puppet::agent::service::daemon starting service before puppet::agent::config

[ INFO 2015-11-26 13:44:42 verbose]  Applying configuration version '1448545472'
[ WARN 2015-11-26 13:44:42 verbose]  /Stage[main]/Puppet::Agent::Service::Daemon/Service[puppet]/ensure: ensure changed 'stopped' to 'running'
[ INFO 2015-11-26 13:44:42 verbose]  /Stage[main]/Puppet::Agent::Service::Daemon/Service[puppet]: Unscheduling refresh on Service[puppet]
[ WARN 2015-11-26 13:44:43 verbose]  Augeas[puppet::set_start](provider=augeas): 
[ INFO 2015-11-26 13:44:43 verbose] --- /etc/default/puppet     2015-11-26 13:44:18.000000000 +0000
[ INFO 2015-11-26 13:44:43 verbose] +++ /etc/default/puppet.augnew      2015-11-26 13:44:43.000000000 +0000
[ INFO 2015-11-26 13:44:43 verbose] @@ -3,7 +3,7 @@
[ INFO 2015-11-26 13:44:43 verbose]  # Enable puppet agent service?
[ INFO 2015-11-26 13:44:43 verbose]  # Setting this to "yes" allows the puppet agent service to run.
[ INFO 2015-11-26 13:44:43 verbose]  # Setting this to "no" keeps the puppet agent service from running.
[ INFO 2015-11-26 13:44:43 verbose] -START=no
[ INFO 2015-11-26 13:44:43 verbose] +START=yes
[ INFO 2015-11-26 13:44:43 verbose]  
[ INFO 2015-11-26 13:44:43 verbose]  # Startup options
[ INFO 2015-11-26 13:44:43 verbose]  DAEMON_OPTS=""
[ WARN 2015-11-26 13:44:43 verbose]  /Stage[main]/Puppet::Agent::Config/Augeas[puppet::set_start]/returns: executed successfully

and then:

# service puppet status
agent is not running ... failed!

This is causing test failures on wheezy and precise (http://ci.theforeman.org/job/systest_foreman/8051).

Drop puppet-foreman requirement

In my opinion, puppet-puppet should not require puppet-foreman but the other way around, puppet should not be aware if foreman is going to use it or not.

It might require changes on puppet-foreman too.

That prevents the module to being used on it's own.

basemodulepath is written in [master] section. Mistake?

When I'm using the following:

 class {
    '::puppet':
      server_common_modules_path => ['/etc/puppet/modules/X','/etc/puppet/modules/Y'],

module puppet writes config under [master] section

    basemodulepath   = /etc/puppet/modules/X:/etc/puppet/modules/Y

However, according to the puppet docs it should be in [main] section.
Even when I'm running command puppet config print modulepath configuration in [master] is not working and puppet module list ignores basemodulepath in [master]
This should be easy fix which even I might be able to fix it but the question is, is it a bug?

Allow server property to be set

Currently puppet/puppet::agent does not allow server in puppet.conf to get set. I don't want to hard code an ip in /etc/hosts either.

This should be a class parameter. Currently I am forced to use a custom template.

Incomplete SSL Configuration

When using the foreman-installer to change from puppet master to puppet server everything completes without error. However when running a puppet agent SSL errors are seen. Through some troubleshooting it seems as if /etc/puppetserver/bootstrap.cfg remained configured to have the puppet server act as the CA. I personally use an external CA so I had to change this configuration. I also had to modify /etc/puppetserver/conf.d/webserver.conf to include the ssl certificate information (cert, key, ca) in order to have successful agent runs.

wrong permissions on environments.conf

When you set puppet::server_environments_group, and or puppet::server_environments_user, envrionments.conf ends up with differing permissions. This can cause spurrious reloads of puppetmaster or puppetserver.

in my environment I used this to fix it:

--- a/modules/puppet/manifests/server/env.pp
+++ b/modules/puppet/manifests/server/env.pp
@@ -38,8 +38,8 @@ define puppet::server::env (
     if $manifest or $config_version or $custom_modulepath or $environment_timeout {
       file { "${basedir}/${name}/environment.conf":
         ensure  => file,
-        owner   => 'root',
-        group   => $::puppet::params::root_group,
+        owner   => $owner,
+        group   => $group,
         mode    => '0644',
         content => template('puppet/server/environment.conf.erb'),
       }

though that is probably not right if running with git, though git users may not be messing with the user settings.

Pull request here #350

foreman-installer doesn't add ssl options in puppet.conf for master

I just ran the foreman installer and assuming this is the module that generated the puppet.conf for the master configuration. It seems like there are some missing options when puppet master is run under apache. Since the installer configures the master to run under apache the following lines need to be added to the puppet master configuration file.

Options included

foreman-installer --enable-foreman-compute-ec2 --enable-foreman-compute-gce --enable-foreman-compute-ovirt --enable-foreman-compute-vmware --enable-puppet --puppet-server-envs-dir=/etc/puppet/environments --puppet-server-environments=test

Necessary options to add to the puppet master conf

   ssl_client_header = SSL_CLIENT_S_DN
   ssl_client_verify_header = SSL_CLIENT_VERIFY

This causes the following error:

Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [self signed certificate in certificate chain for /CN=Puppet CA: puppet_master.company.com]

PuppetDB workaround

When using PuppetDB and this module, the following dependency is needed:

Exec['puppet_server_config-generate_ca_cert'] -> Package['puppetdb']

Not sure what to do with that.

"reports" parameter needs to go into [main] section of puppet.conf

I was having problems with an instance of puppetserver deployed by theforeman-puppet displaying this error on agent run, when integrated with puppetDB:

[puppet-server] Puppet Attempt to assign to a reserved variable name: 'trusted' on node xmaster.vagrant.vm

I found the module is placing the "reports" parameter in the [master] section of the puppetserver's puppet.conf, when it appears to belong in the [main] section instead.
https://tickets.puppetlabs.com/browse/PDB-949?focusedCommentId=198934&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-198934

Also, acknowledging Puppet's own docs about this are vague:
https://docs.puppetlabs.com/guides/reporting.html

~> is not valid

The ~> dependency expression used here is not expressly supported by the Puppet Forge and module tool. It may not always work as desired.

The currently supported expressions are documented here.

1.x or its equivalent range >=1.0.0 <2.0.0 may be substitutes for what you're using today.

Thank you for publishing to the Puppet Forge. I'll consider your use of ~> as a request for it to be added to the Forge.

incorrect usage of ca_port in puppet.conf template

observed in our CI:

# [ INFO 2014-12-24 11:22:46 verbose] Failed to parse template puppet/puppet.conf.erb:
# [ INFO 2014-12-24 11:22:46 verbose]   Filepath: /usr/share/foreman-installer/modules/puppet/templates/puppet.conf.erb
# [ INFO 2014-12-24 11:22:46 verbose]   Line: 29
# [ INFO 2014-12-24 11:22:46 verbose]   Detail: undefined method `empty?' for 0:Fixnum
# [ INFO 2014-12-24 11:22:46 verbose]  at /usr/share/foreman-installer/modules/puppet/manifests/config.pp:17 on node foreman

this happens as ca_port var is integer, and empty? is a method on a string/array.

Missing puppet user/group when installing JVM-based puppetserver on CentOS 7 vbox

I tried running this manifest in standalone on a puppetlabs/centos-7.0-64-nocm virtualbox guest:

  class { '::puppet': 
    runmode => 'service',
    server => true,
    server_jvm_min_heap_size => '2G', 
    server_implementation => 'puppetserver',
    server_foreman        => false,
    server_reports        => 'store',
    server_external_nodes => '',
    server_environments   => [],
  }

Execution fails on missing puppet user/group:

Error: Could not find user puppet
Error: /Stage[main]/Puppet::Config/File[/etc/puppetlabs/puppet]/owner: change from root to puppet failed: Could not find user puppet
Error: Could not find group puppet
Error: /Stage[main]/Puppet::Config/File[/etc/puppetlabs/puppet]/group: change from root to puppet failed: Could not find group puppet

These are the puppet release rpm and agent I was using:

puppetlabs-release-pc1-0.9.2-1.el7.noarch
puppet-agent-1.2.2-1.el7.x86_64

The problem doesn't occur if I create a dummy puppet user/group before running the manifest:

useradd -d /tmp/puppet -s /bin/nologin puppet

creating a puppetmaster when puppet client is already managed

I have something very similar to the following:

# this role is applied *globally*
class role::base {
  include 'company_puppet::base'
  # sshd config, system config, monitoring agents, etc
}

# this role is only applied to the puppetmasters
class role::puppetmaster {
  include 'company_puppet::server'
}

# straight forward: install puppet using theforeman/puppet-puppet and twiddle some settings for puppetctl
# https://github.com/theforeman/puppet-puppet
# https://github.com/mozilla-it/puppetctl
class company_puppet::base {
  class { '::puppet':
    runmode             => 'cron',
    cron_cmd            => 'if test -f /var/lib/puppet/state/disabled.at; then exit 0; else /usr/bin/puppet agent --onetime --no-daemonize --logdest syslog > /dev/null 2>&1 ; fi',
    show_diff           => true,
  }
}

# try and override our base class with additional parameters.
# instead, the "[master]" section of `/etc/puppet/puppet.conf` will be removed!
class company_puppet::server inherits company_puppet::base {
  Class ['::puppet'] {
    server                      => true,
    dns_alt_names               => ["puppet.${environment}"],
    server_storeconfigs_backend => 'puppetdb',
    server_environments         => [],
    server_template             => 'company/puppetmaster_server.conf.erb',
    server_facts                => false,
    server_foreman_url          => "https://foreman.${environment}",
  }
  # a bunch more uninteresting stuff goes here
}

the intent is that all hosts in the fleet receive role::base and then one or more "service" roles, like role::puppetmaster. I have been unable to get this to work using the theforeman/puppet-puppet module.

I know that Puppet inheritance is weird and limited, so I suspect what I'm doing may not be possible via this mechanism. there's a particularly disturbing note here: http://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#inheritance

Note: If a base class declares other classes with the resource-like syntax, a class derived from it cannot override the class parameters of those inner classes. This is a known bug.

I think I could solve this by using parameters in TheForeman, but I prefer to keep as much data in our roles as possible and use TheForeman for environment data (test vs prod).

Directory environments sub directory's should allow for condidtionally creation.

When you automatically create directories under $confdir/environments you break R10K's ability to create and populate those directories.

I used the following snippet to create my puppet server.

class { '::puppet':
server => true,
server_foreman => false,
server_reports => 'store',
server_external_nodes => '',
}
Then initialized R10K using Zack's R10K module. By default /etc/puppet/environment/production exists and contains a manifests & modules directory by way of your module, so when I run r10k deploy environment -pv it errors out with the following:
==> puppet.example.com: Command: git clone --reference /var/cache/r10k/https---github.com-gapotts-r10k-ctl-mmpup.git https://github.com/gapotts/r10k-ctl-mmpup.git /etc/puppet/environments/production
==> puppet.example.com: Stderr:
==> puppet.example.com: fatal: destination path '/etc/puppet/environments/production' already exists and is not an empty directory.
==> puppet.example.com: Exit code: 128

For those of us who plan on using R10K this will become problematic.

Regards -Greg

Service[puppet-run.timer]: Provider systemd is not functional on this host

On EL6, which doesn't have systemd, the puppet::agent::service::systemd class is included with a service resource that tries to use the systemd service provider, which fails:

# [ WARN 2015-11-25 07:35:06 verbose] /Stage[main]/Puppet::Agent::Service::Daemon/Service[puppet]/ensure: ensure changed 'stopped' to 'running'
# [ERROR 2015-11-25 07:38:22 verbose] /Stage[main]/Puppet::Agent::Service::Systemd/Service[puppet-run.timer]: Provider systemd is not functional on this host

(http://ci.theforeman.org/job/systest_foreman/8036/tapResults/)

Perhaps the default value of $::puppet::unavailable_runmodes should take into account which OSes are systemd-enabled?

Configuring fileserver.conf and auth.conf

Unless I missed something in code/docs, at a moment we are unable to edit fileserver.conf and file auth.conf is hardcoded in template/ .
The question is, is there any plans to make it configurable or it is like this for specific reasons?
Do we need PR for this?

Regards

Error shown on Windows nodes

On all my WIndows nodes I see the following on every run. I assume this is something coming over via module sync (or not coming over) that shouldn't.

PS C:\Windows\system32> puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error loading fact C:/ProgramData/PuppetLabs/puppet/var/lib/facter/facts.rb: cannot load such file -- util/sssd

Support for centos

I get the feeling (via some experience) that this package isn't fully configured to support centos. In particular (total hack, don't follow my example) I had to change "puppet-server" to "puppetserver" in a number of places to get puppserver to launch on centos.

If support is envisioned, let me know and I will get more particular about the suggested changes.

adding mac osx agent to puppet foreman

i just started using puppet with foreman. i could not find a source on the net to get help with add mac osx agent to puppet foreman. can someone provide information on this.

Key file ownership constantly changed

The puppet::server::config class manages the group for the host's private key. This also sets the owner to root by default. However, Puppet 3.7.1 (maybe older too?) sets it to puppet when starting.

This causes the ownership of the file to be changed for each run:

Notice: /Stage[main]/Puppet::Server::Config/File[/var/lib/puppet/ssl/private_keys]/owner: owner changed 'puppet' to 'root'
Notice: /Stage[main]/Puppet::Server::Config/File[/var/lib/puppet/ssl/private_keys/foo.example.com.pem]/owner: owner changed 'puppet' to 'root'

Major rewrite proposal

I'd like to suggest a major rewrite of this module like this.
It's IMHO cleaner, specially if you use data-binding.

class puppet(
  ...
  main_section_parameters_used_in_template,
  ...
  agent = false,
  master = false,
  conffile = '/etc/puppet/puppet.conf'
) {
  class { 'puppet::config': }
  if $agent { class { 'puppet::agent': } }
  if $master { class { 'puppet::master': } }
}

class puppet::config {
  Ini_setting {
    section => 'main',
    path    => $::puppet::conffile,
    ensure  => present,
  }
  ...
  if <param> != undef {
    ini_setting { "main_<param>":
      setting => <param>,
      value => <value>,
    }
  }
  ...
}
class puppet::agent(
  ...
  agent_section_parameters_used_in_template,
  ...
) {
  class { 'puppet::agent::install': } ->
  class { 'puppet::agent::config': } ~>
  class { 'puppet::agent::service': } ->
  Class['puppet::agent']

  Class ['puppet::agent::install'] ->
  Class ['puppet::config'] ~>
  Class['puppet::agent::service']
}

class puppet::agent::config {
  Ini_setting {
    section => 'agent',
    path    => $::puppet::conffile,
    ensure  => present,
  }
  ...
  if <param> != undef {
    ini_setting { "agent_<param>":
      setting => <param>,
      value => <value>,
    }
  }
  ...
}

class puppet::master(
  ...
  master_section_parameters_used_in_template,
  ...
  environments = {}
) {
  class { 'puppet::master::install': } ->
  class { 'puppet::master::config': } ~>
  class { 'puppet::master::service': } ->
  Class['puppet::master']

  Class ['puppet::master::install'] ->
  Class ['puppet::config'] ~>
  Class['puppet::master::service']

  create_resources(puppet::environment, $environments)
}

class puppet::master::config {
  Ini_setting {
    section => 'master',
    path    => $::puppet::conffile,
    ensure  => present,
  }
  ...
  if <param> != undef {
    ini_setting { "master_<param>":
      setting => <param>,
      value => <value>,
    }
  }
  ...
}

define puppet::environment(
  $modulepath  = undef,
  $manifest    = undef,
  $manifestdir = undef,
  $templatedir = undef,
) {
  Class['puppet::master::install'] ->
  Puppet::Environment[$title] ~>
  Class['puppet::master::service']

  Ini_setting {
    section => $name,
    path    => $::puppet::conffile,
    ensure  => present,
  }
  ...
  if <param> != undef {
    ini_setting { "${name}_<param>":
      setting => <param>,
      value => <value>,
    }
  }
  ..
}

Usage with databinding:


---
puppet::pluginsync: true
puppet::agent: true
puppet::agent::configtimeout: 300
puppet::master: true
puppet::master::ca: true
puppet::master::environments:
  stable:
    modulepath => '/srv/stable/modules'
  staging:
    modulepath => '/srv/staging/modules'
  dev:
    modulepath => '/srv/dev/modules'
include ::puppet

Usage without databinding:

class { 'puppet':
  pluginsync => true,
}
class { 'puppet::agent':
  configtimeout => 300,
}
class { 'puppet::master':
  ca => true,
  environments => {
    stable => { modulepath => '/srv/stable/modules', },
    staging => { modulepath => '/srv/staging/modules', },
    dev => {modulepath =>'/srv/dev/modules', },
  }
}

We could even have a puppet::user class for the [user] section of the inifile.
What do you think ?

Update puppet so that it easily be used to manage puppet agent.

Currently, puppet::config class isn't parametrized. This means it's not possible just to include that class independently of puppet::init.

It is also not possible to set the following agent properties:

  • pluginsync,
  • splay
  • runinterval

These additions would mean that this module could be used to manage both client and master puppet installations.

Some newer modules need Encoding UTF-8 enabled in rack server

If UTF-8 encoding is not enabled in the rack server's config.ru, it will fail to parse some newer puppet modules. These include the current stable modules in stackforge's openstack series of module.

The particular config option is

Encoding.default_external = Encoding::UTF_8

Config.ru templates missing

The class puppet::server::passenger attempts to setup rack config.ru on Lines 52-57.

However the template files don't exist in the module templates dir.

puppet.conf not readable by puppet

When the system umask is 077, the puppet.conf file is owned by root and has perms of 0600 so the foreman-proxy and puppet server can't read the puppet.conf file.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.