> The ability to shadow sessions on different LTS networks over a WAN link. For
> example, say I have 5 LTS networks located in different cities... I would like
> to be able to shadow sessions in our local office *and/or* in remote
> offices...
>
> Is this gonna require additional coding, or is
> From: "Jason Bechtel" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Date: Tue, 11 Jun 2002 01:15:52 +0200
>
> 1: "Pushing" a session --
> I believe the original messages regarding the existence of
> x0rfbserver were closely followed by someone mentioning a
> presentation in western Canada (Vanco
> Date: Mon, 10 Jun 2002 09:05:14 -0400
> From: Venkat Manakkal <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
>> As distasteful as it sounds, my boss has asked me about the
>> possibility of what I'll call 'Passive Shadowing', ie,
>> shadowing someones workstation without the ability to take
>> it
Charles Marcus ([EMAIL PROTECTED]) wrote:
> Hi all,
>
> I am very excited by the discussions for implementing shadowing capability
> using X0rfbserver in LTSP, but had one question and one comment...
>
> Question:
> Will it be very simple to 'reverse' the concept, so that someone (the Admin,
> o
Hi all,
I am very excited by the discussions for implementing shadowing capability
using X0rfbserver in LTSP, but had one question and one comment...
Question:
Will it be very simple to 'reverse' the concept, so that someone (the Admin,
or someone in the 'Trainers' Group) could *push* their desk
On Fri, 7 Jun 2002, Egan, Matt B. (Artco) wrote:
> > An alternative to NIS might be LDAP, but we haven't gotten
> > that to work for local apps yet.
>
> What are the hangups with LDAP so far?
I'm sort of the point man for LDAP support in LTSP. LDAP support for
loading the workstation's config
On Fri, 7 Jun 2002 [EMAIL PROTECTED] wrote:
> In the past, some people have suggested just copying the
> servers /etc/passwd file to /opt/ltsp/i386/etc, but I can
> tell you very clearly that will NEVER be part of a
> standard LTSP package.
Beyond the obvious 'least privilege argument' in not re
> John,
>
> Just a couple of questions. You say that you run your clients locally,
> does this include the window manager?
** Yes, but I run a very lightweight manager (ICE)
> How much ram do you have in the clients and do you use local or network
> swap?? Also what CPU do you have in them?
On Fri, 2002-06-07 at 04:06, John_Cuzzola wrote:
>
>
> *** Oh yes, sorry about that...I guess somewhat of the confusion is LTSP
> Version 2 to 3. It is significantly different. I haven't had the
> opportunity tpo try version 3 but since we're using version 2 and working
> fine there are no plans
>
> What i'm trying to figure out, is: Does this thing
> work with any Xserver, or does it have to be an xserver
> that uses vesa ?
*** I believe it will work with any Xserver and it does seem to be fairly
lightweight. Although being able to launch it on demand would be a plus :)
Hi,
SSH with PKI keys is one posiblity, see:
http://www.arches.uga.edu/~pkeck/ssh/
You can set up one ssh key for each app you want to run w/o a password and
append the key to to the user who's going to be allowed to use the app.
PS: This requires a ssh server running on the client. I'm now usi
Ok, so the curiosity got the better of me, and I decided
to take a look at the x0rfbserver program.
I grabbed the source tarball and looked at the code, to see if
I could understand how it works, and what it would take
to eliminate the pop-up dialog and to setup the properties
via commandline arg
> Ooh! What about this... What about starting a program
> with xinit as was recently suggested, but instead of
> starting x0rfbserver it starts a monitoring app?
*** I've written a similiar program (God it's a hacked up mess, but I get
by) that listens on the client machine (tcp port) for a
How might the NIS requirement affect those using alternate
authentication schemes? We are happily authenticating users against
our PDC using SAMBA's winbind. For us, winbind makes transitioning
users from PC to thin client quite painless and administration is a breeze.
Can't wait to see ver
Jim,
1) I think that rsh should be avoided on general principle.
2) I don't think local apps and NIS or even LDAP should be
necessary in order to get shadowing capabilities.
Perhaps these ideals are unrealistic and I appreciate the
old maxim about reinventing the wheel, but couldn't we just
find
Matt,
it was over a year ago that Andrew Williams and I tried using
LDAP for authenticating users for Local apps, and I don't remember
all the details. We just didn't get it going, and had to
move on.
I'm confident that it can be done. It's just a matter of pouring
the right amount of time in
> An alternative to NIS might be LDAP, but we haven't gotten
> that to work for local apps yet.
What are the hangups with LDAP so far?
> In the past, some people have suggested just copying the
> servers /etc/passwd file to /opt/ltsp/i386/etc, but I can
> tell you very clearly that will NEVER b
Jason and Matt,
The problem with running an rsh daemon on the
workstations is that it needs to know WHO is sending
the request to run something, and whether they are
allowed to or not.
By turning on local apps, you enable NIS. That is how
the rsh daemon will validate that the "WHO" is a correct
Matt,
I don't think local apps should have to be enabled in order
to get this to work. They should be totally separate
options with no mutual dependency or exclusivity between
them. And I think it could be easily set up to work like
this...
The only thing required is a way to start and stop th
> Date: Thu, 6 Jun 2002 14:27:02 -0400 (EDT)
> From: <[EMAIL PROTECTED]>
> I'll just make a mention that LTSP v3.1 is going to make this
> significantly easier to setup, because of a new feature
> we are calling "Screen Scripts" (for lack of a better name).
>
> Each virtual tty will be able to ru
Oy!
To much info. I read through that twice and its still blew me away.
Anyway. I think your on track for what I would love to see.
These points
No end user visibility or intervention required. (even the password supplied
by the admin invoking the session)
Not always running (I have lots of 4
John,
I'll just make a mention that LTSP v3.1 is going to make this
significantly easier to setup, because of a new feature
we are calling "Screen Scripts" (for lack of a better name).
Each virtual tty will be able to run a session script that
will dictate exactly what happens on that tty.
That
*** Oh yes, sorry about that...I guess somewhat of the confusion is LTSP
Version 2 to 3. It is significantly different. I haven't had the
opportunity tpo try version 3 but since we're using version 2 and working
fine there are no plans to switch. Yes you'll need to be able to run the
xinit comma
Sorry to be obtuse, but I'm confused by what you're doing here (and I'm dying
to understand). How complicated is it to set up to run a "local window manager"?
Why would someone want to run a local window manager (to be able to easily
launch local apps?). Which WM are you running?
Did you h
24 matches
Mail list logo
