fizzyjoe908
-
Posts
12 -
Joined
-
Last visited
Posts posted by fizzyjoe908
-
-
Does Multicraft default to port 25565 if no other servers exist on the IP? Since the default behavior was that it increments the port number, I would assume so. People paying for a dedicated IP address are going to typically expect it to be on the default port.
Multicraft will default to whatever port number is configured as the default port. Multicraft ships with 25565 as the default port but it can be changed.
-
If a user does decide to get the dedicated IP configurable option, how does the module handle that? Does it explicitly run an updateServer API call and set the port to 25565?
-
Currently, coupon code discounts are only applied to a package's base price which is not ideal with certain configurations. Here is why this does not work well for me...
I have a package with a base price of $0.00 per month. The package has several configurable options that increase the price depending on what is chosen. I'm not able to use coupon codes because Blesta thinks the discount is being applied to something that is already free, when it really isn't.
I would appreciate it if coupon codes were applied to the total price of a product with configurable options, not just the base price tag.
-
You have to use .htaccess to rewrite the url and redirect to that folder.
Here is a good article to help you had a rule
here: http://www.addedbytes.com/articles/for-beginners/url-rewriting-for-beginners/If you wat a live chat help, why not use the one we have made that is integrated in blesta? here: http://www.blesta.com/forums/index.php?/topic/1928-blesta-live-chat-rc-104-2%C2%BArc/
Regards,
PV
Thanks for that - solved.
I have tried your live chat plugin however I already have a license for another piece of live chat software which I would prefer to use. For a free alternative though, your plugin is great.
-
I have a quick question about using Blesta with other software.
Blesta has been installed in the root directory of a sub-domain on a cPanel server. For example, the Blesta URL would be my.domain.com. I do have a SSL certificate installed on that sub-domain as well and force HTTPS connections for the entire sub-domain. My issue is that if I want to install any other software, live chat for example, to the my.domain.com sub-domain because it is the only URL with HTTPS in a sub-directory, Blesta doesn't allow it.
Example: installing a live chat software to be accessible via my.domain.com/livechat > that directory may exist however since Blesta handles the URLs, it looks for the URL in regards to itself and returns a 404. Is there a way to get around this via the routes.php file?
-
-
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.
-
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.
-
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.
-
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.
-
How is Blesta with dedicated servers?
More specifically...
1. Does it allow for HTML to be entered into custom product fields?
2. Does it have integrated bandwidth billing via a module to interact with Cacti?
[Rewrite] Proxmox Modules
in Extensions
Posted
I haven't used Blesta's Proxmox module yet but I would love to see some improvements such as these. It seems the current "official" version needs some refinement based on other comments.
+1
EDIT: Off topic, but if anyone can provide screenshots of the client side of the module in action, that'd be awesome!