Menu
▾
▴
RE: [Expectperl-discuss] Issue with Expect.pm ssh command through Apache web
|
From: ROCHE,WILLY (HP-France,ex1) <wil...@hp...> - 2004-02-06 08:49:34
|
Hi,
This proposal was a good one.
I have write a second script which start the first one with qx {
first_script } and this works now. There should really be something =
strange
in the way Expect.pm handle stdin/stdout.
I will still try to find a better solution, has I have large amout of =
data
to get from the web POST, it's not convenient to start the second =
script
with all those data on the cmd line and passing all this through a file
require to ensure that concurrent access to the web page won't crash =
each
other, which is feasible but painfull to implement.
Anyway, thanks for the idea. I now have a more precise idea of where in =
the
expect.pm code to look to try to fix the issue directly.
Regards,
Willy
--=20
Willy ROCHE
Network Support Problem Management
HP Managed Services EMEA Networks
___________________________________
Tel: +33 4 7614 4768
Fax: +33 4 7614 1716
E-Mail: wil...@hp...
Hewlett-Packard Grenoble
5, avenue Raymond Chanas
38053 GRENOBLE Cedex 9
http://www.hp.com/hps/network/
> -----Original Message-----
> From: Dav...@CT... [mailto:Dav...@CT...]
> Sent: jeudi 5 f=E9vrier 2004 16:17
> To: ROCHE,WILLY (HP-France,ex1)
> Cc: exp...@li...;
> exp...@li...; Roland Giersig
> Subject: RE: [Expectperl-discuss] Issue with Expect.pm ssh command
> through Apache web
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> If it works fine from the cmd line and you dont' feel like=20
> messing with it,
> then pending what Roland says, you might want to consider avoiding =
the
> issue by moving your Expect.pm code out of CGI script to an=20
> external perl
> script, then open this external perl script as a read-only=20
> FileHandle from
> CGI. This way, everybody wins. cgi script is happy because=20
> now it only
> deals with standard FileHandle.
>=20
> Personally, I've not had much luck using Expect.pm within=20
> Perl CGI because
> of forking issues and duplicate sessions (among other=20
> things), but rather
> than intellectually solving the problem, I just avoid it. =20
> Whatever the
> CGI script needs to get back for display could simply be=20
> engineered to be
> STDOUT in the external perl Expect script. You can make=20
> STDOUT hot in the
> CGI script (i.e., $|=3D1) if you want to force updates=20
> incrementally from
> external script without making the user wait, but maybe that's not
> important
>=20
>=20
>=20
>=20
>=20
> =20
> =20
> =20
> =20
> To:=20
> Roland Giersig <RGi...@cp...>, =20
> =20
> exp...@li... =20
> cc:=20
> =20
> "ROCHE,WILLY (HP-France,ex1)" =20
> Subject: RE: [Expectperl-discuss] Issue with =20
> <wil...@hp...> =20
> Expect.pm ssh command through Apache web =20
> Sent by: =20
> =20
> exp...@li...urc =20
> =20
> eforge.net =20
> =20
> =20
> =20
> =20
> =20
> 02/05/2004 07:54 AM =20
> =20
> =20
> =20
> =20
> =20
>=20
>=20
>=20
>=20
> Hello Roland,
>=20
> Thanks for your answer.
> Let me explain the whole issue I am facing:
> - I use Net::Telnet::Cisco to control some cisco equipments.
> - Those equipements are accessible only from one "secured" system.
> - This secured system can only be accessed through ssh.
>=20
> Therefore, as the only way for me to use Net::Telnet::Cisco=20
> even after the
> rebound is to use the possibility to start=20
> Net::Telnet::Cisco passing a
> open FileHandle, I have think of using expect->spwan function=20
> to connect
> via
> SSH to the secure system and then pass the FileHandle to N::T::C.
> Maybe it's not the best way to do it? Have you other suggestion?
>=20
> Nevertheless, this work fine when running the script from=20
> console, but when
> I run the script via Apache and Mod_Perl, ssh does not accept to =
start
> properly and answers the error messages
> > Pseudo-terminal will not be allocated because stdin is not=20
> a terminal. #
> when starting
> > read: Bad file descriptor # when I do the first ->expect command
> > ttytype: couldn't open /dev/tty for reading
> > stty: : Not a typewriter
>=20
> My system is a PC with Linux RH8, Perl 5.8.3 / mod_perl=20
> 1.99_12 / Apache
> 2.0.48
>=20
> Is there a better way to initiate a ssh to 1st system and=20
> then telnet to
> something else and then provide an open FileHandle to=20
> Net::Telnet::Cisco?
>=20
> Thanks in advance.
> Willy
>=20
> --
> Willy ROCHE
> Network Support Problem Management
> HP Managed Services EMEA Networks
> ___________________________________
> Tel: +33 4 7614 4768
> Fax: +33 4 7614 1716
> E-Mail: wil...@hp...
> Hewlett-Packard Grenoble
> 5, avenue Raymond Chanas
> 38053 GRENOBLE Cedex 9
> http://www.hp.com/hps/network/
>=20
>=20
> > -----Original Message-----
> > From: Roland Giersig [mailto:RGi...@cp...]
> > Sent: mercredi 4 f=E9vrier 2004 11:05
> > To: exp...@li...
> > Subject: Re: [Expectperl-discuss] Issue with Expect.pm ssh command
> > through Apache web
> >
> >
> > ROCHE,WILLY (HP-France,ex1) wrote:
> >
> > > Hi Everyone,
> > >
> > > I am trying to connect to some equipment through ssh and
> > want to use Expect.
> >
> > Are you sure you HAVE to use Expect? :o)
> > How about non-interactive ssh commands?
> >
> > > It works fine from console, but when starting my perl
> > script from Apache web
> > > server it fails.
> > >
> > > I have Perl 5.8.3 / mod_perl 1.99_12 / Apache 2.0.48
> > >
> > > Code that works on console but not through the web:
> > > $exp =3D new Expect;
> > > $exp->raw_pty(1);
> > > $exp->spawn ('ssh', '-1', '-A', 'me@otherhost');
> > > $exp->expect (10, "\$"); # waiting for the server prompt
> > > $exp->send ("ls\n");
> > > $exp->expect (10, "toto"); # one of the file in ls output
> > >
> > > On console, it works fine and exit properly.
> > > Through web, it does not and ouput following errors:
> > > Pseudo-terminal will not be allocated because stdin is
> > not a terminal.
> > > read: Bad file descriptor
> > > ttytype: couldn't open /dev/tty for reading
> > > stty: : Not a typewriter
> > This is rather strange. What system are you running on? Normally =
the
> > spawned program should get the pseudo-terminal as its controlling
> > terminal...
> >
> > > I also try ssh options "-t" and "-T" with no benefits.
> >
> > Yes, ssh is very security-concerned and won't read a password from =
a
> > non-terminal stdin. But if you set public-key-authentication
> > so you can
> > login without a password then it doesn't have to ask for a
> > password and
> > it should work. BTW, have you read the Expect FAQ about ssh? ;o)
> >
> > Best regards,
> >
> > Roland
> > --
> > RGi...@cp...
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Expectperl-discuss mailing list
> > Exp...@li...
> > https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> >
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
>=20
>=20
>=20
>=20
> ------------------------------------------------
> NOTICE OF CONFIDENTIALITY
> ------------------------------------------------
>=20
> This e-mail and any attachments thereto is intended only for=20
> use by the
> addressee(s) named herein and may be proprietary and/or=20
> legally privileged.
> If you are not the intended recipient of this e-mail, you are hereby
> notified that any dissemination, distribution or copying of=20
> this email, and
> any attachments thereto, without the prior written permission=20
> of the sender
> is strictly prohibited. If you receive this e-mail in error, please
> immediately telephone or e-mail the sender and permanently delete the
> original copy and any copy of this e-mail, and any printout thereof.
>=20
> All documents, contracts or agreements referred or attached=20
> to this e-mail
> are SUBJECT TO CONTRACT.
>=20
> The contents of an attachment to this e-mail may contain=20
> software viruses
> that could damage your own computer system. While CTC=20
> Communications has
> taken every reasonable precaution to minimize this risk, we=20
> cannot accept
> liability for any damage that you sustain as a result of=20
> software viruses.
> You should carry out your own virus checks before opening any=20
> attachment.
>=20
|
