Find apache config files for an IP
httpd -S
Linux, Windows, Software Tips, Articles and Hacks
Find apache config files for an IP
httpd -S
The mod_deflate module allows the Apache2 web service to compress files and deliver them to clients (browsers) that can handle them. With mod_deflate you can compress HTML, text or XML files by up to 70% of their original sizes. Thus, saving you server traffic and speeding up page loads.
Compressing files will increase load on your server, but it is a small tradeoff considering your client’s connection times will decrease significantly.
This will not exclude users with older browsers that cannot handle compressed content. The browser negotiates with the server before any file is transferred, and if the browser does not have the capability to handle compressed content, the server delivers the files uncompressed.
mod_deflate has replaced Apache 1.3’s mod_gzip in Apache2.
This article shows how to enable mod_deflate globally across all the domains on your DV server. Should you only wish to enable for a single domain you’d need to add the AddOutputFilterByType and BrowserMatch rules below to the VirtualHost section in your configuration.
For Plesk:
Set server wide configuration file in /etc/httpd/conf.d/
Make sure that mod_deflate is enabled on your server. Your DV server should have it enabled by default. If the following command returns a line with a “#” at the beginning you will have to remove(uncomment) the “#” character using vi or the perl command below:
# grep 'mod_deflate' /etc/httpd/conf/httpd.conf
If the result was LoadModule deflate_module modules/mod_deflate.so, you can continue.
If the result was #LoadModule deflate_module modules/mod_deflate.so, please run the following command:
# perl -pi -e 's/# LoadModule mod_deflate/LoadModule mod_deflate/g' /etc/httpd/conf/httpd.conf
Now that we have verified that mod_deflate is in fact being loaded by Apache, we must configure the module. First, backup your existing conf file in case you need to revert back:
# cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
Using nano, we will edit our Apache conf file and add the following lines at the very bottom of the file, making sure they are separated from any other configurations:
nano /etc/httpd/conf/httpd.conf # # Deflate output configuration # AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Save your file. Now, we need to check that Apache likes our changes using the apachectl command:
# /usr/sbin/apachectl -t
You should see a Syntax OK message. If not, please check your file to make sure you modified the file correctly. Next, we need to restart apache using the same apachectl command:
# /usr/sbin/apachectl graceful
You have now enabled mod_deflate on your DV server! You can see whether the changes are in effect using the following tool at http://whatsmyip.org/mod_gzip_test/.
Network Error (tcp_error) A communication error occurred: “Operation timed out”The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.
Options ExecCGI FollowSymLinks IncludesNOEXEC Indexes Limit SymLinksIfOwnerMatch
AllowOverride All
results in an error – Syntax error on line 71 of /usr/local/apache/conf/httpd.conf
Based on my understanding, it first disables FollowSymLinks and enables SymLinksIfOwnerMatch at the httpd.conf level and it applies to all the files and subdirectories present inside, /home.
The next directive, AllowOverride. By writing “All”, it allows all the Directives belonging to FileInfo, AuthConfig, Indexes, Limit to be overriden by .htaccess files.
It explicitly mentions the list of Options that can be overriden by the .htaccess files.
So, it allows SymLinksIfOwnerMatch to be overriden by the .htaccess file.
Is my understanding correct?
Why does it allow SymLinksIfOwnerMatch to be overriden by the .htaccess file if it has explicitly mentioned in the line above that the SymLinksIfOwnerMatch is enabled?
1. Introduction
With the size of the Apache configuration file what it is, it can be easier to find and change a virtual host container (configurations) if the settings are in separate files.
This isn’t strictly recommended by the upstream documentation, but is a common manual extension to make the system more manageable.
All manual extensions to your system should be documented for future reference.
There are several places that virtual host source files can be put. This is a complex topic with several major points of view and is not fully addressed in this document.
2. Usual Practice: conf.d/
The most common location for discrete virtual host configuration files is /etc/httpd/conf.d/. The config files can be named to reflect the website(s) to which they refer, provided they don’t conflict with configuration files of existing or future modules. The matching content can be placed under /var/www/ or /var/www/html/ in sub-directories, such as /var/www/example.com/ or /var/www/html/example.com/.
This has the advantage that the parent directories are already created and SELinux is familiar through rule inheritance, as to how to handle access rights. The packaging system leverages this, of course, by dropping the php.conf file into that configurartion directory such that after a package based install of php, and a restart of the webserver, PHP parsed pages ‘just work’
Though placing a vhost configuration file in a directory full of non-vhost related matter, such as: php.conf and mailman.conf, initially appears an out of order jumble, upon closer reading of the documentation, from Apache HTTP Server Version 2.2 – Configuration Sections, we see that: “Most containers are evaluated for each request.”
So, Apache applies the virtual host directives after all non-vhost related stanzas, regardless of the seeming alphabetical sort order position in the configuration file, or in a merged directory full of such config files, in the matter processed.
This is largely a settled area of Systems Administration, such that the most recent documentation from upstream does not appear to include a ‘System Administration Guide’ in the CentOS 5 series. The System Administration Guide from CentOS 4, Chapter 24. Apache HTTP Server Configuration covers the matter in greater depth.
3. Virtual Host Files
Virtual Host container files can be placed in the configuration directory directly or by link. The name must end with .conf to be included. If using links, make sure to update the SELinux properties of the actual file.
3.1. Example
The file should contain the configuration items specific to this host. An example.conf could be…
# file: /etc/http/conf.d/example.conf # vhost: example.org *.example.org <VirtualHost *:80> ServerName example.org ServerAlias *.example.org ServerAdmin webmaster@example.org ErrorLog /var/log/httpd/example.err CustomLog /var/log/httpd/example.log combined DocumentRoot /var/www/example.org <Directory "/var/www/example.org"> Order allow,deny Allow from all </Directory> </VirtualHost>
Of course, a virtual host configuration file may refer to more than one URL or DNS result as a single file tree.
[userid@webhost conf.d]$ cat example.conf ### two domain vhost sites handled here: ### example.com and example.org ### ### the .COM <VirtualHost x.x.x.x > ServerAdmin webmaster@example.com DocumentRoot /var/www/html/example.com/public_html/ ServerName example.com ServerAlias www.example.com ErrorLog logs/example.com-error_log TransferLog logs/example.com-access_log AccessFileName .htaccess </VirtualHost> ### the .ORG <VirtualHost x.x.x.x > ServerAdmin webmaster@example.org DocumentRoot /var/www/html/example.org/public_html/ ServerName example.org ServerAlias www.example.org ErrorLog logs/example.org-error_log TransferLog logs/example.org-access_log AccessFileName .htaccess </VirtualHost>
This file sets up the two domains, one the .com and the other the .org. As to each, it would provide the same content at the bare domain name, and also at the www when used either way in a URL for a web browser, which is usually the desired result, but of course possibly differing content between the two TLD variations as the content down the file tree specified.
4. Virtual Host Inclusion
There might be times when it is desirable to disable a virtual host. Since the include in /etc/httpd/conf/httpd.conf specifies *.conf, it is possible to hide a virtual host by changing the configuration file name.
4.1. Disable Virtual Host
Virtual hosts can be disabled by renaming the file so it doesn’t match the *.conf file specification. Adding a disabled extension is one way.
# mv --verbose /etc/httpd/conf.d/example.conf /etc/httpd/conf.d/example.conf.disabled
If less typing is desired, it can be shortened:
# mv -v /etc/httpd/conf.d/example.conf{,_}
4.2. Enable Virtual Host
Virtual hosts can be re-enabled by removing the extra.
To remove the disabled flag:
# mv --verbose /etc/httpd/conf.d/example.conf.disabled /etc/httpd/conf.d/example.conf
For the shorter version:
# mv -v /etc/httpd/conf.d/example.conf{_,}
Enabling or disabling a virtual host using this method will not take effect until the web server is restarted.
5. Restart Apache
To make your changes take effect, restart Apache. Using the graceful option ensures that existing processes are allowed to finish serving the current page, reducing the chance of disrupting a user’s browsing experience.
# service httpd graceful
Apache fails to restart on plesk server on CentOS 6.5
# service httpd restart Stopping httpd: [FAILED] Starting httpd: Syntax error on line 55 of /etc/httpd/conf/plesk.conf.d/ip_defalt/domain.com.conf: SSLCertificateFile: file '/usr/local/psa/var/certificates/cert-6xg952' does notexist or is empty
Solution:
# /usr/local/psa/admin/sbin/httpdmng --reconfigure-all
# service httpd restart
HTTP Strict Transport Security (HSTS) is an opt-in browser security mechanism that lets web site owners declare “Encrypted Communications Only”.
Strict-Transport-Security HTTP header instructs browsers to only communicate with the domain over SSL/TLS for a set period of time (the max-age). HSTS only goes into effect after a browser receives a valid header from the domain. HSTS is to ensure unencrypted communication is not allowed on your domain or site to mitigate attacks such as SSL-stripping.
The HSTS Header
Strict-Transport-Security: max-age:31536000; includeSubDomains
The max-age parameter value is in seconds; 31536000 seconds equals 365 days. Notice how the above also uses includeSubDomains. This optional parameter informs the browser to force secure communication to the site’s subdomains as well.
Browsers must receive the Strict-Transport-Security header over an HTTPS connection with the domain; HSTS headers over HTTP are not recognized as valid.
Threat Mitigation
HSTS mitigates the following threats.
1. HTTP request to an HTTPS site
For example:
1. User wants to visit SecureSite.com
2. User types SecureSite.com into the address bar
3. Browser automatically appends “http://” making the following request: http://SecureSite.com
4. Server responds with 301 (permanent redirect) to the following location: https://SecureSite.com
5. Browser makes request to above URL
The above scenario allows for a man-in-the-middle attack as a result of the unintentional HTTP request to SecureSite.com. An attacker can leverage a tool such as ssltrip to transparently hijack the HTTP request prior to the 301 redirect. HSTS eliminates this attack window as long as the user previously accessed SecureSite.com over HTTPS and obtained the HSTS header.
Even with HSTS enabled, a user’s initial request to SecureSite.com would remain unprotected from attacks. As a result, both Chrome and Mozilla introduced HSTS preload lists. If SecureSite.com is on Chrome’s HSTS preload list, a freshly installed Chrome browser will only allow secure connections to that site, even if the user never accessed it before.
2. Insecure link referencing an HSTS enabled site
For example:
1. Forum.com includes a link to http://SecureSite.com
2. HSTS will automatically convert the link to HTTPS for the HSTS-enabled site
3. Invalid Certificate
The following would be considered invalid certificates:
– Self-signed and/or untrusted CA signed certificate
– Expired
– Wrong name specified
– …
HSTS displays an error message as shown below. In addition, it will NOT allow the user to override the error message, thus preventing a potential attack by ensuring the victim does not accept the bad certificate.
Enabling HSTS
You can enable HSTS in Apache with mod headers and the following line in your configuration:
<IfModule mod_headers.c> # this domain should only be contacted in HTTPS for the next 6 months Header add Strict-Transport-Security "max-age=15768000" </IfModule>
Afterwards, restart Apache and test the configuration change:
# curl -si nvisium.com | grep ^Strict Strict-Transport-Security: max-age=31536000
In Nginx, update nginx.conf:
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
In Rails, HSTS can be enabled with the following:
# config.force_ssl = true
HSTS Preload Lists
Chrome
Code repository:
https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json
Add your site using using the following:
https://hstspreload.appspot.com
Firefox
Code repository:
http://dxr.mozilla.org/mozillacentral/source/security/manager/boot/src/nsSTSPreloadList.inc
Firefox does not maintain their own list; instead, they use a subset of Google’s. Firefox only accepts sites on Google’s preload list that have a max-age greater than or equal to 18 weeks (10886400 seconds). See https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ for more information.
Testing HSTS
– Leverage an intercepting proxy (e.g. Burp) or browser tools (e.g. Chrome DevTools / Firefox Developer Tools) to examine server responses
– In Chrome, type the below to determine if a host is in your STS cache
chrome://net-internals/#hsts
– In Firefox, you can use the Strict Transport Security Detector add-on to see if the site supports HSTS (https://addons.mozilla.org/en-US/firefox/addon/strict-transport-security-d/)
Source: http://blog.nvisium.com/2014/04/is-your-site-hsts-enabled.html
Home »Service Configuration »Apache Configuration »Global Configuration
Minimum Spare Servers 8 Maximum Spare Servers 32 Max Clients 1500 Max Requests Per Child 0 Start Servers 8 Server Limit 2000 Keep-Alive Timeout 15 Max Keep-Alive Requests 256
Other options:
–addition of memcache
–recompiling Apache to run as PreFork opposed to MPM Worker Event
Check for Prefork or Worker
# [root@austin ~]# /usr/sbin/httpd -V | grep MPM # Server MPM: Prefork # -D APACHE_MPM_DIR="server/mpm/prefork"
Links:
http://kb.sp.parallels.com/en/113007
http://codebucket.co.in/apache-prefork-or-worker/
–Reduced some of the limits in the apache config. Many things that should be in the hundreds were set in the thousands.
–KeepAlive on was simply adding too large of a load to the server.
Timeout Timeout 300
Usually this value doesn’t require editing and a default of 300 is sufficient. Lowering the ‘Timeout’ value will cause a long running script to terminate earlier than expected.
On virtualized servers like VPS servers, lowering this value to 100 can help improve performance.
KeepAlive KeepAlive On
This setting should be “On” unless the server is getting requests from hundreds of IPs at once.
High volume and/or load balanced servers should have this setting disabled (Off) to increase connection throughput.
MaxKeepAliveRequests MaxKeepAliveRequests 100
This setting limits the number of requests allowed per persistent connection when KeepAlive is on. If it is set to 0, unlimited requests will be allowed.
It is recommended to keep this value at 100 for virtualized accounts like VPS accounts. On dedicated servers it is recommended that this value be modified to 150.
KeepAliveTimeout KeepAliveTimeout 15
The number of seconds Apache will wait for another request before closing the connection. Setting this to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.
It is recommended that this value be lowered to 5 on all servers.
MinSpareServers MinSpareServers 5
This directive sets the desired minimum number of idle child server processes. An idle process is one which is not handling a request. If there are fewer spareservers idle then specified by this value, then the parent process creates new children at a maximum rate of 1 per second. Setting this parameter to a large number is almost always a bad idea.
Others Suggestions:
Virtualized server, ie VPS 5 Dedicated server with 1-2GB RAM 10 Dedicated server with 2-4GB RAM 20 Dedicated server with 4+ GB RAM 25 MaxSpareServers MaxSpareServers 10
The MaxSpareServers directive sets the desired maximum number of idle child server processes. An idle process is one which is not handling a request. If there are more than MaxSpareServers idle, then the parent process will kill off the excess processes.
The MaxSpareServers value should be set as double the value that is set in MinSpareServers.
StartServers StartServers 5
This directivesets the number of child server processes created on startup. This value should mirror what is set in MinSpareServers.
MaxClients MaxClients 150
This directive sets the limit on the number of simultaneous requests that will be served. Any connection attempts over the specified limit will be queued. Once a process is freed at the end of a different request, the queued connection will then be served.
For virtualized servers such as VPS accounts, it is recommended to keep this value at 150. For all dedicated servers the recommended value for this setting is 250.
MaxRequestsPerChild MaxRequestsPerChild 0
This directive sets the limit on the number of requests that an individual child server process will handle. After the number of requests reaches the value specified, the child process will die. When this value is set at 0, then the process will never expire.
Other adjustments:
Virtualized server, ie VPS 300 Dedicated server with 1-4GB RAM 500 Dedicated server with 4+GB RAM 1000
Other resources:
http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
https://www.howtoforge.com/configuring_apache_for_maximum_performance
http://stackoverflow.com/questions/8902103/is-there-an-apache-tuner-script-like-mysqltuner-pl
http://jmeter.apache.org/usermanual/get-started.html
For cPanel/WHM, to enable PDO in the system you can use EasyApache:
1. Login to WHM
2. Click Apache Update
3. Click Start Customizing Based on Profile
4. Select an Apache version
5. Click Next Step
6. Select PHP 5
7. Click Next Step
8. Select a version of PHP 5
9. Click Next Step
10. Click Exhaustive Options List button
11. Scroll down to the check box labeled PDO
12. Click Save and Build