Description of problem: Can not delete DS instance from Console Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. setup a complete ds admin and ds slapd server 2. launch console, login as cn=directory manager (or admin) 3. create a new DS instance 4. delete this DS instance Actual results: error window comes out, operation failed Expected results: new DS instance deleted Additional info: please see screen shot and log msg
Created attachment 329522 [details] can not delete ds instance from console UI
Additional notes: 1. I have been testing the same dirsrv server in the past two days, and especially i have done a lot with configuration through UI. This might leave the ds server in a weird stage. 2. error logs 2-1: the admit server has the following complain while CREATING the new instance [Tue Jan 20 16:01:47 2009] [notice] [client 10.14.0.145] admserv_host_ip_check: ap_get_remote_host could not resolve 10.14.0.145 [Tue Jan 20 16:01:47 2009] [crit] [client 10.14.0.145] configuration error: couldn't check access. No groups file?: /Tasks/Operation/Create [Tue Jan 20 16:01:52 2009] [notice] [client 10.14.0.145] admserv_host_ip_check: ap_get_remote_host could not resolve 10.14.0.145 2-2: and when i was trying to remove the new created instance, the admit server has the following : [Tue Jan 20 16:02:07 2009] [notice] [client 10.14.0.145] admserv_host_ip_check: ap_get_remote_host could not resolve 10.14.0.145 [Tue Jan 20 16:02:08 2009] [error] [client 10.14.0.145] (os 0x005e5652)Unrecognized resolver error: mod_restartd: attempt to run unknown program at /slapd-dsx4/Tasks/Operation/Remove. Bailing out. [Tue Jan 20 16:02:08 2009] [crit] [client 10.14.0.145] configuration error: couldn't check access. No groups file?: /Tasks/Operation/Remove [Tue Jan 20 16:02:08 2009] [error] [client 10.14.0.145] Error: [Tue Jan 20 16:02:08 2009] [error] [client 10.14.0.145] Could not authenticate as user 'uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot' to server 'ldap://dsx.rhqa.net:389/o=NetscapeRoot'. Error: DSA is unwilling to perform [Tue Jan 20 16:02:08 2009] [error] [client 10.14.0.145] 2-3: the dirsrv access log has following [20/Jan/2009:16:08:03 -0800] conn=828 op=0 BIND dn="" method=128 version=3 [20/Jan/2009:16:08:03 -0800] conn=828 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [20/Jan/2009:16:08:03 -0800] conn=828 op=1 BIND dn="uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot" method=128 version=3 [20/Jan/2009:16:08:03 -0800] conn=828 op=1 RESULT err=53 tag=97 nentries=0 etime=0 [20/Jan/2009:16:08:03 -0800] conn=828 op=2 UNBIND [20/Jan/2009:16:08:03 -0800] conn=828 op=2 fd=67 closed - U1
Try this: edit /etc/dirsrv/admin-serv/admserv.conf look for this: ## turn off the password pipe when using mod_restartd AdminSDK off change the off to on /usr/sbin/restart-ds-admin Does remove work now?
*** admserv.conf.in.~1.11.~ 2008-03-17 08:59:05.000000000 -0600 --- admserv.conf.in 2009-01-21 13:33:05.000000000 -0700 *************** *** 124,131 **** AuthType basic AuthName "Admin Server" Require valid-user ! ## turn off the password pipe when using mod_restartd ! AdminSDK off ADMCgiBinDir @cgibindir@ Options +ExecCGI RetainPerms on --- 124,130 ---- AuthType basic AuthName "Admin Server" Require valid-user ! AdminSDK on ADMCgiBinDir @cgibindir@ Options +ExecCGI RetainPerms on
Reviewed by: nhosoi (Thanks!) Fix Description: The problem is that ds_remove does not get the admin bind dn and password, and attempts to make an anonymous bind. This fails with err=53 because DS 8.1 will not allow anonymous bind by default. The solution is to allow the admin server to pass the dn and password to the ds_remove process. Platforms tested: RHEL5 Flag Day: no Doc impact: no Checking in adminserver/admserv/cfgstuff/admserv.conf.in; /cvs/dirsec/adminserver/admserv/cfgstuff/admserv.conf.in,v <-- admserv.conf.in new revision: 1.12; previous revision: 1.11 done
i modified the conf file and restart the test vm, but the dirsrv can not start. [root@dsx slapd-dsx]# service dirsrv start dsx Starting dirsrv: dsx.../etc/init.d/dirsrv: line 128: 2825 Segmentation fault $exec -D $instbase/slapd-$instance -i $pidfile -w $startpidfile [FAILED] *** Warning: 1 instance(s) failed to start The Segmentation fault might not be triggered by this change. I will do more test later.
Since the change should only affect the admin server, I'm completely baffled as to why it would cause the directory server to crash.
As it turns out, we just need to enable the password pipe for the remove task, and leave it disabled for the other tasks. *** admserv.conf.in.~1.12.~ 2009-01-21 13:33:05.000000000 -0700 --- admserv.conf.in 2009-01-22 14:38:00.000000000 -0700 *************** *** 119,125 **** # Handle Stop, Start, Restart, Instance Creation - invoke mod_restartd # need to add instance creation because you may want to create an instance # of DS on a low port, and instance creation starts the instance as well ! <LocationMatch /*/[tT]asks/[Oo]peration/(?i:stop|start|restart|startconfigds|create|remove)$> AuthUserFile @configdir@/admpw AuthType basic AuthName "Admin Server" --- 119,140 ---- # Handle Stop, Start, Restart, Instance Creation - invoke mod_restartd # need to add instance creation because you may want to create an instance # of DS on a low port, and instance creation starts the instance as well ! <LocationMatch /*/[tT]asks/[Oo]peration/(?i:stop|start|restart|startconfigds|create)$> ! AuthUserFile @configdir@/admpw ! AuthType basic ! AuthName "Admin Server" ! Require valid-user ! ## turn off the password pipe when using mod_restartd ! AdminSDK off ! ADMCgiBinDir @cgibindir@ ! Options +ExecCGI ! RetainPerms on ! Order allow,deny ! Allow from all ! </LocationMatch> ! ! # special case for the remove task - it needs to use the password pipe ! <LocationMatch /*/[tT]asks/[Oo]peration/(?i:remove)$> AuthUserFile @configdir@/admpw AuthType basic AuthName "Admin Server"
Checking in admserv.conf.in; /cvs/dirsec/adminserver/admserv/cfgstuff/admserv.conf.in,v <-- admserv.conf.in new revision: 1.13; previous revision: 1.12 done
I will verify this with Jan 26th's daily build.
Tested with Jan. 26th's daily build. * The result from Console UI: pass, the instance removed successful from UI * The configuration directory: pass, /etc/dirsrv/slapd-<inst-name> renamed to "slapd-<inst-name>.removed" * The data directory: ? <please confirm> /var/lib/dirsrv/slapd-<inst-name> exist but empty (please confirm this behave). * The admin error log has the following: (there are some negative type message, please confirm as well) [Mon Jan 26 13:41:36 2009] [notice] [client 10.14.0.145] admserv_host_ip_check: ap_get_remote_host could not resolve 10.14.0.145 [Mon Jan 26 13:41:36 2009] [error] [client 10.14.0.145] (os 0x0031d652)Unrecognized resolver error: mod_restartd: attempt to run unknown program at /slapd-yinew/Tasks/Operation/Remove. Bailing out. [Mon Jan 26 13:41:39 2009] [error] [client 10.14.0.145] Can't remove directory /var/lib/dirsrv/slapd-yinew: Permission denied at /usr/lib/dirsrv/cgi-bin/ds_remove line 63 [Mon Jan 26 13:41:39 2009] [error] [client 10.14.0.145] Can't remove directory /var/lib/dirsrv/slapd-yinew: Permission denied at /usr/lib/dirsrv/cgi-bin/ds_remove line 63 [Mon Jan 26 13:41:39 2009] [error] [client 10.14.0.145] Warning: /var/lib/dirsrv/slapd-yinew was not removed. [Mon Jan 26 13:41:39 2009] [error] [client 10.14.0.145] Can't remove directory /var/lock/dirsrv/slapd-yinew: Permission denied at /usr/lib/dirsrv/cgi-bin/ds_remove line 63 [Mon Jan 26 13:41:39 2009] [error] [client 10.14.0.145] Can't remove directory /var/lib/dirsrv/slapd-yinew: Permission denied at /usr/lib/dirsrv/cgi-bin/ds_remove line 63 [Mon Jan 26 13:41:39 2009] [error] [client 10.14.0.145] Warning: /var/lib/dirsrv/slapd-yinew was not removed. [Mon Jan 26 13:41:39 2009] [error] [client 10.14.0.145] Can't remove directory /var/log/dirsrv/slapd-yinew: Permission denied at /usr/lib/dirsrv/cgi-bin/ds_remove line 63 [Mon Jan 26 13:41:48 2009] [notice] [client 10.14.0.145] admserv_host_ip_check: ap_get_remote_host could not resolve 10.14.0.145
And, I still have to manually change the line ## turn off the password pipe when using mod_restartd AdminSDK off to ## turn off the password pipe when using mod_restartd AdminSDK on --- please confirm this as well (I thought we change this conf file default to "on")
Index: mod_restartd-2.2.c =================================================================== RCS file: /cvs/dirsec/mod_restartd/mod_restartd-2.2.c,v retrieving revision 1.2 diff -u -8 -r1.2 mod_restartd-2.2.c --- mod_restartd-2.2.c 12 Jan 2009 16:47:33 -0000 1.2 +++ mod_restartd-2.2.c 26 Jan 2009 22:21:04 -0000 @@ -916,17 +916,17 @@ if ((cgid_pfn_reg_with_ssi) && (cgid_pfn_gtv) && (cgid_pfn_ps)) { /* Required by mod_include filter. This is how mod_cgid registers * with mod_include to provide processing of the exec directive. */ cgid_pfn_reg_with_ssi("exec", handle_exec); } } - ap_regcomp(&uriPat, "/.*/tasks/operation/(start|restart|stop|startconfigds|create)$", + ap_regcomp(&uriPat, "/.*/tasks/operation/(start|restart|stop|startconfigds|create|remove)$", AP_REG_ICASE); return ret; } static void *create_cgid_config(apr_pool_t *p, server_rec *s) { cgid_server_conf *c =
Checking in mod_restartd-2.2.c; /cvs/dirsec/mod_restartd/mod_restartd-2.2.c,v <-- mod_restartd-2.2.c new revision: 1.3; previous revision: 1.2 done
Rich, another side effect that might caused by this: slapd can NOT stop/restart from the console. Noriko help me to change the admin-server-httpd log level to debug, and we found this in admin server's error log file while we click the "stop slapd" from "Tasks" panel: [Tue Jan 27 10:20:02 2009] [notice] [client 10.14.0.145] admserv_host_ip_check: ap_get_remote_host could not resolve 10.14.0.145 [Tue Jan 27 10:20:02 2009] [debug] mod_admserv.c(2748): [client 10.14.0.145] checking user cache for: cn=directory manager [Tue Jan 27 10:20:02 2009] [debug] mod_admserv.c(2751): [client 10.14.0.145] user found in cache cn=directory manager [Tue Jan 27 10:20:02 2009] [debug] mod_admserv.c(1580): [client 10.14.0.145] admserv_check_authz: request for uri [/slapd-dsx/Tasks/Operation/Stop] [Tue Jan 27 10:20:02 2009] [debug] mod_admserv.c(1079): [client 10.14.0.145] check_auth_tasks_cache: task entry [cn=stop,cn=operation,cn=tasks,cn=slapd-dsx,cn=red hat directory server,cn=server group,cn=dsx.rhqa.net,ou=rhqa.net,o=netscaperoot] not cached [Tue Jan 27 10:20:02 2009] [debug] mod_admserv.c(1803): [client 10.14.0.145] admserv_check_authz: uri [Tasks/Operation/Stop] did not begin with [commands/] - not a command [Tue Jan 27 10:20:02 2009] [debug] mod_admserv.c(1856): [client 10.14.0.145] admserv_check_authz: execute CGI [/usr/lib/dirsrv/cgi-bin/ds_shutdown] args [(null)] please look into it
All of this output is normal for debug mode. I don't see any errors here.
when add instance, it fails. (please note that I am using the same build from yesterday). And admin server has the following msg: [Tue Jan 27 10:29:11 2009] [notice] [client 10.14.0.145] admserv_host_ip_check: ap_get_remote_host could not resolve 10.14.0.145 [Tue Jan 27 10:29:11 2009] [debug] mod_admserv.c(2748): [client 10.14.0.145] checking user cache for: cn=directory manager [Tue Jan 27 10:29:11 2009] [debug] mod_admserv.c(2751): [client 10.14.0.145] user found in cache cn=directory manager [Tue Jan 27 10:29:11 2009] [debug] mod_admserv.c(1580): [client 10.14.0.145] admserv_check_authz: request for uri [/slapd/Tasks/Operation/Create] [Tue Jan 27 10:29:11 2009] [debug] mod_admserv.c(1803): [client 10.14.0.145] admserv_check_authz: uri [Tasks/Operation/Create] did not begin with [commands/] - not a command [Tue Jan 27 10:29:11 2009] [debug] mod_admserv.c(1856): [client 10.14.0.145] admserv_check_authz: execute CGI [/usr/lib/dirsrv/cgi-bin/ds_create] args [(null)] Error: could not open PASSWORD_PIPE 34: Bad file descriptor at /usr/lib/dirsrv/perl/AdminUtil.pm line 620. [Tue Jan 27 10:29:14 2009] [error] [client 10.14.0.145] Premature end of script headers: ds_create
This should be fixed once we have an admin server respin
reopening bug
Created attachment 333382 [details] new patch for ds
Created attachment 333383 [details] new patch for admin
Created attachment 333479 [details] cvs commit log Reviewed by: nkinder (Thanks!) Fix Description: As it turns out, my assumption that ds_remove in CGI mode also did the unregistration was false. It is the console that does the unregistration, only after the ds_remove CGI returns success. So, ds_remove needs to run with AdminSDK off, just like the other "special" CGI programs. In addition, ds_remove needs to be more robust - if there is an error during ds_remove, you should be allowed to try again after fixing something. However, the way the error handling worked did not differentiate between fatal errors and errors that could be ignored. In order to do this properly, we need to propagate the errors back up to the top level (oh how I wish perl had real exception handling . . .). The main type of error we need to ignore is file not found or process not found. If we attempted to remove before and that attempt failed for some reason, and left a partial instance, we need to be able to run the remove command again, skipping over the things we shutdown or removed already, and clean up the stuff we need to remove. This can also happen if you use the console to create a ds instance, and remove-ds.pl to remove the instance. The instance will still show up in the console. We need to be able to use the Remove Server in the console to remove the instance from the console, even through there is no physical instance on disk any more. Since the console will only do the unregistration if the CGI returns success, we need to make sure the CGI returns success even though there is no instance on disk. When ds_remove is run via ds_removal, it will do the unregistration. I also took this opportunity to refactor the remove code, creating a removeDSInstance method in DSCreate.pm, and moving some of the other removal helper functions to Util.pm. That simplified the code in both ds_remove and remove-ds.pl. I added a remove-ds-admin.pl script - one of the problems that users have is that they run setup-ds-admin.pl, then hit some error (e.g. bad DNS setup), then find that they cannot restore the system to the state before they ran setup-ds-admin.pl. remove-ds-admin.pl does this. Finally, I added some man pages to the admin package for those commonly used commands. Platforms tested: RHEL4 Flag Day: yes - configure change Doc impact: yes - will need to document the new command remove-ds-admin.pl
re-test on rhel 4 i386 platform, the test I ran is to create a new instance. And the test faileD. From the UI error dialogue, it seems relate to this problem. Please check the attached screen shot my test step is below: 1. install clean rhel4 i386 vm 2. install ds8.1 admin server, ds server and console 3. launch console, login as "cn=directory manager" 4. create a new instance. --> test result : failed ==> Additional notes, I install the DS as below: setup-ds-admin.pl -s -f ds4a.ini and ds4a.ini has following content: -------------------- [root@ds4a ~]# cat /home/yi/ds4a.ini [General] FullMachineName= ds4a.mvqa.net SuiteSpotUserID= yi SuiteSpotGroup= yi AdminDomain= mvqa.net ConfigDirectoryAdminID= admin ConfigDirectoryAdminPwd= redhat123 ConfigDirectoryLdapURL= ldap://ds4a.mvqa.net:9830/o=NetscapeRoot [slapd] SlapdConfigForMC= Yes UseExistingMC= No ServerPort= 3890 ServerIdentifier= ds4a Suffix= o=test.org RootDN= cn=directory manager RootDNPwd= redhat123 InstallLdifFile= suggest AddOrgEntries= Yes inst_dir= /home/yi/slapd-ds4a config_dir= /home/yi/slapd-ds4a schema_dir= /home/yi/slapd-ds4a/schema lock_dir= /home/yi/slapd-ds4a/lock log_dir= /home/yi/slapd-ds4a/logs run_dir= /home/yi/slapd-ds4a/logs db_dir= /home/yi/slapd-ds4a/db bak_dir= /home/yi/slapd-ds4a/bak tmp_dir= /home/yi/slapd-ds4a/tmp ldif_dir= /home/yi/slapd-ds4a/ldif cert_dir= /home/yi/slapd-ds4a [admin] SysUser= yi Port= 9830 ServerIpAddress= 192.168.122.101 ServerAdminID= admin ServerAdminPwd= redhat123 [root@ds4a ~]# =================================================== ================= Build info ===================== =================================================== -------------------- [root@ds4a ~]# rpm -qi redhat-ds-admin-8.1.0-6.el4dsrv Name : redhat-ds-admin Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 6.el4dsrv Build Date: Mon 02 Mar 2009 02:03:55 PM EST Install Date: Tue 10 Mar 2009 06:12:56 AM EDT Build Host: hs20-bc2-5.build.redhat.com Group : System Environment/Daemons Source RPM: redhat-ds-admin-8.1.0-6.el4dsrv.src.rpm Size : 1018932 License: GPLv2 Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.redhat.com/directory_server Summary : Red Hat Administration Server (admin) ------------------------- [root@ds4a ~]# rpm -qi redhat-ds-console-8.1.0-2.el4dsrv Name : redhat-ds-console Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 2.el4dsrv Build Date: Tue 03 Mar 2009 05:54:12 PM EST Install Date: Tue 10 Mar 2009 06:12:56 AM EDT Build Host: ls20-bc2-14.build.redhat.com Group : Applications/System Source RPM: redhat-ds-console-8.1.0-2.el4dsrv.src.rpm Size : 1713809 License: GPLv2 Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.redhat.com/directory_server/ Summary : Red Hat Directory Server Management Console ----------------------------------------- [root@ds4a ~]# rpm -qi redhat-ds-base-8.1.0-20090309.el4dsrv Name : redhat-ds-base Relocations: (not relocatable) Version : 8.1.0 Vendor: Red Hat, Inc. Release : 20090309.el4dsrv Build Date: Mon 09 Mar 2009 04:18:45 AM EDT Install Date: Tue 10 Mar 2009 06:12:55 AM EDT Build Host: hs20-bc1-7.build.redhat.com Group : System Environment/Daemons Source RPM: redhat-ds-base-8.1.0-20090309.el4dsrv.src.rpm Size : 4662167 License: GPLv2 with exceptions Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.redhat.com/directory_server/ Summary : Red Hat Directory Server (base)
Created attachment 334724 [details] screen shot : can not create a new instance
So create instance fails, restart fails - anything else? Does create instance work if you install things in their FHS places, not in custom places as you have done in your ds4a.ini file?
Also, just to confirm - did create instance ever work when you ran setup with your .ini file? If so, when? Earlier in the DS 8.1 cycle? With DS 8.0?
create instance from .ini file works for me in both RHEL 5.3 x86_64 platform and RHEL 4.7 i386 platform. The DS build tested on RHEL 5.3 was the last build before the March 2 respon. The build tested on RHEL 4.7 is what I listed above.
Just tried on fresh installed RHEL 5.3 x86_64 platform with standard user interactive install. We are not be able to create a new instance from Console. The admin server error log has the following: [Thu Mar 12 14:04:31 2009] [notice] SELinux policy enabled; httpd running as context root:system_r:unconfined_t:SystemLow-SystemHigh [Thu Mar 12 14:04:32 2009] [notice] Access Host filter is: *.mvqa.net [Thu Mar 12 14:04:32 2009] [notice] Access Address filter is: * [Thu Mar 12 14:04:33 2009] [notice] Apache/2.2 configured -- resuming normal operations [Thu Mar 12 14:04:33 2009] [notice] Access Host filter is: *.mvqa.net [Thu Mar 12 14:04:33 2009] [notice] Access Address filter is: * [Thu Mar 12 14:05:03 2009] [notice] [client 192.168.122.132] admserv_host_ip_check: ap_get_remote_host could not resolve 192.168.122.132 [Thu Mar 12 14:05:03 2009] [notice] [client 192.168.122.132] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler [Thu Mar 12 14:05:11 2009] [notice] [client 192.168.122.132] admserv_host_ip_check: ap_get_remote_host could not resolve 192.168.122.132 [Thu Mar 12 14:05:11 2009] [error] [client 192.168.122.132] File does not exist: /usr/share/dirsrv/html/java/jars [Thu Mar 12 14:05:11 2009] [notice] [client 192.168.122.132] admserv_host_ip_check: ap_get_remote_host could not resolve 192.168.122.132 [Thu Mar 12 14:05:11 2009] [notice] [client 192.168.122.132] admserv_host_ip_check: ap_get_remote_host could not resolve 192.168.122.132 [Thu Mar 12 14:05:19 2009] [notice] [client 192.168.122.132] admserv_host_ip_check: ap_get_remote_host could not resolve 192.168.122.132 [Thu Mar 12 14:05:19 2009] [crit] [client 192.168.122.132] configuration error: couldn't check access. No groups file?: /Tasks/Operation/Stop [Thu Mar 12 14:05:28 2009] [notice] [client 192.168.122.132] admserv_host_ip_check: ap_get_remote_host could not resolve 192.168.122.132 [Thu Mar 12 14:05:28 2009] [crit] [client 192.168.122.132] configuration error: couldn't check access. No groups file?: /Tasks/Operation/Start [Thu Mar 12 14:06:05 2009] [notice] [client 192.168.122.132] admserv_host_ip_check: ap_get_remote_host could not resolve 192.168.122.132 [Thu Mar 12 14:06:05 2009] [crit] [client 192.168.122.132] configuration error: couldn't check access. No groups file?: /Tasks/Operation/Create
additional test on above environment: start/stop/restart DS instance from console works fine.
Checking in FileConn.pm; /cvs/dirsec/ldapserver/ldap/admin/src/scripts/FileConn.pm,v <-- FileConn.pm new revision: 1.7; previous revision: 1.6 done Fix Description: Create instance was broken, so no instances could be created for purposes of deletion. Create instance was printing the following error: Unable to find Pass Through Authentication Plug-In config entry. This is because the search for this entry in AdminUtil.pm was getting an incorrect error message - something other than "Success" This is because the FileConn->getErrorString() method was returning "0" instead of "Success". Platforms tested: RHEL4 Index: FileConn.pm =================================================================== RCS file: /cvs/dirsec/ldapserver/ldap/admin/src/scripts/FileConn.pm,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- FileConn.pm 27 Feb 2009 14:33:12 -0000 1.6 +++ FileConn.pm 12 Mar 2009 22:12:59 -0000 1.7 @@ -213,7 +213,7 @@ sub getErrorString { my $self = shift; - return ($self->{lastErrorCode} ? ldap_err2string($self->{lastErrorCode}) : LDAP_SUCCESS); + return ldap_err2string($self->{lastErrorCode}); }
this bug has been verified at all RHEL 4 & 5 platform, window 2003, solaris 9. I will verify it at HP-UX soon
verified on HPUX. bug has been fixed in this platform. bug can be closed now
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html