smp@cerc.wvu.wvnet.edu (Shailesh M. Potnis) (02/27/91)
I am having problems in disabling the access control on the personal iris machines. If I give the command xhost + prior to xterm, the system comes back with the message that access control disabled. If one tries to check the allowed hosts by the xhost command iris lists only the local host and the current machine. One cannot display applications from remote servers on this display. However if one has opened any applications like xterm prior to disabling the access control by the command xhost + then everything goes as per the book. What can be the reason for this inconsistancy? and are there any fixes for this. All comments and suggestions appreciated. Shailesh
laplante@ocgy.ubc.ca (Denis Laplante) (02/27/91)
In article <1377@babcock.cerc.wvu.wvnet.edu>, smp@cerc.wvu.wvnet.edu (Shailesh M. Potnis) writes: |> |> I am having problems in disabling the access control on the personal |> iris machines. My fix is to start up an extra new copy of the X server by running 'startx &'. It's best to have a file '.xinit' with sh commands, where the last command puts up a window (so you can tell when the initialization is done). At that point 'xhost' starts running normally on our machine.
rpw3@rigden.wpd.sgi.com (Rob Warnock) (02/27/91)
In article <1377@babcock.cerc.wvu.wvnet.edu> smp@cerc.wvu.wvnet.edu (Shailesh M. Potnis) writes: +--------------- | I am having problems in disabling the access control on the personal | iris machines. If I give the command xhost + prior to xterm, the system comes | back with the message that access control disabled. If one tries to check the | allowed hosts by the xhost command iris lists only the local host and the | current machine. One cannot display applications from remote servers on this | display. However if one has opened any applications like xterm prior to | disabling the access control by the command xhost + then everything goes as | per the book. | What can be the reason for this inconsistancy? and are there any | fixes for this. +--------------- The reason you see this behavior is that when the last client disconnects, the X server resets itself, preparing for another login. This is consistent with its normal use when "xdm" or some similar program is controlling top- level logins. You *want* the server to reset so the next user to login doesn't get any leftovers. But under 3.3.2, still using getty/login/NeWS/etc., the X server is fooled into thinking you've logged out each time it has no clients. What's happening is: 1. You run "xhost +foo" or "xhost +". 2. "xhost" connects to the X server, adds "foo" to the access list. 3. "xhost" exits, having done its work. 4. There are no more clients, so the X server resets the world, including the access list. 5. A subsequent "xhost" finds no foreign hosts enabled. The same thing also happens if you try to run "xrdb" by itself to load some resources, such as your ~/.Xdefaults. It works, but as soon as it exits, the X server says, "o.k., he's logged out, reset everything", and the resources disappear. Frustrating, as you've found out! (Me, too! ;-} ;-} ) This will be automatically fixed in Irix 4.0, which will use "xdm" for the X session control, but in the meantime you can "fake it" by starting up a long-lived X application (I run an "xclock") *before* running "xrdb" or xhost". -Rob ----- Rob Warnock, MS-1L/515 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311