LinuxHostingSupport

PPTP (Point to Point Tunneling Protocol) is a method for implementing VPN (Virtual Private Networks). The basic requirement to configure PPTP VPN is to allow port 1723 (TCP) in the server firewall and to load ip_gre module in the kernel. The module is by default compiled with the kernel but sometimes it is not loaded which can be done using the modprobe command.

# modprobe ip_gre

If you have a VPS, you have to ask your hosting provider to enable the PPP module on your VPS and to load the ip_gre module on the host server. Refer:

Now lets get started with the installation:

1) Install the PPP and PPTPD package on your server. You can either use YUM to install them OR install them manually by downloading their RPMs.

# yum install ppp

# yum install pptpd

OR

download the PPP and PPTPD RPMs from http://poptop.sourceforge.net/yum/stable/rhel5 according to your server architecture. Once downloaded, install them using the ‘rpm’ command:

# rpm -ivh ppp-2.4.4-14.1.rhel5.x86_64.rpm
# rpm -ivh pptpd-1.3.4-2.rhel5.x86_64.rpm

2) Now, open the /etc/pptpd.conf file. The only change you have to make in this file is to specify the localip and remoteip. The parameters are defined at the end of the file.

localip 10.0.0.2
remoteip 10.0.0.10-50

The IP 10.0.0.2 (localip) will be assigned to the PPP interface created on your server. IPs from the IP range 10.0.0.10-50 (remoteip) will be assigned to the clients who will connect to the PPP interface. You can use any Private IP range instead of the above IPs.


3) You now have to define the DNS that PPTP is going to use. The DNS can either be the one provided by your ISP/hosting provider OR you can use Google DNS too.

Edit the file /etc/ppp/options.pptpd and scroll down to the line which states “ms-dns” and uncomment the lines. They should look like follows:

ms-dns 8.8.8.8
ms-dns 8.8.4.4

Save the file.


4) The next step is to add username/passwords of your clients in the /etc/ppp/chap-secrets file (one user per line). The server by default is pptpd and you can restrict a user to a specific IP as well. The file should look like the following:

# client server secret IP addresses
 client1 pptpd pass1 10.0.0.10
 client2 pptpd pass2 10.0.0.11

So the above lines state that their are 2 users, client1 and client2 to whom IPs 10.0.0.10 and 10.0.0.11 will be assigned when their connection to the PPTP server will be established.

You can also state * instead of the IP in the above file and any IP from the ‘remoteip’ range will be assigned randomly to the user.


5) Now activate IP forwarding in the sysctl.conf file by enabling “net.ipv4.ip_forward”. Open /etc/sysctl.conf file and add the following:

net.ipv4.ip_forward = 1

to make the changes active immediately, execute:

sysctl -p

6) Now add the firewall rules to do NAT, accept connections on GRE protocol and on port 1723. You should also add FORWARD rules if you want to route all your internet traffic through the VPN server.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A INPUT -i eth0 -p tcp --dport 1723 -j ACCEPT
iptables -A INPUT -i eth0 -p gre -j ACCEPT
iptables -A FORWARD -i ppp+ -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o ppp+ -j ACCEPT

7) Now start the pptpd service

# service pptpd start

Your are done with the server side configuration.


Now configure the Client side VPN network:

1) Goto Start -> Settings -> Control Panel -> ‘Network Connections’
2) Click on “Create a New Connection” and click Next
3) Select ‘connect to the network at my workplace’
4) Select ‘Virtual Private Network connection’
5) Type a name for your connection and click Next
6) Select ‘Do not dial the initial connection’
7) Type IP or Hostname of the server on which server side PPTP is configured
8 ) Click Finish and it will prompt for username/password
9) Enter one of the username/password that you have specified in the /etc/ppp/chap-secrets file
10) Click Connect.

That’s it. You will now be connected to the PPTP VPN server.

To verify whether your requests are going through the VPN server, browse the website http://whatismyip.com which will display the VPN server IP address instead of your local internet IP.

Somtimes you may want to change the Mysql table from MyISAM to InnoDB engine to setup foreign keys, to use row level locks, improve performace etc.

The conversion of the MyISAM table to InnoDB is easy however, if the table is setup with “FULLTEXT indexes”, it cannot be converted as this feature is not supported in InnoDB.

If a table is setup with “FULLTEXT indexes”, the conversion of table to InnoDB will result in “The used table type doesn’t support FULLTEXT indexes” error message.

mysql> ALTER TABLE test ENGINE=InnoDB;
ERROR 1214: The used table type doesn't support FULLTEXT indexes

The solution is to remove “FULLTEXT indexes” from the table before converting to InnoDB. To check if the table is setup with FULLTEXT indexes, execute:

mysql> show create table test;
 ------------------------
 | Table | Create Table
 ------------------------
 | test | CREATE TABLE `test` (
 `col_name` varchar(10) DEFAULT NULL,
 FULLTEXT KEY `keyname` (`col_name`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1 |

If FULLTEXT is setup, the output of the above command will display a line as follows:

FULLTEXT KEY `keyname` (`col_name`)

Now, remove “FULLTEXT” indexes from the table:

mysql> ALTER TABLE test DROP INDEX keyname;

Now, this table can be converted to InnoDB using the following command:

mysql> ALTER TABLE test ENGINE=InnoDB;
 Query OK, 0 rows affected (0.04 sec)
 Records: 0  Duplicates: 0  Warnings: 0

 
Sometimes a Plesk upgrade may result in an “SWKeyExFatalError: Cannot open file” error while accessing the Plesk panel. The error message looks like

ERROR: SWKeyExFatalError
error: Cannot open file
----------------------------
0: common_func.php3:4537
of_get_key_by_product(string ‘plesk-unix’)
1: common_func.php3:4537
getPleskKey()
2: common_func.php3:4616
getKeyProp(string ‘demo’)
3: auth.php3:48

 
The SWKeyExFatalError error occurs when ownership of files/directories in /etc/sw/keys are incorrect.
The files and directories in /etc/sw/keys/ should be owned by psaadm:swkey-data except registry.xml.

# ls -la /etc/sw/keys
 drwxrws--- 2 psaadm swkey-data 4096 Mar 25 04:02 backup
 -rw-r--r-- 1 psaadm swkey-data 22 May 18 2010 info
 drwxrws--- 2 psaadm swkey-data 4096 Sep 15 2011 instances
 drwxrws--- 2 psaadm swkey-data 4096 Mar 25 04:02 keys
 drwxrws--- 2 psaadm swkey-data 4096 Sep 15 2011 lock
 -rw-rw---- 1 root swkey-data 7431 Apr 8 04:02 registry.xml
 drwxrws--- 2 psaadm swkey-data 4096 Sep 15 2011 restart

 
If the ownership of the files is not what you see above, correct them as follows:

# chown psaadm:swkey-data /etc/sw/keys -R
# chown root:swkey-data registry.xml

 
Next, restart the Plesk service and Plesk control panel should work.

# service psa restart

 
However, if the user ‘psaadm’ is not in the ‘swkey-data’ group, it is possible that the ownership of the files get reverted on restarting the Plesk service.

# id psaadm
 uid=501(psaadm) gid=501(psaadm) groups=501(psaadm),2522(psaserv)

 
As you can see above, the user psaadm is not in the group of swkey-data. You can also verify it as follows:

# grep swkey-data /etc/group
 swkey-data:x:502:

 
In such a case, edit the /etc/group file and add the psaadm user in swkey-data group. The line should look like follows:

swkey-data:x:502:psaadm

 
Save the file and verify the new settings

# id psaadm
uid=501(psaadm) gid=501(psaadm) groups=501(psaadm),502(swkey-data),
2522(psaserv)

 
Restart the Plesk service and the Plesk panel will work without problems.

A SuperBlock in Linux saves information about the File System like, the File System type, size, status etc. A File system cannot be mounted if a Superblock is corrupted.  Corruption of superblock can occur due to various reasons like, abnormal shutdown due to power failure, virus infection, file system corruption etc.

When a Superblock is corrupted, you receive a ” can’t read superblock” error message while accessing the File System. For example, if you try to access a Linux ext3 partition say, /dev/sda3, you will receive the following message:

/dev/sda3: Input/output error
mount: /dev/sda3: can’t read superblock

Linux ext3 file system automatically maintains a backup of superblock at various locations. In cases such as these, you have to restore a superblock from an alternate  backup location to retrieve the data.

Note: You should unmount the partition before performing this task.

First, find / list the superblock locations of the file system /dev/sda3 (we are using sda3 as an example, your partition may be different)

# dumpe2fs /dev/sda3 | grep superblock
 dumpe2fs 1.39 (29-May-2006)
 Primary superblock at 1, Group descriptors at 2-2
 Backup superblock at 8193, Group descriptors at 8194-8194
 Backup superblock at 24577, Group descriptors at 24578-24578
 Backup superblock at 40961, Group descriptors at 40962-40962
 Backup superblock at 57345, Group descriptors at 57346-57346
 Backup superblock at 73729, Group descriptors at 73730-73730

Now, check and repair (fsck) the file system with an alternate superblock #24577. BTW, try superblock from another location if one doesn’t work.

# fsck -b 24577 /dev/sda3
 fsck 1.39 (29-May-2006)
 e2fsck 1.39 (29-May-2006)
 /dev/sda3 was not cleanly unmounted, check forced.
 Pass 1: Checking inodes, blocks, and sizes
 Pass 2: Checking directory structure
 Pass 3: Checking directory connectivity
 Pass 4: Checking reference counts
 Pass 5: Checking group summary information
 Free blocks count wrong for group #0 (3553, counted=513).
 Fix<y>? yes

Free blocks count wrong for group #1 (7681, counted=5059).
 Fix<y>? yes

Free blocks count wrong for group #19 (7939, counted=7697).
 Fix<y>? yes

/boot: ***** FILE SYSTEM WAS MODIFIED *****
 /boot: 35/50200 files (8.6% non-contiguous), 17906/200780 blocks

Now, mount the partition once the file system check is over:

# mount /dev/sda3 /mnt

Once the partition is mounted, you can retrieve the files from /mnt:

# mkdir backup
# cd /mnt
# cp filename /backup/

BTW, it is always good to keep a backup of your data instead of finding yourself in such situations.

After performing a mysql upgrade, you may run into a problem where Mysql won’t start successfully and will result in a “Table ‘mysql.plugin’ doesn’t exist” error message. The mysql error logs will state something like follows:

/usr/libexec/mysqld: Table 'mysql.plugin' doesn't exist
110620  01:01:01 [ERROR] Can't open the mysql.plugin table.
Please run mysql_upgrade to create it.

The solution is to run mysql_upgrade to create the mysql.plugin table but the problem is you can execute the command only when Mysql is online. Tricky situation, isn’t it?

This mostly likely happens when mysql is still using the old my.cnf file after the upgrade. The my.cnf of the new Mysql version is saved as /etc/my.cnf.rpmnew and this is the file you should be using

# cp /etc/my.cnf /etc/my.cnf.old
# cp /etc/my.cnf.rpmnew /etc/my.cnf
# /etc/init.d/mysqld start

Once Mysql is started, you can now execute mysql_upgrade:

# mysql_upgrade -uroot -p <mysqlpass>

This will create the ‘mysql.plugin’ table and will make sure the mysql database is uptodate as per the newer version.