Custom Razor post-install scripts without Puppet: is my method OK?

[Robroy Gregg]

Fellow Razor users,

I'd like Razor to run some custom post-install commands on a computer. 

I gather that when using Puppet, the right way's to configure a "broker" that attaches Razor to Puppet, and have Puppet handle post-install actions--yet I'm not using Puppet.

I've figured out a way that works, yet I suspect that the way I'm doing it may not reflect best practices.  I'd like to do this as cleanly and correctly as possible (that is, without Puppet being in the picture).

Here's how I'm doing it.  The end result of this customization's to leave an empty "/T5K_is_Glorious" file on the computer post-install.

# razor create-broker --name a --broker-type noop

# razor create-repo --name a --iso-url file:///tmp/rhel-server-7.4-x86_64-dvd.iso --task redhat/7

# cd /opt/puppetlabs/server/apps/razor-server/share/razor-server/tasks

# mkdir redhat-c.task

# cd redhat-c.task

# ex metadata.yaml
"metadata.yaml" [New File]
Entering Ex mode.  Type "visual" to go to Normal mode.
:i
os_version: 7
label: Red Hat Enterprise Linux 7
description: Red Hat Linux 7 Customized post-install
base: redhat/7
.
:x!
# pwd
/opt/puppetlabs/server/apps/razor-server/share/razor-server/tasks/redhat-c.task
# cp ../redhat.task/post_install.erb .
# ex post_install.erb
"post_install.erb" 24L, 659C
Entering Ex mode.  Type "visual" to go to Normal mode.
:%#
      1 #!/bin/bash
      2
      3 exec >> /var/log/razor.log 2>&1
      4
      5 echo "Starting post_install"
      6
      7 # Wait for network to come up when using NetworkManager.
      8 if service NetworkManager status >/dev/null 2>&1 && type -P nm-online; then
      9     nm-online -q --timeout=10 || nm-online -q -x --timeout=30
     10     [ "$?" -eq 0 ] || exit 1
     11 fi
     12
     13 <%= render_template("set_hostname") %>
     14
     15 <%= render_template("store_ip") %>
     16
     17 # @todo lutter 2013-09-12: we should register the system with RHN; be
     18 # careful though, since this file is also used by the CentOS installer, for
     19 # which there is no RHN registration
     20
     21 <%= render_template("os_complete") %>
     22
     23 # We are done
     24 curl -s <%= stage_done_url("finished") %>
:22i
touch /T5K_is_Glorious
.
:x!
# razor create-policy --name a --repo a --task redhat-c --broker a --enabled --hostname funmax --root-password DuckMax --max-count 20

I'd really appreciate some feedback on whether this approach is good (or horribly wrong).

Thanks so much!
Robroy

[Scott McClellan]

Hi Robroy,

tl;dr: I suggest making a new broker in /etc/puppetlabs/razor-server/brokers. Details about why are below.

The approach you took has the right idea, and there are a few different ways in Razor to achieve the desired outcome.

The key question is whether the file creation (in the sample case you described) is more a part of the installer (you wouldn't want to install the OS without the file being created) [this would be a new Task], or a part of the code that runs after, say, various OSes complete installation [this would be a new Broker].

My impression is that it probably makes more sense to do this in a broker, since it's code that runs after the installation is complete. Take a look at some of the brokers we have listed here:

https://github.com/puppetlabs/razor-server/blob/master/brokers

In particular, the `noop` broker is a good starting point. All this broker does is report back to the server that the install is done:

https://github.com/puppetlabs/razor-server/blob/master/brokers/noop.broker/install.erb

Brokers in general are just code that triggers something to happen after the actual OS installation is complete. The `noop` broker-type does nothing, the `puppet` broker-type installs FOSS puppet, the `puppet-pe` broker-type installs PE puppet, etc. If you're using a different config management solution, I'd suggest creating a new broker-type.

Another best practice that seems valuable to mention is we generally avoid modifying the tasks, brokers, and hooks in /opt since that prevents future upgrades to those. If you want to take everything from one task but just override one file in it, there's a way to inherit from an existing task too, allowing you to modify just that one file.

Instead, I suggest looking in /etc/puppetlabs/razor-server/brokers and making the change (probably creating the path /etc/puppetlabs/razor-server/brokers/<name>.task). Doing this will allow you to reference <name> as a broker-type when you're creating a broker instance (in the `create-broker` command).

Hope that helps! Let me know if you have any other questions.

Scott

On Tue, Nov 14, 2017 at 6:00 PM Robroy Gregg <robroy...@bigbuckingunicorn.com> wrote:

--

-- 

PuppetConf 2016, 19 - 21 October, San Diego, California

Register to attend or sign up to view the Live Stream