You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by we...@fldna.net on 2000/06/16 20:55:12 UTC
IPC::Open2 v5.6.0 failures.
Hi,
my open2 script failes to work under mod_perl with perl v5.6.0. Works correctly
outside of the 5.6.0-mod_perl environment but works with mod_perl-5.005_03.
The code comes from '/usr/sbin/adduser'.
There are no errors, only the 'RD' handle returns "". As I said works
everywhere else but mod_perl-1.24 with perl v5.6.0.
This is perl, v5.6.0 built for i386-openbsd
Server: Apache/1.3.12 (Unix) mod_perl/1.24
OpenBSD entropic 2.7 entropic#0 i386
Is this a know bug? Is there a bug? Is it right in front of my face?
Workarounds? .... thanks, Wendell
*** script is as follows. and a full perl -V follows further ...
use IPC::Open2;
use strict;
print encrypt("thisisapassword");
sub encrypt {
my $pass = shift;
my $salt = &salt;
my $args = "-b $salt";
my $crypt;
open2(\*ENCRD, \*ENCWR, "/usr/bin/encrypt $args")
or die("Can't open2: '/usr/bin/encrypt': $!");
print ENCWR "$pass\n";
close ENCWR;
$crypt = <ENCRD>;
close ENCRD;
chomp $crypt;
die "encrypt failed" if (wait == -1 || $? != 0);
return($crypt);
}
sub salt { 7 }
__END__
# perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=openbsd, osvers=2.7, archname=i386-openbsd
uname='openbsd'
config_args='-Dopenbsd_distribution=defined -dsE'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='cc', optimize='-O2', gccversion=2.95.2 19991024 (release)
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccflags ='-fno-strict-aliasing -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=true
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='ld', ldflags =''
libpth=/usr/lib
libs=-lm -lc
libc=/usr/lib/libc.so.25.0, so=so, useshrplib=true, libperl=libperl.so.6.0
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=define, ccdlflags=' '
cccdlflags='-DPIC -fPIC ', lddlflags='-Bshareable '
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under openbsd
Compiled at Jun 4 2000 15:10:45
@INC:
/usr/libdata/perl5/i386-openbsd/5.6.0
/usr/local/libdata/perl5/i386-openbsd/5.6.0
/usr/libdata/perl5
/usr/local/libdata/perl5
/usr/local/libdata/perl5/site_perl/i386-openbsd
/usr/libdata/perl5/site_perl/i386-openbsd
/usr/local/libdata/perl5/site_perl
/usr/libdata/perl5/site_perl
/usr/lib/perl5/site_perl
.
Re: IPC::Open2 v5.6.0 failures.
Posted by we...@fldna.net.
On Sat, Jun 17, 2000 at 09:16:25AM -0400, Barrie Slaymaker wrote:
> wendell@fldna.net wrote:
> >
> > Is this a know bug? Is there a bug?
>
> Not that I know of, did you check the archives?
Yes but I didn't find the answer I was looking for.
I also checked out the guide's Forking and Executing Subprocesses ....
and ... Apache::SubProccess.
Apache::SubProccess just hung for me, if I have more time I'll check it out
more.
>
> > Is it right in front of my face?
>
> Something seems odd to me, see below, but it shouldn't be causing you
> too much grief.
>
> First, to educate me, what's encrypt do differently than Perl's crypt?
> why not
>
> crypt $pass, salt() ;
encrypt allows me to use the Blowfish version of crypt;
128 bits vs 12 bits.
>
> ?
>
> <PLUG MODULE="IPC::Run" AUTHOR="me" MODE="shameless">
> If you want to play with it, IPC::Run's up on CPAN and this might make
> your routine simpler and more debuggable. You'd do something like this to
> use it (untested):
>
> use IPC::Run qw( run ) ;
>
> sub encrypt {
> my $pass = shift;
> my $crypt;
>
> run [qw(/usr/bin/encrypt', -b), salt()], \$pass, \$crypt
> or die "Can't run '/usr/bin/encrypt': $!" ;
> chomp $crypt;
> return $crypt ;
> }
>
> The semantic of &run's return value are what you, or at least I, would
> expect. Then, to get a clue about what's happening under the hood, just
> add a {debug=>1} to &run's params:
>
> run [qw(/usr/bin/encrypt', -b), salt()], \$pass, \$crypt, {debug=>1}
> or die "Can't run '/usr/bin/encrypt': $!" ;
>
> and see what happens. Increase the debug level to 2 or 3 if need be,
> and it probably will be.
>
> This is a beta module though, so there might be gotchas. One is that I'm
> soon going to remove '{'...'}' hash constructors around the debug=>2.
> </PLUG>
Thanks, I'll check it out.
>
> Here's what seems odd:
>
> > open2(\*ENCRD, \*ENCWR, "/usr/bin/encrypt $args")
> > or die("Can't open2: '/usr/bin/encrypt': $!");
>
> >From the IPC::Open2 man page:
>
> SYNOPSIS
> use IPC::Open2;
>
> $pid = open2(\*RDRFH, \*WTRFH, 'some cmd and args');
> # or without using the shell
>
> <snip>
>
> open2() returns the process ID of the child process. It
> doesn't return on failure: it just raises an exception
> matching `/^open2:/'. However, `exec' failures in the
> child are not detected. You'll have to trap SIGPIPE your-
> self.
>
> I don't see how this could this be contributing to your grief, though.
> I take it there's no spoor in the error_log?
regrardless, open2 will warn on failure. Checking 'wait' and '$?' will tell
me if the command failed. But something screwy is going on inside of mod_perl.
I'd feel better if I knew what mod__perl was doing with the handles and why
the info was being dropped on the way back.
I also tried Symbol::gensym, Apache::gensym, and autoviv ... ... no diff.
>
> As a performance note, have you considered passing the command line as
> a list like
>
> qw(/usr/bin/encrypt -b ), &salt )
>
> in place of the string? That way the &exec in &open2 is not invoking
> a subshell. Also, if $pass comes from a user, what if they type in
> `mail me@foo.com /etc/passwd`?
the $pass is checked long before it makes it to the shell.
Well time is too valuable, so my solution for right now is to have a local
socket daemon run the encrypt command for me. Just have to remember to
have the daemon running ...
Thanks for your reply and help.
--Wendell
Re: IPC::Open2 v5.6.0 failures.
Posted by Barrie Slaymaker <ba...@slaysys.com>.
wendell@fldna.net wrote:
>
> Is this a know bug? Is there a bug?
Not that I know of, did you check the archives?
> Is it right in front of my face?
Something seems odd to me, see below, but it shouldn't be causing you
too much grief.
First, to educate me, what's encrypt do differently than Perl's crypt?
why not
crypt $pass, salt() ;
?
<PLUG MODULE="IPC::Run" AUTHOR="me" MODE="shameless">
If you want to play with it, IPC::Run's up on CPAN and this might make
your routine simpler and more debuggable. You'd do something like this to
use it (untested):
use IPC::Run qw( run ) ;
sub encrypt {
my $pass = shift;
my $crypt;
run [qw(/usr/bin/encrypt', -b), salt()], \$pass, \$crypt
or die "Can't run '/usr/bin/encrypt': $!" ;
chomp $crypt;
return $crypt ;
}
The semantic of &run's return value are what you, or at least I, would
expect. Then, to get a clue about what's happening under the hood, just
add a {debug=>1} to &run's params:
run [qw(/usr/bin/encrypt', -b), salt()], \$pass, \$crypt, {debug=>1}
or die "Can't run '/usr/bin/encrypt': $!" ;
and see what happens. Increase the debug level to 2 or 3 if need be,
and it probably will be.
This is a beta module though, so there might be gotchas. One is that I'm
soon going to remove '{'...'}' hash constructors around the debug=>2.
</PLUG>
Here's what seems odd:
> open2(\*ENCRD, \*ENCWR, "/usr/bin/encrypt $args")
> or die("Can't open2: '/usr/bin/encrypt': $!");
Re: IPC::Open2 v5.6.0 failures.
Posted by Michael J Schout <ms...@gkg.net>.
On Fri, 16 Jun 2000 wendell@fldna.net wrote:
> Hi,
>
> my open2 script failes to work under mod_perl with perl v5.6.0. Works correctly
> outside of the 5.6.0-mod_perl environment but works with mod_perl-5.005_03.
...
I have the exact same problem using IPC::Open3 under perl 5.6.0/mod_perl 1.24
Its as if everything you write to the filehandle mysteriously disappears before
getting to the opened process. I am not sure why this happens.
Mike