mitsos

Just checked the documentation page for the namecheap module and it's empty (apart from comments). So I have a couple of questions I couldn't find answers for: 1) I didn't enter any nameservers. Will the default (namecheap's) servers be used when the domain is created? 2) Looking at the client side there's no way for a client to edit the domain's records. Is that a feature that's coming, or is the functionality not available? Ie client logs in to blesta's client area, adds an A record, setting gets pushed to namecheap. Thank you

unzipped blesta 3.0.4. Uninstalled the module from blesta, uploaded the newly unzipped namecheap folder, reinstalled and reconfigured the namecheap module and.... it works! I'll go cry in my corner now, thank you all for providing me your time to waste it.

Editing /apis/namecheap_api.php (in the above mentioned lines) 99. $response = curl_exec($ch); 100. var_dump($response); 101. curl_close($ch); gives this on the top of the page: string(372) " Parameter APIUser is missing API01 --4:00 0 " I have set up the correct user for the API on the module manage page. Will try the other modifications and report back EDIT: yeap, apiuser is missing again: string(376) " Parameter APIUser is missing API02 --4:00 0.009 " object(NamecheapResponse)#171 (2) { ["xml":"NamecheapResponse":private]=> object(SimpleXMLElement)#172 (7) { ["@attributes"]=> array(1) { ["Status"]=> string(5) "ERROR" } ["Errors"]=> object(SimpleXMLElement)#173 (1) { ["Error"]=> string(28) "Parameter APIUser is missing" } ["Warnings"]=> object(SimpleXMLElement)#174 (0) { } ["RequestedCommand"]=> object(SimpleXMLElement)#175 (0) { } ["Server"]=> string(5) "API02" ["GMTTimeDifference"]=> string(6) "--4:00" ["ExecutionTime"]=> string(5) "0.009" } ["raw":"NamecheapResponse":private]=> string(376) " Parameter APIUser is missing API02 --4:00 0.009 " } EDIT: strange, I thought that the response should be the same with the first mentioned modification. When I did that modification, I carefully went over the entire page but did not notice anything. Redoing the first modification now gives the same apiuser missing ?!?!?! string(372) " Parameter APIUser is missing API02 --4:00 0 " EDIT2: removing all modifications now gives the same apiuser missing error on check availability. Dunno what made it change it's mind and display that error now

Did that change as well. Nothing changes. the domain is still not available, no other error shows up anywhere. Even combined it with the previous recommended modification, still no change. To clarify myself, I did not receive an error regarding hostnames unable to resolve. Forcing curl to use only ipv4 for the resolution (curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4); above line 99 namecheap api file) takes a couple of seconds longer then comes back with domain not available. Running a packet capture on the WAN side (upstream router) (yes I have both the authority and ability for that ) shows traffic bouncing back and forth between api.namecheap.com's ip and my server, when checking the domain's availability, which is to be expected. That means that the DNS resolution works, something is not working right elsewhere though.

Absolutely no change. Module log is empty as well.

Hit this bug today. Blesta v3.0.4 namecheap module v1.0.6 If I click transfer the domain is available. If I click check availability the domain is always unavailable. Checking on the namecheap site the domain is available. Checked the namecheap module folder, in v3.0.4 of blesta the .php file says that the namecheap module is 1.0.6. Reuploaded the folder just in case, same thing happens. Did the bug fix change any files outside of the module? Need to upload any other file? EDIT: diff between the two files: < private static $version = "1.0.5"; --- > private static $version = "1.0.6"; 1174c1174 < return $response->DomainCheckResult->{"@attributes"}->Available == "true"; --- > return strtolower($response->DomainCheckResult->{"@attributes"}->Available) == "true";

Ah, that makes sense. Was surprised when I saw the paypal settings blank and couldn't remember if I had set them up in the past (when using that other "billing" system (*cough* HB *cough*)). Thanks for the response. Perhaps consider adding this info on the module documentation page.

Hi all, Do you need to configure anything on the paypal site for the paypal payments standard gateway module? So far I have setup the customized template, the API signature and IPN (url=root of blesta install, with message delivery enabled. Do I need to create any buttons/subscriptions separately for the products or does the module take care of that automatically (takes the price I put into the package and the description and takes care of the rest)? Thank you

Adding a new server interface:

At least I'm off to a good start

Light in the tunnel Thanks for the response. Added a couple more sections to the api file. Will work towards making something to control it through blesta, and hopefully make some progress tomorrow. Just hoping it doesn't blow up in my face

Hotter or colder? public function client_get($client_id) { if (!isset($client_id)) { error_log("client_get requires the client's ID"); return false; } $client_record = $remote_api->client_get_id($sys_userid); return $client_record; } Edit:had a revelation (or a stroke)

I have looked at the online documentation, but it's so limited, I didn't get anything out of it (except the module structure). I don't know if I'm doing anything right (or wrong) which is frustrating to say the least. For example can anyone glance over this and tell me if it will work? /** * Change an ISPConfig client's Password *-------------------------------------- * Changes a client's password. * @param string $client_id The client's ID to change the password of * @param string $new_password The new password to change to * @return mixed * */ public function client_change_password($client_id, $new_password) { if (!isset($session_id) || !isset($client_id)) { error_log("Changing a password requires the remote API's ID and the client's ID"); return false; } return $remote_api->client_change_password($client_id, $new_password); } Giving as much info as I can. ISPConfig's API (as far as I can tell, since even that documentation is pretty limited (only 1 example with a bit of commentary on the net)) is "something" that listens for remote instructions. Will the above code send those instructions? Assigning the $new_password is not what I'm trying to do at the moment, just getting the code to send that instruction right, since a form of some sort has to be created first to get the new password from the user/admin. The $remote_api in this case should be a function (if that's the right name) to login using the url/user/pass/session_id. I hope I'm making some sense

I bit more info that popped into my mind when I got up and walked away from the pc. cpanel thinks that each client can only have 1 domain (vaguely remember this, code above seems to agree though). ispconfig thinks that each client can have a trillion (well not really, but many) domains. So the best compromise IMHO is to assign the client to the server using blesta's client ID (what I'm manually doing now), instead of a domain, which helps with administration as well.

Been busy all day today, but managed to get a glimse at the cpanel module. I have created this hierarchy: /modules/ /ispconfig/ /apis/ /ispconfig_api.php /language/ /en_us/ /en_us /ispconfig.php /views/ /default/ /manage.pdt ispconfig.php I'm I on the right track so far? Taking a look at /modules/cpanel/apis/cpanel_api.php shows this for adding a new account: /** * Create a cPanel Account * * This function will allow one to create an account, the $acctconf parameter requires that the follow * three associations are defined: * - username * - password * - domain * * Failure to prive these will cause an error to be logged. Any other key/value pairs as defined by the createaccount call * documentation are allowed parameters for this call. * * @param array $acctconf * @return mixed * @link http://docs.cpanel.net/twiki/bin/view/AllDocumentation/AutomationIntegration/CreateAccount XML API Call documentation */ public function createacct($acctconf) { if (!is_array($acctconf)) { error_log("createacct requires that first parameter passed to it is an array"); return false; } if (!isset($acctconf['username']) || !isset($acctconf['password']) || !isset($acctconf['domain'])) { error_log("createacct requires that username, password & domain elements are in the array passed to it"); return false; } return $this->xmlapi_query('createacct', $acctconf); } I changed that to: /** * Add new client * -------------- * Adds a new client. */ public function client_add($client_conf) { if (!is_array($client_conf)) { error_log("client_add requires that first parameter passed to it is an array"); return false; } if (!isset($client_conf['username']) || !isset($client_conf['password']) || !isset($client_conf['domain'])) { error_log("client_add requires that username, password & domain elements are in the array passed to it"); return false; } return $this->remoteapi_query('client_add', $client_conf); } In the ispconfig download there is /ispconfig/remoting_client/examples/client_add.php which has this: <?php require('soap_config.php'); $client = new SoapClient(null, array('location' => $soap_location, 'uri' => $soap_uri, 'trace' => 1, 'exceptions' => 1)); try { if($session_id = $client->login($username,$password)) { echo 'Logged successfull. Session ID:'.$session_id.'<br />'; } //* Set the function parameters. $reseller_id = 0; // this id has to be 0 if the client shall not be assigned to admin or if the client is a reseller $params = array( 'company_name' => 'awesomecompany', 'contact_name' => 'name', 'customer_no' => '1', 'vat_id' => '1', 'street' => 'fleetstreet', 'zip' => '21337', 'city' => 'london', 'state' => 'bavaria', 'country' => 'GB', 'telephone' => '123456789', 'mobile' => '987654321', 'fax' => '546718293', 'email' => 'e@mail.int', 'internet' => '', 'icq' => '111111111', 'notes' => 'awesome', 'default_mailserver' => 1, 'limit_maildomain' => -1, 'limit_mailbox' => -1, 'limit_mailalias' => -1, 'limit_mailaliasdomain' => -1, 'limit_mailforward' => -1, 'limit_mailcatchall' => -1, 'limit_mailrouting' => 0, 'limit_mailfilter' => -1, 'limit_fetchmail' => -1, 'limit_mailquota' => -1, 'limit_spamfilter_wblist' => 0, 'limit_spamfilter_user' => 0, 'limit_spamfilter_policy' => 1, 'default_webserver' => 1, 'limit_web_ip' => '', 'limit_web_domain' => -1, 'limit_web_quota' => -1, 'web_php_options' => 'no,fast-cgi,cgi,mod,suphp', 'limit_web_subdomain' => -1, 'limit_web_aliasdomain' => -1, 'limit_ftp_user' => -1, 'limit_shell_user' => 0, 'ssh_chroot' => 'no,jailkit,ssh-chroot', 'limit_webdav_user' => 0, 'default_dnsserver' => 1, 'limit_dns_zone' => -1, 'limit_dns_slave_zone' => -1, 'limit_dns_record' => -1, 'default_dbserver' => 1, 'limit_database' => -1, 'limit_cron' => 0, 'limit_cron_type' => 'url', 'limit_cron_frequency' => 5, 'limit_traffic_quota' => -1, 'limit_client' => 0, // If this value is > 0, then the client is a reseller 'parent_client_id' => 0, 'username' => 'guy3', 'password' => 'brush', 'language' => 'en', 'usertheme' => 'default', 'template_master' => 0, 'template_additional' => '', 'created_at' => 0 ); $affected_rows = $client->client_add($session_id, $reseller_id, $params); echo "Client: ".$affected_rows."<br>"; if($client->logout($session_id)) { echo 'Logged out.<br />'; } } catch (SoapFault $e) { echo $client->__getLastResponse(); die('SOAP Error: '.$e->getMessage()); } ?> the soap_config.php file referenced there has this: (I believe this is irrelevant to the add client function I want to implement above, do correct me if I'm wrong (excluding the logging into the API part)) <?php $username = 'admin'; $password = 'admin'; /* $soap_location = 'http://localhost:8080/ispconfig3_3.0.5/interface/web/remote/index.php'; $soap_uri = 'http://localhost:8080/ispconfig3_3.0.5/interface/web/remote/'; */ $soap_location = 'http://192.168.0.105:8080/remote/index.php'; $soap_uri = 'http://192.168.0.105:8080/remote/'; ?> I'm I on the right track, I'm I doing it completely wrong...? Please spare a light for a blind man (you could say I'm completely and utterly blind, always hated programming)

Hi all, Just pushed that pay now button for a blesta license . I would like to develop/help develop a blesta module for interfacing with the ISPConfig control panel. If anyone wishes to help/take over since I'm not a module developer, please download ISPConfig here. Extract the .gz file, and go into the ispconfig folder, then into remote_client. In there, there is documentation for interfacing with the server's api (open index.html in your browser), as well as examples for most (all?) functions. What I need now is some pointers/hints on how to get started with the module. Eg: make this file, edit it to contain such and such, ispconfig's commands go there, test. Perhaps it might help if the cpanel module is analyzed since they are both control panels, with pressumably similar APIs. Functions the module must perform: 1) Create an admin page for editing necessary module information. This must include a server list and API access credentials for each server (access url, remote user and password, off the top of my head). Securely storing these in a secure place is a bonus (read necessity). 2)The module must be able to be told to assign new clients on this specific server (out of the list mentioned above), unless otherwise told not to, eg. server capacity is reached. Simple maximum clients = X for server Z is enough I think (in which case a new server must be selected from the list either automatically or manually by the admin). 3)Must be able to automatically provision new clients on the server, with a selected template used (eg a client selects X hosting package instead of Y during ordering, client is created on server with the template X in use (ISPConfig supports client templates)). 4)Must be able to poll the server in some way for information about the client/package (for billing addon bandwidth for example). 4)Must be able to automatically suspend the client on the server if the client did not pay. 5)Must be able to create/edit email templates. This will be helpful for the typical hosting provider scenario. Client selects package X, pays, account is created on the hosting server, client gets emailed with further instructions, eg here's your control panel, login using such and such. 6)OPTIONALLY (but extremely helpful) it must be able to administer the control panel account from within blesta. Eg: client logs in to your billing page, selects create new website, enters the domain/ftp/email/database info, and those get provissioned on the server). I'm open to other user's input on required functions. And reminding everyone I'm not a developer but a sysadmin, so a bit of help getting started is required. Thank you

Made changes to the client login page, the structure file, the css files (both for admin and clients). It's a long list of changes. Happy to provide feedback. It's what makes us all better

Just when I finished editing the theme files . Anyone knows how to upgrade without manually diffing files for changes? Perhaps some steps need to be implemented in blesta to preserve files, or perhaps make a themes folder to keep the customised theme, that does not get overriden with an upgrade. Personally I like the folder approach, since I'm planning on merging css files (I don't like how the colors are separated from the rest of the attributes and would like to keep them all in a single css file for easier management). From my point of use (point of view), I have made numerous changes to the themeing files and blesta cannot be easily distinguished from the looks of the rest of the website. Don't want to loose those, since what I've read so far about an upgrade, says to override all the files with the new unzipped files. Can some developers look into the themes? What would work best for me and others customizing the look would be: Settings>Company>Themes> Selecting a theme. Each theme should be kept in a different folder, and the upgrade process should ignore user configured themes. What should be in that folder is css files, header and footer (for changing the default header and footer contents). Blesta should then be clever enough to include those files when the page rendering happens. Yes I know that sometimes something could be fixed in the default css/header/footer files and the change needs to be carried over to the customized theme. A security fix (IMHO) should be applied immediatedly, hence the separated files, so the upgrade is something that needs to be installed ASAP. A broken border-radius for example (just saying) can then be looked after in the website's administrator's spare time. A security fix that needs to be installed ASAP and takes down the entire look/formating of the website is not something that will work long term though, so (IMHO) we need a way to preserve the looks and at the same time allowing for the speedy core files upgrade. I hope I'm making sense, if anyone can add anything to this post, please do. If I completely missed something about the upgrade process, please let me know. Thanks all for your time. So far evaluation is going very well, and I'm just a few steps from hitting that order button for a blesta license. After that's done, I'll begin gathering information to make an ispconfig module, since that's what I'm using instead of cpanel. If anyone wishes to take over that task while I'm done mumbling, here's a link to an API example: http://www.howtoforge.com/how-to-create-remote-api-scripts-for-ispconfig-3. Edit: for now I'll be applying the 3.0.0-3.0.4 patch and keep my fingers crossed. Then I'll have to redo my changes documenting each and everyone of them in a file for the future. Edit2: patch seems to have preserved my formatting. Hooray!!! the only things that got changed is the header and footer. Easy fixes so far. Will poke around and see if anything else got changed in ways that it shouldn't.

Nope, 1.0.9 comes with 3.0.3. Taken directly from the unzipped 3.0.3. Success!!! bug is fixed. The domain field is correctly validated, and a message pops up if it is empty. If a domain is written into the box, then it shows up on the next step. Thank you all for your time. Another small step for man, a giant leap for mankind EDIT: (trigger happy post) For those in the same situation as me, don't forget to go back to packages>browse and edit all your packages to point to the correct module "thingy" (service). Otherwise nothing happens when you click select on the order form. Assuming this is due to the module being uninstalled. Easy fix.

Uninstalled the universal module, and when going to modules > available, the version listed is 1.0.8. I think the validation bug is irrelevant, since I cannot upgrade to the latest module version to verify if the bug is fixed or not. As a reminder, my blesta version shows up as 3.0.3 EDIT: Manually uploaded public_html/components/modules/universal_module overwritting the files on the server. Version 1.0.9 showed up correctly. Installed, will test and report back.

Does uninstalling and reinstalling remove any packages/services or is it safe to uninstall and reinstall to test if it upgrades correctly?

Not my fault: Blesta © 2007-2013, Phillips Data, Inc. Licensed to X Installed Version 3.0.3 Universal module has been upgraded through the web gui (the upgrade button came up instead of the manage button, see my post above). Thought that was supposed to upgrade it. Exactly. Adding a rule in the package section, with the input validation, requires me as the admin logged in to enter the hostname when manually editing the package. When "ordering" the product as a client, no validation happens.

Version 1.0.8

This bug has not been fixed in 3.0.3. I've encountered it today while adding a product. Universal module service options: Label: Enter your domain Name: cliententerdomain Type: text Required: Yes Encrypt: Yes Values: empty Input rule validation: {"cliententerdomain":{ "valid":{ "rule":"isEmpty","negate":true,"message":"Domain cannot be empty. We wouldn't know how to set up your product correctly." } } } Additional info: tried changing the field name (see documentation) to service_field_1, uni_cliententerdomain, uni_service_field_1. (uni_ comes from viewing the source of the page. That's the actual name given to the variable) Did not check this before manually applying the patch for the empty order page (as documented in http://www.blesta.com/forums/index.php?/topic/1086-oh-noes-universal-module/#entry8899). Universal module came up with an upgrade button after applying the patch, clicked upgrade then went on with configuring the product. Input validation should happen as soon as you hit the Continue button, after selecting the package required, to prevent the client having to redo this step at the end of checkout. "Proper" ordering flow: Select package, click select, forget to input domain, click continue, message that the domain is required pops up, client enters domain, click continue, enter customer/payment info. Setting the options as the package options instead of the service options (need to change the text on the page to admin options, client options, it's too confusing as it is now) works OK. The validation happens correctly when trying it from the admin site.

You are hired! Thanks to all for your answers, I'll begin evaluation ASAP since all my questions have been answered so far. A couple more questions, if it's not a problem. 11) Any firm date on when the 30% off when migrating ends? Last I've seen was it ends when it ends. Will there be any alert before the offer expires? 12) Is the "Blesta Owned Lifetime" ($500) a branded or unbranded license? Meaning powered by and copyright can be removed? I can't see anything relating to this on the order page. Thanks again