Bug 99249

Summary: php 4.1.2 src.rpm redhat 7.2 recompiled php-imap broke
Product: [Retired] Red Hat Linux Reporter: Jason Nielsen <jnielsen>
Component: phpAssignee: Joe Orton <jorton>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-01-25 16:46:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jason Nielsen 2003-07-16 16:30:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20030131

Description of problem:
I do not know if this is a bug or what. Or just user error but for the life of
me I can not determine what is wrong.

I am attempting to add --with-mcrypt to php-4.1.2-7.2.6.src.rpm.

All related libs (libmcrypt, mcrypt, mhash) install fine.

php src.rpm recompiles apparently perfectly.

php on the web server works perfectly including mcrypt support.

Something appears to be wrong with php-imap though. If I use the precompiled
.rpm from updates.redhat.com (I get the src.rpm from sameplace) php-imap works fine.

I have done this on a totally stock redhat 7.2 system. Meaning I can install the
php-4.1.2-7.2.6.rpm and php-imap works. If I take the src.rpm from same place,
version etc and simply install it, rpmrebuild -ba php.spec php-imap is seems
broken. This happens wether I add mcrypt support or not.

The main system I have upgraded to imap-2002c in hopes this would solve it (non
redhat rpm).  It did not.

After performing the "Steps to Reproduce" I check a phpinfo() test page, a horde
test page, try out our internal PHP apps for interfacing postgresql and mysql
databases and a few other php pages including a test page that uses the new
mcrypt functions.  All of these work fine. The second I attempt to log into
horde though via IMP(uses imap) I get a document contains no data and the php
module crashes. After speaking with numberous people in #php and #horde as well
as reading documents and so on the conclusion was its an IMAP problem or more
than likely directly related to php-imap. I have tried to get a core dump
according to the documents at: http://bugs.php.net/bugs-generating-backtrace.php
 But while running httpd within gdb I cant seem to access the web server and
hence actually try to login to horde via imp.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
-Install imap-2002-1.src.rpm, rebuild, install the associated rpm.
***NOTE: I have tried this with both the 2000c and 2001b rpms from both the
stock RH7.2 install and from up2date.
-Install libmcrypt-2.5.7.tar.gz
-vi /etc/ld.so.conf and add /usr/local/lib
-run ldconfig; check that lib is accessible.
-Install  mhash-0.8.18.tar.gz
-run ldconfig; check that lib is accessible.
-Install mcrypt-2.6.4.tar.gz
-run ldconfig; check that lib is accessible.
-rpm -ivh  php-4.1.2-7.2.6.src.rpm
-change to SPEC dir and edit php.spec adding to the top of the configure options
 --with-mcrypt \
-rpmbuild -ba php.spec
-service httpd stop
-rpm -e  php php-imap php-pgsql php-mysql php-ldap (only ones installed)
-I have /etc/php.ini backed up (known working copy only mods are file uploads
enabled and <? allowed)
-rpm -ivh php php-imap etc from the newly created rpms.
-cd /usr/share; rm -rf pear; tar xvfz /root/horde/pear-1.1.tar.gz
***NOTE: I have attempted only using PEAR from the rpm php install as well with
no luck.
-cp /etc/php.ini.BAK /etc/php.ini
-service httpd start
-access horde imp login.

Actual Results:  php module crashes

Expected Results:  php to authenticate via an imap connection and login.

Additional info:

Comment 1 Jason Nielsen 2003-07-17 14:38:40 UTC
Mistake:  Not a totally stock RH 7.2 (I was thinking of the 7.3 system I
attempted to use).  This system has been run through up2date up until a month or
so ago. The only known non-stock setup is we are using Courier-0.39.  But I
would like to note that I was using the imap and imap-devel packages from RH
during compilation. AMOF php will not compile without them. More specifically
rfc822.h If I remember correctly. - Jason

Comment 2 Joe Orton 2003-07-17 14:44:20 UTC
If you remove all your self-compiled php RPMs, and install the binary RPMs via
up2date (or from FTP or whatever), does php-imap work?

Comment 3 Jason Nielsen 2003-07-17 17:17:52 UTC
I have put together a truly stock RH7.2 machine. Did all the compilation as
stated above etc.  But this time I set up the apache server on this new machine
(vmware). I then wrote a php script that will connect to the original 7.2
server, login via imap and list my mailboxes. This worked.  I moved this php
script to the production 7.2 server and attempted to use it and it failed. The
same rpms are installed on both systems. I simply moved the php rpms from the
new 7.2 machine to the old one as before just to insure I had the same ones. So
my current view is this is NOT a php src.rpm problem. Nor an
mcrypt/libmcrypt/mhash problem. I also do not believe this is a Courier issue
since I am connecting to the same imap server in both cases. So the question is
what on this older 7.2 server (up2date machine) has changed that would cause the
imap authentication/connection to fail even when using php rpms from a machine
that they work on or using the rpms from Redhat? Considering this is now
obviously a problem on our side I suppose this bug can be closed as a user side
issue or the like. I suppose next Ill try to run all the up2date patches to the
test machine and see if it continues to work.

Comment 4 Jason Nielsen 2003-07-17 17:18:29 UTC
Yes. If I use the .rpm files from update.redhat.com php-imap works.

Comment 5 Joe Orton 2005-01-25 16:46:23 UTC
Thanks for the report.  This is a mass bug update; since this release
of Red Hat Linux is no longer supported, please either:

a) try and reproduce the bug with a supported version of Red Hat
Enterprise Linux or Fedora Core, and re-open this bug as appropriate
after changing the Product field, or,

b) if relevant, try and reproduce this bug using the current version
of the upstream package, and report the bug upstream.

c) report the bug to the Fedora Legacy project who may wish to
continue maintenance of this package.