topic Re: X windows in Operating System - OpenVMS

X windows

Brian Reiter — Tue, 09 Mar 2004 09:38:53 GMT

Hi Folks,

On one of our legacy systems (I seem to have a lot of these to look after) we have a requirement to build up graphical data during startup. To do this the system makes use of the X-windows server. A number of complaints have been made by engineers indicating that this building of data fails when the machine (a DS10) is powered on.

My investigation has shown that the graphics data is only processed correctly when a user is logged in via a desktop session (logins via telnet etc. make no difference). Note - the process to build the graphical data is only run after dec windows has started.

The question is - is it possible for the our system to create an X-windows display (not visible) without having a user logged in?

thanks in advance for yout help

cheers

Brian

Are there any security

Re: X windows

labadie_1 — Tue, 09 Mar 2004 09:49:42 GMT

I am not sure I have understood your need, but it seems you should do the following

1) configure X so that one or more windows are started at startup

2) display something, starting decw$clock or ico

$ set display:crea/node=0...
$ mc decw$examples:ico

Re: X windows

Brian Reiter — Tue, 09 Mar 2004 10:07:31 GMT

labadie,

Seems fair enough - so how do I configure X so that one or more windows are started at startup?

I have a lot of VMS experience but not always in the areas where our systems exhibit problems :) As far as I'm concerned X is one of those black arcane arts best left to other people - much prefer a VT320.

Re: X windows

labadie_1 — Tue, 09 Mar 2004 10:12:56 GMT

While searching how to configure, I found another way on this mirror of the doc

2.7.3.13 CREATE/TERMINAL/DETACHED/PROCESS

V1.0

The /PROCESS=procnam qualifier does not work when used in conjunction with the /DETACHED qualifier, unless there is already a process running on the system where its process name is equal to the user name.

To work around this problem, use the following command procedure:

$! CREATE_TERM_PROC.COM
$!
$! Invoke as SPAWN/NOWAIT @CREATE_TERM_PROC procname
$!
$ SET NOON
$!
$! Set Process name to username
$!
$ X = F$CONTEXT("PROCESS", PID, "PRCNAM", "''F$PROCESS()'","EQL")
$ NAME = F$EDIT(F$GETJPI(X,"USERNAME"),"COLLAPSE")
$ SET PROCESS/NAME="''NAME'"
$ CREATE/TERMINAL/DETACHED/PROCESS="''P1'"
$!
$! Allow new process to RUN LOGINOUT before exiting subprocess
$ WAIT 00:00:10

http://pi-net.dyndns.org/docs/openvms0731/731final/6470/6470pro_005.html

Re: X windows

labadie_1 — Tue, 09 Mar 2004 10:32:19 GMT

I think it is in the session manager, tell him somewhere "start 3 decterm, 1 clock, 1 notepad"

I do not have an X Window system at hand, sorry.

Re: X windows

Lokesh_2 — Tue, 09 Mar 2004 11:12:51 GMT

Hi Brian,

I am not clear about your problem. Can you please elaborate ? How do you build your graphical data ?

Best regards,
Lokesh

Re: X windows

Martin Kirby — Tue, 09 Mar 2004 11:50:44 GMT

Brian,

I'm not clear exactly what is needed here.

My guess is that you have some odd
application that needs to open a display
connection even though it doesn't display
anything.

It is possible to configure the local
display server to allow connections from
anyone before anyone logs in. To do this
create a file:

SYS$MANAGER:DECW$SERVER_ACCESS_ALLOWED.DAT

with contents:

LOCAL * *

(a space before each asterisk) and a file

SYS$MANAGER:DECW$SERVER_ACCESS_TRUSTED.DAT

with contents:

LOCAL * SYSTEM

Then restart DECwindows. There are two potential risks doing this.

1. Anyone can now connect to the display
without logging in. If you have
untrustworthy users they could create
a window that looked like the login box
and use it for password capture. Since
only LOCAL access is allowed the
user would need to be logged in
locally.

2. If someone starts this funny graphics
application when a user is logging out the
login window might refuse to start. Again
this is a security feature to prevent
running the login window if there is
another client connected. There is a
logical to turn that check off - I would
need to know which desktop login window
you are using to find out what that
logical is.

Martin Kirby

Re: X windows

Martin P.J. Zinser — Tue, 09 Mar 2004 12:13:56 GMT

Hello Martin,

does this still work with 1.3.x ? I do have problems to get the new security access methods to work...

Greetings, Martin

Re: X windows

Brian Reiter — Wed, 10 Mar 2004 03:50:51 GMT

Martin, will get someone to try it this morning. In my opinion all our applications are odd and in most case very old (10 years+).

Ah well the joys of maintenance.

Re: X windows

Martin Kirby — Wed, 10 Mar 2004 04:20:08 GMT

Martin,

Yes it should work with V1.3-x. In fact, we even document them now even though they have always been there.

There shouldn't be any problems with the new security features in V1.3-x. On the other hand, the specification may be quite complex.

If you open a thread with the problems I'll see if I can help you.

Martin

Re: X windows

Brian Reiter — Wed, 10 Mar 2004 05:06:33 GMT

Martin,

Thanks very much for the info. Initial testing indicate that it has cured the problem.

cheers

Brian

Re: X windows

Rick Dyson — Wed, 10 Mar 2004 09:25:31 GMT

Martin:

Your suggestion about allowing X-win access
before any user has actually logged in was
a great (good!) surprise. I had always thought this was just not possible and never looked deeper.

Now, for a slightly tougher problem. :)
What about an X-terminal instead of the standard display? Should that be possible?

In particular, I have Tektronix (aka NDS)
X-Terminals using their software.

Rick

Re: X windows

Martin Kirby — Thu, 11 Mar 2004 05:07:13 GMT

Rick,

I don't understand your situation.

You have clients running on OpenVMS and your display server is an X terminal. Whether you can display to the X terminal without logging in first depends on the security the X terminal implements.

Martin