Remote Control a terminal or the console. - SCO

This is a discussion on Remote Control a terminal or the console. - SCO ; I have a client on 5.0.7 that was asking me about ways to connect to another terminal remotely and see what was on their screen for error diagnosing a trouble shooting. I told them I seem to recall a product ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Remote Control a terminal or the console.

  1. Remote Control a terminal or the console.

    I have a client on 5.0.7 that was asking me about ways to connect to
    another terminal remotely and see what was on their screen for error
    diagnosing a trouble shooting. I told them I seem to recall a product
    called Double View or Double Vision. Anyone remember this and am I
    correct in what it does. Also any other suggestions?


    --
    Brian Keener
    bkeenerReMoVeAnTiSpAm@thesoftwaresource.com



  2. Re: Remote Control a terminal or the console.

    Brian Keener wrote:
    > I have a client on 5.0.7 that was asking me about ways to connect to
    > another terminal remotely and see what was on their screen for error
    > diagnosing a trouble shooting. I told them I seem to recall a product
    > called Double View or Double Vision. Anyone remember this and am I
    > correct in what it does. Also any other suggestions?
    >
    >


    It's DoubleVision from tridia.com. Very good, unlimited users license is
    standard.

    Kernel resident, does not change how pty's are assigned. Has a good Menu
    system and can translate one terminal type to another. Limited platform
    availability (no Linux except for Red Hat for example).

    The other commercial product I use is Peek, from computron.com, at my
    Unixware sites (Unixware is only recently available for DV).

    Can be cheaper for smaller sites as it has a per user license, but it
    requires launching a Peek shell on login, that then launches sh/ksh/bash
    whatever.

    You have to script your own menu (not hard) or use the character command
    line.

    --
    ----------------------------------------------------
    Pat Welch, UBB Computer Services, a WCS Affiliate
    SCO Authorized Partner
    Microlite BackupEdge Certified Reseller
    Unix/Linux/Windows/Hardware Sales/Support
    (209) 745-1401 Cell: (209) 251-9120
    E-mail: patubb@inreach.com
    ----------------------------------------------------

  3. Re: Remote Control a terminal or the console.

    Brian Keener wrote:
    > I have a client on 5.0.7 that was asking me about ways to connect to
    > another terminal remotely and see what was on their screen for error
    > diagnosing a trouble shooting. I told them I seem to recall a product
    > called Double View or Double Vision. Anyone remember this and am I
    > correct in what it does. Also any other suggestions?
    >
    >


    Has anyone installed and used VNC for this in SCO OpenServer? Or installed
    emacs, and used "emacs -e shell" in order to save the contents of a shell
    interaction to a file?

    I've used both for many years in other OS's.

  4. Re: Remote Control a terminal or the console.

    On Sat, 8 Mar 2008, Nico Kadel-Garcia wrote:
    > Brian Keener wrote:
    > > I have a client on 5.0.7 that was asking me about ways to connect to
    > > another terminal remotely and see what was on their screen for error
    > > diagnosing a trouble shooting. I told them I seem to recall a product
    > > called Double View or Double Vision. Anyone remember this and am I
    > > correct in what it does. Also any other suggestions?

    >
    > Has anyone installed and used VNC for this in SCO OpenServer? Or
    > installed emacs, and used "emacs -e shell" in order to save the contents
    > of a shell interaction to a file?
    >
    > I've used both for many years in other OS's.


    Yes, I use it with UnixWare 7.1.X , OpenServer 5.0.X and OpenServer 6.0.X.
    It is a poor man's way of having the abilities. It takes a bit to compile
    emacs on them. Xemacs is easier.

    --
    Boyd Gerber
    ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

  5. Re: Remote Control a terminal or the console.

    Nico Kadel-Garcia wrote:
    > > called Double View or Double Vision. Anyone remember this and am I
    > > correct in what it does. Also any other suggestions?
    > >
    > >

    >
    > Has anyone installed and used VNC for this in SCO OpenServer? Or installed
    > emacs, and used "emacs -e shell" in order to save the contents of a shell
    > interaction to a file?


    How does this work in relation to having a user/customer running an
    application and you want to see what is on his screen. Since I don't use
    emacs I'm not that familiar with this. Can you provide a little more of what
    would be happening and how it is used.

    bk


  6. Re: Remote Control a terminal or the console.


    ----- Original Message -----
    From: "Brian Keener"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Friday, March 14, 2008 2:49 PM
    Subject: Re: Remote Control a terminal or the console.


    > Nico Kadel-Garcia wrote:
    >> > called Double View or Double Vision. Anyone remember this and am I
    >> > correct in what it does. Also any other suggestions?
    >> >
    >> >

    >>
    >> Has anyone installed and used VNC for this in SCO OpenServer? Or installed
    >> emacs, and used "emacs -e shell" in order to save the contents of a shell
    >> interaction to a file?

    >
    > How does this work in relation to having a user/customer running an
    > application and you want to see what is on his screen. Since I don't use
    > emacs I'm not that familiar with this. Can you provide a little more of what
    > would be happening and how it is used.
    >
    > bk


    DoubleVision works like this:
    You install doublevision on the server.
    The install script installs a kernel module and links a new kernel.
    You reboot the server to get onto the new kernel.

    >From that point on, all ttys, regardless of what kind of login daemon created them (facetwin vtpd, telnetd, sshd, getty (serial), getty (console), etc...), are multiplexable/shareable. In the case of serial and console tty's you can even access tty's that aren't currently logged in or that don't even have a getty running on them.


    What that exactly means is:

    Any user can "dv ttyxx" any other tty, subject to a plethora of permissions configurable in dv config files.

    user tim is logged in on ttyp4
    user root is logged in on ttyp112
    user root can run "dv" and select ttyp4 from an interactive application that shows all the tty's on the system and what program and user is using them where applicable. Or you can say "dv ttyp4" and jump right there skipping the interactive dv app.

    At that point:
    * Both root and tim can type and the keystrokes from both keyboards go to the app running on ttyp4.
    * The output from the app on ttyp4 goes to both screens on ttyp4 and ttyp112.
    It's like ttyp112 goes into the background and ttyp112 becomes a clone of ttyp4. There is an escape key that the user on ttyp112 can press to break out of the dv session and get his normal tty back.

    Further notables:

    You can create cron jobs that direct output to console tty's that don't have getty's running on them, and then you can dv to that tty from anywhere. Example, have your tape backup direct it's output and input to/from tty12,
    30 21 * * * backup.cron /dev/tty12 2>&1
    and then at some later time you can facetwin/ssh/telnet to the server and then dv tyy12 and see the output from the backup program and type into it, like to respond to some prompt or error message like "Tape full: Please insert volume 2 and press [Enter]: _"
    Don't use any tty that has a getty or any other program running on it for this. tty7 through tty12 are perfect, and the redirecting stdin trick doesn't work with _all_ programs.
    You can also type Alt-F12 at the console to flip to that same tty, which you always could have done regardless of dv. dv just means you can get at the same tty from anywhere.

    Several people can dv in to the same tty so it can be pretty good for classes or training multiple users.

    There are controls to do things like allow a particular tty or user to view-only (no typing) a particular other tty or user, and disallow say a normal user from dv-ing any tty that root is using, etc... groups and overlapping classes of users can be set up that have various permissions.

    In a perfect world, dv can translate terminal control sequences from one kind of terminal to another. That is, say user1 is on ttyp1 using a wyse50 terminal (TERM=wy50). Say user2 is on ttyp2 using a scoansi terminal emulator (TERM=ansi). Without translation, multiplexing those two sessions together would just make a big mess. If ttyp2 dv'd to ttyp1, then when the app on ttyp1 outputted some data to draw stuff on the screen, the scoansi terminal on ttyp2 would receive wyse50 escape sequences, which wouldn't work. Conversely, when user2 typed any keys besides the plainest numbers & letters (arrows, pgup,pgdn,F1-F12,backspace,Del,Ins etc...) the app on ttyp1 which thinks it's talking to a wyse50, would receive scoansi byte sequences that would either mean nothing to it, or worse would mean things other than what user2 intended. (like the classic backspace vs delete issue, you press backspace, and the app thinks you pressed break and immediately exits). But dv, if your terminfo and/or termcap are good and complete and accurate for your terminals, and if the dv termtype logger was run from the users .profile or from /etc/profile, then dv can translate all the terminal-specific byte sequences between all the ttys that are sharing a session. Generally though it's simpler to just have everyone using the same type of terminal, ideally a good scoansi emulator, and then there is almost never any glitches.

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


  7. Re: Remote Control a terminal or the console.

    On Mar 7, 6:48*pm, Brian Keener wrote:
    > I have a client on 5.0.7 that was asking me about ways to connect to
    > another terminal remotely and see what was on their screen for error
    > diagnosing a trouble shooting. *I told them I seem to recall a product
    > called Double View or Double Vision. *Anyone remember this and am I
    > correct in what it does. *Also any other suggestions?
    >
    > --
    > Brian Keener
    > bkeenerReMoVeAnTiS...@thesoftwaresource.com


    You can also download and try the 'screen' program which is located on
    the Skunkworks page. It has some limitations, it seems to only work
    with vt100 emulation and you have to force all sessions to run one
    way, so you are able to attach to them later. But it's open source
    and it's free, if that turns you on.

    No question, Double Vision is the cream of the crop from what I've
    seen. But not free.

    Mark

  8. Re: Remote Control a terminal or the console.

    Note: sco has a built in program very similar to screen called mscreen.
    But I don't think either one provides shared sessions.

    SCO made a TLS package that had a facility called spyfs that was supposed to
    allow one user to watch anothers tty. I never tried it myself. It didn't
    saound from the instructions to be good enough for what I need. I have used
    dv a lot on sco, and used to use ttysnoop (free) on linux, but haven't used
    ttysnoop lately because we have to use FacetWin for our terminal emulator,
    and ttysnoop can't work with FacetWin because FacetWin does not call an
    external login program. DV would work because it works at the kernel level,
    but dv is practically useless on linux because of the way they tie in to
    specific kernels and won't work with any other version or build. There is
    another product that works like ttysnoop but isn't free called peek. I
    haven't tried that myself because, if I could use peek, then I could use
    ttysnoop.

    For our support needs we've basically been living without any replacement
    for DV since switching off of SCO. For training and sales demos we use a web
    based full desktop thing via http://www.beamyourscreen.com/US/Welcome.aspx

    Not nearly as convenient or fast, but, for demos and training it is useful
    to be able to show the whole desktop since several parts of the app cause
    things to happen outside the terminal emulator window, like scanning and
    printing and printing to pdf/email/fax etc..

    If I could find a windows programmer to pay to finish my few remaining hacks
    to Putty, and port my existing hacks up to the current putty, then I could
    finally escape facetwin and get dv-like functionality back in the form of
    ttysnoop. *sigh*...

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


    ----- Original Message -----
    From: "mbennett"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Saturday, March 15, 2008 4:19 PM
    Subject: Re: Remote Control a terminal or the console.


    On Mar 7, 6:48 pm, Brian Keener wrote:
    > I have a client on 5.0.7 that was asking me about ways to connect to
    > another terminal remotely and see what was on their screen for error
    > diagnosing a trouble shooting. I told them I seem to recall a product
    > called Double View or Double Vision. Anyone remember this and am I
    > correct in what it does. Also any other suggestions?
    >
    > --
    > Brian Keener
    > bkeenerReMoVeAnTiS...@thesoftwaresource.com


    You can also download and try the 'screen' program which is located on
    the Skunkworks page. It has some limitations, it seems to only work
    with vt100 emulation and you have to force all sessions to run one
    way, so you are able to attach to them later. But it's open source
    and it's free, if that turns you on.

    No question, Double Vision is the cream of the crop from what I've
    seen. But not free.

    Mark


  9. Re: Remote Control a terminal or the console.

    In article <01b701c88783$cade2200$861fa8c0@tv>,
    Brian K. White wrote:
    >SCO made a TLS package that had a facility called spyfs that was supposed to
    >allow one user to watch anothers tty. I never tried it myself. It didn't
    >saound from the instructions to be good enough for what I need.


    spyfs is handy for times when you really need to see the text flowing to a tty,
    with users/apps seeing exactly the same tty name that they normally do, with
    the certainty that tty behavior will be unchanged, and without the cost of
    redirection through a pty. But it doesn't inject anything - it's strictly for
    observing tty output.

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  10. Re: Remote Control a terminal or the console.

    Brian K. White wrote:
    > Note: sco has a built in program very similar to screen called mscreen.
    > But I don't think either one provides shared sessions.
    >
    > SCO made a TLS package that had a facility called spyfs that was supposed to
    > allow one user to watch anothers tty. I never tried it myself. It didn't
    > saound from the instructions to be good enough for what I need. I have used
    > dv a lot on sco, and used to use ttysnoop (free) on linux, but haven't used
    > ttysnoop lately because we have to use FacetWin for our terminal emulator,
    > and ttysnoop can't work with FacetWin because FacetWin does not call an
    > external login program. DV would work because it works at the kernel level,
    > but dv is practically useless on linux because of the way they tie in to
    > specific kernels and won't work with any other version or build. There is
    > another product that works like ttysnoop but isn't free called peek. I
    > haven't tried that myself because, if I could use peek, then I could use
    > ttysnoop.
    >
    > For our support needs we've basically been living without any replacement
    > for DV since switching off of SCO. For training and sales demos we use a web
    > based full desktop thing via http://www.beamyourscreen.com/US/Welcome.aspx
    >
    > Not nearly as convenient or fast, but, for demos and training it is useful
    > to be able to show the whole desktop since several parts of the app cause
    > things to happen outside the terminal emulator window, like scanning and
    > printing and printing to pdf/email/fax etc..
    >
    > If I could find a windows programmer to pay to finish my few remaining hacks
    > to Putty, and port my existing hacks up to the current putty, then I could
    > finally escape facetwin and get dv-like functionality back in the form of
    > ttysnoop. *sigh*...
    >


    Hop over to comp.security.ssh: a number of the Putty programmers work there,
    and I've been active on that group for years. Good people.

    I take it you don't like VNC for this?

  11. Re: Remote Control a terminal or the console.

    Nico Kadel-Garcia wrote:
    > Brian K. White wrote:
    >> Note: sco has a built in program very similar to screen called mscreen.
    >> But I don't think either one provides shared sessions.
    >>
    >> SCO made a TLS package that had a facility called spyfs that was
    >> supposed to allow one user to watch anothers tty. I never tried it
    >> myself. It didn't saound from the instructions to be good enough for
    >> what I need. I have used dv a lot on sco, and used to use ttysnoop
    >> (free) on linux, but haven't used ttysnoop lately because we have to
    >> use FacetWin for our terminal emulator, and ttysnoop can't work with
    >> FacetWin because FacetWin does not call an external login program. DV
    >> would work because it works at the kernel level, but dv is practically
    >> useless on linux because of the way they tie in to specific kernels
    >> and won't work with any other version or build. There is another
    >> product that works like ttysnoop but isn't free called peek. I haven't
    >> tried that myself because, if I could use peek, then I could use
    >> ttysnoop.
    >>
    >> For our support needs we've basically been living without any
    >> replacement for DV since switching off of SCO. For training and sales
    >> demos we use a web based full desktop thing via
    >> http://www.beamyourscreen.com/US/Welcome.aspx
    >>
    >> Not nearly as convenient or fast, but, for demos and training it is
    >> useful to be able to show the whole desktop since several parts of the
    >> app cause things to happen outside the terminal emulator window, like
    >> scanning and printing and printing to pdf/email/fax etc..
    >>
    >> If I could find a windows programmer to pay to finish my few remaining
    >> hacks to Putty, and port my existing hacks up to the current putty,
    >> then I could finally escape facetwin and get dv-like functionality
    >> back in the form of ttysnoop. *sigh*...
    >>

    >
    > Hop over to comp.security.ssh: a number of the Putty programmers work
    > there, and I've been active on that group for years. Good people.
    >
    > I take it you don't like VNC for this?


    I think you are misunderstanding the primary purpose behind this thread
    - It's not to access the server per se, it's the ability to attach to a
    specific users pty or tty *AFTER* they've already logged in and are
    actively running the application you are trying to fix/debug.

    We are talking about the Unix equivalent of the old windows PCanywhere
    program or the current RDP, except we can, with the right permissions,
    attach to any logged in session on the server, or even (with DV) log in
    on a specific serial line or console multi-screen.

    You see what they see, you can intervene and type commands as if you
    were right there with them using their keyboard. Very valuable support tool.

    How you get to the server is immaterial - telnet, ssh, VPN, VNC, modem
    or whatever.

    --
    ----------------------------------------------------
    Pat Welch, UBB Computer Services, a WCS Affiliate
    SCO Authorized Partner
    Microlite BackupEdge Certified Reseller
    Unix/Linux/Windows/Hardware Sales/Support
    (209) 745-1401 Cell: (209) 251-9120
    E-mail: patubb@inreach.com
    ----------------------------------------------------

  12. Re: Remote Control a terminal or the console.

    On Sun, Mar 16, 2008, Pat Welch wrote:
    ....
    >
    >I think you are misunderstanding the primary purpose behind this thread
    >- It's not to access the server per se, it's the ability to attach to a
    >specific users pty or tty *AFTER* they've already logged in and are
    >actively running the application you are trying to fix/debug.
    >
    >We are talking about the Unix equivalent of the old windows PCanywhere
    >program or the current RDP, except we can, with the right permissions,
    >attach to any logged in session on the server, or even (with DV) log in
    >on a specific serial line or console multi-screen.


    Many years ago I did some of this using the ``kibitz'' script
    that was part of ``expect''. At the time I think I was using OSR
    5.0.something (1996 or so).

    Bill
    --
    INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
    URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
    FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676

    The demands of the majority are always greater than taxation
    alone can provide and thats where the FED comes in. The value of
    the dollar has depreciated 97% since the creation of the FED.

  13. Re: Remote Control a terminal or the console.

    John DuBois wrote:
    > In article <01b701c88783$cade2200$861fa8c0@tv>,
    > Brian K. White wrote:
    >> SCO made a TLS package that had a facility called spyfs that was supposed to
    >> allow one user to watch anothers tty. I never tried it myself. It didn't
    >> saound from the instructions to be good enough for what I need.

    >
    > spyfs is handy for times when you really need to see the text flowing to a tty,
    > with users/apps seeing exactly the same tty name that they normally do, with
    > the certainty that tty behavior will be unchanged, and without the cost of
    > redirection through a pty. But it doesn't inject anything - it's strictly for
    > observing tty output.
    >


    Well, far from me to disagree/correct John but the spyfs package comes with
    the spycontrol program which, according to the docs:

    "The spycontrol program is the most powerful demonstration program in SPY.
    It allows you to both observe and control another person's activity, turning
    your keyboard and screen into a mirror of theirs. All keystrokes you type
    (including the SUSPEND, QUIT, and INTERRUPT keys) are sent to the tty
    you're controlling. Because of this, spycontrol uses the special keys used
    by rlogin(TC) to terminate the program, as explained below"

    [snip]

    I dove have a copy of the spyfs package with me (dunno if it's been updated
    during these years) so if anyone's interested, please post here and I'll be
    happy to help.

    Best,
    Rob

  14. Re: Remote Control a terminal or the console.


    ----- Original Message -----
    From: "Pat Welch"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Sunday, March 16, 2008 8:43 PM
    Subject: Re: Remote Control a terminal or the console.


    > Nico Kadel-Garcia wrote:
    >> Brian K. White wrote:
    >>> Note: sco has a built in program very similar to screen called mscreen.
    >>> But I don't think either one provides shared sessions.
    >>>
    >>> SCO made a TLS package that had a facility called spyfs that was
    >>> supposed to allow one user to watch anothers tty. I never tried it
    >>> myself. It didn't saound from the instructions to be good enough for
    >>> what I need. I have used dv a lot on sco, and used to use ttysnoop
    >>> (free) on linux, but haven't used ttysnoop lately because we have to
    >>> use FacetWin for our terminal emulator, and ttysnoop can't work with
    >>> FacetWin because FacetWin does not call an external login program. DV
    >>> would work because it works at the kernel level, but dv is practically
    >>> useless on linux because of the way they tie in to specific kernels
    >>> and won't work with any other version or build. There is another
    >>> product that works like ttysnoop but isn't free called peek. I haven't
    >>> tried that myself because, if I could use peek, then I could use
    >>> ttysnoop.
    >>>
    >>> For our support needs we've basically been living without any
    >>> replacement for DV since switching off of SCO. For training and sales
    >>> demos we use a web based full desktop thing via
    >>> http://www.beamyourscreen.com/US/Welcome.aspx
    >>>
    >>> Not nearly as convenient or fast, but, for demos and training it is
    >>> useful to be able to show the whole desktop since several parts of the
    >>> app cause things to happen outside the terminal emulator window, like
    >>> scanning and printing and printing to pdf/email/fax etc..
    >>>
    >>> If I could find a windows programmer to pay to finish my few remaining
    >>> hacks to Putty, and port my existing hacks up to the current putty,
    >>> then I could finally escape facetwin and get dv-like functionality
    >>> back in the form of ttysnoop. *sigh*...
    >>>

    >>
    >> Hop over to comp.security.ssh: a number of the Putty programmers work
    >> there, and I've been active on that group for years. Good people.
    >>
    >> I take it you don't like VNC for this?

    >
    > I think you are misunderstanding the primary purpose behind this thread
    > - It's not to access the server per se, it's the ability to attach to a
    > specific users pty or tty *AFTER* they've already logged in and are
    > actively running the application you are trying to fix/debug.


    Then I'm not misunderstanding anything.
    That is exactly what I was talking about.
    That is exactly what all of dv, ttysnoop, peek, and spyfs provide, and what screen & mscreen do not provide.

    > How you get to the server is immaterial - telnet, ssh, VPN, VNC, modem
    > or whatever.


    What? Of course how you connect to the server could (and as it happens, does) matter to how and whether a tty multiplexer works.

    How you get to the server matters a great deal, if the tty multiplexer happens to work by replacing /bin/login and sitting between you and the kernel all during your session.
    That is how ttysnoop and peek both work. What happens is, during login, THEY actually become the top level process for that tty instead of your shell, but then they launch your shell and connect it to the tty, so from your point of view it's like any other normal login, but, really there is an application in the background (ttysnoop or peek) that all of the tty data for your entire session is passing through, and so it's possible for that application to multiplex that data with any other sessions which that application is also managing. If all users everywhere have logged in this way, then any tty may be connected to any other tty.

    But FacetWin does not call an external login program, nor can it be configured to do so, nor can you trick it by replacing the real /bin/login with a wrapper, because it just plain doesn't call any external program.

    And so, ttysnoop and peek do both provide exactly the function you describe, and, happen to not be useable if you are logging in via FacetWin.
    They can't be used with openssh either by default, but openssh can be configured to call a login program of your choice, and/or you can replace the real /bin/login with a wrapper.

    DV on the other hand, and spyfs too I beleive, works similarly in that it inserts itself between you and the real tty's, but it does so at a lower level, right in the kernel (in the form of a driver module), and takes the place of, or sits in front of, the kernel level tty api's which any and all userspace tty-granting/tty-using code must talk to, including FacetWin and openssh in it's normal mode and anything/everything else. Therefor, dv and spyfs also provide the same functionality, but in their case it doesn't matter what facility you used to log in and get a tty.

    xterms/xterm-alikes probably fall in the FacetWin category of things that create tty's without calling some external program like /bin/login, however, in that case the xterm binary itself could probably be replaced with a wrapper script that calls ttysnoop or peek. I don't think you can do that with FacetWin's vtpd which is called from inetd (xinetd on linux). I don't remember if I ever tried that... hm...

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



  15. Re: Remote Control a terminal or the console.

    On Sun, 16 Mar 2008, Brian K. White wrote:

    > ...
    > If I could find a windows programmer to pay to finish my few remaining hacks
    > to Putty, and port my existing hacks up to the current putty, then I could
    > finally escape facetwin and get dv-like functionality back in the form of
    > ttysnoop. *sigh*...


    What are you looking for in Putty in this regard?

    I have brainstormed briefly (more of a brainsquall) about adding shadowing
    features to AnzioWin. If enabled, it could send whatever it received to
    another terminal session somewhere on the network. The Unix/Linux server
    would not even be involved. Other options:

    1) A screen dump could be sent on command.

    2) User could allow keyboard input from the shadowing terminal.

    3) User could allow mouse and menu input from the shadowing terminal.

    4) Shadowing terminal could capture print jobs.

    Arguing against doing all this work, though, is that fact that remote
    desktop applications are more all-encompassing, and getting very good. I
    use Webex, and it has assisted greatly in customer support recently.

    I welcome any thoughts.

    Regards,
    .....Bob Rasmussen, President, Rasmussen Software, Inc.

    personal e-mail: ras@anzio.com
    company e-mail: rsi@anzio.com
    voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
    fax: (US) 503-624-0760
    web: http://www.anzio.com
    street address: Rasmussen Software, Inc.
    10240 SW Nimbus, Suite L9
    Portland, OR 97223 USA

  16. Re: Remote Control a terminal or the console.


    ----- Original Message -----
    From: "Bob Rasmussen"
    To: "Brian K. White"
    Cc:
    Sent: Monday, March 17, 2008 3:14 PM
    Subject: Re: Remote Control a terminal or the console.


    > On Sun, 16 Mar 2008, Brian K. White wrote:
    >
    >> ...
    >> If I could find a windows programmer to pay to finish my few remaining hacks
    >> to Putty, and port my existing hacks up to the current putty, then I could
    >> finally escape facetwin and get dv-like functionality back in the form of
    >> ttysnoop. *sigh*...

    >
    > What are you looking for in Putty in this regard?


    Nothing to do with tty sharing, that would just be a side effect.
    Currently I have a 0.58 or 0.59 based putty with:
    * run-program escape sequence
    * passthru print flush timer (stock putty causes a page-eject every time filepro toggles the printer off during a report where screen updates are interspersed with print data)
    * ability to load settings from a url (instead of windows registry)
    * ability to auto-launch putty from a web link and auto load settings mentioned above.

    Thise are a great and major start, and I use that version myself for all my day to day admin stuff and application development and testing the same app that the users use via facetwin, just so it gets as much testing as possible and I have a good chance to hit any glitches myself before users.
    But it's not yet good enough for production until I also add:
    * Automatically discover the default windows printer on the fly and use it by default if the settings don't define a printer or maybe if the settings define a special value that means automatic. (So I can have a web link to a highly configured set of settings, and have everyone use that same link, yet everyones printer works who's default printer is pcl capable.
    * Ability to optionally, easy/simply, save the current settings to a local file (or registry I guess, though a file is so much handier for emailing, copying to a new pc, etc...) So people can log in via the web link, to get a correct set of settings that I have configured to start with, and then customize it locally by defining a non-default printer, storing the login name & password, font size/window size, etc..
    * Ability to store the name & password in the settings in a SIMPLE direct manner, and works regardless which connection protocol telnet/rlogin/ssh/serial. no ssh keys.

    Then, not necessary, but would be nice to also port my existing mods from 0.5x to 0.6x. I had someone look at it and they said that 0.60 is very different from 0.5x and they basically couldn't do it because the guy who actually did my original work was gone and no one else was familiar enough with it.

    What this has to do with tty sharing is not even about putty but the server daemons. putty connects to telnetd, rshd, sshd, or getty, all of which ttysnoop works with. So, if I can ever finish getting putty hacked on to the point where I can actually put it into production, I'll regain dv-like functionality in the form of ttysnoop. I can't use dv itself because it's too kernel specific and I don't happen to use any kernels it supports, and even if I did, I know that in 10 minutes I may change the kernel and thus break dv, so I'd be dumb to use something that I knew would break that easily, or that would prevent me from managing my systems as I wish/need just so as not to break dv. I don't think I can use spyfs either, I never saw any source code for it and I think it was specific to the sco osr5 kernel.

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


  17. Re: Remote Control a terminal or the console.

    Brian K. White wrote:
    > >>
    > >> I take it you don't like VNC for this?

    > >
    > > I think you are misunderstanding the primary purpose behind this thread
    > > - It's not to access the server per se, it's the ability to attach to a
    > > specific users pty or tty *AFTER* they've already logged in and are
    > > actively running the application you are trying to fix/debug.

    >
    > Then I'm not misunderstanding anything.
    > That is exactly what I was talking about.
    > That is exactly what all of dv, ttysnoop, peek, and spyfs provide,
    > and what screen & mscreen do not provide.


    Brian,

    I think Pat was actually replying to Nico when he said "I think you are
    misunderstanding the primary purpose behind this thread" as Nico was the one
    mentioning VNC and "emacs". Part of my curiosity was to the mention of
    emacs and its use and what seemed to be a hint it was the poor man's dv. I
    was wondering if others had done that and where you find documentation or
    how to's on it. As to dv I have actually briefly worked with that a long
    time ago and liked it and your explanation of its usage is exactly what I
    and my customer are looking for.

    Thanks

    bk


  18. Re: Remote Control a terminal or the console.


    ----- Original Message -----
    From: "Brian Keener"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Monday, March 17, 2008 6:47 PM
    Subject: Re: Remote Control a terminal or the console.


    > Brian K. White wrote:
    >> >>
    >> >> I take it you don't like VNC for this?
    >> >
    >> > I think you are misunderstanding the primary purpose behind this thread
    >> > - It's not to access the server per se, it's the ability to attach to a
    >> > specific users pty or tty *AFTER* they've already logged in and are
    >> > actively running the application you are trying to fix/debug.

    >>
    >> Then I'm not misunderstanding anything.
    >> That is exactly what I was talking about.
    >> That is exactly what all of dv, ttysnoop, peek, and spyfs provide,
    >> and what screen & mscreen do not provide.

    >
    > Brian,
    >
    > I think Pat was actually replying to Nico when he said "I think you are
    > misunderstanding the primary purpose behind this thread" as Nico was the one
    > mentioning VNC and "emacs".


    Doh, you are right. I completely missed that.
    Sorry Pat.

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


  19. Re: Remote Control a terminal or the console.

    Brian K. White wrote:
    > ----- Original Message -----
    > From: "Brian Keener"
    > Newsgroups: comp.unix.sco.misc
    > To:
    > Sent: Monday, March 17, 2008 6:47 PM
    > Subject: Re: Remote Control a terminal or the console.
    >
    >
    >> Brian K. White wrote:
    >>>>> I take it you don't like VNC for this?
    >>>> I think you are misunderstanding the primary purpose behind this thread
    >>>> - It's not to access the server per se, it's the ability to attach to a
    >>>> specific users pty or tty *AFTER* they've already logged in and are
    >>>> actively running the application you are trying to fix/debug.
    >>> Then I'm not misunderstanding anything.
    >>> That is exactly what I was talking about.
    >>> That is exactly what all of dv, ttysnoop, peek, and spyfs provide,
    >>> and what screen & mscreen do not provide.

    >> Brian,
    >>
    >> I think Pat was actually replying to Nico when he said "I think you are
    >> misunderstanding the primary purpose behind this thread" as Nico was the one
    >> mentioning VNC and "emacs".

    >
    > Doh, you are right. I completely missed that.
    > Sorry Pat.
    >


    S'ok, as long as you buy the virtual Everclear the next time we happen
    to be at Callahan's at the same time

    --
    ----------------------------------------------------
    Pat Welch, UBB Computer Services, a WCS Affiliate
    SCO Authorized Partner
    Microlite BackupEdge Certified Reseller
    Unix/Linux/Windows/Hardware Sales/Support
    (209) 745-1401 Cell: (209) 251-9120
    E-mail: patubb@inreach.com
    ----------------------------------------------------

  20. Re: Remote Control a terminal or the console.

    Pat Welch wrote:
    > Brian K. White wrote:
    >> ----- Original Message ----- From: "Brian Keener"
    >>
    >> Newsgroups: comp.unix.sco.misc
    >> To:
    >> Sent: Monday, March 17, 2008 6:47 PM
    >> Subject: Re: Remote Control a terminal or the console.
    >>
    >>
    >>> Brian K. White wrote:
    >>>>>> I take it you don't like VNC for this?
    >>>>> I think you are misunderstanding the primary purpose behind this
    >>>>> thread - It's not to access the server per se, it's the ability to
    >>>>> attach to a specific users pty or tty *AFTER* they've already
    >>>>> logged in and are actively running the application you are trying
    >>>>> to fix/debug.
    >>>> Then I'm not misunderstanding anything.
    >>>> That is exactly what I was talking about.
    >>>> That is exactly what all of dv, ttysnoop, peek, and spyfs provide,
    >>>> and what screen & mscreen do not provide.
    >>> Brian,
    >>>
    >>> I think Pat was actually replying to Nico when he said "I think you
    >>> are misunderstanding the primary purpose behind this thread" as Nico
    >>> was the one mentioning VNC and "emacs".

    >>
    >> Doh, you are right. I completely missed that.
    >> Sorry Pat.
    >>

    >
    > S'ok, as long as you buy the virtual Everclear the next time we happen
    > to be at Callahan's at the same time
    >


    Please: that bar stopped being fun with Spider Robinson started getting enough
    to eat and all his stories had the heroes winning in every chapter....

+ Reply to Thread
Page 1 of 2 1 2 LastLast