[Notice]: unserialize() [function.unserialize]: Error at offset

August 28, 2012    |   Posted by admin   |    Category: Linux Administration

The “function.unserialize” error occurs while installing Kayako or any other 3rd party application when the “magic_quotes_gpc” parameter is enabled.

By default the value of “magic_quotes_gpc” is On in the server side PHP configuration and thus you receive the following error message:

[Notice]: unserialize() [function.unserialize]: Error at offset 5 of
41 bytes (includes/functions.php:82)  UNSERIALIZE FAILED:
[Warning]: Cannot modify header information - headers already
sent by (Cookie/class.SWIFT_Cookie.php:157)

The “magic_quotes_gpc” can be disabled server wide ( in /etc/php.ini), however, if you want to keep it enabled server side, it can be disabled for the specific account as well either by using .htaccess (if server is non-SuPHP) i.e. placing the following line

php_value magic_quotes_gpc 0

OR by copying the server side php.ini file under the specific account or directory the application is downloaded

cp /etc/php.ini /home/user/public_html/

and turn off magic_quotes_gpc in new php.ini file (in case SuPHP is enabled).

Comments Off

ssh_exchange_identification: Connection closed by remote host

July 6, 2012    |   Posted by admin   |    Category: Linux Administration

Many a times when accessing a server via SSH you may end up with “ssh_exchange_identification: Connection closed by remote host” error message. For example:

# ssh root@testserver.com
ssh_exchange_identification: Connection closed by remote host

OR may be more descriptive error when you use the verbose mode (-v flag)

# ssh -v root@testserver.com
 OpenSSH_4.0p1, OpenSSL 0.9.7a Feb 19 2003
 debug1: Reading configuration data /etc/ssh/ssh_config
 debug1: Applying options for *
 debug1: Connecting to testserver.com [1.1.1.1] port 22.
 debug1: Connection established.
 debug1: permanently_set_uid: 0/0
 debug1: identity file /root/.ssh/identity type -1
 debug1: identity file /root/.ssh/id_rsa type -1
 debug1: identity file /root/.ssh/id_dsa type 2

The ‘ssh_exchange_identification’ issue occurs for various reasons. So to fix the issue, check the following:

1) TCP wrappers i.e. whether ssh is restricted to certain IPs in /etc/hosts.allow and /etc/hosts.deny. If yes, make sure your local IP is added in the allowed list.

Edit the /etc/hosts.allow file and add the following at the top:

sshd : yourlocalip : allow

2) The /var/empty/sshd folder should be owned by user ‘root’. Sometimes if a new application is installed, it somehow changes the ownership of the /var/empty/sshd directory resulting in ‘ssh_exchange_identification’ error message.

# chown root.root /var/empty/sshd -R

3) If the permission of the private key files are incorrect i.e. if private key files are readable by all, it also results in “ssh_exchange_identification: Connection closed by remote host” error.

For example, if any of the private key file “ssh_host_key, ssh_host_rsa_key or ssh_host_dsa_key” in /etc/ssh directory have 644 permissions, they should be set to 600.

# cd /etc/ssh
# chmod 600 ssh_host_key ssh_host_rsa_key ssh_host_dsa_key
Comments Off

How to Install and Configure PPTP VPN in Linux?

May 15, 2012    |   Posted by admin   |    Category: Linux Administration

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 the second part is to 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.

Comments Off

Howto Recover a Linux Partition after a Superblock corruption?

March 31, 2012    |   Posted by admin   |    Category: Linux Administration

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.

Comments Off

CSF Installation failed: LWP perl module (libwww-perl) missing

March 19, 2012    |   Posted by admin   |    Category: Linux Administration

While installaing CSF firewall on a plain Linux server, you may notice the “LWP perl module” missing error message:

# sh install.sh
 Configuring for OS
 Checking for perl modules failed
 You need to install the LWP perl module (libwww-perl) and then
 install csf

The problem mostly occurs on a plain Linux server where all perl modules are not installed during the OS installation. On servers with control panels, this issue won’t arise.

The fix is to install the libwww-perl module either with YUM OR from cpan prompt.

# yum install perl-libwww-perl

OR goto the cpan prompt and install

# cpan
cpan> install Bundle::LWP [Installing LWP]

Once done, CSF firewall will be installed successfully.

Comments Off