Using hammer to apply errata by type?
Howdy,
Looking at the hammer host errata apply --host (host) I see you only have options to list out the errata ID's to install. Would/could there be an option to apply the errata by type; such as enhancement, bugfix, security? Even better, just an option to apply all available errata :)
Thanks!
Responses
You can't do this with the "host errata apply" command by itself but you can do this with a combination of bash commands.
So to apply all applicable errata to a host, use the following command:
ERRATUM_IDS=$(hammer --csv host errata list --host host.example.net | sed '1d' | cut -d ',' -f2 | paste -s -d, -) ; hammer host errata apply --host host.example.net --errata-ids $ERRATUM_IDS
To break it down:
- hammer --csv host errata list --host host.example.net creates a CSV list of all applicable errata for a host
- sed '1d' removes the headers from the CSV list
- cut -d ',' -f2 cuts out column 2 (the errata IDs)
- paste -s -d, - reformats the errata IDs to their own CSVs
- ERRATUM_IDS is the variable which we store the errata ID CSVs
- hammer host errata apply --host host.example.net --errata-ids $ERRATUM_IDS applies the CSV of errata IDs to the host
You can also specify which type of errata to apply by adding --search 'type = security' to the first hammer command. So for example, the following command only applies security errata to the host:
ERRATUM_IDS=$(hammer --csv host errata list --host host.example.net --search 'type = security' | sed '1d' | cut -d ',' -f2 | paste -s -d, -) ; hammer host errata apply --host host.example.net --errata-ids $ERRATUM_IDS
For ease of use, you could also use this method in it's own bash script (e.g. apply-errata.sh) as per the following:
#!/bin/bash
ERRATUM_IDS=$(hammer --csv host errata list --host $1 --search "type = $2" | sed '1d' | cut -d ',' -f2 | paste -s -d, -)
hammer host errata apply --host $1 --errata-ids $ERRATUM_IDS
Then apply errata types to the host using the following:
./apply-errata.sh host.example.net security
And the script runs the commands to apply all errata by type to the host. With a bit more tweaking you could also use an if statement in the script to accept a blank value for the type so that it applies all errata to the host.
That's unfortunate. Are you using any BMC for power management?
Probably the only other way to perform a reboot via hammer is to use the remote execution features. So run the following to view the different job templates available:
hammer job-template list
Get the ID for the template for 'Power Action - SSH Default'. So for example, it's 92 for me. Then run the following command:
hammer job-invocation create --job-template-id 92 --inputs "action=restart" --search-query "name=host.example.com"
This should restart the system without needing a BMC.
This might be a bit harder to diagnose, but I'll try my best.
it sounds like a DNS error. Something might have changed with the DNS config during the update (just a theory). So if you're using the Satellite or a Capsule for DNS, you might need check that the services on the Satellite/Capsule are running:
systemctl list-units "foreman-proxy*" "named*"
And if either of those two services are failing, try a restart:
systemctl restart foreman-proxy
If the DNS service is working, there might be a problem with how it's resolving. So from the Satellite or Capsule, try to ping the hostname.
ping host.example.com
In Satellite 6.2.8 we default to using the hosts FQDN to connect via Remote Execution. Previously we connected via IP address. However in clustered scenarios, sometimes we'd connect to an IP address which was 'floating', meaning that jobs may sometimes run on an undesired host. (And if it did something destructive... you can see how this can be an issue)
If you wish to revert back to the old behavior, you can set remote_execution_connect_by_ip parameter globally (under Administer->Settings->Remote Execution) or as a host parameter.
remote_execution_connect_by_ip - Should the ip addresses on host interfaces be preferred over the fqdn? It is useful, when DNS not resolving the fqdns properly. You may override this per host by setting a parameter called remote_execution_connect_by_ip.
I'd like to invite you to follow us on the Satellite Blog. Each release (Major,Minor, or Micro) gets an announcement, so that we can inform you of changes like these.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
