easyapache3 is slightly better than a disaster

jdlightsey

Perl Developer III
Staff member
Mar 6, 2007
126
2
243
Houston Texas
cPanel Access Level
Root Administrator
I'll dig into the mod_security code and see if that patch would cause any problems. If it lowers the security of that Apache module it would be make an easy example of a custom EA3 Option Module (the documentation for doing this is a little spartan and difficult to locate at the moment, but we are working to improve it.)

As far as adding multiple IP addresses to a single VirtualHost goes, doing so would no doubt confuse the configuration system since VirtualHosts are always assumed to have a singe IP address. The only time cPanel and WHM should be creating a VirtualHost with more than one IP is when an IP migration is taking place. It might be possible to permanently put those domains into migration and leave them there, but I'd need to research it a bit more to be certain.

The templates used by the new config system are perfectly capable of producing VirtualHosts with more than one IP address, but as far as I know it has never been a requested feature to allow for this. You could, of course, create a custom VirtualHost template for the two domains you want to do this with and hard code the IP addresses into the template, but of course that will likely confuse normal WHM functions like IP migration and the like.

If you want to go the route of creating a custom VirtualHost template, the documention on how to do so is here:

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

I'd personally suggest filing a bugzilla report asking for multiple IP addresses per VirtualHost as an enhancement request.
 

LinuxStandard

Active Member
Jan 22, 2008
27
0
51
jdlightsey said:
I'll dig into the mod_security code and see if that patch would cause any problems. If it lowers the security of that Apache module it would be make an easy example of a custom EA3 Option Module (the documentation for doing this is a little spartan and difficult to locate at the moment, but we are working to improve it.)
.
I appreciate your attention to these problems.

I'll be interested to hear the results of your research. The patch should just recreate 1.9.x's default way of handling access to the SecFilterEngine directive.

Have you researched the patch to SuPHP to do away with the <File *.php> type directives?
 

Hoss

Active Member
Oct 15, 2002
25
0
151
Well, the outcome I was hoping for would be that the httpd.conf would then be compiled to setup those two virtualhosts correctly.
Like as follows...

# DO NOT EDIT. AUTOMATICALLY GENERATED

<VirtualHost xx.xxx.142.133:80>
ServerName xxxxxx.com
ServerAlias www.xxxxxx.com
DocumentRoot /home/xxx/public_html
ServerAdmin [email protected]
UseCanonicalName Off

TransferLog /usr/local/apache/domlogs/xxxxx.com
BytesLog /usr/local/apache/domlogs/xxxxx.com-bytes_log
ErrorLog logs/xxxx_error_log
<IfModule !mod_disable_suexec.c>
User xxx
Group xxx
</IfModule>
ScriptAlias /cgi-bin/ /home/xxxxpublic_html/cgi-bin/


</VirtualHost>


# DO NOT EDIT. AUTOMATICALLY GENERATED

<VirtualHost xx.xxx.142.134:80>
ServerName xxxxxx.com
ServerAlias www.xxxxxx.com
DocumentRoot /home/xxx/public_html
ServerAdmin [email protected]
UseCanonicalName Off

TransferLog /usr/local/apache/domlogs/xxxxx.com
BytesLog /usr/local/apache/domlogs/xxxxx.com-bytes_log
ErrorLog logs/xxxx_error_log
<IfModule !mod_disable_suexec.c>
User xxx
Group xxx
</IfModule>
ScriptAlias /cgi-bin/ /home/xxxxpublic_html/cgi-bin/


</VirtualHost>


I now understand that I can create custom templates. However, I am more then a bit confused exactly how to do this properly.
Do I use the use the custom template option, then addding custom_vhost_template_ap1: /path/to/template to my userdata

or am I better off editing/using the VirtualHost.local or VirtualHost.default ????

As I need to fix this issue ASAP and insure that it stays in place once everything is correctly configured.
 
Last edited:

jdlightsey

Perl Developer III
Staff member
Mar 6, 2007
126
2
243
Houston Texas
cPanel Access Level
Root Administrator
Regarding mod_suphp, I should have been clearer. The latest versions of EA3 has a patch for mod_suphp that allows suPHP_AddHandler and suPHP_RemoveHandler outside of enclosing blocks. The WHM config tool still generates php.conf with these directives inside blocks, but it's not required if you're doing custom configuration.

Now as for the VirtualHosts...

What you really want is a single VirtualHost that has two IP addresses, not two VirtualHosts with the same Servername, Serveralias and DocumentRoot. All three versions of Apache understand VirtualHosts configured that way. IE:

<VirutalHost 1.2.3.4 9.8.7.6>
...
</VirtualHost>

That's perfectly valid, and WHM creates VirtualHosts like that when you perform an IP migration. If you create a custom template for that domain, just replace the logic that generates the IP addresses with the hard-coded IP addresses you want to use, the update the userdata file for that domain so that it can locate the template to use.

If you want to go with the type of setup you just mentioned with two independent VirtualHost entries, you could add the VirtualHost for the IP address that the config system does not generate to the post-virtualhost include in the WHM include editor. Of course, a VirtualHost added that way would not be affected by any changes you make in WHM or cPanel since they would not be aware of it. This would be a very simple way of accomplishing what you want.

I checked on IP migration as an option, and that's not going to work for what you're wanting to do. It would make every domain on the original IP address also resolve to the second IP address. A custom template or using the post-virtualhost include are the best ways to go.
 
Last edited by a moderator:

Hoss

Active Member
Oct 15, 2002
25
0
151
Well after playing around a little late tonight, I can tell you that this does not work. I tried both syntax options..... no joy, only errors


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
Thanks jdlightsey,
So your saying that if I was to use the post-virtualhost include editor to add my additional virtualhost entries, that they would be processed normally when I restart apache? If so it's worth a try.

While I may not have a perfect setup. I don't have to worry about many changes down the road. I'm on a dedicated server running the only vBulletin boards I'm ever going to run. I host my own nameservers, dedicating 2 namesevers & IP's to each board/domain. And all the DNS zone configs to do so with reverse DNS and mx entries working correctly.
If I am not doing so in the proper manner, I'll certainly entertain any enlightening or schooling I can get for free! :)
Or even pay a reasonable fee. :(
My Mailscanner setup and PHP hardening could also do with a bit of tweaking. :cool: ;)

But as things stand, any customizing I do is mine and fine. As long as I know what I did and know how to keep/lock it in place.

In additiion to the above virtualhost entires I pasted in. I have another domain, (the dvdrom-guide & compuhelp domains) setup the same way with the IP's's of xx.xxx.142.136 & xx.xxx.142.137
Of course they point to different DocumentRoot's and Logs. But you get the idea.

Again any schooling on how to BEST accomplish this correctly and effeciently is more then appreciated!
 
Last edited:

LinuxStandard

Active Member
Jan 22, 2008
27
0
51
jdlightsey said:
Regarding mod_suphp, I should have been clearer. The latest versions of EA3 have a patch for mod_suphp that allows suPHP_AddHandler and suPHP_RemoveHandler outside of enclosing blocks. The WHM config tool still generates php.conf with these directives inside blocks, but it's not required if you're doing custom configuration.
Would it be possible to have the WHM configuration tool generate the configuration without the <File *.php> type blocks using the configuration mentioned here as another option? This would make setting up servers much easier as there would be no need for this part of the custom configuration.
 

jdlightsey

Perl Developer III
Staff member
Mar 6, 2007
126
2
243
Houston Texas
cPanel Access Level
Root Administrator
I don't see why you'd want that changed LS.

<Directory />
suPHP_AddHandler ...
</Directory>

Does the exact same thing as

suPHP_AddHandler ...

The <Files> sections in the php.conf generated for mod_suphp aren't required at all. We had originally set up mod_suphp with those <Files> sections and no <Directory> section, but that was changed early on in the EA3 development cycle. Actually, I'll look at removing those <Files *.php#> sections on Monday since they do confuse people who look at the generated php.conf.

Removing the <Directory> block around suPHP_AddHandler doesn't make any sense though. Lots of machines are set up with an older version of mod_suphp that can't have suPHP_AddHandler ouside of a block. Since it's does the exact same thing with and without the <Directory> tags, it'll only cause problems to remove them.
 

jdlightsey

Perl Developer III
Staff member
Mar 6, 2007
126
2
243
Houston Texas
cPanel Access Level
Root Administrator
So your saying that if I was to use the post-virtualhost include editor to add my additional virtualhost entries, that they would be processed normally when I restart apache? If so it's worth a try.
Absolutely. When Apache reads the conf file, the directives in that include are processed as if they were written directly into httpd.conf.

So if you wanted to add a VirtualHost or other directives that are not at all tracked or managed by WHM and cPanel, those includes are a simple way to add them and have the changes preserved when you rebuild Apache and PHP.

The include editor is much easier to work with than creating custom templates. I'd really suggest going that route.
 

Hoss

Active Member
Oct 15, 2002
25
0
151
Thanks again jdlightsey!

I did so and that works even after issuing the /scripts/rebuildhttpdconf command
Apache does seem a bit more sluggish, but it certainly can be lived with.

While we are on this subject, I would mention that the default EasyApache builds in the virtualhost section this entry...


NameVirtualHost *:80

Which generates these errors in the error.log...

NameVirtualHost *:80 has no VirtualHosts

That particular issue may need to be addressed.
 

jdlightsey

Perl Developer III
Staff member
Mar 6, 2007
126
2
243
Houston Texas
cPanel Access Level
Root Administrator
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.
This looks like it was an intentional change on the part of the mod_security development team. Allowing SecFilterEngine in .htaccess files means that an attacker can easily disable mod_security. For instance:

http://www.webhostingtalk.com/showthread.php?t=668614

I've looked at the mod_security 2.5.0 rc2 code and they still have these directives locked to the main httpd.conf as they do in 2.1.4 and 2.1.5. You might submit a bug report to them requesting that they reverse that change. If you go that route, I'd suggest changing OR_ALL to OR_OPTIONS in your patch since that is more consistent with mod_security 1.9 and makes it easier to disable these directives in .htaccess files without disabling .htaccess entirely.

It should be relatively painless to create a VirtualHost include to disable mod_security for individual users though. Just create it once, copy it to the correct location, run /scripts/ensure_vhost_includes --user=<username> and /scripts/restartsrv_httpd.
 

LinuxStandard

Active Member
Jan 22, 2008
27
0
51
This looks like it was an intentional change on the part of the mod_security development team. Allowing SecFilterEngine in .htaccess files means that an attacker can easily disable mod_security. For instance:

http://www.webhostingtalk.com/showthread.php?t=668614

I've looked at the mod_security 2.5.0 rc2 code and they still have these directives locked to the main httpd.conf as they do in 2.1.4 and 2.1.5. You might submit a bug report to them requesting that they reverse that change. If you go that route, I'd suggest changing OR_ALL to OR_OPTIONS in your patch since that is more consistent with mod_security 1.9 and makes it easier to disable these directives in .htaccess files without disabling .htaccess entirely.

It should be relatively painless to create a VirtualHost include to disable mod_security for individual users though. Just create it once, copy it to the correct location, run /scripts/ensure_vhost_includes --user=<username> and /scripts/restartsrv_httpd.
OR_ALL is a dirty hack and I've patched it again to use OR_OPTIONS as that is what I've found in mod_security 1.9.5.

#if !defined(DISABLE_HTACCESS_CONFIG)
#define CMD_SCOPE_ANY OR_OPTIONS
#else
#define CMD_SCOPE_ANY (RSRC_CONF | ACCESS_CONF)
#endif

I've found that allowing customers to disable it on a per application basis has reduced the number of mod_security related support tickets and also keeps customers from telling us to disable it for their entire account.

It is all a matter of choice, but the new mod_security versions don't even allow us the choice of ENABLE_HTACCESS_CONFIG.

It might be a good idea to have an option in easyapache3 to enable the 1.9.x style .htaccess control with the default as it is in mod_security 2.x.
 

LinuxStandard

Active Member
Jan 22, 2008
27
0
51
It seems we have a new easyapache3 bug out in the latest version of release.

We have a CentOS 4.6 system updated with the latest updates and cPanel 11.18.1-R20683.

The system is built with Apache 2.0.x, PHP5, suPHP, and Zend with PHP.

Easyapache will build successfully and then we see this:

[email protected] [/usr/local/apache/conf]# /usr/local/cpanel/bin/rebuild_phpconf 5 suphp suphp 1
Invalid combination.
PHP5 is not available. Please rebuild apache if you require this configuration.

The php.conf is completely blank except for the module to disable suexec and we can't configure php with this tool because there is no way to override it even when we know it is compiled properly.

This is a disaster for a production system as we have to disable PHP in easyapache3 and compile it from source completely outside easyapache3 to bring it back up which takes time.
 

cPanelNick

Administrator
Staff member
Mar 9, 2015
3,481
35
208
cPanel Access Level
DataCenter Provider
It seems we have a new easyapache3 bug out in the latest version of release.

We have a CentOS 4.6 system updated with the latest updates and cPanel 11.18.1-R20683.

The system is built with Apache 2.0.x, PHP5, suPHP, and Zend with PHP.

Easyapache will build successfully and then we see this:

[email protected] [/usr/local/apache/conf]# /usr/local/cpanel/bin/rebuild_phpconf 5 suphp suphp 1
If you did not build php4 you cannot set a handler for it. Please try:

/usr/local/cpanel/bin/rebuild_phpconf 5 suphp none 1



Usage: /usr/local/cpanel/bin/rebuild_phpconf [--dryrun] [--no-restart] [--no-user-updates] [--current|--available] <Default PHP> <PHP4 Handler> <PHP5 Handler> <Suexec>
--dryrun : Only display the changes that would be made
--no-restart : Don't restart Apache after updating the php.conf link
--no-htaccess : Don't update user configurable PHP mime mapping.
--current : Show current settings
--available : Show available handlers and PHP SAPIs
<Default PHP> : Version of PHP to set as default handler for .php files
<PHP# Handler> : Type of Apache module to use in serving PHP requests
<Suexec> : enabled, disabled, 1 or 0


Invalid combination.
PHP5 is not available. Please rebuild apache if you require this configuration.

The php.conf is completely blank except for the module to disable suexec and we can't configure php with this tool because there is no way to override it even when we know it is compiled properly.

This is a disaster for a production system as we have to disable PHP in easyapache3 and compile it from source completely outside easyapache3 to bring it back up which takes time.
 

LinuxStandard

Active Member
Jan 22, 2008
27
0
51
It is still not being configured correctly.

[email protected] [/usr/local/apache/conf]# /usr/local/cpanel/bin/rebuild_phpconf --current
Available handlers: dso cgi none
DEFAULT PHP: 5
PHP4 SAPI: none
PHP5 SAPI: none
SUEXEC: not installed
[email protected] [/usr/local/apache/conf]# /usr/local/cpanel/bin/rebuild_phpconf 5 dso none 1
Invalid combination.
PHP4 has not been compiled as a dso. Please rebuild apache if you require this configuration.
[email protected] [/usr/local/apache/conf]# /usr/local/cpanel/bin/rebuild_phpconf 5 none dso 1
Invalid combination.
PHP5 is not available. Please rebuild apache if you require this configuration.

I can have someone drop a support ticket in about this if it would help.
 

cPanelNick

Administrator
Staff member
Mar 9, 2015
3,481
35
208
cPanel Access Level
DataCenter Provider
It is still not being configured correctly.

[email protected] [/usr/local/apache/conf]# /usr/local/cpanel/bin/rebuild_phpconf --current
Available handlers: dso cgi none
DEFAULT PHP: 5
PHP4 SAPI: none
PHP5 SAPI: none
SUEXEC: not installed
[email protected] [/usr/local/apache/conf]# /usr/local/cpanel/bin/rebuild_phpconf 5 dso none 1
Invalid combination.
PHP4 has not been compiled as a dso. Please rebuild apache if you require this configuration.
[email protected] [/usr/local/apache/conf]# /usr/local/cpanel/bin/rebuild_phpconf 5 none dso 1
Invalid combination.
PHP5 is not available. Please rebuild apache if you require this configuration.

I can have someone drop a support ticket in about this if it would help.
I can not replicate this behavior, so a ticket would be great.

Also a screenshot of
"Configure PHP and SuExec" in whm would be very helpful.
 

LinuxStandard

Active Member
Jan 22, 2008
27
0
51
I don't have a screen shot implementation on this box, but the data is as follows:

Option Configured Value
Default PHP Version (.php files) 5
PHP 5 Handler none
PHP 4 Handler none
Suexec off

Alter Configuration

Option Value
Default PHP Version (.php files) Blank with nothing to select
PHP 5 Handler None with nothing to select
PHP 4 Handler None with nothing to select
Suexec Off selected with On as an option.
 

jdlightsey

Perl Developer III
Staff member
Mar 6, 2007
126
2
243
Houston Texas
cPanel Access Level
Root Administrator
This typically indicates that the PHP CGI binary is not functioning correctly (often due to problems with extensions in the php.ini)

What does /usr/bin/php -v and /usr/php4/bin/php -v say?
 

Website Rob

Well-Known Member
Mar 23, 2002
1,501
1
318
Alberta, Canada
cPanel Access Level
Root Administrator
Would trying to run /bandwidth/index.cgi and getting a download link also be an indication that the PHP CGI binary is not functioning correctly? Ever since using EA3 to upgrade PHP I can no longer use that script to view Bandwidth usage.

WHM 11.15.0 cPanel 11.18.1-R20683
CENTOS Enterprise 4.6 i686 on standard - WHM X v3.1.0

Default PHP Version (.php files) 5
PHP 5 Handler suphp
PHP 4 Handler none
Suexec on
 

cPanelKenneth

cPanel Development
Staff member
Apr 7, 2006
4,607
79
458
cPanel Access Level
Root Administrator
Would trying to run /bandwidth/index.cgi and getting a download link also be an indication that the PHP CGI binary is not functioning correctly? Ever since using EA3 to upgrade PHP I can no longer use that script to view Bandwidth usage.

WHM 11.15.0 cPanel 11.18.1-R20683
CENTOS Enterprise 4.6 i686 on standard - WHM X v3.1.0

Default PHP Version (.php files) 5
PHP 5 Handler suphp
PHP 4 Handler none
Suexec on
No. It is not a PHP CGI script, it is a Perl CGI script.
 

PbG

Well-Known Member
Mar 11, 2003
246
0
166
I will apologize in advance for not having read all the pages of this thread. However I feel compelled to say that:

1. EasyApache 3 is anything but easy!
2. EasyApache 3 should be checking http.conf and integrating our modifications not having us hunt down and modify numerous includes everytime we want to modify the same or install a directive. I think this is pardon my french ass backwards. I will continue reading now:eek:


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: