LinuxHostingSupport

Sometimes SSH won’t allow you to login though correct login credentials has been submitted and the SSH access logs says the following:

sshd: PAM _pam_load_conf_file: unable to open /etc/pam.d/system-auth 
sshd: PAM unable to dlopen(<*unknown module path*>) 
sshd: PAM [error: <*unknown module path*>: cannot open shared object 
file: No such file or directory] 
sshd: PAM adding faulty module: <*unknown module path*>

The SSH access logs are saved in the /var/log/secure file. The logs clearly indicates that the file “system-auth” is missing from the “/etc/pam.d/” directory. This file is responsible for calling the PAM modules and is very much needed for authentication.

root@server [~]# ls -la /etc/pam.d/system-auth 
 /bin/ls: /etc/pam.d/system-auth: No such file or directory

In order to fix the issue, copy over the ‘system-auth’ file from another server and you should be able to SSH in immediately.

An email from a cPanel server with the “tailwatchd failed” warning message indicates that either the cpanel service is offline/down OR the cpanel service was restarted. The complete message looks like the following:

tailwatchd failed @ Tue Jan 1 00:00:00 2010. 
A restart was attempted automagically 
Service Check Method: [check command] tailwatchd is not running

There isn’t anything to worry, however, you can check the tailwatchd logs for the failure reasons:

# tail -f /usr/local/cpanel/logs/tailwatchd_log

To check the status of the ‘tailwatchd’ service and it’s output, execute

# /usr/local/cpanel/libexec/tailwatchd --status 
 Driver (Active: 1) Cpanel::TailWatch::ChkServd
 tailwatchd is enabled
 Running, PID 24463
 Driver (Active: 1) Cpanel::TailWatch::cPBandwd
 Driver (Active: 1) Cpanel::TailWatch::Antirelayd
 Driver (Active: 1) Cpanel::TailWatch::Eximstats

Restart the ‘cpanel’ service once, just to make sure it’s online

# service cpanel restart

and if you still continue to receive the ‘tailwatchd failed’ emails, update “cPanel” on the server

# /scripts/upcp --force

On a Suhosin enabled server, the values of suhosin parameters for example “suhosin.post.max_vars” are updated in the PHP configuration file i.e. php.ini. By default, non of the parameter is listed in the php.ini file and you have to mention the parameter and it’s new value manually.

In order to increase the value of suhosin.post.max_vars from 2000 to 3000, locate the server side php.ini file

# php -i | grep php.ini

and define the parameter and the new value at the end of the file as shown below

[suhosin] suhosin.post.max_vars = 3000

The values of other parameters can be updated in the same way, one per line. Save the file and restart the Web server.

# service httpd restart

To verify the new value, you can either execute the command

# php -i | grep suhosin.post.max_vars

OR create a phpinfo.php file and browse it.

http://yourserverip/phpinfo.php

The error message “php: symbol lookup error: suhosin.so: undefined symbol: zend_atol” occurs when an application/software is not compatible with Suhosin OR is upgraded to the latest version. It may not cause issues with all the applications but definitely does affect some of them.

The only work around is to enable suhosin.simulation for the account (domain) instead of disabling Suhosin server wide. The suhosin.simulation if turned ON, will log the violations as usual but nothing will be blocked or removed from the request.

You can perform this task in one of the either ways:

1) Enable suhosin.simulation in a .htaccess file of the domain (non-suphp enabled server)

php_flag suhosin.simulation On

OR

2) Create a php.ini file under the account (domain) and turn ON the simulation

suhosin.simulation = On

There is no need to restart any service in any of the above case.

The error message “unpacking of archive failed on file /usr/bin/xxxx: cpio: open Failed” indicates that the system failed to install the rpm since it cannot unpack the package under the /usr/bin directory.

For example, you may see the error message as stated below while installing a ‘nano’ package using yum

Error unpacking rpm package nano-1.x.x.i386 
error: unpacking of archive failed on file /usr/bin/nano;
4c70f874: cpio: open Failed:

This indicates that the file /usr/bin/nano cannot be created under the /usr/bin directory which mostly happens if an attribute is set on the directory.

Use the ‘lsattr’ command to check if an attribute is set on the directory:

# lsattr /usr | grep bin 
----i-----I-- /usr/bin

If the file/directory have an immutable bit (lowercase ‘i’) set as shown in the above output, it indicates that the permissions to write in the file/directory has been denied.

To remove the immutable bit, use the ‘chattr’ command:

# chattr -i /usr/bin 

Once done, you can successfully install the rpm.

Important:

In some cases though, the rpm file itself is corrupt and cannot be installed, so it is also recommended to try install the rpm on another server to see if it works. If it fails on another server too, you should download the package from a different website / mirror.