Juergen,
some points about the login scripts, inline below:
Juergen Arndt wrote:
Hello all,
I have some questions about the login scripts of SSGD. I installed
SSGD 4.3 in our intranet on a Solaris server and configured it to
launch some X applications like xterm, which are located on another
application server. The connection protocol between SSGD server and
application server is ssh.
1) Most users don't have problems to start the xterm. But for some
users it just don't work. The error is "ApplicationServerLoginFailed".
I figured out, that it's probably a problem of the login script with
the server login prompt. All users, who cannot start the app, are
asked to enter a passphrase for their ssh key like this:
Enter passphrase for key '/home/myuser/.ssh/id_dsa':
Maybe I have to change something in vars.exp, but I'm not sure in
which way. Could anybody give some hints for that?
Well, there are actually three places you'd need to look - unix.exp,
procs.exp, and vars.exp. At least in 4.31, there's already code for the
ssh key prompt, in the variable "sshprompt" - what version are you using?
2) I'm wondering where the executable is located, to run these login
scripts. As far as I know, they are written in expect, but how they
are started?
As far as I know, expect processing takes place in the ttaexecpe
process, but that's really not the way to look at this.
3) How is it possible to debug these scripts? I found the option
"startdebug" in the scripts for more information in the log files, but
is it really necessary, to log in into SSGD as the user "myuser",
launch the application and then look into the log files? I'd like to
login onto a shell of the SSGD server (Solaris) and start the scripts
as the user "myuser", so I can see, at which point the error occures.
So this corresponds to point 2).
In addition to "startdebug", you'll want to enable xpe logging, like:
/opt/tarantella/bin/tarantella config edit
--tarantella-config-execpeconfig-logfilter execpe/*/*
This will generate additional logging in 'execpe{pid}.log' files. But I
find you can sometimes get the information you need in the "Display
Launch Details" dialog during application launch - this can often tell
you where you've gone wrong.
4) Last point for today ;) It takes a long time to start the
applications, for example the xterm or xclock. It takes around 45 - 60
seconds. When it is started, you can work with it like a charm. But
the long startup time is a little bit strange, I think. Is it possible
to accelerate it? And is this related to the login scripts too?
Almost certainly a mismatch between the login scripts and your .profile
environment - look for an "echo SYNC" message in there, somewhere -
basically expect didn't see something it, uh, "expected", waited for it,
then timed out and sent the next command "in the blind" which resumed
the script. This unexpected prompt is usually an unexpected shell
prompt, and can be added to the list of expected shell prompts on the
line that begins "set prompts(prompt)" in vars.exp.
Or, it could be some other prompt for which we don't have code, like:
Enter project-id:
or
There is new news, read it now?:
For these kinds of things, you'd have to write some custom script to
deal with that. I find the quick test to determine stuff like this is
to simply get rid of the .profile/.bashrc/etc, and just use defaults all
the way around. For example, to test for a shell prompt problem, set
PS1=$ in the users .profile, and see if that resolves the delay.
Hope this helps,
Rick
So, that's all for now. Thank you for reading to the end :-) Any help
is appreciated.
Bye,
Juergen
_______________________________________________
SGD-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sgd-users
