Registry: The 'Registry' is the backend that registrar's have shared access to. Each registrar writes new names to a central registry database, from which the authoritative root (essentially, a table of all domain names on the Internet) is built.

Registrant: A registrant is the person or company who purchases a domain name. For example, Arun Kumar (registrant) registers the name arunkumar.com through OpenSRS (registrar) who in turn writes the name to the central database (Registry).

Technical, Billing and Administrative contacts all will have the domain's same contact details, unless specifically asked to change.

Still in very very rare cases Internic database updates are usually performed once a day, but sometimes it takes up to 3 days. Until the central database is updated, your domain will show as being available, however it is registered, and CAN NOT be registered by another person. As I said, those delays are very rare now a days and hence

Because of the delay in the Internic database updates, occasionally someone will register a name, and before the database is updated, someone else attempts to register that same name. Even if it seems to go through, it may not actually registered to them.

Permissions :

Shared Hosting

The permissions of the parent folder(s) and the php files should not have write permission for others. If there are instructions in the documentation of the web application you are trying to install, which says to change the permission of the upload folder as well as the config.php to 777, you don't have to follow that step . Those instructions are for servers which run PHP in apache mode.

For directories or folders, recommended permission is 755 and for files, it is 644. Change them to either 755 or 644 in File Manager (or using your local FTP client like FileZilla ). If you have shell access, the below shell commands will recursively change the permission of the php files and the folders to the permission fit for the functioning of php pages under a suPHP environment.

find /home/username/public_html -name "*.php" -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

Dedicated Hosting

If you have a dedicated server and has suPHP installed, please check the log at /var/log/httpd/suphp.log or /var/log/suphp.log. If neither of those file is present, please try to figure out the log location by doing a strings on the suphp binary. Try the following commands which will give you a clue.

root@server [~]# type suphp
suphp is /usr/local/sbin/suphp
root@server [~]# strings /usr/local/sbin/suphp  | grep log
_ZTISt11logic_error
_ZSt19__throw_logic_errorPKc
Could not set close-on-exec flag on logfile
Could not open logfile
Could not write to logfile:
" is not a valid log level
/var/log/suphp.log
logfile
loglevel

Make sure that the log file is writeable by the web server user.

Ownership :

When doing a tar xzf from shell or when transferring your account to our servers or editing the file as root on your dedicated server, the files created or extracted will not be under your ownership. In a suPHP environment, all the files must be owned by the user whose directory in which php files and related folders lies at. If you are a shared hosting customer, you need to contact e-GlueWeb support. For dedicated, you need to login as root and change the login details or else can contact the support as well.

Incorrect .htaccess values:

php_values and php_flags

Your .htaccess file may have apache related php tags, php_values or php_flags in it. This causes a 500 Internal server error when attempting to execute the script which will be displayed in the Error log of cPanel. The php_values and php_flags will need to be removed from your .htaccess file and changed to php.ini settings. See the FAQ url How can I change PHP directives in php.ini? for more help on related topic.

php_flags are On/Off values. If you have a entry like

php_flag register_globals 1

when you change it to php.ini, the entry will be like

register_globals = On

After adding the values to php.ini, don't forget to remove or comment the php_flags and php_values from .htaccess though.

ForceType forces the mime type to tell the browser that it is sending a particular type of file no matter what the extension of the file is. Solution for this would be,

to change the existing

ForceType application/x-httpd-php 

to

ForceType x-httpd-php 

AddType, is similar function to ForceType with slight difference.if you have a line AddType application/x-httpd-php .html in the .htaccess, it may throw a 500 error or prompt user to download that file. In such cases change the line to

AddType x-httpd-php .php .html