SSH Message processing (General questions)
by Gary Jones, Monday, February 18, 2008, 22:27 (6122 days ago)
I'm sending a set of commands to a Unix server to run scripts with a c# asp.net program. If I run all the commands in debug mode, everything works fine. However, once I run them all in the program they seem to run to fast or something, because I don't get any results back and the Unix host doesn't seem to get the commands. I'm wondering if there is some kind of timing issue or some known issue? All the setup commands work, but it seems to have problems one the one that calls the unix script. Does anyone have any ideas?
Thanks,
Gary
Re: SSH Message processing
by wodDamir, Monday, February 18, 2008, 22:30 (6122 days ago) @ Gary Jones
Hi Gary,
Did you try using WaitFor / Execute methods?
You should use these methods in Blocking mode in order to send commands one-by-one.
Regards,
Damba
Re: SSH Message processing
by garyjones, Monday, February 18, 2008, 22:43 (6122 days ago) @ wodDamir
I am using the Execute method and it is in blocking mode. We're generating most code dynamically, but I tried my best to put together a sample of what we're doing below.
Connect method
---------------------
this.Session = new WeOnlyDo.Client.SSH();
this.Session.LicenseKey = xxx;
this.Session.Login = this.Login;
this.Session.Password = this.Password;
this.Session.Timeout = this.TimeOut;
this.Session.Protocol = WeOnlyDo.Client.SSH.SupportedProtocols.SSHAuto;
this.Session.Port = this.Port;
this.Session.Blocking = true;
this.Session.Prompt = this.Prompt;
this.Session.Connect(this.Host);
...
ShellSessionAction parentAction = this.Parent as ShellSessionAction;
if (parentAction == null)
throw new ApplicationException( ShellCommandAction parent is not ShellSessionAction. );
SSH session = parentAction.Session;
// Is Session connected
if (session.State != WeOnlyDo.Client.SSH.States.Connected)
throw new SystemException( Session is not connected. );
ExecuteCommand(session, usr/local/bin/pbrun su-billapp ,this.prompt);
ExecuteCommand(session, cd /opt/apps/billing/${BillingEnv}/billing-batch/scripts/ ,this.prompt);
ExecuteCommand(session, . ./export_env_variables.sh
,this.prompt); //this line has the problem
ExecuteCommand(session, ksh ./delete_emp.sh 123456789
,this.prompt); //this line has the problem
...
Execute method (non important code left out)
-----------------------------
public string ExecuteCommand(WeOnlyDo.Client.SSH session, string commandText, string prompt)
{
string ret = string.Empty;
ret = session.Execute(commandText, this.Prompt, this.Timeout);
return ret
}
Thanks!
Re: SSH Message processing
by wodDamir, Monday, February 18, 2008, 23:18 (6122 days ago) @ garyjones
Hi Gary,
What error exactly do you receive?
What prompt are you waiting for after the cd command? I believe that lines after that command fail because of the prompt value specified in the call.
Can you please check that out?
Regards,
Damba
Re: SSH Message processing
by garyjones, Tuesday, February 19, 2008, 00:09 (6122 days ago) @ wodDamir
I don't receive an error, it just doesn't seem to, or it incorrectly processes the commmands. The prompt is always $, so I think that is ok. I use a Putty session to test it first before using the SSH component. I'm attaching that log below. It also does run in debug mode, just not when it runs through real time. The one thing I noticed is when it runs in real time, the delete emp returns the following instead of what it shows in the Putty log below--- . ./export_env_variables.sh ./delete_ecn.sh 112374251845210 . It seems to repeat the commands instead of running them.
Thanks!
Putty log--
Using username jonesga .
Using keyboard-interactive authentication.
Password:
Last login: Mon Feb 18 12:18:36 2008 from r.wel
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ /usr/local/bin/pbrun su-billapp
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ cd /opt/apps/billing/qa1/billing-batch/scripts/
$ . ./export_env_variables.sh
$ ksh ./delete_emp.sh 112374251
SQL*Plus: Release 10.2.0.1.0 - Production on Mon Feb 18 14:41:49 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning and Data Mining options
SQL> SQL> SQL> SQL> SQL> Deleting EMP=112374251
PL/SQL procedure successfully completed.
Commit complete.
SQL> SQL> Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning and Data Mining options
$
Re: SSH Message processing
by wodDamir, Tuesday, February 19, 2008, 09:09 (6122 days ago) @ garyjones
Hi Gary,
Can you please try adding [code]SSH1.DataReady = 0;[/code] in between ExecuteCommand calls?
Also, can you try adding one WaitFor at the end of execute calls? Does that help?
Regards,
Damba
Re: SSH Message processing
by garyjones, Tuesday, February 19, 2008, 16:45 (6121 days ago) @ wodDamir
Is there a generic string pattern I put into the WaitFor, or do I need to always put in the pattern that I'm expecting back?
Re: SSH Message processing
by woddrazen, Tuesday, February 19, 2008, 16:51 (6121 days ago) @ garyjones
Hi Gary,
You can try with regular expression $ #>] that accepts any of those chars $, ,#,> if they appear at the end of the line.
This includes 99.9 of most UNIX command prompts (including root account).
Here is example in VB6:[code] Ssh1.WaitFor( regex:[$ #>] $ )[/code]
Hope this helps.
Regards,
Drazen
Re: SSH Message processing
by garyjones, Tuesday, February 19, 2008, 18:23 (6121 days ago) @ woddrazen
Yes that helped. Thanks. I think I might have found the breakthrough though. I did put in the SSH1.DataReady = 0 which seems to help. But I think the kicker was in the
characters, which I never really mentioned in any previous post. I noticed in another posting that y'all mentioned most Unix servers only liked the LF not the CRLF command. What I found in this case was that I needed both on almost all commands except for the one that calls the delete_emp.sh script. When I just included the
on that command it seems to work every time. Maybe it's something to do with our Unix servers, I'm not sure and I definitely not a Unix guy, but for now it seems to be pretty stable. I'll let you know if I have other problems.
Thanks!