Release: Red Hat Network Satellite 4.0

Background

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.

Resolution

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.

NOTES:

• 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-');
   
   commit;
   quit;
   
   

   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:

   /var/cache/rhn/list_all_packages_complete-solaris-8
   /var/cache/rhn/list_all_packages_complete-solaris-9
   

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

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.

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>
     <servlet-name>  sysinfo </servlet-name>

     <servlet-class>
     com.netscape.cms.servlet.base.SystemInfoServlet</servlet-class>
     <init-param><param-name>  GetClientCert  </param-name>
     <param-value> false </param-value> </init-param>

     <init-param><param-name>  ACLinfo     </param-name>
     <param-value> certServer.ca.sysinfo:read:allow (read)
     user="anybody":anybody </param-value> </init-param>
     <init-param><param-name>  AuthzMgr    </param-name>

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

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

   <servlet-mapping>

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

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 http://java.sun.com/j2se/1.3/docs/api/java/lang/Runtime.html.

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

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.

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.

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
glibc-2.3.2-95.20.x86_64
glibc-2.3.2-95.20.i686