How to fix: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80

sshApache Error: (98) Address already in use

Occasionally your VPS or dedicated server will just not play ball.

Whenever Apache gives up the ghost it usually a case of restarting the service and within seconds your sites are back online, as if nothing happened. Great!

# service httpd restart

Most of the time, this resolves the issue. But, on occasion, apache simply doesn’t want to play. The most common issue we hear about is the Address already in use issue, which looks something like this

# service httpd restart
Stopping httpd:                                            [FAILED]
Starting httpd: (98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
                                                           [FAILED]

How to resolve this apache issue

Unless apache is restarting at the time you are trying to restart manually then what we have here is a locked process. Thankfully the resolution is quite simple. We just need to find the locked process, kill it then restart apache as usual.

Let’s find the locked process id

# netstat -ltnp | grep ':80'

This will return something like this

tcp  0  0 :::80  :::* LISTEN      3826/sudo

Now we have identified the PID as 3826, we just need to kill it

# kill -9 3826

With a little luck, a simple apache start will now get everything working

# service httpd start

Starting httpd: [  OK  ]

If the problem persists then review the apache error log to locate the issue:

# tail -500 /var/log/httpd/error_log

Protect against WordPress Pingback Vulnerability

How to Neutralise a Pingback DDOS Attack

sshThe WordPress Pingback Vulnerability is used to maliciously attack your WordPress site via the Pingback service.

If the attack is heavy enough then not only will your site be seriously slowed if not inaccessible) but your server will also be overloaded with requests thus risking your shared hosting account altogether.

This type of attack is usually instigated via a botnet of many hundreds (if not thousands) of different IP addresses so a simply blocking the IP address of the attacker is not practical.

If you are under attack right now then there are actions you can take to minimise (if not nullify) the effect of attack.

Disable the WordPress XMLRPC Service

We can do this by adding a “deny” to “xmlrpc.php” in your .htaccess file. This will disable the your WordPress site from participating with the pingback requests.

Add the following to the top of your .htaccess file:

<files xmlrpc.php>
order deny, allow
deny from all
</files>

The attack will now have less effect on your server load.

Once the attack is over, you may remove deny code if you need XMLRPC services active on your WordPress site. There’s a 95% chance you can leave it there with no noticeable effect at all.

Blocking the DDOS Attack using CSF

If you use CSF, you may still want to block the IP addresses of the attacking botnet. It’s quite easy to do.

Here is a bash one-liner that will do the job for you in real-time:

tail -f /var/www/vhosts/yourdomain.com/logs/access_log | grep "\"WordPress/" | grep -v "POST " | awk '{print $1}' | while read IP; do /usr/sbin/csf -td $IP 7d BlockPingback; done

There is some satisfaction in having the IPs permanently blocked. You can add the resulting IP block to your deny files on all servers and accounts.

It does make sense as all the attacking WordPress sites are clearly compromised and will no longer be a problem (for you at least) if permanently blocked from your server.

How to Upgrade IGB NIC Driver

Upgrade IGB Driver to Fix Packet Loss Problems

The early versions of igb NIC/LAN driver were buggy, if your version look like this:

# ethtool -i eth1
driver: igb
version: 5.0.5-k

Any version under v5.2.15 is buggy and a simple ping test to your server will show packet loss issues, usually around 20%.

To upgrade the driver, use the following steps.

1) cd /root
2) wget http://sourceforge.net/projects/e1000/files/igb%20stable/5.2.17/igb-5.2.17.tar.gz
3) tar -xvzf igb-5.2.17.tar.gz
4) cd igb-5.2.17/src/
5) make install
6) rmmod igb; modprobe igb
7) rmmod ixgbe; modprobe igb
8) vi /etc/sysconfig/modules/igb.modules

and set 

modprobe igb

9) Following is the output ::

=========================

root@server [~]# modinfo igb

filename: /lib/modules/2.6.32-504.12.2.el6.x86_64/kernel/drivers/net/igb/igb.ko
version: 5.2.17
license: GPL
description: Intel(R) Gigabit Ethernet Network Driver
author: Intel Corporation, 
srcversion: 420A0DE22C6377FB9C68995
alias: pci:v00008086d000010D6sv*sd*bc*sc*i*
=======\\=================
=======================
root@server [~]# lsmod | grep dca
dca 7101 1 igb
=======================

Let’s see the active version after the upgrade:

# ethtool -i eth1
driver: igb
version: 5.2.17
firmware-version: 1.52, 0x800007ae
bus-info: 0000:01:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

That resolves the issue. No reboot/restart is required.

How to: Connect to MySQL Remotely

mysqlEnabling Plesk 12 Remote MySQL Connections

1. Connect to your server via SSH.

2. Log into MySQL.

mysql -u admin -p`cat /etc/psa/.psa.shadow`

3. If you are attempting to grant non-localhost access to a user, you should use this line:

GRANT ALL PRIVILEGES ON dbname.* TO username@'IP' IDENTIFIED BY 'password';

Where:

  • dbname is replaced by the database you’d like to open up (a * here will open up all databases)
  • username is replaced by the user to be allowed access
  • IP is replaced by the actual IP to connect from (a % here will open up to all IPs — NOT RECOMMENDED).
  • password is replaced by the desired password. A blank field here will result in no password (NOT RECOMMENDED). Changing the password for that user listed in Plesk will set it as well.

4. Apply these changes by using the MySQL command:

FLUSH PRIVILEGES;

5. Next, quit MySQL by using this command:

quit

6. You may need to allow the source IP from which you are connecting to connect to port 3306 after granting the privileges inside MySQL. Connect to your server as “root” and issue the following command:

iptables -I INPUT -s -p tcp --dport 3306 -j ACCEPT

Be sure to replace with your IP address.

Plesk 12 Stuck in Power User View

sshPlesk panel stuck in SMB / Power User Mode and Interface Management options are missing

Plesk admin login does not show full admin interface with service plans, subscriptions, domains etc.

If this happens, you need to resort to the command line to disable “Power User View”.

As root user execute the following command:

# /usr/local/psa/bin/poweruser --off

When you access the panel through your browser you will now see “Service Provider View”.