LinuxHostingSupport

An update/upgrade on the existing Drupal website may result in a following error message on the website:

"PHP Fatal error:  Call to undefined function user_access() 
 in /home/user/modules/ad/ad.module on line xxx"

The solution is to update a “status” entry in the Drupal Database. Access your Drupal database either from the Mysql prompt OR using a 3rd party application like phpMyAdmin.

1) Open the table called “System”.

2) Search for the entry “modules/user/user.module” in the “filename” column.

3) Change the value of ‘status’ variable from 0 to 1.

4) Save.

This is it.

Note: If the value of ‘status’ variable is already 1, change it to ‘0’ and then reset back to ‘1’. It should fix the issue.

What is Frame Forwarding and How it is set?

A few lines of Explanation:

Frame forwarding (redirection) of a domain is different than normal forwarding of a domain.

In Frame Forwarding, the visitors are redirected to another site, but the destination address is not displayed in the address bar, so they are not aware of the redirection as opposed to “Normal Forwading” (also called Parked domain).

In Normal Forwading the web site visitors are redirected to another site and the destination address is displayed in the address bar, so the visitor is aware about the redirection.

For example, suppose the main website is abc.com and we frame forwarded xyz.com to it. When we access xyz.com, the URL in the address bar of the browser will stay as it is and the contents will be fetched from abc.com. The user won’t notice the redirection.

Solution:

Using the above domain names as example, in order to set Frame Forwarding for xyz.com, first add the domain on the server as we normally do and add the following code in the index.html file

<frameset rows="100%", *' frameborder=no framespacing=0 border=0> 
<frame src="http://www.abc.com/"></frame> 
</frameset>

This is it.

A Drawback of the above method and a Solution for it:

As you will be setting up a redirection in the index.html file, any other file/directory accessed using a direct URL ( i.e. for example: xyz.com/anyfilename) will result in a “404 Not Found” error.This is because the request will bypass the redirection set in the index.html file and will search for the file under the xyz.com itself.

To overcome this problem, add xyz.com as a “ServerAlias” in the VirtualHost entry of abc.com. Edit the Apache configuration

vi /etc/httpd/conf/httpd.conf

Search for the VirtualHost entry of abc.com and make sure the “ServerAlias” line look like the following

ServerAlias www.abc.com xyz.com www.xyz.com

Save the file and restart the Web server

service httpd restart

Now, directly accessing a file or directory of a target domain using the alias domain name will also work.

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.

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.