In part 1 we discussed the prerequisites required to get Redhat Satellite 6.2 ready as a provisioning platform. Although there were quite a few tasks, as previously mentioned, in the main these are a one off activity and once set up, make provisioning hosts a quick and easy operation.
I had some great feedback from part 1 which was much appreciated. In particular Rich Jerrido from Redhat, ohples and bippity12 via Reddit all of whom pointed out that it’s not necessary to set up Satellite as a DHCP server if you’re relying on external DHCP servers. I tried out their suggestions and they are indeed correct.
So, bearing this in mind, I updated my configuration from part 1 as follows. First I disabled DHCP on the Satellite server:
This week I’m looking at provisioning with Redhat Satellite 6.2. Redhat Satellite 6 has become a bit of a lumbering beast. It does a lot of stuff but it’s not as straight forward as the old versions. Whilst patching remains probably the key function, the provisioning tools are quite powerful. I’ve been investigating this over the past few weeks. Here’s what I found out.
One of the first thing I discovered was that although RedHat have produced quite a bit of documentation for Satellite 6.2, because it’s become quite complex, there’s still bits missing. Hopefully this article will help you with the missing bits. So, on the provisioning side, Satellite can build VMs, including the VM definition itself, act as a DNS source or update DNS, act as a DHCP server, act a tftp server and a puppet server. These parts I have tested. It can also provision to AWS and Docker containers. These remain to be tested (but will be once I have a suitable test environment). The aim of Satellite provisioning is to supply more or less push button building of servers, VMs and presumably AWS EC2 instances and Docker containers. To achieve this, quite a lot of upfront configuration of Satellite is required, so let’s take a look at the prerequisites.
The following Satellite components need to be set up for efficient Satellite provisioning. Although they do not all need to be in advance and it may seem like a lot of work to set up everything, setting up these prerequisites is pretty much a one off activity. As also mentioned it also greatly speeds up and simplifies the actual deployment process.
- Lifecycle environment: A logical way of dividing up hosts depending on the type of environment they serve, e.g. development, user testing and production
- Content View: a subset of the Satellite content, e.g. packages and puppet modules . This will built from specified yum repositories, which may be the RedHat repositories provided by Satellite or custom (see Creating a repository and adding it to a content view). You can also add puppet modules to the content view to make those available.
- Puppet Environment: Satellite can act as a puppet master and creates its own Puppet environments when you import Puppet modules into Satellite (see Setting up Puppet for Satellite)
- Content Source: these are created when Satellite is installed and will either be the Satellite server itself (via an internal capsule) or other capsules.
- Subnets: These define subnets, VLAN IDs and boot modes for Satellite
- Compute Resource & Compute Profile: For VMs, these define the vCenters and the parameters supplied to VMWare to create the VM, e.g. number of CPUs, memory, etc.
- Host Group: All of the above can be added to a Host Group so that when the Host Group is selected, the new host form is auto populated with the correct details.
Yes, I’m jumping on the, “it’s 2017” band wagon so a slightly belated Happy New Year to you all. This edition of the JustSomeStuff blog is about nothing in particular, just me waffling on about recent updates and what we have planned for the year ahead. I think I’m supposed to say what an incredible year 2016 so, 2016 was an incredible year. Not only did it come straight after 2015 but it was immediately before 2017. And so, with that out of the way, here’s just some stuff.
First off, wiki updates. Despite some scepticism. through countless hours of toil and stress, we’ve managed to keep this invaluable resource (to us anyway) up to date. Ok, the fact is we actually don’t mind doing it and, for us, it’s a frequent reference source. Not only have we kept the wiki up to date but there’s also been quite a few new articles since my last update in June .
In the ever expanding Linux section the following articles have been added:
Continuing on from our previous post where we covered systemd and journald, we continue our discovery of the new features of RedHat Enterprise Linux 7.
RedHat EL 7 – Networking
This is a bit of a something about nothing story. There is a new networking service called NetworkManager . There’s also a bunch of new ways to control and configure NetworkManager. These include nmcli, nmtui, control-center (gnome) and nm-connection-editor. As the names suggest, they go from command line, menu driven to GUI based configuration options.
I’ve been struggling to understand what the benefits of this new service are. I found this on the RedHat customer portal “NetworkManager is a suite of cooperative network management tools designed to make networking simple and straightforward by eliminating the need to manually edit network configuration files by hand“. Doesn’t that sound lovely. The problem is that trying to change a setting using nmcli is way more complicated than editing an ifcfg file (which is still supported), so like I said, I don’t get it.
One other thing is that there is a new type of bonding called Network Teaming. This is supposed to have a lower overhead than it’s predecessor and “it’s modular design can be interacted with via an API” . Very useful to API fans everywhere I’m sure. As ever, more details on our wiki page .
I know what your thinking, “come on man, RedHat EL 7 has been out for nearly two freaking years now, get up to date”. Well, if you’re already familiar and using RedHat EL 7, please feel free to go back to watching clips of flower arranging on Youtube or whatever it is you normally do when you’re not reading tech blogs.
OK, now we’ve got rid of the too-kool-for-skool-I’ve-got-a-selfie-with-Linus-Torvalds brigade, I’ll continue. If, like me, you work in an enterprise IT environment, you’ll understand that the pace of change can be a little slow (unless it’s a change requested by a senior manager, then it’s warp factor 8). I suspect that many of you are only just starting to roll out RHEL 7. This is the situation I found myself in. I’d also heard stories about it being different. So I decided I better find out what had changed. The problem was that all I could initially find were sites with a summary of the new features but not much detail or links to paid courses (I did later find some good resources but I still haven’t found a single site covering all of what I wanted to know). So I decided to find out for myself and document what I found. In other words, I’ve read the manuals so you don’t have to! Aren’t I a lovely bloke!
This blog is an overview of the new features. For a more technical perspective with the commands and examples, see this article in our Unix & storage wiki .