Re: OSR507: xm_vtcld : could not open libXm.so


----- Original Message -----
From: "Pepe" <pepe@xxxxxxxxxx>
Newsgroups: comp.unix.sco.misc
To: <distro@xxxxxxx>
Sent: Saturday, July 14, 2007 6:22 PM
Subject: OSR507: xm_vtcld : could not open libXm.so


Hello.

When I connect to my OpenServer 5.0.7 test box (with MP5) from my Linux
laptop, I can run successfully "scoadmin software" if I'm through SSH,
however if I'm through telnet I get this error when calling "scoadmin
software":

"dynamic linker : xm_vtcld : could not open libXm.so"

OSR507 name is "gollum", IP=172.xxx.101.66
LINUX name is "d600", IP=172.xxx.101.107

--------example SSH session from Linux xterm, works fine------------
LINUXLAPTOP $ ssh root@xxxxxxxxxxxxxx
root@xxxxxxxxxxxxxx's password:

you have mail
root@gollum:/root # set
CDSPELL=cdspell
COLUMNS
em=EDITOR
ENV='${_ENVFILE[(_=1)+(_$-=0)-_${-%%*i*}]}'
ERRNO=0
FCEDIT=/bin/ed
HOME=/root
HZ=100
IFS=' '
LINENO=1
LINES
LOGNAME=root
MAIL=/var/spool/mail/root
MAILCHECK=600
MF_ADM=adm.cat@Unix
MSG_MAIL=1
MS_PROFILE=1
OPTARG
OPTIND=1
PATH=/bin:/usr/bin:/etc:/sbin:/usr/gnu/bin
PPID=4747
PS1='root@gollum:$PWD # '
PS2='> '
PS3='#? '
PS4='+ '
PWD=/root
RANDOM=351
SECONDS=2
SHELL=/bin/ksh
SSH_CLIENT='172.xxx.101.107 50453 22'
SSH_CONNECTION='172.xxx.101.107 50453 172.xxx.101.66 22'
SSH_TTY=/dev/ttyp0
TERM=xterm
TMOUT=0
TZ=CET-1CETDST,M3.5.0/1,M10.5.0/1
USER=root
_=PS1='root@gollum:$PWD # '
_ENVFILE[0]=/root/.kshrc
_ism=0
_TAB_Complete=1
root@gollum:/root # scoadmin software ====> it launchs perfectly.
root@gollum:/root #
---------------------------------------------------------------------


--------example telnet session from Linux xterm, gives error---------
LINUXLAPTOP $ telnet 172.xxx.101.66
Trying 172.xxx.101.66...
Connected to 172.xxx.101.66.
Escape character is '^]'.

UNIX gollum.XXXXXX.YYY ttyp1

login: root
Password:

you have mail
root@gollum:/root # set
CDSPELL=cdspell
COLUMNS=196
DISPLAY=d600.XXXXXX.YYY:0
em=EDITOR
ENV='${_ENVFILE[(_=1)+(_$-=0)-_${-%%*i*}]}'
ERRNO=0
FCEDIT=/bin/ed
HOME=/root
HUSHLOGIN=TRUE
HZ=100
IFS='
'
LINENO=1
LINES=74
LOGNAME=root
MAIL=/usr/spool/mail/root
MAILCHECK=600
MF_ADM=adm.cat@Unix
MSG_MAIL=1
MS_PROFILE=1
OPTARG
OPTIND=1
PATH=/bin:/etc:/usr/bin
PPID=4755
PS1='root@gollum:$PWD # '
PS2='> '
PS3='#? '
PS4='+ '
PWD=/root
RANDOM=23089
SECONDS=1
SHELL=/bin/ksh
TERM=xterm
TMOUT=0
TZ=CET-1CETDST,M3.5.0/1,M10.5.0/1
_=PS1='root@gollum:$PWD # '
_ENVFILE[0]=/root/.kshrc
_ism=0
_TAB_Complete=1
root@gollum:/root # scoadmin software ==> gives the error shown below!
dynamic linker : xm_vtcld : could not open libXm.so

root@gollum:/root #
----------------------------------------------------------------------

So I had to "unset DISPLAY" in the telnet session to get "scoadmin
software" to launch.

I am a little worried that even PATHs don't match in both environments.
What's the difference in the user profile that sshd and telnetd are using?
How could I make both environments be as similar as possible?

Thank you.

PS: yes, I will restrict network root logins at a later stage.

Every daemon, regarless of OS, regardless it's purpose, regarless if it
happens to be one that provides a login shell or not, has it's own quirks
and configuration and things you have to know about in order to get it to do
want you want. If you want telnet to behave more like ssh, or vice versa, or
want both to act more like something neither quite does now, the answers lie
in reading the man pages for sshd and telnetd, (and inetd since that is how
telnetd is launched) and from them you do whatever it is you want.

The fact that the environments are not the same is no surprise or even
error. Similarly cron jobs have a different environment, and cgi-bin scripts
yet another, rc.d start scripts yet another, things launched from
rlogin/rsh/rexec/rcmd yet another, etc...

Myself I have been hard coding a path in /etc/profile and root's /.profile
and cron's /etc/default/cron for some years. It differs a little from what
the stock system creates and I'm not willing to claim it's 100% harmless,
but it's what I've been doing for 6 or 7 years (a few hundred boxes counting
replacements and uprades) and haven't encountered a problem caused by it
that I know of. What directories to include, and in what order are somewhat
of a personal preference/religeous issue. One school of thought is to put
add-on directories like /usr/local/bin ahead of system dirs like /usr/bin,
so that you can have a stock system with say a stock awk, and then add an
enhanced or replacement awk as /usr/local/bin/awk and it will automatically
become the awk that gets used everywhere merely by existing. In the case of
SCO boxes, I do not recommand this because all of the umpty-gillion scripts
on a sco system are written for the stock tools, which often behave quite
differently than the gnu equivalents. Instead I install gwxlibs and
gnutools, both of which create and live mostly within /usr/gnu
(bin|sbin|lib|man|etc...), and mostly the gnu versions of things in
/usr/gnu/bin have symlinks with "g" prepended to their names, so there is a
gawk, gtar, gdf, etc... and where there isn't, I create them. I create them
in a seperate dir /u/aljex/bin that is painless to add to new boxes, doesn't
get touched by updates, and is included in the PATH that I set up. Thats
where I put all scripts that I write too for the same reasons. Then when I
write script that really wants for instance, gnu find and gnu xargs, (both
of which have very handy options the stock tools don't and turn 10 lines of
scripting into 1) I use gfind and gxargs. All in all it's a very nice
system.

Below, the PATH is in /etc/profile instead of profile.aljex so that the
remote-execution services like rcmd/rexec and ssh -e can get the path, yet
there is stuff in profile.aljex that hangs if there is no tty and mostly
doesn't apply / isn't needed in that case anyways, so this way, the path is
always set and the rest only happens for interactive logins. /u/appl/fp and
/u/aljex/start won't apply to you just omit, but they are part of another
scheme thats useful for filepro users with many qualifiers and fp data
trees, of which there are a few on this newsgroup. Root should have at least
2 dirs in it's path that no other user should have, so the /.profile is not
intended to be put in everyon's .profile. /etc/profile already applies to
all users, including root, and happens earlier in the login process than the
per-user .profile, so this results in all users getting the /etc/profile
path, and root getting that, plus /etc and /tcb/bin.
an argument could possibly be made for adding /usr/lib and maybe a few
others to root's path for things like sendmail, lpshut, lpsched, but I
happen to not think it's a good enough idea to add another dir to roots
path.

/etc/profile
# Simply add to end
###### aljex ######
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/gnu/bin:/usr/gnu/sbin:/usr/local/bin:/usr/local/sbin:/u/appl/fp:/u/aljex/start:/u/aljex/bin
export PATH

tty -s && . /etc/profile.aljex


/.profile
# Root's home ~/.profile which is / not /root by default.
# Use /root/.profile if you moved root's home.
# Edit in-place NOT simply append.
PATH=${PATH}:/etc:/tcb/bin
export PATH

/etc/default/cron
# can simply append, though I do edit instead for no reason I can justify
beyond aesthetics
# PATH probably accounts for 90% of the problems people have with cron jobs
that don't work.
# TERM probably accounts for 9 of the remaining 10.
# Some apps fail when TERM is not set to something that has a good
definition in termcap or terminfo or the apps own terminal capabilities
database.
# CRON is something of my own, setting CRON allows me to write scripts that
function differently when run interactively vs from cron. It's very helpful
but examples that really show how/why are beyond the scope of this post.
# email may chopt these, to re-assemble, it's 3 lines each starting with
setenv.
setenv
PATH=/etc:/bin:/usr/bin:/usr/lbin:/sbin:/usr/sbin:/usr/gnu/bin:/usr/gnu/sbin:/usr/local/bin:/usr/local/sbin:/u/appl/fp:/usr/vsifax/bin:/usr/vsifax/lbin:/u/aljex/start:/u/aljex/bin
setenv TERM=ansi
setenv CRON=true

(restart cron, /etc/init.d/cron stop ; /etc/init.d/cron start )


You may notice that in 5.0.7 users .profile already includes /usr/local/bin
via a test to see if it even exists, and so it's not needed in /etc/profile.
I junk /usr/lib/mkuser/profile and replace it with just this:

----
:

PATH=${PATH}:${HOME}/bin
MAIL=/usr/spool/mail/$LOGNAME
export PATH MAIL

exec plogin
----

So new users get created with this as their .profile.
In your case I'd just change the PATH line, remove tset, and leave the rest.
My reasons for not needing prwarn, tset, etc.. may or may not apply to you,
and certainly "exec plogin" doesn't.

Notice that neither root nor users nor cron nor anything else has "." in the
path. Another religious issue. You clearly place security very highly in
importance so I'm guessing you probably won't want that either but it should
be noted that some people/scripts do expect it at least in users path. None
of the stock system scripts do so it's harmless to omit as far as the OS is
concerned. Nor do any apps I've used (or written), but I have seen a few
scripts, rarely, that assumed "." was in path.


Some of the other differences you noted between ssh and telnet are the
result of the different daemons, _and_ clients ability, and willingness, to
pass along arbitrary environment variables. At the protocol level, both
telnet and ssh happen to include a mechanism for a client to tell a server
arbitrary variables it would like to have put into the new login session's
environment. Different clients have different ability to perform the
request, and different default behaviour if you don't specify, and different
ways of specifying. Different server daemons have different ability to
accept the request, different default behaviour about honoring it, and
different ways of controlling or altering that.

When you telnetted from an xterm on linux, you had a host of variables in
your env on the linux box, and linux's default telnet client, apparently,
happens to try to propogate all of them along to the remote host, and SCO's
telnetd, apparently, knows how to negotiate that part of the telnet protocol
and apparently by default does deign to honor it. By no means is this to be
counted on in general telnetting from anywhere to anywhere. The only thing
you can normally count on is TERM, and you can't even count on that because
a distressing number of VARS and consultants who set up servers for back end
applicatio use, hard code TERM to whatever arbitrary value they happen to
think is "right" in /etc/profile or users .profile . So even though your
client pushed a value, and the server accepted it, and performed it,
..profile then overwrote it.

sshd on sco is OpenSSH, and is very configurable about accepting/denying env
variables in /etc/ssh/sshd_config via "AcceptEnv", globbing is supported so
"AcceptEnv *" allows a client to set any and all variables it wants.
Otherwise only certain vars are accepted by default. Even aside from
security it might not necessarily be a good idea to propogte all variables
from the local client to the remote session. Much of your environment only
applies to your local box, on some other box they either don't apply at all,
which is at least harmless, but might also be meaningful and wrong, and it
might be better the value isn't set at all than exist and be wrong. I do
have AcceptEnv * in a several places but not everywhere. I haven't hit a
real problem. I'm just pointing out there could be just as I keep it in mind
myself all the time. I'm aware what it might do and I'm on the look out for
that sort of possible problem and might remove it some time in favor of a
specific list of variables I do need to pass. I Just don't want to have to
start maintaining such a list across all boxes unless I have to.

DISPLAY is of particular interest in the case of running scoadmin, because
there is a graphical (tk/tcl/vtcl based) interface as well as a purely
text/curses based interface to scoadmin and the collection of different
programs that scoadmin is merely a menuing system for. If DISPLAY is set,
then it tries to run the graphical version. Unless you take special steps
tht won't work, but it can if you want. At minimum you have to overwrite
DISPLAY to the ip or hostname of your linux box as seen from the unix box's
point of view, which will generally be your routers public IP, and
":X_session_number" appended to that. So usually: "DISPLAY=address:0" Then
that router needs to be port-forwarding the X tcp ports (6000-6999" from the
internet in to your linux box. Then your X serever session needs to allow X
client requests coming from the unix box (run "xhosts unix-box-ip" from an
xterm in the same local X session)
Then, this is not necessary for function, but alleviates a cosmetic error
and error message, copy some X color definitions from /usr/X/lib/rgb.txt on
SCO into /usr/X11R6/lib/X11/rgb.txt on Linux. Namely:
----
203 203 192 scoBackground
11 0 113 scoForeground
255 240 248 scoTopShadow
255 206 137 scoActiveBackground
43 45 49 scoActiveForeground
254 222 255 scoActiveTopShadow
172 186 204 scoAltBackground
0 0 255 scoHighlight
----

Instead of configuring router port forwarding, if using ssh it's also
possible to use the tunnel feature in ssh. (some other article. I never use
the feature so I don't even know how off hand without looking it up same as
you can.)

After all that, you can run scoadmin on the sco box, and have the graphical
version pop up in your local X session. I didn't say it was WORTH it. :) But
there are a few apps here & there that only come in GUI form, and normally
only work at the console, and since they are admin things like raid card
management utils and UPS battery management utils, it's useful to know how
to run them remotely. For scoadmin it's just something you, as a SCO admin
(heh), should know about your OS. When you run scoadmin you first need to
unset DISPLAY if it might be set from however you happen to be logged in
right then. That's actually not strictly a sco thing. I've seen a few apps
scattered throughout the gnu and commercial world that automaticlly try to
run a gui or curses version of themselves based on the presence of DISPLAY.
So its just an ordinary feature of life as a *nix user, not a SCO admin.
Also, it's not purely fluff even for scoadmin. The gui version of the
process list is particularly handy once in a while. The print job manager
and accout manager too sometimes.

Off topic, Both those examples with the gui-only interface, the particular
products I'm thinking of _used_ to have perfectly good text interfaces. very
useful. Especialy the *coughadapteccough* raid card, it was not only text it
was non-iteractive, batcheable, menuable to give users safe preconfigured
commands to do things like just view status, shut off the alarm, etc. Could
run them from _anywhere_ via _any_ means of connection, from dumb serial
terminal, non-tcp (not PPP) dialup, telnet/ssh, etc.. from any long chain of
boxes sometimes needed to get in to internal app servers that might not be
directly accessible, etc... And being plain text or at worst a little
ansi/curses colors they were fast even over 9600 baud dialup, both the
accessibility and speed being critical CRITICAL features for apps like this
which are often needed as part of dealing with an emergency, or heading an
emergency off just in the nick of time... but apparently some pain in the
neck old guy that the next generation of kids hired in the company don't
understand and don't like, got knocked off or forcibly retired, and the kids
improved that boring old text app to death. Sigh. That too is another
conversation...

Brian K. White brian@xxxxxxxxx http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

.

Relevant Pages

  • Re: Can I do it using python?? about xterm and telnet
    ... SSH is advisable over telnet in nearly all situations. ... there are a few times where telnet is better. ... pexpect will do the job you need. ... Build the scripts ...
    (comp.lang.python)
  • Re: How do I unlock a specific user for telnet?
    ... > None of the systems I work on have telnet so I've never encountered ... > reasonable risk on a small local LAN, but I need ssh to get off LAN ... But I have started switching my security scripts from ssh to telnet. ... Ive even had a couple of nice saves where the skiddies scripts shutdown ...
    (comp.os.linux.security)
  • RE: Commentary on the seven words
    ... When I was an operating systems programmer we all too often forgot that the Operating system existed to support the application, not the other way around. ... A Because the application that we run uses a telnet client that doesn't support ssh - and that's why I can't run ssh on this system. ... I administrate one system that has 128 clients on it and it's ...
    (RedHat)
  • Re: Commentary on the seven words
    ... A Because the application that we run uses a telnet client that doesn't ... support ssh - and that's why I can't run ssh on this system. ... General Red Hat Linux discussion list ... >operating system and utility advice and assistance and there are SEVEN ...
    (RedHat)
  • Re: Commentary on the seven words
    ... routinely asked to help with enabling rsh and telnet. ... Shoot, I use SSH & all that, but if I wanted to allow it for some ... > I wrote in with a complaint that Linux will allow a process (like Tar, ... I administrate one system that has 128 clients ...
    (RedHat)