Issue #16 February 2006

Tips & tricks

Red Hat's customer service team receives technical support questions from users all over the world. As they are received, Red Hat technicians add the questions and answers to the Red Hat Knowledgebase on a daily basis. Individuals with a login are granted access. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.

Tips from RHCEs

Remote control of Red Hat Enterprise Linux boxes without VNC configuration

It's no secret that system administrators often like to remote control a user's Red Hat Enterprise Linux desktop without the mess of configuring VNC. With Red Hat Enterprise Linux 4, this is now possible. Red Hat Enterprise Linux 4 provides the GNOME desktop with a vnc like service called vino. It will allow a VNC client to remotely control the logged in users native GNOME desktop and enable desktop sharing.

To activate the target user's desktop, do the following:

  1. log in
  2. click Applications --> Preferences --> Remote Desktop and check 'Allow other users to view your desktop' checkbox.
  3. Hit close.

Voila! It's that easy. A remote VNC client can then access the current users GNOME desktop by pointing it to display :0 on the machine.

Why does my Solaris patch installation fail?

Release: Red Hat Network Satellite 4.0


Red Hat Network (RHN) Satellite supports Solaris Technology as part of the RHN Satellite 4.0 release. One possible reason why patches fail to install is because of a bug within the solaris2mpm command that was released with Satellite 4.0.0 and 4.0.1 under the right conditions, generated incorrect data to be associated with the patch.

If the system runs the Solaris client command with verbose output, such as rhn_check -vvv, this output should be seen:

Computing transaction...
D: Sending back response (102, "Patch install failed: Can't install
patch-solaris-112805-01-1: no package provides patch-solaris- >= 01",
{'version': 0, 'name': 'solarispkgs.patchInstall'})

The key part to this error message is "patch-solaris-". The solaris2mpm command is part of the rhnpush package. If the patch mpms were created using rhnpush < rhnpush-4.0.5-62.rhel3 or rhnpush < rhnpush-4.0.5-63.rhel4, the mpms could possibly contain this incorrect "patch-solaris-" dependency information.


This is a two part resolution. The first is to run a small SQL script on the Satellite server database to remove this information. The second is to delete any channel cache files from the Satellite that may have been generated that also contain this data.


  • Have the database administrator (DBA) perform these tasks if the RHN Satellite is an external Oracle database

  • If the system is running an embedded database, then follow these commands exactly:

  1. Determine how many packages are current affected by this issue in the database, create a text file with name check.sql and contents:

    select count(*) as "Total bad entries" from rhnpackagerequires where capability_id in (
    select id from rhnpackagecapability where name='patch-solaris-');

    Run this SQL query as root on the RHN Satellite server with command /opt/oracle/bin/sqlplus rhnsat/rhnsat@rhnsat @check.sql.

  2. If needed, delete the incorrect data from the database. To do this, create another text file with name delete.sql and contents:

    delete from rhnpackagerequires where capability_id in (
    select id from rhnpackagecapability where name='patch-solaris-');

    Run this SQL query as root on the RHN Satellite server with command /opt/oracle/bin/sqlplus rhnsat/rhnsat@rhnsat @delete.sql.

  3. Re-run the first command to confirm that all incorrect data has been removed.

  4. Now, delete the RHN Satellite channel cache files. These files will be automatically regenerated as soon as a client system requests the data. These files are created to match the Channel associated with them; example files are:


    Use the ls and rm command to list and delete the appropriate files from the /var/cache/rhn/ directory.

What is a Self-Signed Cert and how can they be identified with Issuer and Subject Distinguished Names?

A self-signed certificate is a certificate that is digitally signed by the same entity. For example, the Root CA that the certificate identifies.

In order to identify them, look in the details of the self-signed certificate. The Issuer or Issuer Distinguished Name (DN) and Subject Distinguished Name (DN) will be the same. For example:

Issuer: CN=Certificate Manager,O=TestOrg,C=US
Subject: CN=Certificate Manager,O=TestOrg,C=US

Note: Netscape Certificate Management System (CMS) is now called Red Hat Certificate System.

What is the best way to determine if a system is nearing the memory threshold while generating a Certificate Revocation List (CRL) with Red Hat Certificate System?

To determine if a system is nearing the memory threshold, enable the SystemInfoServlet functionality. Enable this on the End Entity (EE) interface and use wget or some similar tool to poll the stats of the server to see how memory usage is growing as the Certificate Revocation List (CRL) is being built.

Edit the <server-root>/cert-xxx/web-apps/ee/WEB-INF/web.xml file. At the top of the file, register the servlet. Add this immediately after the web-app line.

     <servlet-name>  sysinfo </servlet-name>

     <init-param><param-name>  GetClientCert  </param-name>
     <param-value> false </param-value> </init-param>

     <init-param><param-name>  ACLinfo     </param-name>
     <param-value> (read)
     user="anybody":anybody </param-value> </init-param>
     <init-param><param-name>  AuthzMgr    </param-name>

     <param-value> BasicAclAuthz </param-value> </init-param>

At the bottom of the file, add a servlet mapping:


      <servlet-name>  sysinfo </servlet-name>
      <url-pattern>   /sysinfo </url-pattern>

Once the CA instance is restarted, visit the URL http://{YourEndEntityPage}/sysinfo to view useful stats. For example:

Server Started Time:    Thu Apr 28 15:00:25 PDT 2005
Current Time:   Thu Apr 28 15:01:38 PDT 2005
Available Processors:   1
Active Threads:         25
Max Memory (in Bytes):  512000000
Total Memory (in Bytes):        12384768
Free Memory (in Bytes):         6399864
Free Memory / Total Memory:     51%

Max, Total, and Free memory values are determined by the calls to Runtime.getRuntime(), {maxMemory(), totalMemory(), and freeMemory()} respectively. The API's and definitions for some of these functions can be found at

Note: Netscape Certificate Management System (CMS) is now called Red Hat Certificate System.

How do I add a Builtin Root CA Certificate into Network Security Services (NSS)?

The original article can be found at the Newsgroup: netscape.public.mozilla.crypto

This tech note explains how to add a builtin root CA certificate to Network Security Services (NSS). The builtin root CA certificates in NSS are stored in the nssckbi PKCS #11 module. The sources to the nssckbi module are in the mozilla/security/nss/lib/ckfw/builtins directory. Use the addbuiltin command-line tool to add a root CA certificate to the nssckbi module. In the procedure described below, it is assumed that the new root CA certificate is distributed in DER format in the file newroot.der.

  1. Build addbuiltin by using gmake in the mozilla/security/nss/cmd/addbuiltin directory. (As of NSS 3.5, addbuiltin is not built by default.)
  2. Add the directory where the addbuiltin executable resides to your PATH environment variable. Then, add the directory where the NSPR and NSS shared libraries (DLLs) reside to the platform-specific environment variable that specifies the shared library search path: LD_LIBRARY_PATH (most Unix variants), SHLIB_PATH (32-bit HP-UX), LIBPATH (AIX), or PATH (Windows).
  3. Copy newroot.der to the mozilla/security/nss/lib/ckfw/builtins directory.
  4. In the mozilla/security/nss/lib/ckfw/builtins directory, execute addbuiltin to add the new root certificate. The argument to the -n option should be substituted by the name of the root certificate. Then execute:
    % gmake generate
    % cd mozilla/security/nss/lib/ckfw/builtins 
    % addbuiltin -n "Name of the Root Certificate" -t C,C,C < newroot.der >> certdata.txt 
    % gmake generate
  5. Edit constants.c to bump the version of the module.
  6. Execute gmake in mozilla/security/nss/lib/ckfw/builtins to build the nssckbi module.
  7. Verify the new nssckbi module is correct, then check in certdata.txt, certdata.c, and constants.c.

Note: Netscape Certificate Management System (CMS) is now called Red Hat Certificate System.

How can I install an i386 package with up2date on a x86_64/EM64T system?

Some third party applications require 32 bit versions of libraries to be installed when running on 64 bit system.

To install the latest version of the 32 bit package and automatically resolve dependencies, use the command:

up2date -u [package-name] --arch=i386

For example:

up2date -u xorg-x11-deprecated-libs --arch=i386

This would install the xorg-x11-deprecated-libs and associated 32 bit dependencies.

Why do I see duplicate packages when querying the rpm database?

Some applications require 32 bit versions of libraries to be installed when running on 64 bit machines. These packages can usually be installed at the same time.

The architecture of an installed package can be shown with the command:

rpm -q --queryformat="%{n}-%{v}-%{r}.%{arch}\n" packagename

This would query the package "packagename" for its name, version, revision and architecture.

Below is the example for glibc on a 64 bit x86 system:

# rpm -q --queryformat="%{n}-%{v}-%{r}.%{arch}\n" glibc

The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

This article is protected by the Open Publication License, V1.0 or later. Copyright © 2004 by Red Hat, Inc.