Archive for the ‘Controlpanels’ Category
Solution for amavisd error – TROUBLE in process_request: Error writing a SMTP response to the socket: Broken pipe – on OpenVZ server
If you get error messages from amavisd similar to the one posted below on a server which is virtualized with OpenVZ:
Mar 5 09:09:02 v100 amavis[17378]: (17378-14) (!!)TROUBLE in process_request: Error writing a SMTP response to the socket: Broken pipe at (eval 100) line 987, <GEN44> line 31.
then the issue can be caused by the NUMTCPSOCK value in the openvz limits. Even if the barrier of this limit was never met in /proc/user_beancounters, the above error occurs when more then 25% of all TCP sockets were used. The solution is to set the NUMTCPSOCK barrier and limit to a high value in the openvz container configuration file. Here a value that worked for me on a moderately used mailserver:
NUMTCPSOCK=”2000:2000″
Finally restart the OpenVZ VM to apply the new limit value.
Apache mod_security settings for WordPress and ModX
If you use the apache mod_security module on your apache server, you might encounter wrong 403 errors for several URL’s of the cms systems. Here are some exception rules to avoid that:
For WordPress Blogs
<locationmatch "/wp-admin/admin-ajax.php">
SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016
SecRuleRemoveById 300017
</locationmatch>
<locationmatch “/wp-admin/page.php”>
SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016
SecRuleRemoveById 300017
</locationmatch>
<locationmatch “/wp-admin/post.php”>
SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016
SecRuleRemoveById 300017
</locationmatch>
For the ModX CMS
<LocationMatch "/manager/index.php">
SecRuleRemoveById 300016
</LocationMatch>
<LocationMatch “/connectors/resource/index.php”>
SecRuleRemoveById 300013 300014 300015 300016
</LocationMatch>
<LocationMatch “/connectors/element/tv.php”>
SecRuleRemoveById 300013 300016
</LocationMatch>
Add these rules inside the vhost file of the website. If you use ISPConfig to manage the server, then add the rules in the apache directives field of the website settings in ispconfig.
Many thanks to PlanetFox for providing the rules.
How to disable MySQL replication on master/master andmaster/slave setups
The following guide shows how to disable and remove mysql replication from two or more mysql servers. These steps can be used for master/slave and master/master mysql setups. The following SQL commands have to be be executed in phpmyadmin or with the mysql commandline program. It is just important that you are logged in as mysql root user. Below I will use the mysql commandline client.
Login into mysql as root user from commandline:
mysql -u root -p
the mysql command will ask for the mysql root password.
Then execute these commands if the installed mysql version is < 5.5.16:
STOP SLAVE;
RESET SLAVE;
QUIT
use the commands below instead if the mysql version is > 5.5.16
STOP SLAVE;
RESET SLAVE ALL;
QUIT
Now edit the my.cnf file (/etc/mysql/my.cnf) and add a # in front of all lines that start with “replicate-” or “master-”. Example:
# replicate-same-server-id = 0 # master-host = 192.168.0.105 # master-user = slaveuser # master-password = akst6Wqcz2B # master-connect-retry = 60
Then restart mysql:
/etc/init.d/mysql restart
Setting up email routing to gmail / google apps via ISPConfig 3
The following guide describes the steps to add DNS records that route emails from a domain managed in ISPConfig 3 to google apps / gmail. The guide assumes that you have already setup the dns zone for your domain in ispconfig.
Login to ISPConfig, click on the DNS module icon in the upper navigation bar, then open the settings of the DNS zone that you want to redirect to google and click on the “records” tab. You should see a record list similar to this:
Now Delete the existing MX record and the “mail” A-Record. Then add the following new records:
CNAME Record:
Hostname: mail
Target: ghs.google.com.
MX Records:
example.com. ASPMX.L.GOOGLE.COM. 10
example.com. ALT1.ASPMX.L.GOOGLE.COM. 20
example.com. ALT2.ASPMX.L.GOOGLE.COM. 30
example.com. ASPMX2.GOOGLEMAIL.COM. 40
example.com. ASPMX3.GOOGLEMAIL.COM. 50
IMPORTANT: All full domain names like “ghs.google.com.” have to end with a dot, if the dot is missing, the name is treated as subdomain of the zone.
The resulting record list should look like this:
Change of mail header form field identifier from ISPConfig 2 to ISPConfig 3
If you have a local mail server installed and change your server controlpanel to ISPConfig 3, having used ISPConfig 2 in the past, you may have to change the value that defines the form field observed by all functions in need of the address that mails are supposed to be delivered to (catchalls, etc.) on your mail server preferences since the identifier has changed from X-Delivered-To to Delivered-To in ISPConfig 3; otherwise the system won’t be able to find the necessary information in the mails’ headers.
Restart the server afterwards and you should find it working again.
Thanks to Alexander Fox for this post!
Fix “HTTP request length 134926 (so far) exceeds MaxRequestLen” error on Debian Linux
If you get a 500 error in a webpage hosted on Debian Linux (6.0) with apache webserver and fastcgi, take a look into the apache error.log file. This can either be the global error.log or the error.log of the website where you got the error. If you find a error similar to this one:
[Fri Apr 10 15:18:05 2012] [warn] [client 192.168.0.55] mod_fcgid: HTTP request length 134926 (so far) exceeds MaxRequestLen (131072), referer: http://www.example.tld/administrator/index.php?option=com_installer
then the MaxRequestLen setting of mod_fccgid is too low. To fix that, edit the file /etc/apache2/mods-available/fcgid.conf
vi /etc/apache2/mods-available/fcgid.conf
and add or edit the line “MaxRequestLen 15728640″ to set the Request Limit to 15MB. The resulting file should contain these settings:
AddHandler fcgid-script .fcgi
FcgidConnectTimeout 20
MaxRequestLen 15728640
Save the changes and restart apache:
/etc/init.d/apache2 restart
Debugging of ISPConfig 3 server actions in case of a failure
The follwing article describes the steps that can be taken to debug the ISPConfig 3 server scripts.
Enable the debug Loglevel in ISPConfig
Login to the ISPConfig intterface and set the log level to Debug under System > System > Server Config (see also chapter 4.9.2.2 of the ISPConfig 3 manual) for the affected server. After one or two minutes, there should be more detailed messages in ISPConfig’s system log (Monitor > System State (All Servers) > Show System-Log).
Disable the server.sh cronjob
Go to the command line of the server on which the error happens (on multiserver systems, it is often the slave and not the master) and run (as root):
crontab -e
Comment out the server.sh cron job:
#* * * * * /usr/local/ispconfig/server/server.sh > /dev/null >> /var/log/ispconfig/cron.log
Run the server script manually to get detailed debug output
Then run the command:
/usr/local/ispconfig/server/server.sh
This will display any errors directly on the command line which should help you to fix the error. If you have fixed
the error, please don’t forget to uncomment the server.sh cron job again.
Apache mod-security installation on Debian 6.0 (squeeze)
Install the apache mod-security 2 module with apt from the Debian repositories
apt-get install libapache-mod-security
Create the folder for the mod-security configuration files
mkdir /etc/apache2/mod-security
chmod 600 /etc/apache2/mod-security
Download and unpack the mod-security rules
cd /tmp
wget http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.1.tar.gz
tar fvx modsecurity-core-rules_2.5-1.6.1.tar.gz
mv *.conf /etc/apache2/mod-security/
ln -s /var/log/apache2 /etc/apache2/logs
Configure apache to load the activated mod-security rules
vi /etc/apache2/conf.d/mod-security.conf
Include /etc/apache2/mod-security/*.conf
To enable mod-security, edit the file
vi /etc/apache2/mod-security/modsecurity_crs_10_config.conf
and remove the # in front of the line:
SecDefaultAction “phase:2,log,deny,status:403,t:lowercase,t:replaceNulls,t:compressWhitespace”
Then reload apache.
/etc/init.d/apache2 force-reload
Mod security will now start to block hack attempts to your websites and log the actions in the file /var/log/apache2/modsec_audit.log.
tail /var/log/apache2/modsec_audit.log
You will see very likely some falsely blocked URL’s. To whitelist them, you can add the ID’s of the rules that should not be used in the whitelist file.
Example:
vi /etc/apache2/mod-security/modsecurity_crs_99_whitelist.conf
SecRuleRemoveById 960015
SecRuleRemoveById 960016
nginx server error: 413 Request Entity Too Large
The nginx webserver has a max. body size limit of 1 MB for requests as default. This might be too low for file uploads in scripts and you will see the following error message when you try to upload a file:
413 Request Entity Too Large
The configuration variable for this option is “client_max_body_size” and it can be set in the http, server and location sections of the nginx configuration file. To set the Limit globally to 25 MB, edit the nginx.conf file and add:
client_max_body_size 20M;
in the http section.
Example for Ubuntu Linux:
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
geoip_country /etc/nginx/geoip/GeoIP.dat; # the country IP database
geoip_city /etc/nginx/geoip/GeoLiteCity.dat; # the city IP database
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
client_max_body_size 20M;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Enhanced e-mail SPAM protection in ISPConfig 3
The command below enables a stricter SPAM handling for postfix on ISPConfig 3 servers.
In Detail:
- Reject sender hostnames with invalid syntax
- Reject sender hostnames that are no fully qualified domains (e.g. reject “server1″ but allow server1.domain.tld)
- Reject sender domains that have no DNS records
- Check sender IP addresses against realtime blacklists.
First make a backup of the postfix main.cf file in case that you want to reverse the changes later:
cp -pf /etc/postfix/main.cf /etc/postfix/main.cf.bak
Then execute this command to enable the additional spam protection functions (the command is one line!).
postconf -e ‘smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_recipient_domain, reject_non_fqdn_recipient, reject_unauth_destination, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_rbl_client cbl.abuseat.org,reject_rbl_client dul.dnsbl.sorbs.net,reject_rbl_client ix.dnsbl.manitu.net, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination’
Then restart postfix:
/etc/init.d/postfix restart


