THT Community

Full Version: [SOLVED] Step 5 error help request (CentOS 5.9+kloxo)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I've gone through everything i can think of, and i still can't seem to narrow down the reason why i'm seeing the following error on step5:
An error has occurred. Please inform your system administrator.

Steps taken to clear the error:

1) Curl issues:

php_curl, and php_curl_exec is allowed for both master php.ini, and kloxo's php.ini for the domain in question.

Tested php_curl functionality with the following script:
echo '<pre>';
echo '</pre>';

resulting in positive response from server informing me curl functionality is correct..

Output of script:
array(9) {
  string(6) "7.15.5"
  string(21) "i686-redhat-linux-gnu"
  string(15) " OpenSSL/0.9.8b"
  string(5) "1.2.3"
  array(9) {
    string(4) "tftp"
    string(3) "ftp"
    string(6) "telnet"
    string(4) "dict"
    string(4) "ldap"
    string(4) "http"
    string(4) "file"
    string(5) "https"
    string(4) "ftps"
2) Naming / password correct

tripple checked username / password for tht.aux in kloxo, and THT configuration making sure they are identical with no additional spacing at the end / begining.

3) Package Configuration:

Tripple check package name in THT against resource plan backend name in kloxo making sure no errant spacing is present in beginning or end of package name.

4) ports

attempted with, and without SSL support, making sure the ports are properly configured in THT, as well as on Kloxo.

5) Enable error reporting in /etc/php.ini as well as THT's domain php.ini (seperate ini created by kloxo)

This did not result in any errors being reported on screen during the error reproduction process, nor did it result in logged errors in server side php error logs.

Final Notes:

I feel it would do more good for all parties involved if THT implemented some sort of error logging on it's side to capture, and record what it sees as an error, so better determination of error resolution can be tracked client-side without the need to request assistance from the developer.

Currently THT's error reporting extends only as far to state a generic " there was an error " with no leading information to help track down the errors source problem. With error logging script side, we could better determine a probable fix without the need of resorting to forum posting.
First of all, thank you for making my life easier and doing every step needed you think you needed to do to try to fix it yourself. I've been getting lots of PMs about the Kloxo script when people forget they accidentally put in a space or whatever. Tongue

Now, about your problem. Since these steps were taken into consideration, I would guess the problem would be on THT's end. Was the account created on the server even though it produced an error on THT?
That error message isn't generated by THT so it's difficult to tell exactly where the issue is.
This is my based on my personal experience

1) Use a original CentOS 5 template, yum update it and do not use a Kloxo Hostinabox template

2) Make sure your server hostname (in SolusVM, or whatever VM your provider has given you) is NOT the domain you are trying to install it on, so if your domain is, your server hostname CANNOT be - Make it server1, or

3) Don't use Lighttpd or anything but Apache, it really likes to stick with Apache otherwise you are going to have login issues

Good luck to you
(02-03-2013, 12:18 AM)Kevin Wrote: [ -> ]That error message isn't generated by THT so it's difficult to tell exactly where the issue is.

Oh yeah. I forgot I put that myself. LOL. Sorry.

Have you made sure that the auxiliary login CAN make client accounts?
ok. i thought the error was generated by THT..

in answer to your question(s)

No, the user account was not created on the server, nor in THT / Kloxo

I am using the httpd server that is stock with centos / kloxo.
not using lighttp.

There were some recent changes to kloxo however that were not part of the regular " update " process from the admin panel in kloxo, these changes however had to do with roundcube, and php 5.3 support.

Update announcement is HERE

hrm.. seems THT is indeed generating the error.. well.. the kloxo.php plugin is..

//echo $action."<br />". $reseller;
                $command = $this->remote($string);
                if($command == true) {
                        return true;
                else {
                      echo "An error has occurred. Please inform your system administrator.";
                       return false;

Not sure if these changes would have any effect on THT's integration process as i don't see any specific mention of API changes, or changes to kloxo code itself.
Problem resolved.

It would appear that even though the administration account for Kloxo is a reseller, and has full rights, and privileges on the server, it is not recognized as a reseller by the auxiliary login scheme.

Steps to resolve the issue:

1) Create reseller accoutn
2) if selling subdomains only, move root domain(s) to the new reseller account
3) create auxiliary login for reseller account
4) create a " resource plan " for the reseller to sell
5) add server to THT setting
6) add domain for subdomain resales if required
7) disable SSL in general settings > security
8) add package
9) test to make sure it works
well i have tried alot to solve it but yet i am not able to find its answer but give me sometime.
Sunny isles Locksmith