Showing posts with label Error. Show all posts
Showing posts with label Error. Show all posts

Unable to understand response from admin bin: apache sent

0 comments
I was getting below error when logging to cpanel of the domain:

Unable to understand response from admin bin: apache sent: LISTSUBDOMAINS 0 received:[]: Illegal seek at /usr/local/cpanel/Cpanel/AdminBin.pm line 161. Cpanel::AdminBin::adminfetch('apache', '/usr/local/apache/conf/httpd.conf', 'LISTSUBDOMAINS', 'storable', 0) called at /usr/local/cpanel/Cpanel/DomainLookup.pm line 36 Cpanel:omainLookup::listsubdomains() called at /usr/local/cpanel/Cpanel/Park.pm line 23 Cpanel::Park::Park_cplistaddons() called at (eval 28) line 1 eval 'Cpanel::Park::Park_cplistaddons(@{$argref});' called at cpanel.pl line 1644 main::exectag('<cpanel Park="cplistaddons()">') called at cpanel.pl line 4737 main::dotag(undef) called at cpanel.pl line 4620 main::cpanel_parseblock('SCALAR(0x1e9fb10)') called at cpanel.pl line 4572 main::cpanel_parse('GLOB(0x15ad13b0)') called at cpanel.pl line 1312

Unable to understand response from admin bin: reseller sent: RESELLERSUSERS root received:[]: Illegal seek at /usr/local/cpanel/Cpanel/AdminBin.pm line 161. Cpanel::AdminBin::adminfetch('reseller', 'ARRAY(0x10c7ba10)', 'RESELLERSUSERS', 'storable', 'root')
called at /usr/local/cpanel/Cpanel/Resellers.pm line 36 Cpanel::Resellers::Resellers_accountlistopt() called at (eval 31) line 1 eval 'Cpanel::Resellers::Resellers_accountlistopt(@{$ar gref});' called at cpanel.pl line 1644
main::exectag('<cpanel Resellers="accountlistopt()">') called at cpanel.pl line 4737
main::dotag(undef) called at cpanel.pl line 4620
main::cpanel_parseblock('SCALAR(0x1e9fb10)') called at cpanel.pl line 4572
main::cpanel_parse('GLOB(0x105a63b0)') called at cpanel.pl line 1312

Possible Solutions:

1. Check if the domain's user entry in the /etc/shadow
2. Touch /var/cpanel/skipparentcheck
(creating /var/cpanel/skipparentcheck causes cPanel to operate properly with the links)
3. Make sure that your Perl module is 5.8.8
4. Login to WHM and click on 'Manage wheel group' and make sure root is in wheel group. If not, do the

following:
- edit /etc/group
- find 'wheel:x' if it exits that means everything should be fine.
- if it does not then add line 'wheel:x:10:root' (without quotes)

Your /etc/group first 10 lines would look similar to this:

root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon
tty:x:5:
disk:x:6:root
lp:x:7:daemon,lp
mem:x:8:
kmem:x:9:
wheel:x:10:root

Thats work fines..

How to deal with error - 500 Internal Server Error

0 comments
This is for server administrator or who have root permissions to the server. The easy way to deal with 500 internal server error is to check the httpd logs; which can be found at /etc/httpd/logs/error_log

# tail -f /etc/httpd/logs/error_log

tail -f will add the modification to the file if even if the file is open. Now access the URL that is throwing the 500 internal server error. You should see more explanatory error in the error log on what is bothering it.

Note: In most case it is something in .htaccess that is bothering but whatsoever you get more information from the file

PHPsuexec: Fix permissions for “Internal Server Error”

0 comments
Run the following commands from the user’s public_html directory:
(MAKE SURE YOU’RE IN THE PUBLIC_HTML DIRECTORY)

find -type d -exec chmod 755 ‘{}’ \;
find -type f -exec chmod 644 ‘{}’ \;
find -iname “*.pl” -exec chmod 755 ‘{}’ \; -o -iname “*.cgi” -exec chmod 755 ‘{}’ \;
chown `pwd|cut -d/ -f3`.`pwd|cut -d/ -f3` -R .

Error 554 message returned in an SMTP email bounceback

0 comments

Problem:


Customer was getting the following errors from their Domino SMTP mail server when sending emails via the Email Report Server:





03/25/02 08:55:23: Mail from root@linux.mylastname... 03/25/02 08:55:24: SMTP Host did not acknowlege MAIL FROM command. [554 Mail from root@linux.mylastname rejected for policy reasons. ] 03/25/02 08:55:25: Mail transfer failed, reason: SMTP Host did not acknowlege MAIL FROM command. [554 Mail from baduser@malformed.address rejected for policy reasons. ]


This is what the Domino Log says: 03/25/2002 07:35:19 AM SMTP Server [01F6:002D-028C] Mail from root@linux.mylastname rejected for policy reasons. Domain not found in DNS. 03/25/2002 07:35:20 AM SMTP Server [01F6:002D-028C] Mail from baduser@malformed.address rejected for policy reasons. Domain not found in DNS.



Solution:


This problem should be able to be resolved by making the following changes on the Lotus Domino server and then restarting the Domino server.


1.) Start the Domino Administrator program.


2.) Go to the "Message/Messaging Settings" tree pulldown in the administrator window. On the right side window you will see the "Messaging Settings" window.


3.) From the "Messaging Settings" window Click the "Restrictions and Controls" tab and then click the "SMTP Inbound Controls" tab.


4.) Change the "Verify Connecting Host Name in DNS" setting to "Disabled".


5.) Optionally you can also change the "Verify sender's domain in DNS" setting to "Disabled".


6.) Save the settings by clicking the "Save and Close" button.


7.) Shutdown and restart the Domino Server.

Ftp error “553 Disk full - please upload later”

0 comments

Problem: You get the ftp error “553 Disk full - please upload later”, even when the quota of the user has not

been exceeded and the disk partition in which all the user accounts reside (say /dev/sda5) is not full.

Cause: The value of the variable ‘MaxDiskUsage’ in the pure-ftpd configuration file (/etc/pure-ftpd.conf ) will

be equal to or less than the percent use of the partition.

——————————————–

root@ [~]# grep MaxDiskUsage /etc/pure-ftpd.conf

MaxDiskUsage 90

——————————————–

# df

Filesystem Size Used Avail Use% Mounted on

/dev/sda5 144G 59G 78G 90% /

——————————————–

Last: Change the MaxDiskUsage value to 99 (Some high value) and restart pure

Problem: You get the ftp error “553 Disk full - please upload later”, even when the quota of the user has not been exceeded and the disk partition in which all the user accounts reside (say /dev/sda5) is not full.

Cause: The value of the variable ‘MaxDiskUsage’ in the pure-ftpd configuration file (/etc/pure-ftpd.conf ) will

be equal to or less than the percent use of the partition.

——————————————–

root@ [~]# grep MaxDiskUsage /etc/pure-ftpd.conf

MaxDiskUsage 90

——————————————–

# df

Filesystem Size Used Avail Use% Mounted on

/dev/sda5 144G 59G 78G 90% /

——————————————–

Last: Change the MaxDiskUsage value to 99 (Some high value) and restart pure



Go_GrEen^ThiNk_GReeN~LoVE_GreEn - Pushkar





Go_GrEen^ThiNk_GReeN~LoVE_GreEn - Pushkar


Plesk error: Unable to open logs

6 comments

While restarting  apache we face the following error in/var/log/httpd/error_log unable to open logs


You need to just fire the below commands and it done:


# echo $ulimit


If it is blank or a low value, try executing the command


# ulimit -n 65536


This is should fix the issue and apache should be working fine.



Failure Reason: Unable to connect to port 80

2 comments
httpd failed @ Thu Aug  11 01:39:08 2009. A restart was attempted automagically.
Service Check Method:  [tcp connect]
 
Failure Reason: Unable to connect to port 80


It seems that your server is exceeding number of allowed connection. Check Apache error log:

# grep MaxClients /usr/local/apache/logs/error_log


Edit the http.conf file.

 

Error: Fantastico is not installed at the default location

0 comments
The error was

Fantastico is not installed at the default location

/usr/local/cpanel/3rdparty/fantastico. Either move the Fantastico directory

from it's current location to /usr/local/cpanel/3rdparty/fantastico OR

enable ioncube loaders in WHM -> Tweak settings.

Make sure ioncube installed on server as well as make sure it is enable in WHM -> Tweak settings.

Check the Ioncube radio button and click on Save

If Ioncube is not installed on the server please fire the command below

root@server [~]# /scripts/phpextensionmgr install IonCubeLoader

Enabling ioncube did not fix it for me. Maybe it will for you. After looking I found cpanel now uses

/var/cpanel/3rdparty/bin/php NOT /usr/local/cpanel/3rdparty/bin/php

After doing a php info I saw it did not have a php.ini file in the new location. The fix was:

cp /usr/local/cpanel/3rdparty/etc/php.ini /var/cpanel/3rdparty/etc

Other Possible Fixes

Try to update fantastico with

# cd /usr/local/cpanel/whostmgr/docroot/cgi/fantastico/scripts/ ; /usr/local/cpanel/3rdparty/bin/php cron.php

Rebuild cpanel’s php with

root@server [~]# /scripts/makecpphp

Try a cpanel update with

root@server [~]# /scripts/upcp --force

'Fatal error: Cannot redeclare JConfig::$password

0 comments
Error : cannot redeclare JConfig::$password in /home/username/public_html/configuration.php on line 51'

Nothing to worry, just need to comment the line as you can see is the "var $password " entry was already present under the configuration at line no 36 and assigned the user name for your database.

Now all should work fine.

Horde webmail fatal error

0 comments
If you are receiving the following error code while Horde webmail login.

Error: Horde "A fatal error has occurred Could not connect to database for SQLSessionHandler. Details have been logged for the administrator"
Code:

#vi /usr/local/cpanel/base/horde/config/conf.php

How to fix the error : 401 errors

0 comments
find . -name “.htaccess” -type f -print | xargs grep -e ‘.*401.*http’ /dev/null

500: [warn] Directory / is not owned by username

0 comments
If your site is getting a 500 error, you’ll want to check Apache’s error_log at /usr/local/apache/logs/error_log.

If you see the following error, you’ll want to check the ownership of “/” to ensure it’s owned by root:root, and not a user on your server.

[Mon May 13 2:26:47 2008] [warn] Directory / is not owned by rrsdd

Let’s check the ownership:

# stat /
File: `/'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 1bh/27d Inode: 99717474 Links: 26
Access: (0755/drwxr-xr-x) Uid: ( 535/ cpus123) Gid: ( 0/ cpus123)

This shows that the / folder is owned by “cpus123? which is incorrect, and you’ll want to change the ownership to root:root.

#chown root:root /

Now let’s verify:

# stat /
File: `/'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 17h/23d Inode: 917505 Links: 25
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)