Puppet Enterprise (Public)

OK I should clarify this somewhat. There is the —installer-payload parameter, but the Puppetmaster/Console should store the payload internally and use this by default. It seems less than friendly to insist on a tarball to be located when the remote installer should be able to bootstrap the process itself.

Furthermore, even when the installer payload is supplied, it still seems to go to the internet:

[root@puppetmaster manifests]# puppet node install -l root --keyfile ~/.ssh/id_rsa puppetclient.localdomain --installer-payload=/vagrant/puppet-enterprise-2.0-all.tar.gz  --debug
notice: Waiting for SSH response ...
info: Executing remote command ...
debug: Command: date
debug: Fri Jan 13 16:16:33 UTC 2012
debug: SSH Command Exit Code: 0
info: Executing remote command ... Done
notice: Waiting for SSH response ... Done
info: Executing remote command ...
debug: Command: bash -c 'umask 077; mkdir /tmp/50374290-8c29-edd0-ac6a-bb05c1f26798'
debug: SSH Command Exit Code: 0
info: Executing remote command ... Done
notice: Uploading Puppet Enterprise tarball ...
notice: Uploading Puppet Enterprise tarball ... Done
notice: Installing Puppet ...
debug: Compiled installation script:
debug: #!/bin/bash
# This script is intended to be used with the install action
# of puppet-cloudpack

set -u
set -e

function rpm_install(){
  # Setup the yum Puppet repository
  cat >/etc/yum.repos.d/puppet.repo <<'EOFYUMREPO'
[puppetlabs]
name = Puppetlbas
baseurl = http://yum.puppetlabs.com/el/$releasever/products/$basearch/ 
gpgcheck = 1
enabled = 1
gpgkey = http://yum.puppetlabs.com/RPM-GPG-KEY-puppetlabs
EOFYUMREPO

  # Install Puppet from yum.puppetlabs.com
  yum install -y puppet
}

function apt_install() {
  # Download and install the puppetlabs apt public
  apt-key adv --recv-key --keyserver pool.sks-keyservers.net 4BD6EC30
  
  # We need to grab the distro and release in order to populate
  # the apt repo details. We are assuming that the lsb_release command
  # will be available as even puppet evens has it (lsb_base) package as
  # dependancy.
  
  # Since puppet requires lsb-release I believe this is ok to use for
  # the purpose of distro and release discovery.
  apt-get update
  apt-get -y install lsb-release
  distro=$(lsb_release -i | cut -f 2 | tr "[:upper:]" "[:lower:]")
  release=$(lsb_release -c | cut -f 2)
  
  # Setup the apt Puppet repository
  cat > /etc/apt/sources.list.d/puppetlabs.list </etc/puppet/puppet.conf <<'EOFPUPPETCONF'
[main]
  logdir = /var/log/puppet
  rundir = /var/run/puppet
  vardir = /var/lib/puppet
  ssldir = $vardir/ssl
  pluginsync = true
  report = true
  server = puppet
  environment = production
  
  certname = puppetclient.localdomain-b97da23c-51a4-93f3-ecb8-bd3c43ecff0f
  
EOFPUPPETCONF

  if [ -f /etc/default/puppet ]; then
    cat > /etc/default/puppet < Running transaction check
debug: ---> Package puppet.noarch 0:2.7.9-1.el5 set to be updated
debug: --> Processing Dependency: ruby(abi) = 1.8 for package: puppet
debug: --> Processing Dependency: facter >= 1.5 for package: puppet
debug: --> Processing Dependency: ruby >= 1.8.1 for package: puppet
debug: --> Processing Dependency: ruby-shadow for package: puppet
debug: --> Processing Dependency: ruby-augeas for package: puppet
debug: --> Processing Dependency: /usr/bin/ruby for package: puppet
debug: --> Processing Dependency: libselinux-ruby for package: puppet
debug: --> Running transaction check
debug: ---> Package facter.noarch 0:1.6.4-1.el5 set to be updated
debug: ---> Package libselinux-ruby.x86_64 0:1.33.4-5.7.el5 set to be updated
debug: ---> Package puppet.noarch 0:2.7.9-1.el5 set to be updated
debug: --> Processing Dependency: ruby-shadow for package: puppet
debug: --> Processing Dependency: ruby-augeas for package: puppet
debug: ---> Package ruby.x86_64 0:1.8.5-19.el5_6.1 set to be updated
debug: ---> Package ruby-libs.x86_64 0:1.8.5-19.el5_6.1 set to be updated
debug: --> Finished Dependency Resolution
debug: puppet-2.7.9-1.el5.noarch from puppetlabs has depsolving problems
debug:   --> Missing Dependency: ruby-shadow is needed by package puppet-2.7.9-1.el5.noarch (puppetlabs)
debug: puppet-2.7.9-1.el5.noarch from puppetlabs has depsolving problems
debug:   --> Missing Dependency: ruby-augeas is needed by package puppet-2.7.9-1.el5.noarch (puppetlabs)
debug:  You could try using --skip-broken to work around the problem
debug:  You could try running: package-cleanup --problems
debug:                         package-cleanup --dupes
debug:                         rpm -Va --nofiles --nodigestThe program package-cleanup is found in the yum-utils package.
debug: SSH Command Exit Code: 1
info: Executing remote command ... Done
err: The installation script exited with a non-zero exit status, indicating a failure.  It may help to run with --debug to see the script execution or to check the installation log file on the remote system in /tmp/50374290-8c29-edd0-ac6a-bb05c1f26798.
err: Try 'puppet help node install' for usage

You’re using the default install script which installs open source puppet and not Puppet Enterprise. You’ll need to specify to use the —install-script=puppet-enterprise parameter in conjunction with the payload parameter.

@Carl – I wasn’t aware that was even an option. The help text only shows the alternatives between gem and puppet-enterprise so I assumed it would default to the system I’m using – puppet-enterprise. The third option for puppet-community is not mentioned anywhere I can find. Even the web docs at http://docs.puppetlabs.com/pe/2.0/cloudprovisioner_man_node.html don’t mention a third option. Surely this should not even enter into the equation when a tarball is explicitly provided anyway?

@Nigel – I’m not sure I’ve thought that far ahead yet. Our current mechanism for installing is doing it through the kickstart process but I’m reporting bugs as I go during my PE evaluation. Aside from that I don’t think it’s appropriate to do anything about the client config when using “puppet node install”. On the other hand it seems to make sense when doing a “puppet node init” as that should give the system enough information to figure out what kind of client config should be provisioned.

Longer term we are absolutely heading in a direction to make new agent installation much simpler and more easily driven from a central location. Look for a proposal to be coming out around “Puppet Sites” in the next month.

I’d like us to unpack this report a little more.

It sounds like we’ve got a documentation bug, and some minor bugs around allowing non-tarball based distribution methods when a tarball is specified? Is that right?

Just to add my comments to this ticket. Nigel, do you think this is a separate ticket or not?

I’d like to do this immediately after installing PE on platforms that support online repositories: puppet resource package pe-ruby-devel ensure=installed

I want to do this to get Gem’s installed.

I think I may have already filed a ticket on this, but this came up first in the search. Maybe because it’s more recent.

-Jeff

Can you unpack this a little more Jeff? Is this centered around PE having a role that is the “repository server” ?

Nigel Kersten wrote:

Can you unpack this a little more Jeff? Is this centered around PE having a role that is the “repository server” ?

No, this is just me trying to do my thing.

As a developer of Puppet Enterprise I want to run inside of ruby-debug

So that I can interactively debug puppet

I want to have the ruby development headers installed

So that I can install ruby-debug

Right now, to satisfy these wants I have to go look for the package and manually install it with dpkg or rpm. I can’t use apt or yum and the ruby development headers aren’t in any online or offline repository anywhere.

Specifically, writing a module to do this is ridiculously hard because there aren’t any repositories with the ruby development headers anywhere.

Nigel Kersten wrote:

Can you unpack this a little more Jeff? Is this centered around PE having a role that is the “repository server” ?

I guess the answer is actually yes, I guess this would need the PE packages hosted in a repository.