JavaScript must be enabled to correctly display this content

Chapter 1 Release Notes

1.1 About Spacewalk Release 2.7

There are no significant differences between Oracle's version of Spacewalk and the Spacewalk upstream project.

Installation

For information about installing or upgrading Spacewalk 2.7 servers and proxies, see Spacewalk for Oracle® Linux: Installation Guide for Release 2.7.

Summary of New Features and Changes Since Release 2.6

In addition to numerous fixes and other enhancements, Spacewalk Release 2.7 includes the following new features and improvements:

Addition of the taskotop utility, which monitors taskomatic daemon activities. The taskotop utility is included in the spacewalk-utils package.
jabberd daemon, which supports the Open Source Architecture Daemon (OSAD), now uses the sqlite database for improved reliability.
jpackage libraries and packages have been replaced with standard packages and libraries.
Improved kickstart profile support.
New channel.listManageableChannels API call added.

For detailed information about these changes, see the Release Notes for the Spacewalk project at https://github.com/spacewalkproject/spacewalk/wiki/ReleaseNotes27.

1.2 Known Issues for Spacewalk Release 2.7

The following known issues pertain to the Spacewalk Release 2.7.

1.2.1 Cannot Launch Web Page for Spacewalk Server After Upgrading to Spacewalk Release 2.7 on Oracle Linux 6

A "404" error is encountered when you attempt to launch the web page for the Spacewalk server after upgrading from Spacewalk Release 2.6 to Release 2.7 on an Oracle Linux 6 system. This problem is due to the removal of the /usr/share/java/jta.jar symbolic link by yum during the upgrade process.

To resolve the problem, run the following command on the Spacewalk server:

# ln -s geronimo-jta.jar /usr/share/java/jta.jar

After running the command, restart the Spacewalk services:

# /usr/sbin/spacewalk-service restart

1.2.2 Snapshot Rollback Feature Requires Remote Management Client To Be Installed and Enabled

To successfully roll back a target system to a previous snapshot by using Spacewalk, the target server must have the Spacewalk Remote Management client installed with at least the deploy files option enabled. However, Oracle recommends enabling all remote configuration options.

For information about administering the Spacewalk Remote Management client, see Spacewalk for Oracle® Linux: Client Life Cycle Management Guide for Release 2.7.

1.2.3 Running spacewalk-repo-sync From crontab With -q or -quiet Breaks After Upgrading to Spacewalk 2.6

If you previously configured a cronjob to run the spacewalk-repo-sync command with either the -q or -quiet option, the cronjob fails after upgrading to Spacewalk 2.6. You must remove the option from the command line after the upgrade.

Note that the version of the spacewalk-repo-sync command in Spacewalk 2.6 is now quiet by default and automatically logs its actions to the /var/log/rhn/reposync.log file. (Bug ID 25743208)

1.2.4 Issues That Require You to Replace the jabberd/osa Database

You might need to replace the jabberd/osa database on a Spacewalk server or proxy if you encounter any of the following errors:

OSA status shows "offline as of unknown" for client servers.
osa-dispatcher errors in /var/log/messages on the Spacewalk server or proxy.
"db: corruption detected! close all jabberd processes and run db_recover" message in /var/log/messages on the Spacewalk server or proxy.

These problems occur because the default Berkeley database format does not support transactions, and as a result, can become damaged when too many clients attempt to update at the same time. Switching to SQLite provides transactional support for the jabberd database and can handle significantly more downstream clients.

For detailed instructions on replacing the jabberd/osa database, see Spacewalk for Oracle® Linux: Installation Guide for Release 2.7.

1.2.5 SELinux Policy Prevents SQL*Plus From Connecting to Oracle Database

If SELinux is enabled, the default SELinux policy prevents the version of SQL*Plus that is installed by the Oracle Instant Client packages from connecting to the Oracle Database.

To work around this issue, use the SQL*Plus binary that is installed by Oracle Database itself, which is located in $ORACLE_HOME/bin. Another workaround is to set SELinux to permissive mode. (Bug ID 25743208)

1.2.6 Oracle Linux 6 Update 8 Fails to Run yum Commands After Registration

Registration of an Oracle Linux 6 Update 8 server succeeds with the built-in packages, but subsequent yum commands fail with the error: "KeyError: 'X-RHN-Auth-Expiration’”.

Installing the full Spacewalk client for Oracle Linux 6 resolves this problem and should be done prior to registration. Follow the steps in Installing the Spacewalk Client Software and Registering a Client System by Using the rhnreg_ks Command in Spacewalk for Oracle® Linux: Client Life Cycle Management Guide for Release 2.7.

1.2.7 Spacewalk Logging Settings

Spacewalk generates large numbers of log messages, particularly under /var/log/httpd. To avoid running out of disk space, you might need to adjust the logrotate settings to implement more active rotation, compression, and archival of log files.

For more information, see the relevant information in Oracle® Linux 6: Administrator's Guide or Oracle® Linux 7: Administrator's Guide.

1.2.8 Spacewalk Fails to Install Due to the slf4j Package Being Installed

In some circumstances, the Spacewalk installation can fail if the slf4j (Simple Logging Facade for Java) package is installed. The workaround is to remove the slf4j package. Be aware that Eclipse depends on this package, so you either have to uninstall Eclipse or remove the package with the rpm -e --nodeps slf4j command.

1.2.9 Tomcat Fails to Start After Initial Spacewalk Configuration

If the Tomcat service fails to start after the initial configuration of Spacewalk, check that the geronimo-jta-1.1-api package is installed. If you installed Oracle Linux using a software set other than Minimal or Basic Server, the jta package might be installed on the system and the presence of this package prevents the geronimo-jta-1.1-api package from being installed. The geronimo-jta-1.1-api package is required to ensure that all of the Spacewalk services start correctly. If the geronimo-jta-1.1-api package is missing from your system, remove the jta package, install the geronimo-jta-1.1-api package, and then shutdown and reboot the system.

1.2.10 PXE Boot Fails Due to Incorrect Host Name Configuration

If the Spacewalk server was installed without a fully-qualified domain name (FQDN) specified, or with a name that cannot be resolved in DNS, Spacewalk creates invalid Preboot eXecution Environment (PXE) boot configuration files.

You can validate that Cobbler is configured correctly by checking that the IP address that is used in the ks= parameter in the /var/lib/tftpboot/pxelinux.cfg/default file is correct.

To reconfigure a Spacewalk server after an installation, do the following:

Edit the /etc/cobbler/settings file and change all instances of incorrect host names, such as localhost.localdomain.
Restart Spacewalk by running the spacewalk-service restart command.
Resynchronise Cobbler by running the cobbler sync command.

1.2.11 Out of Memory Issues With Large Repositories or Data Sets

When building repository metadata, Spacewalk can fail with an "Out of Memory" error that is linked to default Java memory settings. For a detailed discussion about this issue and its resolution, see Memory Considerations When Building Repositories in Spacewalk for Oracle® Linux: Client Life Cycle Management Guide for Release 2.7.

1.2.12 Client Registration Issues Due to an Invalid FQDN

During an installation, Spacewalk generates a CA certificate. This certificate is used in the client registration process. If a Spacewalk server does not have a valid FQDN, Spacewalk does not generate a valid CA certificate. Note that Spacewalk does not consider .local and .localdomain valid domain names.

1.2.13 Clients Might Have to Re-Register After an Upgrade

After a Spacewalk server is upgraded, Spacewalk clients might have to re-register with the Spacewalk server. The web interface shows these clients as registered, but when you run the rhncfg-client command on the client, errors such as Authentication failed: Invalid digital server certificate are displayed.

If this problem occurs, use either the rhn_register command or the rhnreg_ks --force command to re-register the client.

1.2.14 Spacewalk Does Not Work If root User Has a Restrictive umask

If the root user's umask is too restrictive (for example, 0077 or similar, instead of 0022), Apache, Tomcat, and Java processes cannot read some files that are written during a Spacewalk installation or written by commands such as spacewalk-repo-sync or spacecmd. Clients might also stop working because Spacewalk cannot serve yum metadata or package files.

1.2.15 yum Command Displays HTML

To prevent the yum command from displaying many lines of HTML when it is run on a Spacewalk client, do either of the following:

Edit the /etc/yum/pluginconf.d/ulninfo.conf file and set the enable value to 0.
Remove the yum-plugin-ulninfo package.

1.2.16 Issues With Kickstart After an Upgrade

After a Spacewalk server is upgraded, using existing kickstart profiles and distributions might result in errors.

The web interface might display error messages such as the following:

This kickstart profile uses a different type of encryption by default than the root password is currently using. You must reset the root password to encrypt it with the new method.

As a workaround, do the following:

Reset the root password.
Restart the Spacewalk service.
```
# /usr/sbin/spacewalk-service restart
```
Remount your distribution trees and ISO images.