The software described in this documentation is either no longer supported or is in extended support.
Oracle recommends that you upgrade to a current supported release.
Chapter 1 Release Notes
1.1 About Spacewalk 2.6 for Oracle Linux
There are no significant changes in the Oracle version of Spacewalk from the upstream project.
Installation
For information about installing or upgrading Spacewalk 2.6 servers and proxies, see Spacewalk for Oracle® Linux: Installation Guide for Release 2.6.
Summary of new features and changes since release 2.4
In addition to numerous fixes and other small enhancements, the Spacewalk 2.6 release includes the following features:
-
The taskotop command-line utility has been added to the
spacewalk-utils
package. This utility monitors Taskomatic activities and provides information about the status of each job. -
Most system entitlements and Software Channel entitlements have been removed.
NoteThe Virtualization entitlement is still supported in this release.
-
Improved first organization creation.
-
spacewalk-repo-sync
improvements, including the following:-
Can sync channels with several repositories.
-
Can update a kickstart tree in a repository.
-
-
Improved Python 2/3 compatibility for all tools.
-
OSAD now works in failover mode via proxy.
-
The 'Select All' button now correctly selects only filtered systems, packages, errata, and so on.
-
Changes to the organization of the menus within the Spacewalk web interface. For example, you can configure an organization by selecting the Organization menu under the Admin tab.
-
New API calls:
-
actionchain.addErrataUpdate
-
system.listSuggestedReboot
-
packages.listSourcePackages
-
packages.removeSourcePackage
-
system.scheduleLabelScriptRun
-
system.schedulePackageInstallByNevra
-
system.schedulePackageRemoveByNevra
You can find up-to-date API documentation under the Help tab of the web interface by selecting the API menu option, then browse the URL
https://
on the server, or by going to http://www.spacewalkproject.org/documentation/api/2.6.swksvr_FQDN
/rhn/apidoc/index.jsp -
For detailed information, see the release notes for the Spacewalk project at https://github.com/spacewalkproject/spacewalk/wiki/ReleaseNotes26.
1.2 Spacewalk 2.6 Known Issues
- 1.2.1 Snapshot Rollback Feature Requires Remote Management Client To Be Installed and Enabled
- 1.2.2 Running spacewalk-repo-sync From crontab With -q or -quiet Breaks After an Upgrade Fails
- 1.2.3 Issues That Require You to Replace the jabberd/osa Database
- 1.2.4 SELinux Policy Prevents SQL*Plus From Connecting to Oracle Database
- 1.2.5 Oracle Linux 6 Update 8 Fails to Run yum Commands After Registration
- 1.2.6 Spacewalk Logging Settings
- 1.2.7 Spacewalk Fails to Install Due to the slf4j Package Being Installed
- 1.2.8 Tomcat Fails to Start After Initial Spacewalk Configuration
- 1.2.9 Spacewalk Client Fails to Install on Oracle Linux 5
- 1.2.10 Upgrading Spacewalk Packages on Oracle Linux 7
- 1.2.11 Oracle Linux 5 Does Not Register With Spacewalk After a Kickstart Installation
- 1.2.12 PXE Boot Fails Due to Incorrect Host Name Configuration
- 1.2.13 Out of Memory Issues With Large Repositories or Data Sets
- 1.2.14 Client Registration Issues Due to an Invalid FQDN
- 1.2.15 Clients Might Have to Re-Register After an Upgrade
- 1.2.16 Spacewalk Does Not Work if root User Has a Restrictive umask
- 1.2.17 yum Command Displays HTML
- 1.2.18 Issues With Kickstart After an Upgrade
The following known issues pertain to the Spacewalk 2.6 release.
1.2.1 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.6.
1.2.2 Running spacewalk-repo-sync From crontab With -q or -quiet Breaks After an Upgrade Fails
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.
1.2.3 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.6.
1.2.4 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.
1.2.5 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 2.6 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.6.
1.2.6 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.7 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.8 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.9 Spacewalk Client Fails to Install on Oracle Linux 5
The Spacewalk client conflicts with the
up2date client that is installed by default
for connectivity to the Unbreakable Linux Network (ULN).
Before you install the Spacewalk Client for Oracle Linux 5,
remove the up2date
and
up2date-gnome
packages manually by using
the rpm -e --nodeps command.
1.2.10 Upgrading Spacewalk Packages on Oracle Linux 7
Before upgrading Spacewalk packages on an Oracle Linux 7
system, run the following commands, which force
cglib
and python-debian
to stay at cglib-2.1.3-4.jpp5.*
and
python-debian-0.1.21-10.el7.*
:
#yum install yum-versionlock
#yum versionlock cglib-2.1.3-4.jpp5.*
This entry is required because the versions of
cglib
and python-debian
in Oracle Linux 7 are more recent than the versions in
Spacewalk 2.6. Otherwise, you see dependency errors such as
the following:
Error: Package: spacewalk-java-2.4.79-1.0.2.el7.noarch (@ol7_spacewalk24_server) Requires: cglib < 2.2 Error: Package: spacewalk-taskomatic-2.4.79-1.0.2.el7.noarch (@ol7_spacewalk24_server) Requires: cglib < 2.2
1.2.11 Oracle Linux 5 Does Not Register With Spacewalk After a Kickstart Installation
If Oracle Linux 5 does not register with Spacewalk after a
kickstart installation, add -up2date
and
-up2date-gnome
to the kickstart profile on
the Software,
Package Group
screen during the installation.
1.2.12 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 aslocalhost.localdomain
. -
Restart Spacewalk by running the spacewalk-service restart command.
-
Resynchronise Cobbler by running the cobbler sync command.
1.2.13 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.6.
1.2.14 Client Registration Issues Due to an Invalid FQDN
During 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
to be valid domain names.
1.2.15 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.16 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.17 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 theenable
value to0
. -
Remove the
yum-plugin-ulninfo
package.
1.2.18 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.
The workaround is to do the following:
-
Reset the
root
password. -
Restart the Spacewalk service.
#
/usr/sbin/spacewalk-service restart
-
Remount your distribution trees and ISO images.