Satellite 6 - Adding an existing host with full management

Latest response

Following up from the discussion in the Satellite video thread:
https://access.redhat.com/discussions/1517523

I have a requirement to add RHEL hosts built outside of Satellite to the Satellite 6 server. Doing this for subscription manager services (eg. yum) is fairly straightforward and the host will be displayed under 'Content Hosts', but to get an existing server (that isn't provisioned through Satellite) to appear in 'All Hosts' to allow management with Puppet appears a little more involved.

As suggested in the linked thread above, I have investigated using the hammer-cli and API to carry out the add automatically but it appears there are still some gaps in the process, so would appreciate any input on your experiences/solutions.

The goal of this process:
1. Build host outside of Satellite
2. Register with Satellite for updates / package management
3. Register with Satellite to assign Puppet classes / remediate configuration

This is currently achieved with another product, but am looking to combine multiple products into Satellite 6. The steps listed here can be run from the freshly built host (and packages etc. cleaned up afterwards) or from an orchestration host.

Process:
1. Build standard RHEL X.x build

2. Install katello-ca package rpm from Satellite 6 server

rpm -ivh http://sat61b.network.local/pub/katello-ca-consumer-latest.noarch.rpm

3. Use subscription-manager to subscribe the system to Satellite 6 for packages / updates

subscription-manager register --username=admin --password=password --org=Default_Organization --auto-attach

At this stage the host will appear under Host -> Content Hosts on the Satellite 6 server.

4. Subscribe the host to the Satellite tools repo for installation of additional components

subscription-manager repos --enable=rhel-7-server-satellite-tools-6-beta-rpms

5. Install additional tools that are used for host creation/registration on Satellite 6 server

yum install -y facter katello-agent puppet rubygem-hammer_cli rubygem-hammer_cli_katello

6. Use the hammer CLI to create the empty host record on the Satellite 6 server (facter used to pull MAC). Note: to determine the numbers to pass in you need to call hammer against each item to determine the ID number it has been allocated eg. hammer environment list. This is a long command, scroll right to see the whole thing!

hammer  --server https://sat61b.network.local --username admin --password password host create --name "$(facter hostname) --environment-id 1 --architecture-id 1 --domain-id 1  --puppet-proxy-id 1 --operatingsystem-id 1 --partition-table-id 7 --location-id 2 --organization-id 1 --medium-id 7 --root-password "password" --mac "$(facter macaddress)" --build 0

At this stage you will now have a host record under 'All Hosts' matching the hostname of your new host.

7. Next, create a Puppet certificate signing request. You will need to modify the Puppet configuration file before running the following command, or alternatively pass the Satellite 6 hostname at the command line for the initial request.

puppet agent -t --server sat61b.network.local

The Puppet signing request will now be listed under Infrastructure -> Capsules -> Capsule Name -> Certificates

This is where the automated process falls down. I haven't been able to find a way for Hammer CLI or the API to sign the certificates remotely. Additionally, there doesn't appear to be a method to create Autosign entries using the CLI/API (this could be done after step 6). I have found an associated bug report here:
https://bugzilla.redhat.com/show_bug.cgi?id=1140671

Is anyone able to provide/suggest workaround? or a different method to do the scripted registration of existing hosts? Does anyone have a single line answer that makes all of the above look irrelevant?

Responses

For anyone that may be following this, I have persisted and got it working.
One critical item that I have added to the hammer command used at step 6. above is the

--build 0

I found that without this, it was extremely tedious to get the server out of the 'building' status (need to call URL with token so server is aware build is complete).

For Puppet, the workaround is to add a glob for the domain name for your domain as an autosign entry in your capsule configuration, eg:

*.network.local

This isn't exactly a solution but it is a workaround for non-interactive Puppet registration until autosign entry creation/removal is added to the hammer-cli.

wow, thanks for detailing this out fine sir ... I was just looking for EXACTLY the same solution ... Trying it out now.

Just a follow up ... AWESOME, it worked as advertised ... I did it on a RHEL5.11 system and it's now showing in All Hosts. This is definitely the kind of thing that should be covered in the docs because anyone coming from a non-satellite environment to Satellite will require this ability. Now to do it 3,000 more times ... yay.

Hi Sean,

Thanks for the feedback.

I am going to put it all into a script to streamline it. Luckily I only have about 500 hosts to do!

I have been working on a similar effort (my effort was initially focused at moving systems from Satellite 5 to Satellite 6), but should be easily adaptable to work for hosts provisioned outside of Satellite (which is your usage) . See github. PRs accepted :)

A couple of items worth noting.

  • in my script, I cheat a little bit. Instead of creating the host record (via hammer or the API), I install puppet and then issue a puppet agent -t, which creates the host entry and submits a cert request.

  • I think (and should probably confirm) that if you add autosign entries into autosign.conf, that they are respected.

  • I am a firm believer in not installing additional packages if I could avoid it, hence why the script is in python. (It could proably be ported to ruby if you need that)

Let me know if this gets you closer to your destination.

Thanks for the info Richard, I had a memory that just registering with Puppet didn't get the host in the same state under 'All Hosts', I will double check this.

It's correct that if you add entries to autosign.conf they are respected, but how are you updating the file on the capsule from a remote host / orchestration tool? Are you running the orchestration script off the capsule itself? The above method makes the assumption you are external to the capsule.

As for additional packages, currently only packages required to register the host are installed (facter is actually installed as a Puppet dep). The hammer related packages can be installed on the orchestration host and are not required on the host that is registering in Satellite, I have included both on the registering host to simplify my example (I should make note of that).

-edit-

I just went through the process without the 'hammer' command and my memory was correct, the host will register with Puppet and receive configuration but will only show up under 'Content Hosts' not 'All Hosts' unless the hammer cli or manual registration steps are completed.

This is showing on the client that it is correctly registered in Puppet.

[root@sat61bc3 ~]# puppet agent -t --server sat61b.network.local
Info: Retrieving plugin
Info: Caching catalog for sat61bc3.network.local
Info: Applying configuration version '1437778857'
Notice: Finished catalog run in 0.04 seconds

But this client is not listed under 'Hosts' -> 'All Hosts' in the Satellite Web UI.

The host ends up 'Any Context' /'Any Location' if you do not specify (and send a org/location fact). Switch to Any Context/Any Location and then go to 'All Hosts' and you should see your host. You can then assign an org/location in the UI. That doesn't work from an automation perspective, but that's why you don't see your host (yet it 'works')

You can set a default org/location for hosts that don't report it (such as those you are bootstrapping) under Administer->Settings->Puppet in the UI.

What I did in my script is make it mandatory to specify the org/location, as I make additional API calls to set the user-specfied org/location. (effectively what you did in your invocation of hammer).

The expected invocation of my bootstrap script is that it is copied from the Satellite to the client (via wget, curl, etc) and run locally on the client. In full disclosure, I haven't tested it with the overhauled 6.1 capsules, so there may be bugs there that I haven't accounted for.

Hi Richard, thanks for this post.. it includes some excellent information. I made the (poor) assumption that if you had a single organization configured, joins to Satellite would default to this organization rather than ending up unassigned.

One thing to note (that isn't clear) is that Administer -> Settings -> Puppet :: default_organization appears to only accept the Name of the Organization not the Label.

In hindsight, this part of the problem is probably better solved with an activation key so I am going to re-work my method to use that.

With regards to your posted script, I still don't see how the autosign problem is solved, unless the download of the script creates an autosign entry on the host (or are you assuming autosign is enabled for everything in the current domain like I have posted above?)

-edit-

Last question answered, found this in your assumptions
Autosigning is enabled for the system in question. (And be careful, auto-signing isnt one of those things you'd leave enabled forever)

Thanks Rich!

The hammer/api approach is REALLY convoluted way of getting hosts in. I appreciate the bootstrap script, but a simpler approach needs to be taken here, esp. when we are talking about migrating a few hundered or in some people's situations, 1000's of systems from RHN to Sat 6.

But I will test out the bootstrap on our side as well!

PS - Keep on Cookin!

So how can you add the organization and location in as puppet facts when running the 'puppet agent -t' command to create the host record?

How did you achieve this on RHEL5? I do not see rubygem-hammer_cli* packages in the Red Hat Satellite Tools 6.1 for RHEL 5 Server RPMs repos.

Zac,

Thanks for pointing this out, I haven't migrated any RHEL 5 hosts sorry (my sites using Sat 6 don't have RHEL 5).

Richard Jerrido mentions above that he uses a Python script with the API to achieve the same goal but avoids additional package installations, which may be an option.

Another option is to run the Hammer portions of the process from an orchestration node running RHEL6/7 (eg. with Ansible) or do all the creations as a batch on a RHEL 6 node... depending on how many RHEL 5 hosts you are dealing with.

Last option, you may be about to build the hammer cli / ruby packages for use in RHEL 5 (might be a bit much to just join a few nodes!), but this may cause other issues/conflicts with your installed packages and would be a little more involved.

Hi, thanks for the article.

One observation, with:
--server mysatellite.example.com

One will get: "Error: 301 Moved Permanently"

This will work:
--server https://mysatellite.example.com

Ref: https://projects.theforeman.org/issues/11147
hammer says "Error: 301 Moved Permanently" when you are missing "https://" in server option

Cheers.

Thanks Guillermo, that solved my problem.

Cheers,
Ahmed.

Hi, thanks for all comments. It's working except using DHCP clients. I'm getting a DHCP record conflict for this host. Of course the client got already an IP and hammer cannot create it again. Any idea?

Thanks in advance. Micha

Solved. I had to use --ip "$(facter ipaddress)" + --mac "$...

Thanks Guillermo,

I have updated the original post with this fix/workaround.

Thanks Richard, your article is really usefull.

Is there a way to do this without having to supply the system's root password in such plain view?

Zac,

The root password isn't supplied in any of the steps, are you referring to the Satellite admin password that is passed in steps 3. and 6.?

Ideally you're running these commands from some kind of orchestration tool/host not directly on the host being joined.

You can alternatively use an activation key.. which has a few minor quirks too (specifying location), but removes the requirement to pass the admin user. This is the method I am using now.

Step 6, "--root-password". That's the root password for the machine you're adding, right? This is a required value.

Hi Zac,

Sorry I missed that reference.

From memory this can be a dummy value as in this instance Satellite isn't provisioning the host/VM (and setting the root password) but it is a required field when making the blank host record ie. if you make this a random/dummy string it shouldn't affect the outcome.

Depending on what you are trying to achieve (ie. just patching, no Puppet), Activation Keys may achieve what you need (although from my experience you lose some configurability).

Pixel, how do you solve the "Location" issue? Also, do you know the use of specifying "activation key" when creating a "Host group". As far as I know the important thing is to specify the " --hostgroup-id" with "hammer host create" to make puppet work. What I mean is as far as I see specifying act key withing the host group does not change anything. Thanks in advance.

Hi Alpaslan,

You're in luck because I was working through this again today trying to get a better solution for Puppet machine registration (without using hammer at all).. but unfortunately activation keys aren't much good for Puppet... and Puppet generally in Sat 6.. is.. a lengthy process.

If you use activation keys, you can remove step 4. from my original steps as these channels (views) can be provided through the content view assigned in the activation key.

To solve location issue, you can generate a local 'fact' in facter on the host before registration. This fact is used when you register and needs to be called 'foreman_location'. A quick way to do this is to create bash script for the fact by doing the following (as root):

mkdir -p /etc/facter/facts.d/
echo '#!/bin/bash' > /etc/facter/facts.d/location.sh
echo 'echo foreman_location=mylocation' >> /etc/facter/facts.d/location.sh
chmod +x /etc/facter/facts.d/location.sh

You should be able to verify that the fact is then returning correctly in facter by using

# facter | grep foreman
foreman_location => mylocation

Make sure you do this before joining the Satellite. Please let me know if you get the result you're after.

Thanks a lot Pixel. That seems to be a good idea to solve the location issue. The trick is "how can we install the needed packages without registering with the Satellite first?"

Here is my customized version of the procedure which does not solve the location issue but automates the puppet client conf (the hostgroup should be created beforehand so that we can use the "--hostgroup-id" option - and the activation key too of course):

host# rpm -ivh http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm

host# subscription-manager register --org=Organization --activationkey=actkey

host# yum install -y facter katello-agent puppet rubygem-hammer_cli rubygem-hammer_cli_katello

host# echo "server=satellite.example.com" >> /etc/puppet/puppet.conf

host # hammer --server https://satellite.example.com --username admin --password redhat host create --name "$(facter hostname)" --environment-id 14 --architecture-id 1 --domain-id 1 --puppet-proxy-id 1 --operatingsystem-id 1 --partition-table-id 7 --location-id 2 --organization-id 9 --medium-id 8 --root-password "any_string" --mac "$(facter macaddress)" --build 0 --hostgroup-id X

satellite# cat /etc/puppet/autosign.conf

servera.example.com

host# puppet agent -t

host# systemctl enable puppet

host# systemctl start puppet

This has helped me considerably over the last week, thanks v.much :-)

QQ - I've been able to automate setting the location by adding foreman_location=mylocation to a file in /etc/facter/facts.d but can't set hostgroup by using foreman_hostgroup=myhostgroup. Any idea how to set hostgroup without using hammer?

TIA Steve

Once you have the Puppet agent registered the next challenge is configuring the Puppet environment. This can be straightforward (setting the puppet environment in the local puppet.conf) but the process changes depending on how you are using Puppet with Satellite 6.

From my experience, there appears to be two distinct methods when it comes to using Puppet with Satellite 6, a more traditional method that is similar to how I have seen Puppet Enterprise used in the past, and the Content View method which is what appears to be used in most (not all) Red Hat documentation.

In the traditional method, you store your Puppet configuration in VCS and check it out to an environment directory under the following path (this is manually managed using your VCS on the Satellite server)

/etc/puppet/environments

eg.
/etc/puppet/environments/production

In its simplest form, this method has a single environment 'production'. If all you are doing if using this single environment 'production', the Puppet registration doesn't need to be modified because Puppet will default to the 'production' environment. To extend this slightly, you may have multiple branches/tags for your environments in your VCS, and then check these out separately to your Satellite server, the result being environments such as:

/etc/puppet/environments/development
/etc/puppet/environments/test
/etc/puppet/environments/production

These environments can then be imported into your Satellite configuration by using Configure -> Environments -> Import from satellite.example.com

To assign your newly registered hosts to these environments, you can change the 'environment' option locally in puppet.conf on the host you are registering against Satellite before the first Puppet run (puppet agent -t). Alternatively, you can modify the host's environment on the Satellite server by joining a host group that specifies the 'Puppet Environment' (Note: this is very different to Lifecycle Environment). You can also use the host groups to define 'roles' by assigning Puppet Classes from the selected environment (how/if you implement the role/profile model is up to you).

I find the Content View method of Puppet integration a little more involved. It requires the following steps to get your Puppet content into the Satellite server:

1. Create a new product in Content -> Products
2. Create a puppet module repository in this product by selecting Repository -> Create Repository
3. Upload your Puppet module bundles (tgz) files through the web interface or by using hammer
4. Create a Content View that includes the Puppet content from the Puppet product/repository (choosing versions) in Content Views -> Create New View
5. Publish the Content View to the Library 'Publish New Version'
6. Promote the Content View to a Lifecycle Environment

At this point Satellite creates a new Puppet environment with a 'KT' (katello) prefix in the following location:

/etc/puppet/environments/KT_<Organization>_<LifecycleEnvironment>_<ContentView>_<IncrementingNumber>

This is essentially a Content View specific Puppet environment (takes a snapshot/copy of the Puppet modules at a point in time). The issue I am seeing at the moment is that it's difficult to get a new Puppet registration to pick up this Content View based Puppet environment name. Even though you select a 'Content View' in the activation key and the Content Host registration joins this Content View correctly, this doesn't change/configure the host's Puppet Environment configuration under All Hosts -> Edit -> Host tab. In fact, this configuration section is completely blank. Through the UI you can select the option 'Reset Puppet Environment to match selected Content View' but I haven't found a straightforward way to replicate this functionality (there is probably a hammer command for this).

For the time being I am managing Puppet using environments I define manually in /etc/puppet/environments so it's just a matter of configuring the environment in puppet.conf at time of build and then configuration is applied for the correct Puppet environment at first Puppet run (puppet agent -t).

I am interested to hear how others are using the Puppet integration and automatically registering their hosts to pick up configuration + yum repositories at time of build without any manual interaction.

Hello, not sure if you have solved it but, there is s

When I add an Rhel 5 host that was built outside of sat server 6. I get the message "No Products Available"

Marcel: https://access.redhat.com/solutions/100423

I am getting this error message when I run the command. Any ideas?

Could not create the host: ERROR: insert or update on table "hosts" violates foreign key constraint "hosts_medium_id_fk" DETAIL: Key (medium_id)=(7) is not present in table "media".

Okay, this explains a lot...

Running into the following attempting to implement this solution:

[root@sabre01 ~]# yum install rubygem-hammer_cli rubygem-hammer_cli_katello Loaded plugins: package_upload, product-id, security, subscription-manager rhel-5-server-rpms | 2.1 kB 00:00
rhel-5-server-satellite-tools-6.1-rpms | 1.8 kB 00:00
Setting up Install Process No package rubygem-hammer_cli available. No package rubygem-hammer_cli_katello available. Nothing to do [root@sabre01 ~]# subscription-manager repos --list +----------------------------------------------------------+ Available Repositories in /etc/yum.repos.d/redhat.repo +----------------------------------------------------------+ Repo ID: rhel-5-server-rpms Repo Name: Red Hat Enterprise Linux 5 Server (RPMs) Repo URL: https://satellite6.solipsys.com/pulp/repos/Solipsys/Library/rhel-5/co ntent/dist/rhel/server/5/$releasever/$basearch/os Enabled: 1

Repo ID: rhel-5-server-satellite-tools-6.1-rpms Repo Name: Red Hat Satellite Tools 6.1 (for RHEL 5 Server) (RPMs) Repo URL: https://satellite6.solipsys.com/pulp/repos/Solipsys/Library/rhel-5/co ntent/dist/rhel/server/5/5Server/$basearch/sat-tools/6.1/os

Enabled: 1

facter katello-agent and puppet install without issue.

Seems those packages are not available on Red Hat 5.

The command line tools such as hammer are only available on RHEL 6 and 7.

Doh, just re-read the entire comment stream and noticed that along with the proposed work-arounds.

can you please confirm: WHEN DELETING A HOST, do I have the backward process exactly ? 1- remove puppet certificate 2- delete host 3- unregister or id does not matter ?

When I attempt to register to puppet I get the following error:

puppet agent -t --server sat6server

Exiting; no certificate found and waitforcert is disabled

Dane,

This is normal behaviour, and on first attempt to connect a CSR (certificate signing request) will be generated on the server. This CSR will then need to be signed, and the client will need to be re-run and Puppet will then work as expected.

The alternative to this process is to enable autosigning on the server.

I you get this error: puppet agent -t --server sat6server Exiting; no certificate found and waitforcert is disabled

then you can do: -on master: add in:

/etc/puppet/puppet.conf
 [main]
 certificate_revocation = false

-on client:

rm -rf /var/lib/puppet/ssl/*
 puppet agent -t --server sat6server 

and certificate will be regenerated...So you can sign cert on Satellite UI

A variant use-case : I want to create a "bare metal" VMWare VM outside of Satellite (due to more options available). From this thread, I think I can add a host record using a similar "hammer host create . . . build=0" command. Now for the question : How might I initiate provisioning on the VM ?

I'm trying to add hosts to satellite puppet that were not provisioned from satellite via a script I can give my local admins. I'm trying to do this without exposing a hammer command in the script with a satellite account/password. So far I'm able to join satellite and puppet, but it's not dropping into the correct org and environment. It places the host in the any host list as having no org and the default "production" environment. It doesn't appear to look at the org that the host is subscribed to. Is there a way to manually join a host to the puppet part of satellite via the command line or puppet.conf without using a hammer command? I am setting my environment in the puppet.conf file, but that does not set the org. I don't want to have to pre-populate satellite via the hammer command.

Is this possible?

You can specify which organization, location and puppet environment that unknown hosts are placed in if they do not report those facts. See Administer -> Settings -> Puppet and see the following settings

Default location
Default organization
Default Puppet Environment

This will allow you to configure puppet.conf and just run a puppet agent -tv to enroll them. Alternatively (and this is my preference), use the bootstrap script to register hosts not provisioned via Satellite.

I don't want to set the default since I have more than one organization. Is the bootstrap method something that's run on the host being added? I wonder if there is a way to preload satellite with the hostname/org/location/environment of a list of hosts prior to provisioning them, such that when I set up the /etc/puppet.conf and run "puppet agent -t" it drops into the correct org/environment?

I've set my capsule up to autosign.

My requirements are that the local admins will not get access to satellite server (I'm on 6.1.9) nor a satellite admin account. They can have access local admin to the capsule. So I've setup unattended via PXE boot on the capsule to allow for provisioning. they can provision and via keys register into the correct patch life cycles.

Thanks

Correct. Bootstrap runs on the host being added. You can scope the permissions of the user account being used by the bootstrap script to be minimal. (Basically, view and add hosts)

If you need to not allow users even those permissions, you can precreate the host entry using any supported method:

  • the UI (under Hosts->New Host)
  • the CLI (hammer host create).
  • the API (a POST to /api/hosts)

In the original post, the hammer CLI tools were installed on the individual clients as they were being added. You can use that method, but that requires the person adding the client to have some level of credentials. It is an identical workflow that the bootstrap script uses.

(_....as an aside...)_Early in the development of bootstrap, we debated on whether to write the script in Ruby (or install hammer as above). We opted not to so as to not install packages unnecessarily. (It is also why we use python-urllib to connect to the API in lieu of python-requests - it is on *every* RHEL system).

For your usage (not wanting to give your admins credentials in Satellite, but allowing them to register systems for both puppet and content), I would suggest the following:

  • use hammer host create from Satellite (or your admin workstation that you've installed hammer on) to precreate the host entry, associated with the correct hostgroup, organization and location. This will ensure that the host record is where you need to it to be.
  • give the local admins an activation key to register via subscription-manager that provides access to a subscription AND a Content VIew that provides the satellite-tools repo.

Their workflow is:

  • Install the katello-ca-consumer-latest RPM from their Satellite or Capsule.
  • Register via subscription-manager.
  • Enable the satellite-tools repo (if your activation key isn't configured to do it, or if your version of subscription-manager is < 1.10
  • yum install puppet katello-agent
  • Configure puppet.conf
  • Run puppet puppet agent --test --noop --tags no_such_tag --waitforcert 10
  • Celebrate!!!
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.