Installing Spacewalk to manage Oracle Linux

Spacewalk is a popular Linux management tool that can be used to manage several operating systems, including the Red Hat Enterprise Linux derivatives like CentOS and Scientific Linux, Debian and even Solaris.

While the Spacewalk installation instructions are very thorough, here is a brief guide to installing Spacewalk on Oracle Linux 6. It is possible to install on Oracle Linux 5, but it requires a lot more manual intervention as the Unbreakable Linux Network packages installed on Oracle Linux 5 conflict with some Spacewalk packages. You should use both the Spacewalk installation instructions in combination with this guide to install Spacewalk.


This guide assumes that you are familiar with the Oracle Linux 6 installation process, as well as basic system administration tasks, including registering with the Unbreakable Linux Network (ULN) or configuring YUM to use  The Oracle Linux 6 Administrator's Solutions Guide provides more information on these tasks.

Oracle Linux 6 Installation

This guide uses Oracle Linux 6.4 (x86_64). Download Oracle Linux 6.4 from the Oracle Software Delivery Cloud or one of the mirrors. You can choose either to do a "Basic Server" install, or a "Minimal" install. I recommend performing a "Basic Server" install as this provides basic system administration tools. If you are using a previous version of Oracle Linux 6, please ensure it is either registered with the Unbreakable Linux Network or is configured to use for updates.

You should assign both a fixed hostname as well as a fixed IP address for your Spacewalk server. The hostname should be resolvable via DNS on your network.

Pre-Requisite Installation

Binary packages of Spacewalk are available through YUM repositories at ‚Äč To use this repository, install the spacewalk-repo package with commands below:

# rpm -Uvh

Additional repositories and packages

For Spacewalk on Oracle Linux 6, additional dependencies are needed from JPackage. Please configure the following yum repository before beginning your Spacewalk installation:

cat > /etc/yum.repos.d/jpackage-generic.repo << EOF
name=JPackage generic

We specifically want the 5.0 generic directory in the above URL.

Spacewalk requires additional dependencies from the Enterprise Packages for Enterprise Linux (EPEL) repository. To enable this repository run the following command:

# rpm -Uvh 

Database Server

Spacewalk supports either Oracle Database 10g or higher or PostgreSQL 8.4 or higher to store its primary data. While Oracle Database XE is supported by Spacewalk, it is not supported by Oracle. Therefore, we recommend either using an existing Oracle Database Standard or Enterprise Edition server or using PostgreSQL. 

Oracle Database Setup

Installation of an Oracle Database server is outside the scope of this walk-through. We assume you have an existing Oracle Database server installed and available. The spacewalk user needs to have the CONNECT and RESOURCE roles as well as the ALTER SESSION, CREATE SYNONYM,CREATE TABLE and CREATE VIEW system privileges.

You will also need to make the following code change on your Spacewalk server, after you have installed the Spacewalk software:

# diff -u /etc/sysconfig/rhn/oracle/main.sql-20110504 /etc/sysconfig/rhn/oracle/main.sql
--- main.sql-20110504	2011-04-08 21:40:53.000000000 +0200
+++ main.sql	2011-05-04 14:20:24.000000000 +0200
@@ -38940,6 +38940,12 @@
 -- Source: data/common/rhnPackageSyncBlacklist.sql
+select lookup_package_name('gpg-pubkey') from dual;
+select lookup_package_name('rhns-ca-cert') from dual;
+select lookup_package_name('rhn-org-trusted-ssl-cert') from dual;
 insert into rhnPackageSyncBlacklist (package_name_id)
 	values (lookup_package_name('gpg-pubkey')); 

Without this change, the Spacewalk installation fails with the following error in /var/log/rhn/populate_db.log:

ORA-02291: integrity constraint (SPACEWALK.RHN_PACKAGESYNCBL_PNID_FK) violated - parent key not found 

The Oracle Instant Client packages can be installed from ULN by subscribing to the Oracle Software channel and running the following command:

# yum install oracle-instantclient11.2-basic oracle-instantclient11.2-sqlplus

If you are not subscribed to ULN, you can download the Oracle Instant Client RPMs from the Oracle Technology Network and install them manually.

Once the Oracle Instant Client has been installed, you need to add the library path to ldconfig:

# echo /usr/lib/oracle/11.2/client64/lib > /etc/
# ldconfig

Spacewalk Installation

If you want to use the PostgreSQL embedded backend on the same server as Spacewalk:

# yum install spacewalk-setup-embedded-postgresql 
# yum install spacewalk-postgresql

If you want to use an Oracle Database backend:

# yum install spacewalk-oracle 

The rest of this guide uses an Oracle Database backend. Don't forget to make the code change listed under Oracle Database Setup before continuing!

The Spacewalk binary packages are missing a dependency on the geronimo-jta-1.1-api RPM, so install it manually:

# yum install geronimo-jta-1.1-api

Configuring Spacewalk

Your Spacewalk server should have a resolvable FQDN such as ''. If the installer complains that the hostname is not the FQDN, do not use the --skip-fqdn-test flag to skip.

If you installed spacewalk-setup-embedded-postgresql above, run

# spacewalk-setup --disconnected

If you set up the database server manually (either on the same or on a different machine), run

# spacewalk-setup --disconnected --external-db

A sample interactive install:

 # spacewalk-setup --disconnected --external-db
* Setting up Oracle environment.
* Setting up database.
** Database: Setting up database connection for Oracle backend.
Database service name (SID)?
Database hostname [localhost]?
Username? spacewalk
** Database: Testing database connection.
** Database: Populating database.
*** Progress: ############################################################
* Setting up users and groups.
** GPG: Initializing GPG and importing key.
** GPG: Creating /root/.gnupg directory
You must enter an email address.
Admin Email Address?
* Performing initial configuration.
* Activating Spacewalk.
** Loading Spacewalk Certificate.
** Verifying certificate locally.
** Activating Spacewalk.
* Enabling Monitoring.
* Configuring apache SSL virtual host.
Should setup configure apache's default ssl server for you (saves original ssl.conf) [Y]?
** /etc/httpd/conf.d/ssl.conf has been backed up to ssl.conf-swsave
* Configuring tomcat.
** /etc/sysconfig//tomcat6 has been backed up to tomcat6-swsave
** /etc/tomcat6//server.xml has been backed up to server.xml-swsave
** /etc/tomcat6//web.xml has been backed up to web.xml-swsave
* Configuring jabberd.
* Creating SSL certificates.
CA certificate password?
Re-enter CA certificate password?
Organization? Oracle Demo
Organization Unit []?
Email Address []?
City? Redwood Shores
State? CA
Country code (Examples: "US", "JP", "IN", or type "?" to see a list)? US
** SSL: Generating CA certificate.
** SSL: Deploying CA certificate.
** SSL: Generating server certificate.
** SSL: Storing SSL certificates.
* Deploying configuration files.
* Update configuration in database.
* Setting up Cobbler..
Processing /etc/cobbler/modules.conf
`/etc/cobbler/modules.conf' -> `/etc/cobbler/modules.conf-swsave'
Processing /etc/cobbler/settings
`/etc/cobbler/settings' -> `/etc/cobbler/settings-swsave'
cobblerd does not appear to be running/accessible
Cobbler requires tftp and xinetd services be turned on for PXE provisioning functionality. Enable these services [Y]?
cobblerd does not appear to be running/accessible
* Restarting services.
Installation complete.
Visit to create the Spacewalk administrator account.

Once your install is complete, visit to create the initial Spacewalk administrator account. Documentation on using Spacewalk can be found on the Spacewalk wiki

Oracle Linux YUM Repositories

The following channels on  contain errata information that can be ingested by Spacewalk: 

  • ol5_i386_latest
  • ol5_x86_64_latest
  • ol6_i386_latest
  • ol6_x86_64_latest

Each repository stores ALL packages released since the first Generally Available (GA) release of each version. This means the storage requirements for each of these repositories is between 20GB-30GB each. Care should be taken to ensure you have enough disk space to mirror each repository.

Adding the Oracle Linux 6 (x86_64) Latest channel

Goto Channels -> Manage Software Channels -> Manage Repositories. Click "create new repository" and provide the following configuration:

  • Repository Label: External yum repo - Oracle Linux 6 (x86_64)
  • Repository URL:

Then click "create repository".

After creating the repository, you need to link it to one or more Software Channels. Goto: Channels -> Manage Software Channels. Click "create new channel" and provide the following configuration:

  • Channel Name: Oracle Linux 6 (x86_64)
  • Channel Label: oraclelinux6-x86_64
  • Architecture: x86_64
  • Yum Repository Checksum Type: sha256
  • Channel Summary: Oracle Linux 6 (x86_64)
Then click "create channel". Once the channel is created, click the "Repositories" tab that appears and select the "External yum repo - Oracle Linux 6 x86_64" repository and click "Update Repositories". Once you've enabled the repository, click the "Sync" tab and either click the "Sync Now" button to trigger an immediate sync, or schedule a sync. Note that the initial repository sync can take 2-3 days to complete for each repository.


Hi Avi.

Do you think it is possible to have the OEL Spacewalk server register against ULN? I came accross that question because the spacewalk installation will replace several rhn* packages with the original Red Hat packages...

Posted by Daniel Schindler on May 02, 2013 at 12:10 PM PDT #

Hey Daniel,

No, a Spacewalk server will not be able to register with ULN, as the required packages are replaced by the Spacewalk ones. This disables ULN access, unfortunately. What I haven't tested is if a Spacewalk server still works if it's registered with ULN before installing Spacewalk, i.e. before the packages are replaced.

Essentially, I recommend using our OTN mirror script for all the ULN channels that are not on and using Spacewalk to combine the channels (which includes the errata) and the ULN channels that are mirrored.

Posted by Avi Miller on May 02, 2013 at 01:14 PM PDT #

Had a short check on it: after registering the system to ULN I installed spacewalk packages and afterwards the desired SSLCACert under /usr/share/rhn/ULN-CA-CERT is gone and yum will fail to work :(

Posted by Daniel Schindler on May 02, 2013 at 02:13 PM PDT #

Yes, you'll have to copy back the ULN-CA-CERT from another OL6 machine.

Posted by Avi Miller on May 02, 2013 at 02:15 PM PDT #

Hey Avi,

I too face the same error.
ERROR: can not find RHNS CA file: /usr/share/rhn/ULN-CA-CERT

Posted by Niks on May 08, 2013 at 09:10 AM PDT #

Yes, that's why this article is not about connecting Spacewalk to ULN -- it replaces too much of the code and other files we need. It's about connecting Spacewalk to

Posted by Avi Miller on May 08, 2013 at 02:35 PM PDT #

So how do you handle patching systems via Spacewalk that use ksplice? If your repository/Spacewalk server has to register to ULN to get ksplice RPMs then that wouldn't work, would it? Would you have to exclude kernel updates in spacewalk and then have a separate manual job to update the kernel via ksplice? Spacewalk would still think your ksplice enabled clients were non-compliant because all it knows about it the on-disk installed kernel RPM, not the effective kspliced kernel.

I don't think Enterprise Manager 12c is aware of kspliced systems when it comes to patching either. Are there any patch management systems out there that are ksplice-aware?

Posted by guest on May 14, 2013 at 08:15 AM PDT #

Actually, now that we have Ksplice Offline patching, it's a lot simpler than that: just subscribe your yum mirror to the Ksplice Offline channel and you can then import Ksplice patches into Spacewalk just like normal RPMs. You could even using custom commands to run uptrack-upgrade from within Spacewalk.

Read the post from Wim on Ksplice Offline:

Keep in mind that we recommend combining both Ksplice and normal yum patching of kernels so that if for any reason a machine does reboot, it has the latest kernel without needing to be Kspliced. So, as long as you upgrade the kernel normally via yum (which doesn't take affect until a reboot) and you use Ksplice as well, Spacewalk and Ksplice will both think you're up-to-date, which you will in fact be.

Posted by Avi Miller on May 14, 2013 at 02:03 PM PDT #

I was able to mirror the packages and errata sucessfuly from public-yum to my spacewalk server for ol6_i386_latest and ol6_x86_64_latest. However I am not able to get any errata from ol5_i386_latest or ol5_x86_64_latest. I'm seeing messages like this in the taskomatic logs:

| 2013-05-23 16:03:01,811 [DefaultQuartzScheduler_Worker-7] INFO com.redhat.rhn.taskomatic.task.RepoSyncTask - Repo URL:
| Packages in repo: 9623
| No new packages to sync.
| Repo has comps file comps.xml.
| Repo has 729 errata.
| 3 errata skipped because of empty package list.
| Sync completed.
| Total time: 0:22:01
| 2013-05-23 16:03:01,829 [DefaultQuartzScheduler_Worker-7] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask - ERROR: duplicate key value violates unique constraint "rhn_errata_advisory_uq"

Any ideas?

Posted by Adam Robinson on May 24, 2013 at 10:26 AM PDT #

Hey Adam,

Sorry for the delay -- I wanted to rebuild my Spacewalk environment to see if I could recreate the issue. Unfortunately, I can't. My Spacewalk correctly imports errata from both OL5 and OL6 repositories and correctly assigns the same errata to multiple channels.

I'm afraid you're going to have to reach out to the Spacewalk mailing lists for additional support here.

Posted by Avi Miller on May 27, 2013 at 02:00 PM PDT #

Hi Avi,
I figured it out. I had been importing the errata on my own with a Python script. I deleted all of my manually created errata before syncing with the public-yum server. For some reason, the OL5 errata weren't completely deleted from the database. I had to go into the table manually and delete a few rows.

Posted by Adam Robinson on May 27, 2013 at 05:21 PM PDT #

Hi Avi,

Where did you make the change in spacewalk. I have the same problem but know can edit the main.sql script because it creates the deploy.sql.

I have been trying to fix my application as it is down.


Posted by Alvin Johnson on June 04, 2013 at 08:18 PM PDT #

The changes are made in /etc/sysconfig/rhn/oracle/main.sql but these need to be done before spacewalk-setup is run, otherwise it won't work at all. This probably wouldn't fix an existing Spacewalk implementation.

Posted by Avi Miller on June 05, 2013 at 01:40 AM PDT #

Can I then use your mrepo howto to mirror ULN on a spearate box, then have satellite pull errata from the public-yum and packages from the mrepo server?


Posted by guest on September 11, 2013 at 08:01 AM PDT #

It would be easier to use our existing ULN mirror script from and then get Spacewalk to pull both packages and errata from this mirror.

Though, if you have Satellite already, just point it directly at for the repositories and it'll pull both packages and errata. Then use the mirror script for the rest of the channels that are not on because most of them don't have errata anyway.

Posted by Avi Miller on September 11, 2013 at 01:55 PM PDT #

Avi's last remark says that if you point Satellite at the public repo, it will pull both packages and errata. I found a post elsewhere that said Oracle had explicitly worked on how they do the errata so it would work with Satellite and Spacewalk. But my ol6 Satellite channel pointed at gets packages only, no errata.

Any clues on this before I go kludging it up with Frankie writes nice stuff, but it's kludgy to schedule the channel update in the GUI and the errata import in cron, IMO.

Posted by guest on October 08, 2013 at 09:01 AM PDT #

Can you see any errors in /var/log/rhn/reposync? I have several Spacewalk systems and they're all happily pulling the errata metadata from

Also, can you let us know what version of Spacewalk you're running? This has been testing on 1.9 and 2.0.

Posted by Avi Miller on October 08, 2013 at 12:14 PM PDT #

This is RHN Satellite 5.4.0 (satellite-branding-, with spacewalk-backend-1.2.13-79.el5sat and yum-utils-1.1.16-21.el5. I don't know how that maps onto spacewalk versions. Running on "Red Hat Enterprise Linux Server release 5.10 (Tikanga)" (/etc/redhat-release).

Latest GUI-scheduled reposync that actually pulled updates logged:

Sync started: Tue Oct 8 01:00:00 2013
['/usr/bin/spacewalk-repo-sync', '--channel', 'ol6_x86_64_latest', '--type', 'yum']
Repo has 17718 packages.
1/10 : NetworkManager-devel-0.8.1-61.el6_4-1.x86_64
2/10 : NetworkManager-glib-0.8.1-61.el6_4-1.i686
3/10 : NetworkManager-0.8.1-61.el6_4-1.x86_64
4/10 : xinetd-2.3.14-39.el6_4-2.x86_64
5/10 : NetworkManager-glib-devel-0.8.1-61.el6_4-1.x86_64
6/10 : NetworkManager-devel-0.8.1-61.el6_4-1.i686
7/10 : NetworkManager-gnome-0.8.1-61.el6_4-1.x86_64
8/10 : ypserv-2.19-26.el6_4.2-0.x86_64
9/10 : NetworkManager-glib-0.8.1-61.el6_4-1.x86_64
10/10 : NetworkManager-glib-devel-0.8.1-61.el6_4-1.i686
Sync complete

Later in the day I adapted Franky Liedekerke's and to my environment and got 345 errata using the "year" time frame.

Thanks for responding so promptly.

Posted by guest on October 09, 2013 at 04:49 AM PDT #

I don't actually know how Satellite maps to Spacewalk releases, but I'm guessing perhaps that you don't have the latest Satellite 5.5 running. If I look at Spacewalk 1.9 and 2.0, I see the following at the end of the reposync run:

Linking packages to channel.
Repo has comps file f9a0334a0fac7d497531201c75888ee978513c89-comps.xml.gz.
Repo has 972 errata.
Sync completed.
Total time: 0:10:44

Is it possible to upgrade to Satellite 5.5 and check again? Or try it with Spacewalk 2.0? That way, at least we'll know whether older versions of Satellite support the updateinfo.xml errata or not.

Posted by Avi Miller on October 09, 2013 at 12:43 PM PDT #

Thanks, Avi. Since I don't see the comps or errata messages in my logs, I suspect that you're right about it being a version thing. Unfortunately, our monthly patch cycle/scaling and our new platform deployment (kickstart) backlog are such that I can't do a version upgrade right now, so I'll have to use the workaround for the time being.

I have opened a case with Red Hat regarding the failure of spacewalk-repo-sync to retrieve and insert data, and will post back with response. They should be able to tell me at what version of Satellite the feature was implemented.

Posted by J Epperson on October 10, 2013 at 07:11 AM PDT #


This has been fixed in spacewalk-backend-1.9.1-1. You can refer to this bug I opened

Kind regards,

Posted by Daniel Schindler on October 10, 2013 at 07:24 AM PDT #

I had seen Daniel's bugzilla report, but did not have those symptoms and was running Satellite rather than spacewalk, per se, so applicability was not clear.

Red Hat response on my case:
"The spacewalk-repo-sync utility is satellite 5.4 does not sync errata. This is a know limitation is satellite 5.4 and this feature is added to spacewalk-repo-sync utility in satellite 5.5."

Posted by guest on October 11, 2013 at 04:34 AM PDT #

Great, thanks for the update. We can now let existing Satellite customers know that they'll need to be running Satellite 5.5 to get automatic errata sync.

Posted by Avi Miller on October 11, 2013 at 02:32 PM PDT #

I've tried to test this documentation using spacewalk 2. I had problem with provisioning using kickstart. I had the spacewalk-2.0-client as child channel and added the rhn-setup package on my ks profile.

My kickstart complained about missing repomd.xml for my child channel. My question is how can I subscribe my server to spacewalk if I can't install those package from child channel during ks?

Posted by guest on November 05, 2013 at 12:14 PM PST #


repomd.xml is created by Spacewalk when it generates the yum metadata for the channel. It sounds like the spacewalk-2.0-client channel hasn't been successfully created yet, so there is no yum metadata available, which means packages can't be installed.

This blog isn't a great place to provide support, and Oracle doesn't really support the upstream Spacewalk project, so I suggest you use the Spacewalk mailing lists or IRC channels for more assistance.


Posted by Avi Miller on November 05, 2013 at 12:24 PM PST #

I have exactly the same problem.
We are almost a year later.
Do you have a solution ?

Posted by guest on February 17, 2014 at 03:39 PM PST #

We've tested this through QA and it works with the Spacewalk 2.0 packages delivered on I've also re-tested this locally, so you just need to make sure that both your parent and child channels are fully functional prior to configuring the kickstart. Once the channels are working, a kickstart installation should work just fine.

Note that you will need to ensure that you do not install the up2date and up2date-gnome packages if you're trying to kickstart OL5 as these conflict with the Spacewalk provided client packages.

Posted by Avi Miller on February 17, 2014 at 03:44 PM PST #

Are there plans to continue releasing Oracle packaged Spacewalk releases, such as the recent 2.1 branch, or will 2.0 be it?

Posted by guest on March 24, 2014 at 03:06 PM PDT #

We are currently working on ULN integration for Spacewalk and the upcoming release of Oracle Linux 7. We will be releasing new versions of Spacewalk in time, after the integration work with ULN is complete. We have evaluated the 2.1 release and there were no critical bug fixes that needed immediate release. If you have a particular issue with 2.0, please log an SR.

Posted by Avi Miller on March 24, 2014 at 03:18 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Get the latest updates on strategy, products, events, news, customers, partners and all things Oracle Linux! Connect with Oracle's Linux experts.

Stay Connected




« April 2014