Just about everything updated (including the site)

September 22, 2009 by · 90 Comments 

Alright, just about every package in the repo was just updated.  Some significantly, others not so much, but the ones people are likely to care about are there.  MySQL is now up to 5.0.84, PHP is up to 5.2.11, and httpd is up to 2.2.13.

In addition to the package updates, I also included php-memcache for connecting to a memcached server and a choice of PHP accelerators as these were both things that many people were requesting.  You can now choose between php-xcache, php-apc, and php-eaccelerator (all of which conflict so don't try and force more than one to install).  I've not extensively tested the latter two as I personally use xcache, so someone will have to let me know if I should change something.

Lastly, the site itself has been updated to the newest release of WordPress, I've ripped out a bunch of plugins, added a few new ones, and I've installed a new skin.  I'll be tweaking everything as time goes on so things may be moving about and features may break from time to time.  If you notice anything flaky then please use the comment form on the About page.

Comments

90 Responses to “Just about everything updated (including the site)”
  1. pg says:

    Thanks, Jason! We truly appreciate it. Now I know why your repo was hanging on yum update earlier in the day!

    Also looking forward to the xcache update, as I had to uninstall it a couple months back when it was causing problems.

  2. Jason says:

    It might have been hanging for 30 minutes or so while I cleaned things up. There was about 20GB worth of outdated stuff to remove and at one point I unwittingly removed a .htaccess file that was somewhat critical to making things work...

  3. pg says:

    Eeeek. I just updated and now apache is FUBAR. Thanks for getting this fixed ASAP.

    I knew I should have waited a day or two and not be the first lamb to slaughter....

    /usr/sbin/httpd: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto/Apache2/ServerUtil/ServerUtil.so: undefined symbol: ap_get_server_banner
    [Tue Sep 22 19:04:11 2009] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
    /usr/sbin/httpd: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto/Apache2/ServerUtil/ServerUtil.so: undefined symbol: ap_get_server_banner
    [Tue Sep 22 19:05:17 2009] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
    [Tue Sep 22 19:05:17 2009] [info] Init: Initialized OpenSSL library
    httpd: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto/Apache2/ServerUtil/ServerUtil.so: undefined symbol: ap_get_server_banner
    [Tue Sep 22 19:05:20 2009] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
    /usr/sbin/httpd: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto/Apache2/ServerUtil/ServerUtil.so: undefined symbol: ap_get_server_banner
    [Tue Sep 22 19:05:42 2009] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
    /usr/sbin/httpd: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto/Apache2/ServerUtil/ServerUtil.so: undefined symbol: ap_get_server_banner

    If possible to contact you for assistance, I'd appreciate it.

  4. Jason says:

    What OS? What architecture? What packages do you use? Oh, and feel free to use the contact form on the About page to email me, that will be faster than going back and forth in the comments.

    EDIT #1: perl 5.8.8 means EL5. RHEL or CentOS? i386 or x86_64? Where do those messages show up?

    EDIT #2: I just checked out the mod_perl package on CentOS 5 (32- and 64-bit) and it seems to be fine for me on both.

    EDIT #3: Talking offline, seems like protectbase or priorities mucking things up again by not allowing deps to be properly installed.

  5. DerFalk says:

    Is it now save to update?

  6. David says:

    Thanks and well done, Jason. Very grateful indeed.

  7. Jason says:

    @DerFalk,

    Don't see why it wouldn't be. pg didn't report back in with exactly what the issue was, but I expect that it had something to do with trying to install my php & mysql packages without httpd and the other deps I provide.

  8. Daniel says:

    your php-common for x86_64 is set as version 5.2.11 (which is fine), but release 1, which is wrong. It should be release jason.1. As it is, php-mcrypt refuses to install as it cannot find php-common--5.2.11-jason.1.x86_64.

  9. BlueHawk says:

    Thanks Jason, very good job. But what about src.rpm files, for php 5.2.11 specially? Is it possible to add it to your repository?

  10. paris sportytrader says:

    Hi Jason , I have the same question than BlueHawk. Thanks in advance for your reply

  11. Jason says:

    @Daniel,

    I've not been able to replicate that and just had no problem installing php-mcrypt on EL4 x64 and EL5 x64. Are you sure you don't have another repo pulling in similar packages?

    @BlueHawk & paris sportytrader,

    I have released SPRMS in the past and it has led to nothing but problems. All that ends up happening is people try and recompile them without the proper deps, build environment, or knowledge, fail, and then ask me for help.

    No patches to GPL'd code were included in any of these updates beyond what was already included in upstream packages for Fedora (though, when updating some packages beyond Fedora 10, I did remove some patches that had been committed to the release branch), I simply used my own spec file or a modified upstream spec to get them to build under EL4 and EL5.

    I'm going to post the SRPMS later today but know this, any messages regarding getting them to build on your system will be ignored.

  12. BlueHawk says:

    Jason I understand you but I disagree with you. You can to say "There are src.rpm. AS IS, NO SUPPORT". Its simple and clear.
    PHP is GPL coded, we can to want source you _must_ give over.

    If you dont want to pusblish for free to all can you send it to me? Thanks.

    I dont want support I promise.

  13. Jason says:

    @BlueHawk,

    Read my comment again. It says right at the bottom that the SRPMS would be uploaded (I edited it to say that about 30 seconds after making the original comment). In fact, they're available now.

    One thing though, PHP is not GPL-licensed. It's licensed under the "PHP License" which is closer to the BSD license than GPL. As I read it (and I just checked again now), I am not required to distribute the source of derivative works using PHP and you have no right to demand that I do so. The only real restriction is that a copy of the license needs to be distributed with the package (which it is).

    Even for the GPL'd code in other apps, I'm only required to redistribute the GPL'd source with modifications, not complete, ready-to-build packages with non-GPL'd content (some of my build scripts).

  14. BlueHawk says:

    Thanks for SRPMS. Great job.

  15. Joe Scherler says:

    Hi Jason, Thank you very much for providing the SRPMS. You've saved me from a huge lot of work!

    Joe

  16. Hi,

    I have been using your repos flawlessly for since centos4 with no issues because I tried to follow your directions to the T. Fresh install etc.

    Today I did a yum update and restarted a few services and httpd will not start I even tried a reboot of the whole server.

    I'm experiencing the same issue as "pg" whereas in my case httpd will not start due to this following error log.

    ERROR:
    [Sun Sep 27 12:19:23 2009] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
    /usr/sbin/httpd: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto/Apache2/ServerUtil/ServerUtil.so: undefined symbol: ap_get_server_banner

    I did some looking around and many have said it is a bug in Perl and in order to resolve it either mod_perl would have to be upgraded but it appears yours is the correct version... mod_perl-2.0.4-7.jason.1

    They also mention that an upgrade to Apache to 2.2.4+ would fix it. Mine is showing a lower version in my following server specs.

    Any ideas. I have been down for about 5 hours and the calls are starting to roll in and I am in non stop Adrenalin mode Not sure how to make a frazzled face in text so here is a plain old :-/

    Thanks ahead of time.

    Here are my specs

    Operating system CentOS Linux 5.3
    Perl version 5.008008
    Path to Perl /usr/bin/perl
    Apache version 2.2.3
    PHP version 5.2.11
    MySQL version 5.0.86

    rpm -q mod_perl
    mod_perl-2.0.4-7.jason.1

    rpm -q perl
    perl-5.8.8-18.el5_3.1

    rpm -q httpd
    httpd-2.2.3-22.el5.1vm

    rpm -q php
    php-5.2.11-jason.1

    rpm -q mysql
    mysql-5.0.86-jason.1

  17. Jason says:

    @John Wolgamot,

    You cannot use part of my repo and leave some of the stock packages behind. The version of httpd you have is the default version from EL5 rather than mine (2.2.13).

    Assuming you didn't do something like run "yum update php mysql" and instead ran "yum update", you likely have either the protectbase or priorities plugin installed and mucking things up.

  18. Thanks Jason for the fast reply,

    I will research the protectbase and priorities plugin. Sounds like a good lead.

    I always did use the yum update until last night when python threw an error reporting it was missing a couple of dependencies and could not complete an update. I installed them so python updates could make their way with no errors.

    I'm using your repos with Virutalmin Pro so maybe they have some protective items mentioned above which isn't letting your repos be used for httpd.

    I'll post my findings so the community will know the outcome.

    Thanks again.
    John

  19. KoGt2S says:

    heeyyy good... but dont forget ModSecurity Stable: 2.5.10 Thkz!!!!!!

  20. Jason says:

    @KoGt2S,

    That wasn't released last week when I built these packages. I'll do an update within the next day or two.

  21. Positive outcome. This may sound easy for many of you however I was sweating.

    Not sure what I did that caused my server not to use your repo for 2 items meaning httpd and perl however what happened is mod_perl got updated without updating httpd. The newer version of mod_perl kept the web server from starting.

    When I researched the log entry error, everyone said either update httpd or downgrade perl. Perl has a lot of dependencies so that was a scary thought.

    It turns out that I only had to downgrade mod_perl which did not have any dependencies.

    After reading many posts I stumbled onto this that mentioned the --oldpackage
    http://linux.derkeiler.com/Mailing-Lists/Fedora/2005-07/4752.html

    I looked at my yum log and found the previous version of mod_perl

    I went here and got the previous version
    http://rpm.pbone.net/index.php3?stat=26&dist=55&size=4232903&name=mod_perl-2.0.4-6.el5.i386.rpm

    rpm -Uvh --oldpackage mod_perl-2.0.4-6.el5.i386.rpm

    service httpd start

    All is good for now.

    I did some research on your suggested leads.
    Something is definitely stopping httpd from updating usuing your repo however it is apparently something beyond the protectbase and priorities plugin as they weren't installed or enabled.

    mod_further_research enabled.

    Thanks for the guidance.

    John

  22. Jason says:

    @John Wolgamot,

    I'm glad to hear that you got things working again. Thus far I've not been able to duplicate the issue with httpd not getting updated during a "yum update" (though I did have one system not report ANY updates until I ran a "yum clean all").

    I may, at some point, toss in some stricter version checking (rather than just the MMN), though that will likely force more system updates as I'd need to rebuild every package depending on httpd anytime I change the httpd build (ie. jason.1 to jason.2, not something like 2.2.12 to 2.2.13).

  23. I tried yum clean with no luck.

    It's probably something to do with Virtualmin Pro holding something back.

    I used Centos for stability but soon ran into the issue with Magento needing a newer version of php.

    That is how I stumbled onto your repos.

    Virtualmin Pro is a great product for less experienced admins like myself. Virtualmin Pro sets up a bulletproof server by simply executing a script However when I needed to get the bleeding edge LAMP stuff that Centos does not offer, that is where I used your repos.

    I should have kept better notes concerning the install and testing phase.

    Your docs mention it's best to start from a stock install and let your repos do the work.

    Virtualmin Pro is similar in that if you have much more than a stock install then the script may fail or need to be tweaked.

    I obviously did something wrong during the Virtualmin's install and the implementation of your repos as they are not seeing that httpd and for that matter the main perl install is not using your repos either.

    rpm -q perl
    perl-5.8.8-18.el5_3.1

    rpm -q httpd
    httpd-2.2.3-22.el5.1vm

    I was able to update mod_perl ok which lead to the issue and the discovery of these other underlying issues where something is holding back the 2 updates.

    Thankfully downgrading mod_perl was easy. It was just finding the safe way to do it that took time.

    This downgrade of mod_perl bought me some time to investigate further.

    This nudged me into the purchase cloudmin which will allow me to more easily duplicate the server environment and will hopefully allow me to quickly move customers to a freshly installed server in the Amazon Cloud if I ever need to rebuild the vpslink server.

    I now use http://vpslink.com/vps-hosting/ the LINK-6 plan

    I'm hoping to use cloudmin to setup a server either locally using openvz or in the Amazon Cloud so I can quickly make a switch to the Amazon cloud, redo my vpslink server and then transfer it back without too many glitches.

    Perhaps there is a way to setup my server locally in the openvz environment and then transfer the server bubble to the S3 backup servers where the vpslink techs could get at it and replace my bubble with the backup.
    Not sure, just thinking out loud.

    I elected to use openvz instead of Xen due to performance and memory issues related to Xen
    SEE: http://vpslink.com/compare/openvz-vs-xen-vps-hosting/

    I use the AmazonS3 backup servers to do Nightly incremental backups and weekly full backups and hold on to 2 months of backups on the S3 servers.

    The nice part is the backups transfer from Vpslink to the S3 backup servers at the rate of 4000 making my nearly 10gig backup complete very quickly.

    So really data loss is not a big concern. What is a concern is being able to get the server up quickly if it is knocked out for some reason.

    This is why I want to start getting up to speed with cloud servers. I am thinking I can build a server in the Amazon Cloud and then store it in the S3 Backup and then if I need to I can turn it on and use it for several days or a couple of weeks while I redo the vpslink server.

    So many options to get ones Geekitude flowing.

    Thanks for your suggestions and (now) listening to My "Ramblings" :-)

  24. KoGt2S says:

    Sorry Jason a question, the mod_evasive works fine for apache 2.2.x?

    I install it and test with Test.pl and with my browser and does not block anything!! Ouch!! Thkz

  25. Jason says:

    @KoGt2S,

    When I first added mod_evasive I'm 99% certain that I tested it on both EL4 and EL5 and it worked on both. When I rebuilt it for httpd 2.2.13 last week I tested it again on EL4 and it correctly blocked a client where I had held down F5. Let me know what OS and arch you're using and I'll test it again.

    @John Wolgamot,

    I do not update perl from the default version so what you have is correct. You can see exactly what packages I provide by checking out the RPMs for your OS and arch using the links on the Yum Repository page.

    As to "running servers in the cloud", that's another issue entirely. I've been using OpenVZ for virtualization for a few years now. It's easy to use, it performs well, and overall I am very happy with the results. Running systems on EC2 is a whole different animal though and is something I've only recently gotten into.

    The issue you'll have on EC2 is that you don't have any local persistent storage. This isn't an issue for static content because you can host it on S3 and set your links to look there rather than on the local system, but for databases this can present a serious risk of data loss.

    Now, I know what you're thinking: EBS. Well, it's not all it's cracked up to be. Yeah, you can put your MySQL database on an EBS volume and yeah, you can snapshot it regularly to S3, but if you ever have an instance die you need to either reattach the volume (hopefully still intact) to a new instance or roll back to a previous snapshot and use it to create a new EBS.

    There's also the issue of how to get your apps on the VM in the first place. Yeah, you can bundle your code directly into the AMI, but that's kludgy and makes it a real pain to update because then you've got to rebundle (and if you don't dump temp files, clean up test code, etc., then your bundle gets larger and larger).

    That all said, I jumped in anyway and decided that rather than manage everything myself and have to come up with ways around the above-mentioned issues (not to mention all the other problems I didn't mention) that I'd sign up for an account with RightScale.

    I'm running one of their "WebSite" accounts which runs $500/month. Not cheap, particularly since you've still got to pay for EC2 time, bandwidth used, etc., but worth every penny.

    I've got the following config running and it took about 4 hours to setup (which included my initial training):

    - (2) Primary web servers with haproxy, httpd & php
    - (2) MySQL Servers in Master/Slave pair
    - (0-8) Secondary Web Servers with httpd & php

    The MySQL systems store their data on EBS and snapshot regularly to S3 (hourly for master, every 15 minutes for slave). In the event I lose the master, with a single click I can promote the slave to master and then with a second click I can bring up a new slave.

    Site data for the web servers is stored on S3 and is pulled locally, uncompressed, and configured on startup of an instance. If I update the code for a given vhost then a single click for each virtual system will bring it up to date with the newest code.

    The two primary web servers share an A DNS record which points to the two Elastic IPs. Connections come in to one or the other and are then sent to an appropriate httpd instance (whichever has lower load at the moment). If both primary servers are under heavy load (configurable, I've got mine set to an average load >80% for more than 3 minutes) then secondary systems are automatically spawned and added to the cluster. When they are no longer needed they're killed off to minimize unneeded billing.

    At the moment I'm running a couple WordPress sites (not this one) and a few mission-critical apps for some of our eCommerce stores. I plan to add more to the mix over the next couple months as time permits.

    The instances are all m1.small and are capable of handling a surprising amount of traffic. As an example, one of our WP sites was getting hammered one day and, without breaking a sweat (meaning, nowhere near the point where a 3rd web system would be spawned), the systems were collectively handling about 200 page views/second for a total of around 20 minutes. WP isn't exactly light on the resources, so you can do the math yourself for a simpler site. We had one point on a different occasion where heavy load on a different site caused a 3rd web server to be spawned and, as I hear it, no one noticed a slowdown or interruption. Everything scaled smoothly while absorbing about 350 hits/second and the extra system dropped off just as smoothly when traffic dropped back down to a normal level.

  26. KoGt2S says:

    Hi Jason,

    CentOS Linux 5.3, Linux 2.6.18-164.el5 on x86_64, Apache/2.2.13 (Unix)

    mod_security config.
    DOSHashTableSize 6194
    DOSPageCount 10
    DOSSiteCount 60
    DOSPageInterval 1
    DOSSiteInterval 1
    DOSBlockingPeriod 30
    DOSEmailNotify "my mail"
    # DOSSystemCommand "su - someuser -c '/sbin/... %s ...'"
    # http://security.lss.hr/index.php?page=details&ID=LSS-2005-01-01
    #DOSLogDir "/var/lock/mod_evasive"
    #DOSWhitelist 127.0.0.1
    #DOSWhitelist 192.168.0.*

    I use the DOSSystemCommand for the "CSF" temporarily block the IPs with the following command

    DOSSystemCommand "su - nobody -c 'cfs -td %s 600' "

    and does not work. any suggesion? Thkz again!

  27. KoGt2S says:

    Jason, check this form http://www.configserver.com/blog/index.php?amount=0&blogid=1&query=mod_evasive

    Removed mod_evasive from Server Checks Report as it appears to be less relevant, especially with Apache v2..

    best relevant?...

  28. Jason says:

    @KoGt2S,

    I just tested it on EL5 x64 and it works fine. The default values are very lax and will likely be very difficult to actually trigger but if you adjust them downward it works fine.

    Sorry, but I don't know anything about using a custom command for blocking (never tried it, the default 403 works fine), nor have I used the cfs command.

  29. KoGt2S says:

    Thanks Jason,

    Never left a 403 simply detects and sends me email, but access continues.

    I check more details and thanks for your support!

    Congratulations for the great repository

  30. Ataa says:

    Thanks for the update,

    updated packages on 3 CentOS 5.3 boxes using "yum update", On one of them getting "segmentation fault" in error_log and websites on that server is not accessible (Zero Reply on client side), other servers working just fine. Please advice.

  31. Jason says:

    @Ataa,

    Make sure that you're using all of my packages on the system that is flaking out. Most of the issues that people are having are related to installing PHP, mod_perl, etc. without first adding my httpd packages.

  32. pg says:

    sorry I didn't check back in on this... your httpd was incompatible with my hosting setup (virtual domains under /home), so I reverted back to older packages with the exception of mysql.

    I intend to re-install x-cache now that I've sorted out some other issues.

    Thanks again for your assistance in my hour of need, it did help me quickly track down the cause.

  33. Ataa says:

    @Jason,

    I think I am using all of them, how to make sure about that? Like always I used "yum update" on all boxes and i has updated too many packages successfully.

    I asked the technical support of data center to change the ram modules to check if "Segmentation Fault" issue is related to bad memory, but it didn't solve the issue.

    Like pg, my hosting setup on that box is virtual domains under /home, Do I have to revert back to the older packages? If so How to do that? all of my sites are down since 2 days ago :(

    Thanks for your time.

  34. Jeff says:

    Hi Jason,

    I have a question about the latest upgrade. After doing the upgrade on my CentOS Box, everything is working except my SugarCRM install. When I try to go to the site, it just have some binary data. None of my other sites on same machine has the problem.

    Thanks,

    Jeff

  35. Jason says:

    @pg,

    Unless your old setup was using some custom 3rd-party module for that type of hosting (or was compiled manually, à la cPanel) then there shouldn't be an incompatibility. I've got a development box at work using mod_userdir that works very well.

    http://httpd.apache.org/docs/2.2/mod/mod_userdir.html

    @Ataa,

    Read my response to pg for home dirs. As to checking for installed versions, my suggestion would be to run "yum list installed | grep jason". That will give you a listing of all the packages from my repo that you've installed. If it doesn't match on each box, or if you're missing something obvious like httpd, then your yum update went awry...

    Here's an example from a PHP App Server of mine (MySQL is on a separate server, if it's local for you then you should see, at a minimum, mysql-server added to the list).

    apr.i386 1.3.8-1.jason.1 installed
    apr-util.i386 1.3.9-1.jason.1 installed
    apr-util-ldap.i386 1.3.9-1.jason.1 installed
    httpd.i386 2.2.13-jason.3 installed
    mysql.i386 5.0.86-jason.2 installed
    mysqlclient14.i386 4.1.22-1.el4s1.1.jason installed
    pcre.i386 7.8-1.jason.1 installed
    php.i386 5.2.11-jason.1 installed
    php-cli.i386 5.2.11-jason.1 installed
    php-common.i386 5.2.11-jason.1 installed
    php-pdo.i386 5.2.11-jason.1 installed
    php-pear.noarch 1:1.7.2-2.jason.1 installed
    php-xcache.i386 1:1.2.2-jason.4 installed

    @Jeff,

    I don't know anything about SugarCRM, sorry. If it runs under the stock version of httpd then it should work under mine as well. Are there any particular mods you needed to make to your httpd config (in httpd.conf or in .htaccess) when you installed the app? Have you checked the httpd error logs for more information?

  36. Ataa says:

    Thanks for your reply Jason,

    Mine has more package than yours!

    apr.i386 1.3.8-1.jason.1 installed
    apr-devel.i386 1.3.8-1.jason.1 installed
    apr-util.i386 1.3.9-1.jason.1 installed
    apr-util-devel.i386 1.3.9-1.jason.1 installed
    apr-util-ldap.i386 1.3.9-1.jason.1 installed
    httpd.i386 2.2.13-jason.3 installed
    httpd-devel.i386 2.2.13-jason.3 installed
    mod_security.i386 2.5.9-1.jason.1 installed
    mod_ssl.i386 1:2.2.13-jason.3 installed
    mysql.i386 5.0.86-jason.2 installed
    mysql-server.i386 5.0.86-jason.2 installed
    pcre.i386 7.8-1.jason.1 installed
    php.i386 5.2.11-jason.1 installed
    php-cli.i386 5.2.11-jason.1 installed
    php-common.i386 5.2.11-jason.1 installed
    php-devel.i386 5.2.11-jason.1 installed
    php-gd.i386 5.2.11-jason.1 installed
    php-mcrypt.i386 5.2.11-jason.1 installed
    php-mysql.i386 5.2.11-jason.1 installed
    php-pdo.i386 5.2.11-jason.1 installed
    php-pear.noarch 1:1.7.2-2.jason.1 installed
    php-xcache.i386 1:1.2.2-jason.4 installed
    php-xml.i386 5.2.11-jason.1 installed

    Everything is similar on all boxes, but only one CentOS box is facing this issue!

  37. Jason says:

    @Ataa,

    I install servers with a minimal set of packages and then only add what I need. If the app running on a system doesn't require php-mcrypt then it doesn't get added, if I'm not planning on compiling a special package on that server then devel packages are not added (and this is almost always the case because production servers shouldn't have compilers instlaled), etc. The package list came from a vBulletin server so it's fairly minimal (and I use ImageMagick with vB, not GD, so php-gd isn't installed either).

    Anyway, the list of packages looks OK. Can you post the info from the error log for the segfault and a few lines above it? Does it segfault on every page view or just some? Have you tried disabling (or removing) mod_security (which reacts poorly in it's default config to some programs)?

  38. Jeff says:

    Hi Jason,

    I have almost the same set of install except I install APC with pecl.

    I have looked at all my http log. There is nothing there that show why the pages result in some binary data.

    Thanks,

    Jeff

    Here is my list:

    apr.i386 1.3.8-1.jason.1 installed
    apr-devel.i386 1.3.8-1.jason.1 installed
    apr-util.i386 1.3.9-1.jason.1 installed
    apr-util-devel.i386 1.3.9-1.jason.1 installed
    apr-util-ldap.i386 1.3.9-1.jason.1 installed
    httpd.i386 2.2.13-jason.3 installed
    httpd-devel.i386 2.2.13-jason.3 installed
    mod_ssl.i386 1:2.2.13-jason.3 installed
    mysql.i386 5.0.86-jason.2 installed
    mysql-devel.i386 5.0.86-jason.2 installed
    mysql-server.i386 5.0.86-jason.2 installed
    pcre.i386 7.8-1.jason.1 installed
    php.i386 5.2.11-jason.1 installed
    php-cli.i386 5.2.11-jason.1 installed
    php-common.i386 5.2.11-jason.1 installed
    php-devel.i386 5.2.11-jason.1 installed
    php-gd.i386 5.2.11-jason.1 installed
    php-imap.i386 5.2.11-jason.1 installed
    php-mbstring.i386 5.2.11-jason.1 installed
    php-mcrypt.i386 5.2.11-jason.1 installed
    php-mysql.i386 5.2.11-jason.1 installed
    php-pdo.i386 5.2.11-jason.1 installed
    php-pear.noarch 1:1.7.2-2.jason.1 installed
    php-soap.i386 5.2.11-jason.1 installed
    php-xml.i386 5.2.11-jason.1 installed

  39. Ataa says:

    Just removed xcache and everything is working just fine.

  40. Jason says:

    @Ataa,

    I've had that issue before, though not with XCache (I had a server that segfaulted constantly with eAccelerator). That's why I now include APC, eAccelerator, and XCache. One of them is likely to work on your system.

    @Jeff,

    Can you send me a link with the contact form on the about page? I want to see what you mean by "binary data".

  41. Jeff says:

    Jason,

    You can see it on one of my test box.

    http://sandbox.solvate.com

    Best,

    Jeff

  42. Jeff says:

    Hi Jason,

    Also, you can view the phpinfo page here.

    http://sandbox.solvate.com/phpinfo.php

    Everything else seems to be working except my sugarcrm install.

    Thanks again for your help!

    Best,

    Jeff

  43. Jason says:

    @Jeff,

    That output is gzipped (if I unpack it then it displays correctly). Clients can typically unpack gzipped output without issue, so your system is probably gzipping it twice, perhaps once in sugar and once in php or httpd, or maybe once in php and once in httpd, I don't know. If the rest of your sites work then I'd put the blame on the first one.

  44. Jeff says:

    Dear Jason,

    Thanks for the info! I am, however, unable to locate any of the setting that control compression and gzip. Do you happen to know?

    Thanks again for your help!

    Best,

    Jeff

  45. Jason says:

    @Jeff,

    in /etc/php.ini make sure zlib.output_compression = Off. In /etc/httpd/conf/httpd.conf make sure you don't have mod_deflate configured (just comment out the LoadModule, if you get errors then it's configured but not properly wrapped in an IfModule block).

    Beyond that, you should also check for any mod_deflate settings that might be in a .htaccess file for SugarCRM.

    One thing I just noticed is that your site is not returning a "Content-Encoding: gzip" header when I load the link you posted. This would explain why the browser is not unpacking it so it may not be that your content is encoded twice.

    Both mod_deflate and PHP's zlib.output_compression add this header without issue (I just tested them to make sure) so it could be something odd that SugarCRM is doing.

  46. Jeff says:

    Jason,

    Thanks again! At this point, I am petty sure it's php 5.2.11 that is causing the problem. Since I still need php 5.2.*, what do you think is the easiest way to revert back to 5.2.6?

    Thanks,

    Jeff

  47. Jason says:

    @Jeff,

    There isn't one. I do not keep the older packages I made once newer ones are released (and I don't get flooded with complaints).

    EL5 ships with PHP 5.1.6 so if you removed all my packages and went back to the default ones you could run that, but if you've got to use 5.2.x then you'll need to get my 5.2.11 working or build your own packages.

  48. Jason says:

    @Jeff,

    Alright, try this. In the include/utils.php file, find function setPhpIniSettings() and change:

    // zlib module
    if(function_exists('gzclose') && headers_sent() == false) {
    ini_set('zlib.output_compression', 1);
    }

    ... to...

    // zlib module
    if(function_exists('gzclose') && headers_sent() == false) {
    ini_set('zlib.output_compression', 'true');
    }

  49. Jeff says:

    Jason,

    That fixes it. Thank you very much.

    Jeff

  50. Joey says:

    I wanted to install php-gd and I am getting the following errors:

    # yum install php-common
    Loaded plugins: fastestmirror
    Loading mirror speeds from cached hostfile
    * updates: centos.omnispring.com
    * base: centos.eecs.wsu.edu
    * addons: mirror.hmc.edu
    * extras: mirror.hmc.edu
    Setting up Install Process
    Parsing package install arguments
    Package matching php-common-5.2.11-jason.1.x86_64 already installed. Checking for update.
    Nothing to do
    # yum install php-gd
    ...
    Setting up Install Process
    Parsing package install arguments
    Resolving Dependencies
    --> Running transaction check
    ---> Package php-gd.x86_64 0:5.2.11-jason.1 set to be updated
    --> Processing Dependency: php-common = 5.2.11-jason.1 for package: php-gd
    --> Finished Dependency Resolution
    php-gd-5.2.11-jason.1.x86_64 from utterrambliings has depsolving problems
    --> Missing Dependency: php-common = 5.2.11-jason.1 is needed by package php-gd-5.2.11-jason.1.x86_64 (utterrambliings)
    Error: Missing Dependency: php-common = 5.2.11-jason.1 is needed by package php-gd-5.2.11-jason.1.x86_64 (utterrambliings)

    Thanks!
    Joey

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!

You must be logged in to post a comment.