Bug 167685

Summary: include symlink to xserver SecurityPolicy
Product: Red Hat Enterprise Linux 4 Reporter: Lawrence Lim <llim>
Component: redhat-lsbAssignee: Lawrence Lim <llim>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: eng-i18n-bugs, tools-bugs, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: redhat-lsb-3.1-10.2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-13 04:55:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 145007    

Description Lawrence Lim 2005-09-07 04:40:56 UTC
Description of problem:
To test lsb-vsw4, an external Xvfb has to be used. Unfortunately, the binary
hardcoded the path to the xserver SecurityPolicy to
/usr/X11R6/lib/X11/xserver/SecurityPolicy when our is located at 
/etc/X11/xserver/SecurityPolicy.

I was hoping redhat-lsb can set up the symlink to ease the burden of testing
lsb-vsw4 in EL4 especially via external vendors.

Version-Release number of selected component (if applicable):
redhat-lsb-3.0-8.EL

How reproducible:
always

Steps to Reproduce:
1. rpm -Uvh lsb-tet3-3.6b-8.lsb3.x86_64.rpm lsb-test-vsw4-3.0.0-4.x86_64.rpm
2. Download lsbsi-test (sample implementation) from the LSB site.
<http://www.linuxbase.org/download/#impl>
3. opy the new Xvfb from lsbsi to the /usr/X11R6/bin/
4. cd /opt/lsb/test/vsw4; ./run_vsw4.sh
  
Actual results:
Starting X Virtual Frame Buffer
error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy

Expected results:
Test able to run from start to finish

Additional info:

Comment 1 Leon Ho 2005-09-19 01:42:25 UTC
What does the X team think about this symlink for redhat-lsb?

Comment 3 Lawrence Lim 2005-09-26 00:09:26 UTC
In response to Comment #2,
No the LSB does not have a formal requirement to have the symlink present. The
new directory structure in X11R7 will only impact the next LSB release and not
the current LSB 3.0 which EL4 will certify till the end of product life cycle.

For LSB 3.0, Xvfb was used as a tool to test the Xlib in our system. As the Xvfb
included in EL4-U2 does not have backing store enabled, we were using the Xvfb
binaries from LSB Sample Implementation which have the path to the Security
Policy set to /usr/X11R6/lib/X11/xserver/SecurityPolicy rather than
/etc/X11/xserver/SecurityPolicy.

Hence, I created this bug to request for the symlink to be included in so that
our distro is more 'test friendly' for us and vendors. 

Comment 4 Mike A. Harris 2005-09-26 18:02:30 UTC
I believe that would lead down a very slippery slope that could drag in a
lot of extra "compatibility" junk, which is not really necessary.

Our Xvfb should work just fine AFAIK.   Enable backingstore from the commandline
using:  +bs

"Xvfb --help" for details.

The real problem seems to not be a missing symlink, but backingstore
availability in the Xvfb server.  I've shown how to turn that on now.

Can you confirm this solves your real underlying problem?



Comment 5 Lawrence Lim 2005-09-27 00:38:29 UTC
I understand your concern. Unfortunately, Xvfb is called within the Test Suite
binary rather than running from command line. I dont think modifying the Test
Suite to add in the option is 'legal', if not it would make life so much easier. :-)

Comment 6 Mike A. Harris 2005-09-27 08:17:47 UTC
How does it turn on backingstore in the non-Red Hat Xvfb server?

If it isn't passing the +bs option, how is it enabling backingstore
at all on any server it?  IMHO this is a bug/limitation in the test
suite, and the test suite itself should be fixed to work properly.

Another hack you could do, is to use a shellscript wrapper for Xvfb
that adds the +bs option, but I don't see how any local hacks should
be necessary on the Red Hat side.  Get the test suite fixed and the
problem is solved upstream where it should be IMHO.

Comment 8 Lawrence Lim 2006-07-13 04:55:40 UTC
Fixed in rawhide.