Jump to content

Module: Multicraft


Tyson

Recommended Posts

UPDATE! This module ships with Blesta 3.3+ Please use the official release.

 

Attached is the Multicraft module for Blesta. You can use this module to provision Minecraft game servers.

 

You may want to take a look at the module documentation for help with configuring the module in Blesta.

 

You can upload the contents of the attached zip to your Blesta installation directory, and then head into Blesta's admin interface to install the module under [settings] -> [Modules] -> [Available].

multicraft_v1.0.0.zip

Link to comment
Share on other sites

IS possible to attach other package to the configurable options ? and altering the price package ?

 

Not sure exactly what you're asking -- configurable options can be added to any package, and can alter the price of the package. But, the Multicraft module actually uses those configurable options to provision Minecraft servers. For example, a configurable option for a Dedicated IP address (which may cost say $3/mo extra), if selected the Minecraft server will be provisioned with the extra IP.

 

It's possible I'm way off and just don't understand your question, so feel free to clarify :D

Link to comment
Share on other sites

i have not make a big profound to the order forms/packages until now .

my question was .

i have package A for , let say 14$ ;

i have package B for , let say 4$ ;

i want to setup order form with package A that have a confugurable option for package B with 0$ as price with out i add two package add ad it as addons .

Link to comment
Share on other sites

i have not make a big profound to the order forms/packages until now .

my question was .

i have package A for , let say 14$ ;

i have package B for , let say 4$ ;

i want to setup order form with package A that have a confugurable option for package B with 0$ as price with out i add two package add ad it as addons .

 

A configurable option cannot result in another package being ordered. What you should do is add Package B to an Addon Package Group who's parent Package Group contains Package A. Then, during checkout, users can select it as an Addon.

Link to comment
Share on other sites

Hello Again

yes i know this , but i'm asking for the price overide with out creating two package .

 

They don't "override" the price so much as alter it. The package has a base price, configurable options, if selected can add to that price.

 

For example:

 

Package A $10

Dedicated IP Address + $3

Extra Disk + $20

Extra RAM + $10

 

Total $43/mo

Link to comment
Share on other sites

Good job on this, I'll try to test it out this weekend and see what other features it should have on there. One that would be nice however not sure if it depends on multicraft itself would be the option to select a map that you want installed on the server from a pre-defined set of maps.

Link to comment
Share on other sites

Could you put the option for a dedicated IP on the package settings page?

I prefer to add dedicated IP to a packager rather then allow them to select the option.

I just went around it and made it a drop down with one option only.

 

Also have the issue where it assigns it to daemon one.

 

I do not have a daemon 1. It does not automatically pick the daemon with the most free memory.

It also does not give it an ip. Dedicated ip is set to 0. In multicraft the default IP is set to the daemon IP.

Link to comment
Share on other sites

If you encounter an issue with the module, you can open a bug report where we can discuss it.

 

If you do not set a daemon ID, nor a dedicated IP, then Multicraft determines how to setup the server, sets the IP, etc., and notifies Blesta of that information. There are some Multicraft configuration files that you may need to update if you're having a problem with starting a server. There may also be an error in the Module Log that can shed some light on possible API-related issues.

Link to comment
Share on other sites

I remember introducing Multicraft to the team back in May/June of 2012!  So glad to see it finally added!! 

 

A bit too late for me to use it now, but perhaps in my next project :)  Will definitely recommend it to industry partners, once it's out of beta.

 

Congratulations all!  :)

 

 

Link to comment
Share on other sites

I remember introducing Multicraft to the team back in May/June of 2012!  So glad to see it finally added!! 

 

A bit too late for me to use it now, but perhaps in my next project :)  Will definitely recommend it to industry partners, once it's out of beta.

 

Congratulations all!   :)

 

It took a while for us to get around to it, unfortunately -- we had lot's to do! The biggest thing that held this back was the addition of configurable options, which allow this module to work as it should.

 

We definitely appreciate any industry recommendations. We think we can do well with GSP's, and have more planned.

Link to comment
Share on other sites

  • 3 weeks later...

Sorry to refresh this older thread however while testing this module today, I have come across a couple concerns:

 

1. Daemon ID setting - The example given for the daemon id setting is based on daemon location. It assumes you only have 1 daemon per location. What if you have 10 daemons in a single location but 8 of them are considered full? You know that, but Blesta and Multicraft don't. There should be options to have multiple daemon IDs belong to one location. For example, setting the dropdown option for the Chicago location to have a value of 1,3,5,7 which Blesta can then choose a daemon ID from that list based on the daemons that have not yet reached a memory threshold. The Multicraft API does allow the ability to view how much memory/RAM is already in use on a daemon.

 

2. IP Management - The module always assigns the main daemon IP to a new Minecraft server and increments the port by 1 unless the dedicated IP option is chosen. Instead, if the dedicated IP option isn't chosen, it should choose a random IP from an IP pool on the specified daemon ID and a random port between 10000 - 65000.

 

Minecraft hosting is huge and these are two issues that would be difficult to fix and make things harder to manage within a company that hosts thousands of servers.

Link to comment
Share on other sites

Sorry to refresh this older thread however while testing this module today, I have come across a couple concerns:

 

1. Daemon ID setting - The example given for the daemon id setting is based on daemon location. It assumes you only have 1 daemon per location. What if you have 10 daemons in a single location but 8 of them are considered full? You know that, but Blesta and Multicraft don't. There should be options to have multiple daemon IDs belong to one location. For example, setting the dropdown option for the Chicago location to have a value of 1,3,5,7 which Blesta can then choose a daemon ID from that list based on the daemons that have not yet reached a memory threshold. The Multicraft API does allow the ability to view how much memory/RAM is already in use on a daemon.

With configurable options, it would be possible to add multiple Daemon ID's to the config option, ie "1,3,5,7" as the value, but then the module would need to look for that, and parse out the ID's, choosing from one of them to provision. Do you see this as a viable solution? It should be fairly easy to implement.

2. IP Management - The module always assigns the main daemon IP to a new Minecraft server and increments the port by 1 unless the dedicated IP option is chosen. Instead, if the dedicated IP option isn't chosen, it should choose a random IP from an IP pool on the specified daemon ID and a random port between 10000 - 65000.

 

Minecraft hosting is huge and these are two issues that would be difficult to fix and make things harder to manage within a company that hosts thousands of servers.

I believe Multicraft determines the port number to use, so a couple questions for you as I try to understand the reasoning behind this.

1. Is there a benefit for selecting a random port number between 10,000 and 65,000, other than making it difficult for someone to guess what port the minecraft servers are on without doing a port scan?

2. With 50,000+ possible port numbers, why would additional IP addresses be used on each Daemon ID for shared (not-dedicated) purposes?

Thanks! We appreciate your feedback.

Link to comment
Share on other sites

With configurable options, it would be possible to add multiple Daemon ID's to the config option, ie "1,3,5,7" as the value, but then the module would need to look for that, and parse out the ID's, choosing from one of them to provision. Do you see this as a viable solution? It should be fairly easy to implement.

 

Yes, that would be appropriate. Once the module gets the comma-separated list, it could either cycle through each ID in order or check the used memory on each ID and create the new server on the daemon with the least amount used.

 

 

I believe Multicraft determines the port number to use, so a couple questions for you as I try to understand the reasoning behind this.

1. Is there a benefit for selecting a random port number between 10,000 and 65,000, other than making it difficult for someone to guess what port the minecraft servers are on without doing a port scan?

2. With 50,000+ possible port numbers, why would additional IP addresses be used on each Daemon ID for shared (not-dedicated) purposes?

 

1. Some Minecraft server owners do not like people being able to go through each port incrementally from 25565 and being able to find their server. It's more of a customer concern than of an issue with the module.

 

2. From a business perspective, it is not smart to put more than a few Minecraft servers on a single IP address. DDoS attacks are a common issue in gaming, even more so in Minecraft. With tens or hundreds of servers on the same IP, any malicious network traffic targeted for that IP could bring all those customers offline. It isn't just network attacks either - it could also be some rare routing issue that affects a single IP or a small amount of addresses. In any case, distribution is key.

 

Also, I just found another issue. The module automatically creates an account on Multicraft (and FTP) for the new server but the password is never given. It is not the same as the client's password on Blesta, which it could be, and I have not found where to find the password at all. The password is required to login to FTP via Multicraft which is not automatically done when logging in to Multicraft from Blesta.

Link to comment
Share on other sites

I added the multiple Daemon ID improvement to CORE-1329. I'd like to discuss the multiple IP address / port provisioning recommendations with Tyson before I create a task on that. If anyone has anything to add, please chime in.

 

As for the Multicraft account (And FTP), the account is created when the first server is provisioned for the account, and this email should contain the login details for Multicraft. Subsequent servers are added to the same account, and the Multicraft login details are unknown by the service so they are not included.

 

This can be handled in the welcome email by using a conditional statement or a note to say that it's the same login as the previous servers.

 

We are working on a feature where modules may share information between services, and I hope to have this in 3.3. This would allow a 2nd, 3rd, etc server to include the same login details as the first.

Link to comment
Share on other sites

I added the multiple Daemon ID improvement to CORE-1329. I'd like to discuss the multiple IP address / port provisioning recommendations with Tyson before I create a task on that. If anyone has anything to add, please chime in.

 

As for the Multicraft account (And FTP), the account is created when the first server is provisioned for the account, and this email should contain the login details for Multicraft. Subsequent servers are added to the same account, and the Multicraft login details are unknown by the service so they are not included.

 

This can be handled in the welcome email by using a conditional statement or a note to say that it's the same login as the previous servers.

 

We are working on a feature where modules may share information between services, and I hope to have this in 3.3. This would allow a 2nd, 3rd, etc server to include the same login details as the first.

 

Thank you for the attention. I can't wait until this module is out of beta and completed. The client area controls and management functions are fantastic!

 

EDIT: It would also be nice if Tyson's thoughts on the IP / port provisioning recommendations would be updated here.

Link to comment
Share on other sites

Another idea that just came to mind for the value of the location configurable option could be a JSON list of daemon IDs and arbitrary names that are displayed to the client. Right now, after the service is setup, the client sees "Location: 1" in the client area. Just to make it a little more intuitive, it could say "Location: Chicago, IL, USA" or whatever value is chosen. The JSON value for the Chicago location in the dropdown would then be something like:

{
"1": "Chicago, IL, USA",
"3": "Chicago, IL, USA",
"5": "Chicago, IL, USA",
"7": "Chicago, IL, USA"
}

And each consecutive location in the dropdown would follow a similar format.

Link to comment
Share on other sites

Another idea that just came to mind for the value of the location configurable option could be a JSON list of daemon IDs and arbitrary names that are displayed to the client. Right now, after the service is setup, the client sees "Location: 1" in the client area. Just to make it a little more intuitive, it could say "Location: Chicago, IL, USA" or whatever value is chosen. The JSON value for the Chicago location in the dropdown would then be something like:

{
"1": "Chicago, IL, USA",
"3": "Chicago, IL, USA",
"5": "Chicago, IL, USA",
"7": "Chicago, IL, USA"
}

And each consecutive location in the dropdown would follow a similar format.

 

Or perhaps where configurable options are displayed, the name of the field should be shown instead for drop downs. This has more to do with the configurable options than the multicraft module so we'll need to evaluate.

 

The result would be as you describe, showing the friendly location name rather than the Daemon ID, but the question is whether this is an acceptable solution across various other modules and uses of configurable options. I suspect it is.

Link to comment
Share on other sites

After discussing with Cody, I've added task CORE-1330 to address the display value for dropdown, checkbox, and radio fields within the client area. In these cases, the name and not the value should be displayed. This will correct the issue you describe where the Daemon ID is displayed, rather than the location name. It's a change to the core, and should be included in 3.2.2 (If there is one), and 3.3.0.

Link to comment
Share on other sites

Sorry to refresh this older thread however while testing this module today, I have come across a couple concerns:

 

1. Daemon ID setting - The example given for the daemon id setting is based on daemon location. It assumes you only have 1 daemon per location. What if you have 10 daemons in a single location but 8 of them are considered full? You know that, but Blesta and Multicraft don't. There should be options to have multiple daemon IDs belong to one location. For example, setting the dropdown option for the Chicago location to have a value of 1,3,5,7 which Blesta can then choose a daemon ID from that list based on the daemons that have not yet reached a memory threshold. The Multicraft API does allow the ability to view how much memory/RAM is already in use on a daemon.

 

2. IP Management - The module always assigns the main daemon IP to a new Minecraft server and increments the port by 1 unless the dedicated IP option is chosen. Instead, if the dedicated IP option isn't chosen, it should choose a random IP from an IP pool on the specified daemon ID and a random port between 10000 - 65000.

 

Minecraft hosting is huge and these are two issues that would be difficult to fix and make things harder to manage within a company that hosts thousands of servers.

 

 

Allowing multiple daemon's per location sounds good to me, although I am less-enthused with comma-separated values. I'd much rather have configurable options support a one-to-many type that can be used for a select/multi-select field, for example, to choose one, or some, of the values. That would accomplish the same thing here, but it would be a completely different task.

 

IP management is a little more complex. I'm not sure how Multicraft chooses what port to use, but I imagine that it starts at one port (from a config setting in the Multicraft panel) and increments from there for additional servers, while checking to make sure the port is unused. This last part is what Blesta and the Multicraft API can't determine. Sure, we could have the module support a hard-coded or user-defined port range for a daemon, then randomly choose a port to use from the range, but that port could be in use by another multicraft server or a different service altogether. I don't see a way for us to determine whether a port we choose is actually available for use. Similarly for daemon IP addresses--it doesn't look like the Multicraft API allows us to determine what IP addresses are available to a daemon.

 

If you take a look at the Multicraft Settings, there is an option to choose how an IP is chosen when a server is created ("All Interfaces (0.0.0.0)", "Daemon IP", "Daemon FTP IP"; default "Daemon IP").

 

I think that Multicraft should allow the kind of IP/port management configuration you suggest, rather than Blesta. All Blesta really needs to tell Multicraft is to "create a server for me" (as it currently does), and the IP:port associated with that server should be determined by Multicraft and your configured settings.

Link to comment
Share on other sites

Allowing multiple daemon's per location sounds good to me, although I am less-enthused with comma-separated values. I'd much rather have configurable options support a one-to-many type that can be used for a select/multi-select field, for example, to choose one, or some, of the values. That would accomplish the same thing here, but it would be a completely different task.

 

The thought crossed my mind as well, but this is a much more complex feature for config options that could be implemented in the future while maintaining backwards compatibility. CORE-1329 solves this for now.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...