Create Service After Provision

[Virtovo]

I've got an issue with the SousVM module for a specific client whereby Blesta will not provision a service no matter what.  As usual with Blesta there are no error messages or otherwise that could be used to debug the issue.  The only steps I know which led to the issue (although not confirmed as the cause) are:

 

Client signed up but met reject score on Maxmind so was not allowed to sign up

Client then met review score on Maxmind and order was set to 'for review'

Service was activated out of 'for review'

Client was sent an email which thought they had an existing solusVM login as it matched on if service.solusvm_password and sent a username (which didn't exist in SolusVM).

 

I've got a ticket open with Blesta, they took the time to move it down to medium priority but did not fashion it with a reply.

 

As a quick solution in case this problem occurs again (I've already lost a high profile client as a direct result of this), does anyone know how to provision a service after it has been created.  There is no 'create' option in the service actions.  Failing this, is there a way to manually link a VPS to a service in Blesta.  This can be achieved in every other billing system I've used by simply assigning the vserverID to the service.

 

I really want to like Blesta; however it's currently issue after issue at the moment and pretty much 0 useful info/errors are given when things do not work.  

[Virtovo]

Please close this thread.  I'll deal with the matter in the support ticket.  Four days with no response on an issue that is losing us clients is not great.  The Blesta team seem like really nice guys; however, the level of support I've received on issues from Blesta has paled in comparison to that offered by WHMCS or Hostbill and that really is saying something.

[Tyson]

I've got an issue with the SousVM module for a specific client whereby Blesta will not provision a service no matter what.  As usual with Blesta there are no error messages or otherwise that could be used to debug the issue.  The only steps I know which led to the issue (although not confirmed as the cause) are:

 

Client signed up but met reject score on Maxmind so was not allowed to sign up

Client then met review score on Maxmind and order was set to 'for review'

Service was activated out of 'for review'

Client was sent an email which thought they had an existing solusVM login as it matched on if service.solusvm_password and sent a username (which didn't exist in SolusVM).

 

Was the service provisioned automatically by cron, or manually by you in Blesta? Did you uncheck the "Provision using the SolusVM module" checkbox if you provisioned it manually? What is in the module log?

 

If there was an error, the service should not have been activated. However, if you provisioned the service manually, not through the SolusVM module, then the service would have only been setup in Blesta, and SolusVM fields would be unknown, like the virtual server ID and password.

 

In that case, a simple

{% if service.solusvm_password %} ... {% else %} ... {% endif %}

would always execute the else statement in the email template because no password is known.

 

The SolusVM module makes use of serveral fields besides the virtual server ID, so you may need to set more than just that field. You could either re-create the service altogether, provisioning it successfully through SolusVM, or update the database service fields.

 

To update the database service fields, search for the service by ID under the `service_fields` table. The service ID is the integer at the end of the URL when you go to manage the service in Blesta. Then you can set the `service_field`.`value` for each key as appropriate.

 

All of the available fields are described under the Welcome Email documentation, but the most important ones would be: solusvm_vserver_id, solusvm_username, solusvm_type, solusvm_template, solusvm_plan, solusvm_node, solusvm_main_ip_address, solusvm_hostname.

[Virtovo]

Was the service provisioned automatically by cron, or manually by you in Blesta? Did you uncheck the "Provision using the SolusVM module" checkbox if you provisioned it manually? What is in the module log?

 

If there was an error, the service should not have been activated. However, if you provisioned the service manually, not through the SolusVM module, then the service would have only been setup in Blesta, and SolusVM fields would be unknown, like the virtual server ID and password.

 

In that case, a simple

{% if service.solusvm_password %} ... {% else %} ... {% endif %}

would always execute the else statement in the email template because no password is known.

 

The SolusVM module makes use of serveral fields besides the virtual server ID, so you may need to set more than just that field. You could either re-create the service altogether, provisioning it successfully through SolusVM, or update the database service fields.

 

To update the database service fields, search for the service by ID under the `service_fields` table. The service ID is the integer at the end of the URL when you go to manage the service in Blesta. Then you can set the `service_field`.`value` for each key as appropriate.

 

All of the available fields are described under the Welcome Email documentation, but the most important ones would be: solusvm_vserver_id, solusvm_username, solusvm_type, solusvm_template, solusvm_plan, solusvm_node, solusvm_main_ip_address, solusvm_hostname.

 

Hello there,

 

Thanks for the reply.  I did include some additional info in the ticket which explained things a little better; however it's unanswered for nearly 48 hours.  I included extracts from the module log in the ticket.

 

To clarify some points:

 

1) It was provisioned from on hold using the solusVM module.

 

2) The client received an email with username and password password contained within (for an account which did not exist)

 

3) Repeated attempts of provisioning an order for this client all resulted in the same outcome

 

4) I'm not really liking the idea of editing the database directly to work around problems like this.  It was needed for the ticket cron import issue I faced and also now this.  Not all staff can be given access to the MySQL database directly so this is a massive inconvenience.  Is there a reason why these linking fields are not available within Blesta itself?

 

5) Have you considered having some way to search or filter the module log?  The solusVM log fills up pretty quickly as it adds an entry everytime the template list is retrieved.  You then have to click on every single entry to see what that entry is.  It's a cumbersome task.

 

I'd like to re-iterate that I really like Blesta; however many things feel like I am seriously swimming against the current.  

[Tyson]

1) It was provisioned from on hold using the solusVM module.

Does this mean an admin activated it manually through Blesta, or the cron provisioned it after the service had been paid for?

 

 

 

 

2) The client received an email with username and password password contained within (for an account which did not exist)

 

3) Repeated attempts of provisioning an order for this client all resulted in the same outcome

 

This sounds like a manual service provision that only added the service to Blesta, and did not attempt to provision the service on SolusVM. Can you confirm that you are activating the service with "Provision using the SolusVM module" checked?

 

4) I'm not really liking the idea of editing the database directly to work around problems like this.  It was needed for the ticket cron import issue I faced and also now this.  Not all staff can be given access to the MySQL database directly so this is a massive inconvenience.  Is there a reason why these linking fields are not available within Blesta itself?

Unfortunately for some issues, correcting or debugging them cannot be accomplished through the user interface. The reason all of the service fields are not available for edit in the admin interface is because they may pose serious security risks. For example, allowing an admin to set the virtual server ID for the service from the interface may solve the problem you're having, but if they enter the wrong ID, such as for someone else's virtual server, then that client now has access to someone else's server. Maybe that is a risk we should let admins undertake to avoid the problem you're having, but it currently does not work this way.

 

 

 

5) Have you considered having some way to search or filter the module log?  The solusVM log fills up pretty quickly as it adds an entry everytime the template list is retrieved.  You then have to click on every single entry to see what that entry is.  It's a cumbersome task.

Yes, we've considered adding filtering/search options for the logs in a future release. I have the same problem finding certain logs I'm looking for sometimes.

[Virtovo]

 

 

Does this mean an admin activated it manually through Blesta, or the cron provisioned it after the service had been paid for?

 

It was held for review by maxmind.  It needed to be activated out of review, the cron would not pick it up.

 

 

 

This sounds like a manual service provision that only added the service to Blesta, and did not attempt to provision the service on SolusVM. Can you confirm that you are activating the service with "Provision using the SolusVM module" checked?

 

I am 99.9% sure the tick box was checked.  For instance the service has 'use module' ticked under solusVM options on the service page.  I've included some extracts from the Module log which might help inform this further.

 

 

 

Unfortunately for some issues, correcting or debugging them cannot be accomplished through the user interface. The reason all of the service fields are not available for edit in the admin interface is because they may pose serious security risks. For example, allowing an admin to set the virtual server ID for the service from the interface may solve the problem you're having, but if they enter the wrong ID, such as for someone else's virtual server, then that client now has access to someone else's server. Maybe that is a risk we should let admins undertake to avoid the problem you're having, but it currently does not work this way.

 

Although I can appreciate where you are coming from on this point, the alternative you are telling me is to run SQL queries directly on the database.  Which is the lesser of the two evils?  

 

 

 

 

Yes, we've considered adding filtering/search options for the logs in a future release. I have the same problem finding certain logs I'm looking for sometimes.

 

That is awesome news.

 

[Virtovo]

Any ideas?