The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

easyapache3 is slightly better than a disaster

Discussion in 'EasyApache' started by LinuxStandard, Jan 22, 2008.

  1. LinuxStandard

    LinuxStandard Active Member

    Joined:
    Jan 22, 2008
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    1
    I've kept many systems running old easyapache2 built installations with Apache 1.3.41 manually put into place with a rewritten version of the buildscript that easyapache2 generated awhile back. The reason for this is so many broken servers and incompatible changes put into place by easyapache3.

    Would you like to put a custom Ruby on Rails installation together or a module that cPanel's scripts cannot recognize? In my experience this will cause all those changes to be overwritten unless you are willing to dig through many different cPanel files to work around their rebuilding process.

    easyapache2 simply modified the parts of the existing httpd.conf that needed to be modified for that update. This wasn't perfect, but it was very functional and was less problematic with each new release. easyapache3 rebuilds the entire httpd.conf with each change and will overwrite any changes made that you don't specifically "log in" with their script.

    easyapache3 has taken three steps backwards in the ability to customize the Apache installation.

    1) Any changes to the Apache httpd.conf will be overwritten by any cPanel updates to the file. The distiller is unable to pick up changes as simple as ServerTokens Prod which some of us believe is a worthwhile configuration change. Even a basic change to KeepAlive values must be manually put into place by editing the /var/cpanel/conf/apache/main file due to the distiller being unable to pick up on even the most basic changes to the httpd.conf.

    Note: This was last tested on FreeBSD 6.2, but it has happened in similar ways on CentOS systems.

    2) easyapache3 seems to be unable to build PHP4 and PHP5 support simultaneously on FreeBSD. The system will install both in the same location in /usr/bin/. This may be a minor bug, but it is only part of a larger problem with the easyapache3 design which makes this bugs extremely hard to work around.

    A new cPanel release comes out and we upgrade a production system only to find it breaks when easyapache3 runs. We can contact the datacentre support who then contacts cPanel support for a fix for this. We cannot have hours or days of downtime due to a bug in a script.

    3) Install locations for certain built items. easyapache3 puts several things into /opt/ on FreeBSD instead of using the system supported method of installing programs such as curl via ports.

    Why are these put into /opt/?

    These are just a few points, but I've seen several threads where people are posting workarounds for easyapache3 overwriting their changes. This should not be needed and cPanel should not work against the system administrator by overwriting the configurations when the system administrator needs to implement something a certain way.
     
  2. cPanelNick

    cPanelNick Administrator
    Staff Member

    Joined:
    Mar 9, 2015
    Messages:
    3,426
    Likes Received:
    2
    Trophy Points:
    38
    cPanel Access Level:
    DataCenter Provider
    I have tested this on 11.17.4-CURRENT_19834 by adding the line in question to httpd.conf , running /usr/local/cpanel/bin/apache_conf_distiller --update and then running /scripts/buildhttpdconf
    The change was preserved

    UPDATE: I have also tested to verify that the change was preserved after rebuild


    However its much better to use the include files instead of making changes directly to httpd.conf

    I am testing this now on a freebsd machine. I will update this post once the testing is complete.


    UPDATE: php5 was installed in the usual place and php4 was prefixed to /usr/php4/

    You can always open a ticket without your datacenter a https://tickets.cpanel.net/submit/ . If you need priority support you can purchase it at the cPanel store at https://www.cpanel.net/store/

    UPDATE: Also if you build in whm, you will get a pop up window upon failure with all the failure information pre-filled which will can be submitted into our support system with an increased priority level.

    /opt is used so that library problems are avoided by not inadvertently overwrite the os libraries. ports/yum/etc cannot be used in some cases because we cannot guarantee the base os will have the needed libraries, or they are not broken releases.

     
  3. LinuxStandard

    LinuxStandard Active Member

    Joined:
    Jan 22, 2008
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    1
    I can confirm that it is working after a upcp to the latest current build.

    I am still quite frustrated with easyapache3 due to the incompatibility with older installs left over from easyapache2.

    Custom mod_security installations are broken, custom suphp installations are very badly broken, and all this from running the upgrade script. We even have a system where we uninstalled all of this before running easyapache3 and we are still left with an Apache 1.3 installation that has segmentation faults at version 1.3.39.

    It seems the only safe way to upgrade anything other than a default install with easyapache2 is to build a new system with easyapache3 and migrate the accounts over after verifying there are no quirks. Production systems simply cannot be upgraded due to cPanel overwriting all changes and the major behavioral changes between easyapache2 and easyapache3.

    Thank you for your attention. cPanel cannot be expected to support necessary software installations left over after easyapache2, but it is still frustrating to know there is no safe upgrade path available to easyapache3.
     
  4. tenaciousJ

    tenaciousJ Member

    Joined:
    Dec 18, 2003
    Messages:
    7
    Likes Received:
    0
    Trophy Points:
    1
    I've been running the stable tree of cPanel for about 4 years now without problem. But, the past 3 days since we upgraded to the the latest stable release have been nothing but a nightmare.
     
  5. cPanelNick

    cPanelNick Administrator
    Staff Member

    Joined:
    Mar 9, 2015
    Messages:
    3,426
    Likes Received:
    2
    Trophy Points:
    38
    cPanel Access Level:
    DataCenter Provider
    If you would like us to look at this specific server, please by all means open a ticket at https://tickets.cpanel.net/submit/

    If you don't have any customizations it should be fine. The overall configuration migration failure rate averages about 1.3% (of people that have not unchecked submit build report). We'd like to do everything we can to get that number to zero, but its not possible to account for every custom configuration.
     
  6. LinuxStandard

    LinuxStandard Active Member

    Joined:
    Jan 22, 2008
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    1
    I've found that most parts of cPanel 11 work very well. There have been several very good improvements in the new version that work far better than the old versions. The SSL Installation system works very well where the old version in cPanel 10 did not work right very often.

    There are still some problems such as cpbackup on FreeBSD being unable to copy daily backups to weekly backups or monthly backups. I've also noted a few problems with the new Exim Configuration Editor overwriting changes it shouldn't, but these are some long standing problems that we have not reported due to the systems being highly customized. cPanel support most likely wouldn't support the systems with all the changes.

    Notes about cpbackup issue (if anyone is interested): The rsync version on the system is 2.6.9 and is built from ports. I've used it to transfer the backups to another system for offsite backups without any errors. Perl is 5.8.8 also built from ports and has no issues that I can see.

    easyapache3 has been a very big headache since easyapache2 was replaced. Some of our Apache installations are very out of date, but we simply cannot upgrade them all now. I still have one production system that is still down after 7 hours because I cannot fix the problems caused by easyapache3 conflicting with our old installed software.

    We cannot expect cPanel to support all of these installations, but it is still good to note on the forum that easyapache3 can cause severe problems if the system is modified a certain way.
     
  7. LinuxStandard

    LinuxStandard Active Member

    Joined:
    Jan 22, 2008
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    1
    We appreciate the offer, but this system is definitely an unsupported configuration that we will need to sort out ourselves. The support team couldn't help us with a FreeBSD 6.3 system that was heavily modified before running easyapache3. We will just need to work with the new system until we can force it to work as we need it to work.

    We are considering a move to CentOS due to these problems as it has had less issues than our recent upgrades on FreeBSD 6.2/6.3. We're 0 for 3 so far on successful rebuilds. This is not cPanel's fault though.
     
  8. cPanelNick

    cPanelNick Administrator
    Staff Member

    Joined:
    Mar 9, 2015
    Messages:
    3,426
    Likes Received:
    2
    Trophy Points:
    38
    cPanel Access Level:
    DataCenter Provider
    By all means, please open a ticket @ https://tickets.cpanel.net/submit/ , even the complimentary queue has much shorter wait times that that. (however if your ticket is about easyapache then it will get a higher priority)

     
  9. cPanelNick

    cPanelNick Administrator
    Staff Member

    Joined:
    Mar 9, 2015
    Messages:
    3,426
    Likes Received:
    2
    Trophy Points:
    38
    cPanel Access Level:
    DataCenter Provider
    Also you might want to read the ea3 faq section on includes.

    http://www.cpanel.net/support/docs/ea/ea3/faq_ea3.html

    Here is the body of the entry I'm referring to:


     
  10. cPanelNick

    cPanelNick Administrator
    Staff Member

    Joined:
    Mar 9, 2015
    Messages:
    3,426
    Likes Received:
    2
    Trophy Points:
    38
    cPanel Access Level:
    DataCenter Provider
    Also you might want to read the ea3 faq section on includes.

    http://www.cpanel.net/support/docs/ea/ea3/faq_ea3.html

    Here is the body of the entry I'm referring to:


     
  11. LinuxStandard

    LinuxStandard Active Member

    Joined:
    Jan 22, 2008
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    1
    I was not having problems with the virtualhost entries except where easyapache3 will write the SuPHP_UserGroup directive when I don't expect it to and won't when I do expect it to.

    I've worked around easyapache3's workarounds and worked around the workarounds to my workarounds over and over.

    It seems that easyapache3's configuration building system detects suphp and then reacts according to what it expects to be there even if suphp isn't compiled from easyapache3. This makes life extremely hard if you don't want to build it via easyapache3 due to the lack of source to patch.

    easyapache3 also seems to go into .htaccess files in user's directories and comment out AddHandler directives that have been setup for years causing many support tickets about broken applications.

    The following is the configuration in my suphp_httpd.conf file which I tried to use to hide suphp from easyapache3's configuration rebuilding script to no success:

    LoadModule suphp_module modules/mod_suphp.so
    <IfModule mod_suphp.c>
    suPHP_Engine On
    </IfModule>
    <Directory />
    suPHP_AddHandler application/x-httpd-php
    suPHP_AddHandler application/x-httpd-php5
    suPHP_AddHandler application/x-httpd-php6
    suPHP_AddHandler application/x-httpd-php-compat
    </Directory>
    <Files *.php5>
    suPHP_AddHandler application/x-httpd-php5
    </Files>
    <Files *.php4>
    suPHP_AddHandler application/x-httpd-php
    </Files>
    <Files *.php3>
    suPHP_AddHandler application/x-httpd-php
    </Files>
    <Files *.php2>
    suPHP_AddHandler application/x-httpd-php
    </Files>
    <Files *.phtml>
    suPHP_AddHandler application/x-httpd-php
    </Files>

    This barely works and the next time easyapache3 comments out the AddHandler directives in user's directories we will have to go back in and put them back. I don't see a way to disable this functionality.

    by adding the following patch to the mod_suphp.c in src/apache2/mod_suphp.c I avoid the need for the Files directives:

    Line 316 file suphp-0.6.2/src/apache2/mod_suphp.c

    Change

    AP_INIT_ITERATE("suPHP_AddHandler", suphp_handle_cmd_add_handler, NULL, ACCESS_CONF,

    to

    AP_INIT_ITERATE("suPHP_AddHandler", suphp_handle_cmd_add_handler, NULL, RSRC_CONF | ACCESS_CONF,

    a similar modification can be made to the RemoveHandler to allow it to be placed into the httpd.conf. I've found no risk in doing this and it has allowed a far more flexible use of the directives. The same patch can be made to the Apache 1.3 source for similar functionality.

    Can I have the following information as a courtesy?

    1) How can I stop easyapache3 from modifying .htaccess files in user directories that they use to change from php4 to php5 and php5 to php6?

    AddHandler application/x-httpd-php5 .php will be commented out despite my best efforts.

    2) Where is the source for the cPanel compile of suphp that is placed in /opt/ so I can patch it?

    3) Is it possible to configure easyapache3 to write the suphp directives or not by touching a file or similar?

    4) Is it possible to configure easyapache3 to avoid overwriting the modules/ directory when easyapache3 is run?

    I am attempting to maintain a mod_security installation without using easyapache3 to install it.

    Thank you for your time.
     
  12. LinuxStandard

    LinuxStandard Active Member

    Joined:
    Jan 22, 2008
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    1
    It would also be helpful to have a workaround for the following problem put in place by default:


    SoftException in Application.cpp:377: Mismatch between target GID (1553) and GID (65534) of file "/home/username/public_html/phpinfo.php"

    The workaround for this is to change

    paranoid_gid_check=true

    to

    paranoid_gid_check=false

    in /opt/suphp/etc/suphp.conf on each server due to Pure-FTPD setting the group of the files to nobody when they are uploaded. This happens on every FreeBSD server I've looked at after the upgrade to easyapache3. I am not aware of this happening on CentOS though.

    The ideal fix would be for Pure-FTPD to write the file as user:group instead of user:nobody, but this may not be possible as I have not found a patch or configuration option to do this yet.
     
  13. cPanelKenneth

    cPanelKenneth cPanel Development
    Staff Member

    Joined:
    Apr 7, 2006
    Messages:
    4,458
    Likes Received:
    22
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    This is a BSD-ism. New files always take on the group of the directory. Whereas on a System V system (e.g. Linux), new files take on the primary group of the owner.

    Since by default, in a cPanel system, /home/user/public_html is user:nobody, any file uploads to that directory will be user:nobody. The same will happen if a user logs in via SSH, cd's to public_html and creates a file there. i.e. it's not limited to Pure-FTPd.

    Work arounds include:

    1. Upload to a directory set to user:user then move the file(s) to public_html
    2. Upload to public_html then chgrp to user
    3. Upload using the cPanel file manager

    Additionally, Pure-FTPd makes available an after-upload hook which may allow a smoother alternative, wherein a script/binary could execute after file upload and chgrp the file appropriately.
     
  14. LinuxStandard

    LinuxStandard Active Member

    Joined:
    Jan 22, 2008
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    1
    I am aware of the problem, but I have not found an acceptable solution to this for FTP. :)

    It is necessary for the workaround to be put into place by default or SuPHP on FreeBSD systems will cause 500 Internal Server Errors until the suphp.conf is manually modified.

    I can see using /opt/ to avoid library errors so this should be no different than the decision to use /opt/ instead of the default paths.
     
  15. jdlightsey

    jdlightsey Perl Developer III
    Staff Member

    Joined:
    Mar 6, 2007
    Messages:
    126
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Houston Texas
    cPanel Access Level:
    Root Administrator
    The tool doing this is /usr/local/cpanel/bin/update_php_mime_types. If you run that tool with the --man flag it has a detailed description of how it works.

    If you simply want to prevent it from checking the .htaccess files in the /home/username/public_html directory or below, open up "Tweak Settings" in the WebHost Manager interface and change "The maximum number of directories deep to look for .htaccess files when doing .htaccess checks" to 0.

    If you leave that setting at 2 and prefix the AddHandler lines with the leading comment as described in the man page, this tool will automatically fix the mime types when you switch the PHP handler settings in WHM.

    This is also mentioned in the EA3 documentation:

    http://www.cpanel.net/support/docs/ea/ea3/ea3php_php_customize.html

    http://httpupdate.cpanel.net/cpanelsync/easy/targz/Cpanel/Easy/Apache/PHPAsUser.pm.tar.gz

    The patches we apply have all been sent upstream to the author of mod_suphp.

    The configure string EA3 uses is "./configure --prefix=/opt/suphp --with-apxs=/usr/local/apache/bin/apxs --with-logfile=/usr/local/apache/logs/suphp_log --with-apache-user=nobody"

    EA3 also sets --with-apr=/usr/local/apache/bin/apr-(1-)config if appropriate.

    If you mean inside the VirtualHost containers in httpd.conf, you'd need to create custom VirtualHost templates for that. Since you mention that, I assume you're compiling mod_suphp in owner mode. It would actually be very simple to patch mod_suphp to accept and ignore the suPHP_UserGroup directives when compiled in owner mode.

    This isn't likely. Those modules are compiled against a specific version of Apache. It isn't safe to assume they're valid for the new version when Apache is recompiled. You'd really need to dig deep into EA3 and write a custom optmod to reconfigure things how you want or just manually make the changes after EA3 runs.
     
  16. jdlightsey

    jdlightsey Perl Developer III
    Staff Member

    Joined:
    Mar 6, 2007
    Messages:
    126
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Houston Texas
    cPanel Access Level:
    Root Administrator
    Ken already mentioned that this is a problem particular to FreeBSD systems. it would make sense to automatically change this setting when mod_suphp is being installed for the first time on a FreeBSD system.

    I'll look into changing that.
     
  17. LinuxStandard

    LinuxStandard Active Member

    Joined:
    Jan 22, 2008
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    1
    The additional information is appreciated. The documentation on easyapache3 is very detailed and helpful in some cases. :)

    I would still recommend a change to mod_suphp using the patch I've previously mentioned in the thread. It allows for a cleaner overall implementation as there is no need to tie a specific handler to a specific file type. It can all be set and changed at any level with complete flexibility when the File directive is not used.
     
  18. jdlightsey

    jdlightsey Perl Developer III
    Staff Member

    Joined:
    Mar 6, 2007
    Messages:
    126
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Houston Texas
    cPanel Access Level:
    Root Administrator
    Yes, most distros apply one variation or another of that patch. I'm not really sure what the logic was behind restricting those directives to location blocks in httpd.conf. The configuration cPanel's tools create already works around mod_suphp's odd behavior here, but it wouldn't harm anything to patch it.
     
  19. LinuxStandard

    LinuxStandard Active Member

    Joined:
    Jan 22, 2008
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    1
    Some additional thoughts after working with easyapache3 and the new software versions it includes:

    1) The SuPHP patch to allow the suPHP_AddHandler outside the <File *.php> type directives is a must. This patch makes life much easier for those of us that have customers that would like to use different versions of PHP to test their scripts without the need to change extensions.

    2) mod_security 1.9.x is much different than 2.1.x. There are a few gotchas along the way that might be a problem for some.

    Disabling SecFilterEngine via .htaccess is a must as mod_security will break certain applications. Editing the httpd.conf each time mod_security needs to be disabled isn't that easy.

    modsecuity-apache-2.1.15/apache2/apache2_config.c


    Line 1291:

    AP_INIT_TAKE1 (
    "SecRuleEngine",
    cmd_rule_engine,
    NULL,
    CMD_SCOPE_ANY,
    "On or Off"
    ),

    You can change it to:

    AP_INIT_TAKE1 (
    "SecRuleEngine",
    cmd_rule_engine,
    NULL,
    CMD_SCOPE_ALL,
    "On or Off"
    ),

    and add:

    #define CMD_SCOPE_ALL (OR_ALL)

    after
    #define CMD_SCOPE_ANY (RSRC_CONF | ACCESS_CONF)

    around line 1094.

    It may also be possible to create an additional block such as:

    AP_INIT_TAKE1 (
    "SecFilterEngine",
    cmd_rule_engine,
    NULL,
    CMD_SCOPE_ALL,
    "On or Off"
    ),

    after the SecRuleEngine block to prevent Internal Server Errors on websites that were setup with the old directive.

    The gotroot mod_security rules can also cause a problem with incorrect matches.

    http://www.gotroot.com/downloads/ftp/mod_security/2.0/rules.conf

    the line:

    SecDefaultAction "log,deny,phase:2,status:500,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase"

    may cause problems with rules that are not completely written in lowercase.

    the following may solve the issue, but could also cause additional problems:

    SecDefaultAction "log,deny,phase:2,status:500,t:urlDecodeUni,t:htmlEntityDecode"
     
    #19 LinuxStandard, Feb 2, 2008
    Last edited: Feb 2, 2008
  20. Hoss

    Hoss Active Member

    Joined:
    Oct 15, 2002
    Messages:
    25
    Likes Received:
    0
    Trophy Points:
    1
    Virtualhosts

    This has all been very interesting and helpful, though while no offense Nick :), a bit confusing at times.
    I did find this link that cleared up most of the confusion for me....
    http://servertune.com/kbase/?View=entry&EntryID=153

    While I have already submitted a support ticket ID #235533
    I do have a couple questions...
    EasyApache has completely messed up my virtualhost config in httpd.conf I now understand that by editing the domain/user files in /var/cpanel/userdata I should be able to rectify this situation? The xxxxx.com files

    And I think I do see the solution.
    However, my 2 vBulletin board domains are using 2 different IP address's
    So, can I or would I enter both IP's in the ip: xx.xxx.xxx.134 section?

    And if so what would be the correct syntax?
    ip: xx.xxx.xxx.133 xx.xxx.xxx.134

    or

    ip: xx.xxx.xxx.133: xx.xxx.xxx.134

    Also one of my boards also uses 2 different domains, both pointing to the same VBulletin forums.
    www.dvdrom-guide.com & www.compuhelpforum.com (They decided they wanted a name change)
    My former virtualhost config got this job done fine. But is there now anything I need to consider with this new EasyApache config?

    Thank you for your time.
    All Help IS appreciated!
    - Hoss
     
    #20 Hoss, Feb 2, 2008
    Last edited: Feb 2, 2008
Loading...

Share This Page