Bad Request (Invalid Hostname) when accessing via IP

Customer wanted to have a dedicated IP, but once I change the IP from the plesk control panel, I couldn’t get the website when accessed using IP. Instead, it was giving me the plesk control panel’s default page. Reason ? Default Website was having the IP as “All Unassigned”. Set that to the main IP address. But after that I was getting a new error.

What I could get was “Bad Request (Invalid Hostname)” in bold letters. Here is what I did to fix the same.

Start -> Run -> inetmgr -> Expand the (+) -> Websites -> Right click on the domain name -> Take Properties -> Website -> IP Address (make sure that it has the dedicated IP assigned there) and then click “Advanced”

Add/Edit Web Site Identification

IP Address : Choose the dedicated IP from drop down list
TCP/IP Port : 80
Host Header Value : Leave it blank (Important)

Leaving the Host Header Value should fix the issue and fetch the website when accessing it using the IP.

How to recover forgotten plesk password from a Linux or Windows Dedicated or VPS server

To Recover your plesk password on a Linux Dedicated or VPS Server

1. Login as root to the server using ssh
2. Then issue the command below, to see your plesk password cat /etc/psa/.psa.shadow

To Recover your plesk password on a windows dedicated or VPS server

1. cd %plesk_bin%
2. Make sure that you ended up in a folder which is a line similar to “C:\Program Files\SWsoft\Plesk\admin\bin\” If not, you will have to do a “D:\” or so depending on which drive or disk you installed Plesk on and then issue the below command
3. plesksrvclient.exe -get

Why are you getting 500 internal server error on your php pages

Usually this happens in a suPHP environment. There could be few reasons why this could happen. We list here a few. The solution is intended for those with shell access.

• Ownership issues
  In a suPHP environment, depending on the mode of suPHP enabled on the VPS or server, there is a min_uid setting, which is configurable in suPHP.conf under /etc or /usr/local/etc or /opt/suphp/etc . By default the setting is 100, which means if the file is owned by a UID less than that value (100), it shouldn’t parse the php code and will result in 500 Internal Server Error. In a cPanel server, the error will be shown @ /usr/local/apache/logs/suphp.log. This restriction would enable better security, since even if a php can do some privilege escalation, it wont affect the server. Solution would be

  chown your_username.your_username path_of_your_php_file

  If that fixes only that file and not your entire php files, use the below command to change all the php files.

  find . -type f -name “*.php” -exec chown username.username {} \;
  find . -type d -exec chown username.username {} \;

  Ignore “*.php” in the above command if it still errors out for a php file. If it still don’t fix, move on to other solutions below.

• Permission issues
  It could be the world writable directories or files which is causing the issue. In a non-suphp environment, if a php script has to upload a file on a folder, (eg:  php based gallery script where customers are able to upload photos) inorder to get it uploaded to the folder, it needs to have world writable permissions. Or else apache can’t write to the folder. Here in suPHP, since the php is executed as the user itself who already have the permissions you don’t need to change it to 777 permissions and is happy with 755 (rwxr-xr-x) permissions. When a customer is moved from a non suPHP env to suPHP enabled server, we need to adjust the permissions then. Often a command like below should help

  find . -name “*.php” -type f -exec chmod 644 {} \;
  find . -type d -exec chmod 755 {} \;

  Often, you can do the above command without the -name “*.php” in the command.

• suphp.log exceeds 2GB size.If the entire servers’ php application gives you internal server error, next chance is that the suPHP log has exceeded 2GB space. Just clear the file and you are on track again. To null it, execute the command below. Below command assumes you are having the issue in a cPanel server
  

  cat /dev/null > /usr/local/apache/logs/error_log

• suPHP log don’t exist
  In a Plesk or Webmin or other servers, often the suPHP will be installed but /var/log/httpd or such folders where the suPHP.log can be created wont exist. suphp can understand and create a non-existent suphp.log, but you would need to manually create the folder /var/log/httpd. I hope you know how to create a folder though.

If you know any other cases which require another solution for this, please comment here or edit the blog.

One website in Plesk is asking for user name and password. What is the solution

This is common issue, but solutions varies based on situations. It could be one or a combination of a solutions listed below. If you had to go through another solution to solve it, please add it over here for others.

• Permission issue was making the website to ask for the password. Run the Plesk permissions fix from the Plesk reconfigurator. It could help you 10% of the time
• If it is asking for username and password, right after you changed the password of the account, 80% of the cases, below command based solution would work.
  

  cd %plesk_bin%
  websrvmng –update-anon-password –domain-name=domainname.com

• Login to plesk, select the domain, click web directories. And there, select the the protection tab and click remove protection if enabled – Only 5% chances to have this solve your issue
• Try resetting the domain password from Plesk, with Additional Write/Modify permissions checked. This may sync the IUSR_username’s password and the Plesk/FTP password. If it didn’t move on to next option to manually synchronize it.
• Go to IIS > Web sites > domainname.com > Properties > Directory Security tab > Click on Edit button within “Authentication and access control” section > enter “password” in password filed > click OK.
  After that, Go to Users Management > find user IUSR_pleskusername > Right Click > set password > proceed > enter “password” > click OK. If this also didn’t fix, issue is much more serious and move on to next options
• Depending on the Plesk versions you use, Plesk group `psacln` should be allowed to access the server from the network. For that Go to, Administrative Tools > Security Settings > Local Polices > User Rights Assignment > Access this computer from the network
• Check whether there is any new FTP accounts added with the “Home directory” as httpdocs itself. If so please remove it and then change the password at Domain Setup and save it
• Check whether the plesk_username and IIS_pleskusername are added and has proper permissions for the DriveLetter:\Inetpub\vhosts\domainname.com as well as DriveLetter:\Inetpub\vhosts\domainname.com\httpdocs.

Okay those are my current solutions.

When trying to log in to Plesk horde, the login page reloads and does not log in into webmail.

Operating System was Linux

No one was able to login to Plesk’s default webmail, horde. Enabled error reporting in php.ini and got the error message as below in the “/etc/httpd/logs/error_log” and/or “/var/log/psa-horde/psa-horde.log”

PHP Warning: Unknown(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/usr/local/psa/admin/sessions) in Unknown on line 0, referer: http://webmail.supportsages.com/test.php?mode=unregister

Here the solution was to edit the php.ini to use /tmp as the session.save_path or even “/var/lib/php/session”

Other solution, for similar issue (not this exact error though) is to set,

session.auto_start = 0 in php.ini
Making sure that localhost entry is in /etc/hosts and resolves. For that do a telnet localhost 143 and if you get “Connected to” message, its not that issue check /etc/hosts file. It must have permissions -rw-r–r– (644) on a ls -l
Whatever be the session.save_path setting in the php.ini, it should have the permission of 1777
Run IMP test to check the problem at: http://webmail.DOMAIN.COM/horde/imp/test.php and make sure that you get the green words for all the tests.
This problem may occur if the domain’s web content is hosted on another server and the MX DNS record doesn’t exist or points not to the Plesk server. IMP tries to check mail on whatever server the domain name resolves to. In order to prevent this from happening the domain name or MX record (if it exists) must be resolved locally to the server.

References : http://kb.parallels.com/article_41_260_en.html