What’s New in Beaker 20?¶

Beaker 20 introduces system pools, and the ability to apply the same access policy across many systems. This release also brings support for configurable netboot loaders and several other enhancements.

System pools and shared system access policies¶

Beaker 20 introduces “system pools” as arbitrary collections of systems.

Previously, a group in Beaker could contain both users and systems. However, groups are primarily a way of managing Beaker users. With the introduction of system pools, the existing group mechanism becomes exclusively “user groups”. It is no longer possible to add systems to user groups.

As part of the upgrade to Beaker 20, for each group which contained one or more systems, a new system pool will be created with the same name and containing the same systems. Pools created during this migration process will have their initial description set to “Pool migrated from group <name>” and will be owned by the corresponding user group.

Building on the system pools feature, Beaker 20 also makes it possible to share a single access policy across a large number of systems. System owners can now choose to apply the access policy from a pool, rather than defining the policy rules explicitly on their system.

For example, if you own the hardware for the fictional Project Unicorn development team, you can create a new Beaker pool named “Project Unicorn”. In the pool access policy, you can grant reserve permission to the Project Unicorn developers. Then you can add each system to the pool, and set them to use the access policy from the “Project Unicorn” pool.

Refer to System pools and Shared access policies for more details. See also the original design proposal for further background and rationale.

(Contributed by Amit Saha, Matt Jia, and Dan Callaghan in #%s1057463.)

Other new features and enhancements¶

Configurable netboot loader¶

Beaker now supports configuring the netboot loader used on a per-recipe basis, by passing netbootloader= in the kernel options. For example, in ppc64 recipes Beaker can use yaboot when provisioning older distros and GRUB2 when provisioning newer distros. This feature requires that the DHCP configuration for the system is updated appropriately.

Refer to Kernel options for details about the netbootloader= option, and to Boot loader images for details about the new TFTP directory layout.

(Contributed by Amit Saha in #%s1156036.)

Workflow commands accept --reserve¶

A new option --reserve is now accepted by bkr workflow commands. This option adds the <reservesys/> element to each recipe in the job, causing Beaker to reserve the system after all tasks have finished executing (or if the recipe is aborted). The duration can be controlled using --reserve-duration.

For more details about the <reservesys/> element, refer to Using the <reservesys/> element.

(Contributed by Dan Callaghan in #%s1186719.)

Workflow commands accept wildcards in --distro¶

The bkr workflow commands now treat the value of the --distro option as a SQL LIKE pattern (the % character matches any substring).

(Contributed by Bill Peck in #%s1200427.)

bkr system-modify can update host hypervisor field¶

Using bkr system-modify --host-hypervisor you can update the host hypervisor field for a system.

(Contributed by Dan Callaghan in #%s1206978.)

New --proxy-user option, to authenticate as other users¶

This option can only be used when the authenticating user is a member of a group which has been granted “proxy_user” permission by the Beaker administrator. Typically this permission is granted to service accounts so that a trusted script can perform actions on behalf of any other Beaker user.

(Contributed by Ján Stanček in #%s1199853.)

Notable changes¶

Task roles are now visible between host and guest recipes¶

In previous Beaker releases, task roles were not visible between the guest recipes and the host recipes in a recipe set.

For example, in the following recipe set:

<recipeSet>
  <recipe system="hostA">
    <task role="SERVERS" />
    <guestrecipe system="guest1">
      <task role="SERVERS" />
    </guestrecipe>
  </recipe>
  <recipe system="hostB">
    <task role="CLIENTS" />
    <guestrecipe system="guest2">
      <task role="CLIENTS" />
    </guestrecipe>
  </recipe>
</recipeSet>

the role environment variables in both host recipes would have previously been:

SERVERS=hostA
CLIENTS=hostB

and in both guest recipes they would have been:

SERVERS=guest1
CLIENTS=guest2

However, this separation between host and guest recipes has been removed. In the above example, all four recipes would see the same role environment variables:

SERVERS=hostA guest1
CLIENTS=hostB guest2

(Contributed by Dan Callaghan in #%s960434.)

BIOS boot partition is defined in kickstarts¶

Beaker’s kickstart templates now define a 1MB “BIOS boot” partition when:

the recipe uses custom partitioning (<partition/> or a related kickstart metadata variable);
the system is x86 with BIOS firmware (or EFI firmware running in BIOS compatibility mode); and
the distro supports GPT format disks for BIOS systems (Fedora, CentOS 7, RHEL 7).

The BIOS boot partition is needed in case the boot disk is larger than 2TB, which causes Anaconda to use GPT instead of MBR when formatting the disk. If the boot disk is smaller than 2TB, the BIOS boot partition is still created but it will be empty and unused.

(Contributed by Dan Callaghan in #%s1108393.)

bkr workflow-installer-test is deprecated¶

This workflow command was used for submitting jobs to test the Anaconda installer. It included support for rendering custom kickstarts on the client side using template variables.

Use the --kickstart option for bkr workflow-simple (or any other workflow command) instead. This option lets you pass a kickstart template which is rendered on the server using Beaker’s existing kickstart templating mechanisms.

Beaker’s server-side templating has been expanded to cover all use cases which were supported by bkr workflow-installer-test, and is now fully documented. Refer to Custom kickstart templates.

(Contributed by Alexander Todorov and Dan Callaghan in #%s1184720, #%s966348, #%s1077251.)

New `<pool/>` host filter replacing `<group/>`¶

With the introduction of system pools, a new XML host filter <pool/> has been added for filtering by pool membership. It follows the behaviour of the previous <group/> element, which allowed filtering systems by group membership.

For backwards compatibility, the <group/> element will remain as a deprecated alias for <pool/>.

bkr policy-list shows active policy by default¶

The bkr policy-list command now retrieves and prints the rules from the system’s currently active access policy, which may be a pool policy. If you want to retrieve the rules from the system’s custom access policy, use the --custom option.

Changes to reporting queries using `system_access_policy`¶

As part of the support for pool access policies described above, the database structure for representing system access policies has changed.

If you are running Beaker database queries which join the system_access_policy table in order to filter by access policy rules, you must update the join condition. Previously the join condition was:

JOIN system_access_policy
ON system.id = system_access_policy.system_id

Replace this with:

JOIN system_access_policy
ON system.active_access_policy_id = system_access_policy.id

Task and harness updates¶

A new task /distribution/rebuild has been published, for experimental mass rebuilds of the entire distribution from source. See /distribution/rebuild. (Contributed by Dan Callaghan in #%s1183913.)

Bug fixes¶

A number of bug fixes are also included in this release:

#%s1207727: Fixed a regression in Beaker 19.3 with advanced search, causing some fields to be incorrectly treated as date fields. (Contributed by Matt Jia)
#%s1109614: The “post-install done” check-in step in Beaker recipe kickstarts now always appears at the very end of the kickstart. Previously in some circumstances it would be performed before all post-install actions were done. (Contributed by Dan Callaghan)
#%s1101817: Activity pages no longer display a total count of all activity records in Beaker, because this is too expensive to compute. (Contributed by Dan Callaghan)
#%s1122464: The Executed Tasks tab on the system page now cancels previous AJAX requests before submitting new ones. (Contributed by Matt Jia)
#%s1173376: The scheduler now correctly clears the candidate system mapping for a recipe when it is cancelled or aborted. This prevents a large number of rows needlessly accumulating in the system_recipe_map database table. (Contributed by Matt Jia)
#%s1149944: The administration guide now includes a complete copy of the server.cfg and labcontroller.conf configuration files, showing an explanation for each option and its default value. (Contributed by Dan Callaghan)

Maintenance updates¶

The following fixes have been included in Beaker 20 maintenance updates.

Beaker 20.1¶

This release fixes four security vulnerabilities:

#%s1215034: Modifying key types and power types is now properly restricted to Beaker administrators. Previously these operations were unintentionally available to all users, including anonymous users. (Contributed by Matt Jia)
#%s1215020: DTDs and XML entities are no longer accepted in job XML submitted to Beaker. This prevents a type of attack called “XXE” where an authenticated user can cause Beaker to disclose the contents of files on the server’s filesystem. (Contributed by Dan Callaghan)
#%s1215030: Recipe set comments are no longer interpreted as HTML, they are now interpreted as plain text and HTML characters are escaped. This prevents authenticated users from performing <script> injection attacks using recipe set comments. (Contributed by Dan Callaghan)
#%s1215024: Closing </script> tags are now properly escaped in the JavaScript source for the advanced search bar. (Contributed by Dan Callaghan)

Beaker 20.2¶

#%s1226076: Fixed a problem with the handling of <group/> and <pool/> elements in <hostRequires/> which would cause the filter to match incorrect systems, and in some cases exhaust temp table space on the database. (Contributed by Matt Jia)
#%s1212517: The bkr client is now compatible with the SSL-related changes in Python 2.7.9. (Contributed by Dan Callaghan)
#%s1102442: The bkr system-release command can now also release a system which is held by a recipe in Reserved status (using <reservesys/>). (Contributed by Matt Jia)
#%s1181700: The bkr system-power command now accepts --action=none in conjunction with --clear-netboot to allow clearing a system’s netboot configuration without rebooting it. (Contributed by Matt Jia)
#%s1128002, #%s1128004: Beaker can now perform automatic hardware scanning on aarch64 and ppc64le distros. (Contributed by Amit Saha)
#%s1217695: The pre-defined host filters for the --host-filter option have been updated to exclude virtualized systems for CPU-based filters, and a number of new CPU-based filters have been added. (Contributed by Michael Petlan)
#%s1235317: Beaker now treats Red Hat Gluster Storage 3 like Red Hat Enterprise Linux 6 for kickstart templating purposes. (Contributed by Dan Callaghan)
#%s1197074: The <or/> and <and/> elements now have their expected effect inside the <disk/> element in <hostRequires/>. Previously they were ignored. (Contributed by Matt Jia)
#%s1217158: The --pool option replaces the --group option for bkr list-systems <bkr system-list>. The old option is still accepted as an alias for compatibility. (Contributed by Dan Callaghan)
#%s1219965: The kickstart templates now define an EFI System Partition when using custom partitioning on aarch64, for compatibility with systems which have UEFI firmware. (Contributed by Matt Jia)
#%s1217283: When a user views the list of systems on the pool page, systems which they do not have permission to view will now appear as (system with restricted visibility). (Contributed by Matt Jia)
#%s1213203: In the list of systems on the pool page, the Remove button now correctly appears only when the user has permission to remove the system. Previously the button would always appear. (Contributed by Matt Jia)
#%s1212725: The bkr client now reports a meaningful error message when no configuration file was loaded, rather than attempting to connect to localhost. (Contributed by Matt Jia)

Version 1.2-6 of the /distribution/inventory task has also been released:

#%s1211850: Fixed false positives in checking if virtualization features are disabled by the BIOS, which could occur if the system has “kvm” in its hostname. (Contributed by Amit Saha)

Version 4.66 of the rhts test development and execution library has also been released:

#%s1219920: The rhts-lint command (invoked when building and uploading task RPMs) now ignores unrecognised fields in testinfo.desc rather than reporting a warning and failing the build. (Contributed by Dan Callaghan)
#%s1219971: Fixed an issue which would cause make rpm to incorrectly attempt to upload the task to Beaker when invoked on a Beaker test system. (Contributed by Dan Callaghan)