SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)
Mark Daniel
Management ..." thread. Please restrain the impulse to do so if this post
just reinforces your experience over the years. If there are others out
there in this same situation it just might be an opportunity to inform
those OpenVMS Engineering Project Managers who frequent and now are often
active in these newgroups, of what (I feel is) a very basic requirement.
This relates to my day-job (DSTO), not the proprietory company represented
by my email address (VSM). That really dosn't change anything of course.
Small organizations as well as large are equally dependent the ubiquitous X
Window System environment.
We are in the process of replacing a large number of older X-terminals that
provide only 8 bit colour with those supporting 24 bits (amongst other
reasons). In so doing we discovered that a candidate solution (which best
goes unspecified in this forum) requires the support of MIT-MAGIC-COOKIE-1.
Now, I don't want to debate the efficacy of the this method of
"authentication" or privacy insurance. Suffice to say it *is* a
requirement. It is also a "policy" that such such an authentication scheme
be used with X-terminals to reduce the possibility of unauthorized clients
accessing sensitive information, including displays, entered passwords,
etc. In other words, all the stuff that the standard X Window System so
promiscuously allows. Up until now we have not been able to implement the
"policy" on our VMS systems because we use TCP/IP extensively as a
transport and DECwindows 1.0->1.2 has only supported user-based
authentication for DECnet, or the XDM-AUTHENTICATION-1 which is cumbersome
and was not practicable (at least in our environment).
Motif 1.3 has changed this. It supports MIT magic and works well. (Many
thanks to the specialist handling the call at our national CSC for chasing
this down and obtaining a copy for us well before we would have received it
on the Q2 distribution.) OK, all is well. Hmmm, not quite. After time
and effort was expended getting the XDM to support the MIT_MAGIC-COOKIE-1
authentication it still didn't. And won't! You see, apparently all of
OpenVMS' X Display System (DECwindows) has received a major overhaul EXCEPT
THE XDMCP tool! Yes, the XDM was "overlooked" (?) and does not provide
what the rest of the suite does.
When I pressed my contact at the CSC he relayed his impression from OpenVMS
Engineering over this issue. I quote (with permission) my reply here (with
only some private detail removed) so as not to have to recompose the same
sentiments. He understood the remarks and is forwarding them to the
"whomever". Thanks for your reading time.
> From: Daniel, Mark Sent: Monday, June 02, 2003 11:17 AM
> Subject: RE: magic cookies
>
> Hi [name],
>
>> Sigh... I thought we were well past "yes/no", you can't do it with
>> XDM. We've been trying to raise this as a "please fix
>
> My mistake. I thought we were still in the "get the folks back home to
> tell us how" stage :^)
>
>> this ASAP", but getting lots of "yeah, sure, after Itanium ships" type
>> noises. :-(
>
> Never thought I'd be so exasperated. I know I'm not telling you
> anything new [name], just expressing myself out loud. Perhaps you can
> return this reply verbatim to "whomever".
>
> Not wishing to again express any opinion over the essential value of MIT
> magic cookie style authentication, it is so fundamental a part of
> heterogenous environments (which we all live in these days) that for it
> to be absent is tantamount to illuminating a neon sign over VMS saying
> "DOES NOT FIT IN". VMS does not need to draw attention to itself in
> *this* way. Now, MIT magic in Motif 1.3 is an *excellent* move. BUT,
> it's only half done if the XDMCP tool does not support it!! Thin-client
> environments just cannot be supported without an effective XDM. I would
> have thought this would have been obvious to blind-Freddy. I'm
> surprised that someone in the DECwindows Motif 1.3 enhancement project
> did not notice this, or did not state long and loud that the XDM is an
> essential component of the VMS X Display System environment. Perhaps it
> should be wrested from the TCP/IP team, or some better coordination
> between them and DECwindows project management. Perhaps it is just Too
> Hard.
>
>> Can you give me a rough dollar value on what we could sell you guys if
>> we delivered this capability? If not dollars, then some number of DS??
>> systems? As they say, money talks.
>
> Ignoring the issue of future Itanium sales :^) Perhaps you might remind
> the bean counters that new systems aside, my Division retains hardware
> and software maintenance on the existing systems. I just enquired of
> our IT Manager and for this Division alone it's in the order of [considerable number]
> Australian beans per annum, the majority of which is for VMS systems
> (perhaps not major customer status, but significant, I'd say,
> "money-for-jam"). Considering the reported disparity in margins between
> sales of new iron and that for "services", I would suggest that OpenVMS
> first strive to retain this income stream before asking how much more
> we'll spend next year. In fact it is probably from this source that
> ports to Itanium are being funded. Nobody is debating that now the
> Alpha platform has been declared obsolescent that a
> Itanium/Opteron/whatever port is necessary and inevitable but not to the
> exclusion of much else that is necessary.
>
>> Or would we be giving sales to [platform]? XP workstations give heaps more
>> than 8 bit colour depth. DS10 or DS15 instead maybe? Wouldn't need
>> magic cookies at all...
>
> Still would. It has now come to the attention (after the need to
> explain why we can't support VMS sessions on [platform] - at least before
> Motif 1.3) of our IT Security Officer that those using VMS have no
> connection authentication enabled on their X-Terminals.
> Needless-to-say, "this needs to be addressed".
>
>> [signature]
>
> Hope this is of some value.
>
> Regards,
>
> Mark Daniel.
Fred Kleinsorge
Motif V1.3 was done primarily in response to the needs of software like JAVA
for client features in X11R6.x. The refresh brought both the server and
client bits up to the current release. It also brought along with it a
number of features that had not previously been available - Magic-Cookie,
and Kerberos just being a few - some of which were needed by DII/COE.
The XDM implementation is not provided as part of Motif or the base OS -
instead it is a component of the TCPIP product. So it is not that it was
"overlooked" - it wasn't part of the Motif project.
The OpenVMS priority right now is focused on the delivery of OpenVMS on
Itanium. With the underlying Magic-Cookie support now available, I imagine
at some point XDM Magic-Cookie support will follow, your request to the
TPCIP group should help make sure that it is on their future work list.
As to 24-bits... simply change the pixel depth. Most of the cards we ship
today support 8, 16 and 24 bit depths. The default depth of 8 is mostly
historical and performance driven. The Radeon 7500 will have a 24-bit
default. I run my personal workstation (with the Oxygen VX1) at 1920 x 1200
@ 16bits.
"Mark Daniel" <Mark....@wasd.vsm.com.au> wrote in message
news:3EDAD271...@wasd.vsm.com.au...
Mark Daniel
> It just a matter of priorities, time, and resources.
Yes.
> Motif V1.3 was done primarily in response to the needs of software like JAVA
> for client features in X11R6.x. The refresh brought both the server and
> client bits up to the current release. It also brought along with it a
> number of features that had not previously been available - Magic-Cookie,
> and Kerberos just being a few - some of which were needed by DII/COE.
Yes. A Sun environment in drag.
> The XDM implementation is not provided as part of Motif or the base OS -
> instead it is a component of the TCPIP product. So it is not that it was
> "overlooked" - it wasn't part of the Motif project.
This beggars belief Fred. It's a little like saying the TCP/IP product
included an XDM but it can't be used with DECwindows (yet) because the XDM
project did not include the provision of hooks into the Session Manager.
> The OpenVMS priority right now is focused on the delivery of OpenVMS on
> Itanium. With the underlying Magic-Cookie support now available, I imagine
> at some point XDM Magic-Cookie support will follow, your request to the
> TPCIP group should help make sure that it is on their future work list.
Would the provision of the XDM be more appropriately positioned with the
DECwindows group? This is where the XFS resides, which is also a TCP/IP
based server.
> As to 24-bits... simply change the pixel depth. Most of the cards we ship
> today support 8, 16 and 24 bit depths. The default depth of 8 is mostly
> historical and performance driven. The Radeon 7500 will have a 24-bit
> default. I run my personal workstation (with the Oxygen VX1) at 1920 x 1200
> @ 16bits.
We no longer generally use desktop workstations Fred. Too expensive and
not necessary for our activity profile. The post and issue concerns the
necessity for the comprehensive support of the X Window System for
thin-client environments (remember, we are replacing *X-terminals*, and the
colour depth was one of multiple issues).
I am unsure what your working environment is like Fred. Ours (probably in
keeping with many non-commercial) requires access to multiple applications
distributed across multiple platforms. VMS (currently) has a place in
this. There are also multiple Unices in use and Windows Terminal Server.
The one desktop applicance needs access to any or all of these. VMS needs
to integrate seamlessly into this heterogeneity. In some instances the one
desktop also needs to allow multiple uses and users to host their sessions.
It is not only an annoyance if access controls need to be disabled when
starting a VMS hosted application (now addressed with 1.3) or session but
unproductive and counter security policy in many circumstances as well. It
also raises complaints (which VMS could well do without) from those who
have no interest or investment in O/S idiosyncracies, platform
dependencies, the vendors' time, resources and priority allocations.
Of course, this is preaching to the converted. I am not wishing to dwell
on the bleeding obvious here (or unduly to sound like much of the banter in
this forum). I just wish to emphasize that the much-needed update of
DECwindows without any corresponding functionality changes in a fundamental
component of that X environment is a significant anomaly that would be best
receiving immediate attention (project management boundaries notwithstanding).
Thanks for listening.
Fred Kleinsorge
>
> > The XDM implementation is not provided as part of Motif or the base OS -
> > instead it is a component of the TCPIP product. So it is not that it
was
> > "overlooked" - it wasn't part of the Motif project.
>
> This beggars belief Fred. It's a little like saying the TCP/IP product
> included an XDM but it can't be used with DECwindows (yet) because the XDM
> project did not include the provision of hooks into the Session Manager.
>
XDM was provided by the TCPIP group completely independent of the X11/Motif
project. In fact, I was pleasantly suprised to find it when I went looking
for it about a year ago. You can argue where it really belongs... In any
case, no capabilities existed for years for *either* XDM or Magic-Cookie -
VMS had a DECnet focus. TCPIP provided XDMCP and XDM. Now Motif has added
Magic-Cookie. I would anticipate that TCPIP will add the capability to XDM
at some point. AFAIK there was never a "XDM project" - somebody in TCPIP
decided that if they were doing XDMCP, it only made sense to have XDM - and
ported it - there was no change made to DECwindows that I know of.
> > The OpenVMS priority right now is focused on the delivery of OpenVMS on
> > Itanium. With the underlying Magic-Cookie support now available, I
imagine
> > at some point XDM Magic-Cookie support will follow, your request to the
> > TPCIP group should help make sure that it is on their future work list.
>
> Would the provision of the XDM be more appropriately positioned with the
> DECwindows group? This is where the XFS resides, which is also a TCP/IP
> based server.
>
Who knows. Possibly. But not without some amount of pain - since the
"DECwindows" group is actually outsourced support to a 3rd party.
>
> Of course, this is preaching to the converted. I am not wishing to dwell
> on the bleeding obvious here (or unduly to sound like much of the banter
in
> this forum). I just wish to emphasize that the much-needed update of
> DECwindows without any corresponding functionality changes in a
fundamental
> component of that X environment is a significant anomaly that would be
best
> receiving immediate attention (project management boundaries
notwithstanding).
>
And we will take the input, and I'll do a check to see where things are
heading. The "DECwindows" folks are currently porting to IPF and planning
the port of XM to Version 2.1. The TCPIP folks are among many other things,
porting to IPF.
David Webb
>"Mark Daniel" <Mark....@wasd.vsm.com.au> wrote in message
>news:3EDBE387...@wasd.vsm.com.au...
>>
>
>project. In fact, I was pleasantly suprised to find it when I went looking
>for it about a year ago. You can argue where it really belongs... In any
>case, no capabilities existed for years for *either* XDM or Magic-Cookie -
>VMS had a DECnet focus. TCPIP provided XDMCP and XDM. Now Motif has added
>Magic-Cookie. I would anticipate that TCPIP will add the capability to XDM
>at some point. AFAIK there was never a "XDM project" - somebody in TCPIP
>decided that if they were doing XDMCP, it only made sense to have XDM - and
>ported it - there was no change made to DECwindows that I know of.
>
Well I for one was asking for XDM for years and years before "somebody in
TCPIP" decided to provide it. Whenever I tried to get someone at DEC in either
the TCPIP or DECWINDOWS groups to look at it they would profess ignorance of
what it was and then that they would ask the other group to see whether they
could implement it in the future since it was really a TCPIP/Xwindows (which
ever was the other group) facility.
XDM has always seemed to fall down the crack between groups.
So it isn't really that much of a suprise that updates which should have
affected it have been missed.
David Webb
VMS and Unix team leader
CCSS
Middlesex University
Fred Kleinsorge
the *Terminals* group. So all of the stuff to do non-VMS, non-DECnet,
X-Terminal-like things weren't done by the graphics/Motif folks - but was
done by people mostly doing *LAT* work! So the font server, the LAT
transport, etc *did* fall through the cracks for the most part - because it
wasn't originally part of the "DECwindows" group.
XDM falls through the same crack. It wasn't in the original DECwindows
source, which is outsourced for maintenance. The TCPIP folks were nice
enough to do the work to port it when they did XDMCP. And now that a new
capability is available, it wasn't added because the group adding the
capability is A) mostly unaware of it, and B) aren't being paid to do
anything to it.
"David Webb" <dav...@alpha2.mdx.ac.uk> wrote in message
news:bbigk2$23d$1...@aquila.mdx.ac.uk...
JF Mezei
> The XDM implementation is not provided as part of Motif or the base OS -
> instead it is a component of the TCPIP product.
I wasted many hours trying to fiddle with the TCPIP 5.3 XDM only to come to
the conclusion that it didn't supportthe MIT magic cookie. The TCPIP
documentation didn't make any mention that it didn't support that established authentication.
Since XDM is was introduced fairly recently in the TCPIP Services software, I
fail to understand why they would have conveniently forgotten about it. At the
very least, they should have documented that it didn't support MIT magic cookie.
My workaround has become:
$set display/transport=tcpip/node=eclair.chocolate.com
$mc decw$startlogin
and that bring up the real login screen on te target display.
Also note that the XDM login display (it will work "once" if you define the
terminal in one of the config files) doesn't support logain failure alarms or
intrusion detection/evasion.
JF Mezei
> heading. The "DECwindows" folks are currently porting to IPF and planning
> the port of XM to Version 2.1. The TCPIP folks are among many other things,
> porting to IPF.
What about Alpha and VAX ? HP's "plan of record" mentions continued support of
at least Alpha. And making VMS behave properly with (old) established
standards is a must. If you get only the "required" features on that IA64
thing, it will be useless to VMS customers who won't see IA64 stuff for a few
more years, if they ever see it.
Mark Daniel
latter part of DEC's halcyon days).
IIRC; after a requirement to move from a cluster of desktop VAXstations
(approximately 70 of them at one stage) to more economical and easier to
manage X-terminal technology was brought up with our DEC account management
(or such like) we received the (perhaps implied) advice that X-terminal
development and support was not a DEC priority, would eat into workstation
sales, and not to expect such an idea to become corporate strategy (that's
the way I remember interpreting it anyway - certainly it's continued
neglect wouldn't disqualify this interpretation).
Of course that advice changed *our* strategy completely ;^) Having
identified this as a major issue for us we found someone who *would*
support it on VMS (however tenuously towards the end). We made a
significant investment in NCD equipment. It included a VMS-based XDM, a
vital component for the support of X used in this way. This was a good
move for us. These NCD units gave us many years of generally excellent
service. When the TCP/IP Services XDM finally became available we moved to
that (loyal - wherever possible).
Perhaps in the light of it being considered not "strategic" it is easier to
understand the current references to XDM as an effective afterthought and
not to expect too much of it because it's there gratis, nobody's paying any
"real" money for it, and nobody's getting paid any "real" money to maintain
it. Thanks to whomever in TCP/IP did decide to include it, perhaps because
they personally saw it as an monumental deficiency, but couldn't raise the
interest anywhere else for some "real" resources to invest in it. Anybody
who has seen the login banner, dialog, logo (NOT), etc., can't dismiss the
impression that some kind soul did it in their own spare time. It's not
difficult to imagine why our academic brethren didn't often end up with the
DECwindows Motif SM, or more recently DCE, hosting their session on the
office or computer lab X-terminal.
Apologies, I've slipped into sarcasm. Guess this issue has caused my
long-time and simmering astonishment at the neglect of this vital component
of the X environment to get the better of me.
Thanks for listening some more.
Fred Kleinsorge
Sorry, that did not imply that Motif V2.1 was being done for IPF. It would
be both Alpha and IPF if/when it is done. VAX, because it is a very old,
very unique code base - will never be moved forward.
"JF Mezei" <jfmezei...@istop.com> wrote in message
news:3EDD664B...@istop.com...
Mark Daniel
is these days) and this issue has generated only the *slightest*
interest from the c.o.v. community.
The only conclusion I can draw from this is what is such a *significant*
problem for our environment is unique to us (I'm tempted to add - in
contrast to so many, seemingly off-topic threads, that do get
considerable discussion in this forum). No one else needs to
interoperate in heterogenous X environments? It would seem then, that
DEC/Cpq/HP have made the correct call on where their resources need to
be deployed (and who can blame them for that).
I'll (one more time) need to go, cap-in-hand, to those that administer
our environment and explain that VMS, yes - once again, cannot be made
to integrate into that. Oh well, perhaps RLM made the correct call
after-all. Shame. Never thought I'd be resigned to it, but you can't
swim against the tide indefinitely.
+--------------------------------------------------------------------+
Mark Daniel http://wasd.vsm.com.au/adelaide
mailto:Mark....@wasd.vsm.com.au (Mark....@dsto.defence.gov.au)
+--------------------------------------------------------------------+
Dirk Munk
participating in this newsgroup. It seems there are still something like 450,000
VMS systems around, and if only 1% of those systems would be represented by one
person here, we would see 4,500 name popping up in this newsgroup. There are far
less contributors I'm afraid.
So it may well be that others have the same problems as you, but don't read this
newsgroup.
On the other hand that is not really the issue. The problem you are facing is a
problem that we can see more often, and not just with HP. In your case the
problem is that no one seems to be reponsible for the Motif architecture as a
whole, that is including for instance the TCP/IP changes that have to be made to
bring the Motif environment up to today's standard. Someone should have told
the TCP/IP engineers to make the necesarry changes, and he should have made sure
the work was done. Somehow this did not happen, and that is poor product
management in my view, and that is the real problem. Now you are stuck with an
unfinished product, and you as a customer really don't care who is reponsible
for that, the Motif engineers or the TCP/IP engineers.
I'm facing a similar problem that HP isn't going to solve on short term.
TCP/IP services for VMS can also be used as a BIND server, and it can be used
with dynamic DNS updates. So in that respect TCP/IP services are up to date.
As we all know we can cluster VMS sytems for high availability, and so we can
also make a clustered BIND server. This is great, most likely the only such
product around.
However you can NOT use dynamic updates with such a clustered BIND server.
Now if you want to build a VMS TCP/IP production cluster, it will use the
Loadbroker, and that relies on dynamic DNS updates.
So there we have a high availability clustered VMS BIND server that can not be
used with high availability production clusters, because the BIND server can not
be used with the dynamic DNS updates that the production cluster needs !!
This is just as silly as your problem. If this wasn't the case I could recommend
using VMS BIND servers to our network group. They don't have a sollution for a
failing master BIND server, except by manually 'promoting' a slave BIND server
to master BIND server.
These inconsistencies are very irritating and harm the reputation of the
products, specialy when HP doesn't want to fix them.
JF Mezei
> The only conclusion I can draw from this is what is such a *significant*
> problem for our environment is unique to us
No, it is not unique to you. But otehsr have given up on hope. The VMS
engineers are way too busy with the unwanted port to IA64 to make the sofwtare
changes necessary to meet customers's need. We'll have to wait a few years
before they can get to it.
What the TCPIP folks should do is simply publish the source to their XDM
server so that we could fix it ourselves.
JF Mezei
> participating in this newsgroup. It seems there are still something like 450,000
> VMS systems around,
This figure is good to publish to help kill the image that VMS is dead, but I
personally do not find it credible in terms of "active" VMS sites.
> problem is that no one seems to be reponsible for the Motif architecture as a
> whole, that is including for instance the TCP/IP changes that have to be made to
> bring the Motif environment up to today's standard.
1- Motif is progressing nicely. It is up to version 2.1 I think (or is it
2.0). Ironically, it is available on HP-UX. But VMS has a very old version of
Motif. Someone took a decision that VMS wouldn't be scalable anymore and would
only run on wildfireclass systems.
2-XDM has very little to do with Motif. It is just a "who is willing to give
me a login screen" ? protocol. It is only after XDM has done its job that
X-windows comes into play with the X-client popping a login screen onto the
X-server. And this is done at the TCPIP level. While X can use DECNET for
transport, XDM is a TCPIP stack protocol, so it is logical to put in in the
TCPIP software.
Dirk Munk
> Dirk Munk wrote:
>
>>participating in this newsgroup. It seems there are still something like 450,000
>>VMS systems around,
>
>
> This figure is good to publish to help kill the image that VMS is dead, but I
> personally do not find it credible in terms of "active" VMS sites.
>
>
>>problem is that no one seems to be reponsible for the Motif architecture as a
>>whole, that is including for instance the TCP/IP changes that have to be made to
>> bring the Motif environment up to today's standard.
>
>
> 1- Motif is progressing nicely. It is up to version 2.1 I think (or is it
> 2.0). Ironically, it is available on HP-UX. But VMS has a very old version of
> Motif. Someone took a decision that VMS wouldn't be scalable anymore and would
> only run on wildfireclass systems.
I was refering to the 'new' Motif on VMS.
>
> 2-XDM has very little to do with Motif. It is just a "who is willing to give
> me a login screen" ? protocol. It is only after XDM has done its job that
> X-windows comes into play with the X-client popping a login screen onto the
> X-server. And this is done at the TCPIP level. While X can use DECNET for
> transport, XDM is a TCPIP stack protocol, so it is logical to put in in the
> TCPIP software.
I did understand that. But the two are connected, so if it is 'normal' for
present day versions of Motif to be accompanied by a newer version of XDM, then
such a version of XDM should also be available on VMS when a new version of
Motif is released.
Bob Marcan
> Well, it's been a fortnight (or whatever the metric equivalent of that
> is these days) and this issue has generated only the *slightest*
> interest from the c.o.v. community.
>
> The only conclusion I can draw from this is what is such a *significant*
> problem for our environment is unique to us (I'm tempted to add - in
> contrast to so many, seemingly off-topic threads, that do get
> considerable discussion in this forum). No one else needs to
> interoperate in heterogenous X environments? It would seem then, that
> DEC/Cpq/HP have made the correct call on where their resources need to
> be deployed (and who can blame them for that).
>
> I'll (one more time) need to go, cap-in-hand, to those that administer
> our environment and explain that VMS, yes - once again, cannot be made
> to integrate into that. Oh well, perhaps RLM made the correct call
> after-all. Shame. Never thought I'd be resigned to it, but you can't
> swim against the tide indefinitely.
>
> +--------------------------------------------------------------------+
> Mark Daniel http://wasd.vsm.com.au/adelaide
> mailto:Mark....@wasd.vsm.com.au (Mark....@dsto.defence.gov.au)
> +--------------------------------------------------------------------+
>
No, we just give up and use workarounds.
Regards, Bob
--
Bob Marcan mailto:bob.m...@snt.si
Aster^H^H...HermesPlus^H^H^H...S&T mailto:bob.m...@aster.si
Nade Ovcakove 1 tel: +386 (1) 5894-329
1000 Ljubljana, Slovenia http://www.snt.si
Carl Karcher
->As we all know we can cluster VMS systems for high availability, and so we can
->also make a clustered BIND server. This is great, most likely the only such
->product around.
->
->However you can NOT use dynamic updates with such a clustered BIND server.
->
->Now if you want to build a VMS TCP/IP production cluster, it will use the
->Loadbroker, and that relies on dynamic DNS updates.
Yes it's a dilemma.
However, through testing (TCPIP 5.3, ECO-2 on VMS 7.3-1) I've found this
restriction to mean you can't have BIND writing to the same zone file. In
TCPIP$BIND.CONF, I have the following options line:
directory "SYS$SYSROOT:[TCPIP$BIND]";
I have a writable zone file (TEST.DB) that receives updates from Lbroker.
Provided there's a copy of this file in the first level of the search list
sys$sysroot (e.g. the file is sys$specific:[tcpip$bind]test.db), bind will
update this file on each node without complaints.
Not that I would recommend relying on this in a production cluster but it
does appear to work so long as each node has it's own copy of the writable
zone file.
--
-- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison
-- karcher.n...@waisman.wisc.edu
JF Mezei
> I did understand that. But the two are connected, so if it is 'normal' for
> present day versions of Motif to be accompanied by a newer version of XDM,
For what its worth, MI-X, the X-terminal software for old MACs uses the
MIT-MAGIC-COOKIES, so that technology can't be that recent. The XMD server was
introduiced with TCPIP Service 5.3, which *is* brand new. There is no excuse.
Fred Kleinsorge
potentially could use this wasn't updated. Was it an oversight? Yes. XDM
is not widely used on VMS that I know of. TCPIP added it because other
vendors, like Multi-Net provided it with their stack.
XDM is an ugly little interface, and probably most people today use RSH or
REXEC to kick off a DECW$STARTLOGIN - which gets you the familiar VMS login
box.
So most people have not been stymied by the lack of XDM.
Will XDM be updated? Yes. We are discussing it internally. And in fact
your note has been passed around internally. But there seems to be an
expectation that you want a patch for it tomorrow... I can't say when it
will be done - or if it is simple or hard to do - I don't know at this
point. But both the DECwindows developers and TCPIP developers have been
made aware of the request.
"Dirk Munk" <mu...@home.nl> wrote in message
news:bchses$1eh$1...@news2.tilbu1.nb.home.nl...
Fred Kleinsorge
> Dirk Munk wrote:
> > participating in this newsgroup. It seems there are still something like
450,000
> > VMS systems around,
>
> This figure is good to publish to help kill the image that VMS is dead,
but I
> personally do not find it credible in terms of "active" VMS sites.
>
> > problem is that no one seems to be reponsible for the Motif architecture
as a
> > whole, that is including for instance the TCP/IP changes that have to be
made to
> > bring the Motif environment up to today's standard.
>
> 1- Motif is progressing nicely. It is up to version 2.1 I think (or is it
> 2.0). Ironically, it is available on HP-UX. But VMS has a very old version
of
> Motif. Someone took a decision that VMS wouldn't be scalable anymore and
would
> only run on wildfireclass systems.
In fact, the most widely used version of Motif is 1.2-5 -- which is very
old, and what VMS uses. V2.1 broke binary compatability and has caused many
vendors to phase it in (offering both V1.2-5 and V2.1).
Motif has little to do with the size of the system. Even a Wildfire needs
it if you want to use many of the e-tools -- like JAVA.
After having gotten the X11 bits up to X11R6.6, we are now about to start
work on getting xm (the motif library) to V2.1/2 (or whatever).
.
David Webb
>VMS added a feature it had lacked. Magic-Cookie. A component that
>potentially could use this wasn't updated. Was it an oversight? Yes. XDM
>is not widely used on VMS that I know of. TCPIP added it because other
>vendors, like Multi-Net provided it with their stack.
>
>XDM is an ugly little interface, and probably most people today use RSH or
>REXEC to kick off a DECW$STARTLOGIN - which gets you the familiar VMS login
>box.
>
>So most people have not been stymied by the lack of XDM.
>
I think most people wanted XDM but since it wasn't forthcoming they used the
workarounds of RSH and REXEC which are pretty ugly workarounds.
So yes people weren't stymied by lack of XDM but lots weren't happy about it
not being available.
David Webb
VMS and Unix team leader
CCSS
Middlesex University
Fred Kleinsorge
"Dirk Munk" <mu...@home.nl> wrote in message news:bcikab$ls9>
> I did understand that. But the two are connected, so if it is 'normal' for
> present day versions of Motif to be accompanied by a newer version of XDM,
then
> such a version of XDM should also be available on VMS when a new version
of
> Motif is released.
>
This is not a "version" issue with XDM. It hasn't been compiled with the
magic cookie support because Xlib didn't support magic cookie. It does now,
and XDM needs the support compiled in and debugged on VMS.
Fred Kleinsorge
THERE WAS NO SUPPORT IN XLIB FOR IT, SO XDM DIDN'T INCLUDE IT! NOW THERE
IS, AND IN SOME FUTURE RELEASE IT SHOULD BE CHANGED TO USE IT.
Sheesh.
Fred Kleinsorge
>
> I think most people wanted XDM but since it wasn't forthcoming they used
the
> workarounds of RSH and REXEC which are pretty ugly workarounds.
> So yes people weren't stymied by lack of XDM but lots weren't happy about
it
> not being available.
>
Granted. but also this is a feature that is something like 15+ years old
and has never been on VMS. So getting bent out of shape about the
sequencing of upgrading of the X11 bits and adding the functionality...
lighten up a little. As we shift to an IP focus, we're slowly filling
things in.
JF Mezei
> potentially could use this wasn't updated. Was it an oversight? Yes. XDM
> is not widely used on VMS that I know of.
XDM isn't widely used because it wasn't supported until TCPIP 5.3. It is like
saying an Amputee doesn't need to run because it has no legs.
In the heydays of Digital workstation and X terminals, how did the standalone
"dumb" X-terminals get their sessions initiated ?
> XDM is an ugly little interface, and probably most people today use RSH or
> REXEC to kick off a DECW$STARTLOGIN - which gets you the familiar VMS login
> box.
Ugly ???? X server sends broadcast "who wants to be my client". One or more
hosts respond "me !". X-server chooses which one, and tells it "ok, you've won
the right to connect to me , do it"
(and in non-broadcast mode, the X-server sends the same request to just the
one designated VMS host, VMS host makes its offer, X-terminal accepts and voila.
But many X terminal (or emulators) require some authentication scheme. VMS's
CDM supports one, but does support what seems to be the more popular MIT magic cookie.
> So most people have not been stymied by the lack of XDM.
That is because you guys at Digital had been so busy sending workstation
customers over to Sun and other manufacturers for the last 13 years.
> Will XDM be updated? Yes. We are discussing it internally.
While you are at it, you should note that the current XDM software presents
its own login screen/process. This piece of software does not generate any
alarms when an invalid username/ password is entered, nor does it trigger
break in evasion/detection etc.
Larry Kilgallen
> After having gotten the X11 bits up to X11R6.6, we are now about to start
> work on getting xm (the motif library) to V2.1/2 (or whatever).
Hooray !!!
JF Mezei
> THERE WAS NO SUPPORT IN XLIB FOR IT, SO XDM DIDN'T INCLUDE IT! NOW THERE
> IS, AND IN SOME FUTURE RELEASE IT SHOULD BE CHANGED TO USE IT.
I am curious. Why with the XDM magic cookies authentication be included in
X-lib ? These happen well before an "x" functions are started.
Also, note that the current incarnation ( 5.3) does support magic-cookies, but
not the MIT-MAGIC-COOKIE.
Fred Kleinsorge
> Fred Kleinsorge wrote:
> > THERE WAS NO SUPPORT IN XLIB FOR IT, SO XDM DIDN'T INCLUDE IT! NOW
THERE
> > IS, AND IN SOME FUTURE RELEASE IT SHOULD BE CHANGED TO USE IT.
>
> I am curious. Why with the XDM magic cookies authentication be included in
> X-lib ? These happen well before an "x" functions are started.
>
No, not really. X11 has a weak and ad-hoc security method. When the
connection is made, the server exhanges - via some X11 protocol messages -
any authentication. Magic-Cookie-1 is just one of them. This all happens
way down in XLIB on the client side. If the authentication fails, then the
connection is not completed.
JF Mezei
> No, not really. X11 has a weak and ad-hoc security method. When the
> connection is made, the server exhanges - via some X11 protocol messages -
> any authentication. Magic-Cookie-1 is just one of them.
I am curious. My old MAc X server uses MIT_MAGIC_COOKIE for XDM. VMS doesn't
support that authentication. Yet, I have no problems connecting. Does this
mean that while it might use the MIT magic cookie for XDM requests, it would
use magic-cookie-1 for the actual session authentication ?
JF Mezei
Since XDM is available on VAX, what will happen when you update XDM to support
MIT-MAGIC-COOKIE based on availability of support in x-lib but that newer
x-lib won't make it to vax ? ???
Seems to me that the easiest solution is to simply port the newer Xlib stuff
to VAX which will simplify all the rest. Need I remind you that there is an
infinitely greater number of VAX customers than there are IA64 customers.
Only once IA64 has more customers than VAX should you consider diminishing the
availability of modern software on VAX.