OSR507: xm_vtcld : could not open libXm.so - SCO

This is a discussion on OSR507: xm_vtcld : could not open libXm.so - SCO ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

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

  1. 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@172.xxx.101.66
    root@172.xxx.101.66'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.

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


    ----- Original Message -----
    From: "Pepe"
    Newsgroups: comp.unix.sco.misc
    To:
    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@172.xxx.101.66
    > root@172.xxx.101.66'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@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


+ Reply to Thread