Bug 167685 - include symlink to xserver SecurityPolicy
Summary: include symlink to xserver SecurityPolicy
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: redhat-lsb
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Lawrence Lim
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 145007
TreeView+ depends on / blocked
 
Reported: 2005-09-07 04:40 UTC by Lawrence Lim
Modified: 2014-03-26 00:52 UTC (History)
3 users (show)

Fixed In Version: redhat-lsb-3.1-10.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-07-13 04:55:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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. 


Note You need to log in before you can comment on or make changes to this bug.