What is your client registration method (bootstrap or kickstart script)?

Latest response

I was curious what method people use to register their clients to their Satellite?

I currently use a fairly "vanilla" kickstart profile (with all of the registration stuff removed) and then have a more robust bootstrap.sh which allows me to register using an activation key based on a section of the hostname (dev vs prd vs tst, etc...)

I am also wondering whether people actually use the kickstart functionality of the Satellite, or simply use the Satellite server as the distribution URL and kickstart config.

Thanks!

Responses

Most of our Linux systems are VMs. Much of the customization - of which registration is a part - is done via a run-once type of script placed into the VM's first-boot startup.

In our environment, configuration management is multi-platform done via "one ring" kind of provisioning and patching application. Satellite is used simply as a yum repository rather than a provisioning-source.

We either use a kickstart via the Satellite server, or a bootstrap script set to the proper Satellite server and proper activation key

I am currently using the kickstart functionality of Satellite with PXE boot etc. Previous places I have booted off ISOs of media (because of restricted control over the network) and then kickstarted off the Satellite server.

To be honest now though, I have moved about 95% of the host configuration into puppet, so the process looks like:
1. PXE boot from network and kickstart off Satellite server.
2. Satellite installs base OS and registers new host / subscribes to configuration channel.
3. Configuration channel works as version control (and profile management) for puppet manifests and provides new host specific manifests for build. Activation key determines which manifests are deployed.
4. Configured puppet manifests are pulled down by the new host in post ks and it configures itself using masterless puppet (ie. no puppet master / infrastructure required)

PixelDrift,

I've never used Puppet, your 3rd point above, do you use your Satellite configuration channels along with or in tandem with Puppet? (do they somehow talk with each other with your instantiation?). Are some of your configuration channels actual Puppet Manifests?

The tiny bit I've read shows Puppet as rather powerful.

Thanks,
Remmele

I have now configured it to the point that configuration channels only contain puppet manifests, no direct files on the filesystem are managed in Satellite anymore.

This way other admins can use Satellite as per usual (associating configurations with hosts) but puppet does the heavy lifting with the actual host configuration and is more robust for modifying files, managing local users, dynamic config file settings and ensuring things like packages are installed and services are set to start on boot and are running when puppet runs/checks.

I was getting frustrated with the lack of kickstart snippet version control in Satellite and the clunky "make a script, deploy it to servers, run remote command" approach that Satellite kept forcing me down.

Interestingly Red Hat appear to be going with Puppet in Satellite 6.. so I can only assume they came to a similar conclusion re: Satellite configuration management.

I am surprised the link you provided doesn't explore the idea of using both... I find it works extremely well!

Thanks, I appreciate the reply, it seemed from that article that it was a 'tip of the iceberg'.

Do you use or prefer the enterprise version of Puppet (or is it needed in a large environment) over the non-enterprise version?

Haven't used Puppet Enterprise in this configuration because there was no desire to run a Puppet central server, it is basically being used to extend satellite configuration management capability.

Think of it like installing any other language interpreter. You install the Puppet packages so it can interpret the puppet manifest files locally, don't even deamonise Puppet on the hosts (it's executed through cron to keep complexity down). The cron (in essence) just runs 'puppet apply local.manifest.file.pp'

Packages are available from here:
http://yum.puppetlabs.com/el/

You can import/sign the base packages + deps into a custom channel and deploy during base build (unfortunately won't be supported by Red Hat).

I have also built additional RPMs for some of the modules (stdlib and firewall) to add capability as I didn't want hosts fetching modules from the Internet.

The configuration management tool doesn't necessarily have to be Puppet, you can use whatever tool can interpret manifest/configurations locally and get the same results.. some other options are Chef, CFEngine etc.

I have previously used a similar local Puppet (masterless) configuration to deploy hosts in OpenStack and AWS using git/svn as the version control for manifests, so for me the choice of Puppet was based on previous (positive) experience, not because of any specific interoperability with Satellite.

PixelDrift,

Thanks very much for the details there, Puppet sounds worthwhile to examine - I will check it out.

Thanks again,
Remmele

In the last Red Hat Summit 2014, the presentation "moving from Sat 5 to Sat 6" did mention that there will be some transition best Practice Guides for : Satellite 5 coreSOE, Satellite 5 and Puppet, Satellite 6 coreSOE
When are these going to be available, I could not seem to locate them

Hope this helps: