X windows

[Brian Reiter]

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

[labadie_1]

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

[Brian Reiter]

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.

[labadie_1]

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

[labadie_1]

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.

[Lokesh_2]

Hi Brian,

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

Best regards,
Lokesh

[Martin Kirby · Accepted solution]

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

[Martin P.J. Zinser]

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

[Brian Reiter]

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.

[Martin Kirby]

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

[Brian Reiter]

Martin,

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


cheers

Brian

[Rick Dyson]

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

[Martin Kirby]

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