Paypal, Money and Minecraft Servers - The do's and don'ts to help avoid getting bitten.

February 5, 2013 at 8:26 PMPhonicUK

First off just a little preface: Most of of my advice is based on my subjective experiences with Paypal. I may be entirely incorrect on some of the assumptions I make, so take the following with a few pinches of salt.

So dealing with payments to help with the running costs of a Minecraft server is something that a sizable amount of the community will have come up against at some time or another. Chances are you've read before about server owners being hit with chargebacks or paypal holding onto large sums of money for extended periods of time.

This post is about things you should and should not do as a server owner to help avoid some of the worst problems, and some advice about dealing with common issues you'll come across.

 

Dealing with payment disputes and chargebacks.

One of the common issues the Minecraft community has to deal with is younger players using their parents credit cards to buy benefits on servers without their permission, and then the cardholder invoking a chargeback with their credit card provider, or a dispute on paypal for unauthorized use.

Chargebacks are the bane of everyone who uses Paypal to accept payments. They're extremely difficult to fight, and worse they come with a hefty £14 GBP/~$20 USD fee if you don't win them, even though you're not at fault.

If the cardholder raises the dispute with Paypal you're very lucky. You'll lose the money originally given to you, but that's it. Paypal even refund the fees. For virtual goods there's no seller protection so there is still the problem where someone can donate, then raise a dispute saying it was unauthorized, and get their money back. This doesn't happen often though because paypal will not allow an unauthorized transaction dispute in the particular case of a family member using your card. Hence parents are very likely to just jump straight to the credit card company who will.

This is where things start to really suck. Since you're essentially selling virtual goods, it's almost impossible to prove receipt/delivery to the degree that will satisfy the credit card company. Any which point you're hit by the nasty fees mentioned earlier. 

Now there are some ways to help mitigate this problem:

For larger donations (Over about £20/$30), consider sending a 'thankyou' card, voucher, or something physical to the billing address via recorded delivery. This allows you to prove where the transaction came from, which makes dealing with disputes much much easier. This of course doesn't work if you're handling higher volumes of smaller amounts.

Discourage minors from donating. This is a bit of an issue since they are likely to make up a large amount of your player base. Consider requiring users to register before they can donate and require their age. If they're under 18, require that they provide a signed parental consent form. You can tie their registration to their Minecraft username to prevent someone registering twice once they find out that there is an age restriction.

Now this will cost you perfectly legitimate donations that you might have gotten otherwise due to the extra hassle. So you'll need to carefully consider the balance between income and risk to determine what barriers you're willing to put in peoples way.

 

Don't use the 'D' Word

This is a word you should avoid at all costs, not because it's really that inaccurate - but because it's a very easy way to have your funds frozen.

That word is 'Donation' or 'Donate'.

Paypal and other payment providers get very uptight if you use those words but aren't actually a registered charity or non-profit (Google checkout won't even let you take the payments unless you provide documentation proving you're a non-profit). Yes, the reality is that players are in effect donating towards the upkeep of the server with nothing real in return for it - but avoiding those words will save you a lot of pain. There's also legislation in certain countries that dictates donations have to be refundable within a certain amount of time or if they're over a certain amount - so keeping distanced from that will save you a lot of hurt.

So instead you can call it a "Contribution" or invite users to "Contribute" and give them a rank of "Contributor", and on any websites use the "Pay now" button instead of the "Donate" button to the effect that users are buying access to the "Contributor" rank on your server, along with any benefits you decide to bestow on them for this.

 

Do run your server like a business

This may seem counter intuitive for something that's just meant to be for fun, but it goes a long way to keeping everything manageable. Incoming contributions are your revenue source, the server is an expense, and dealing with payment issues is a cost of business that you need to allow for (see the section earlier on chargebacks).

In this vein you need to keep an eye out on cash flow. If 100% of your incoming revenue is used up the moment your server bill comes in, then you've got a cash flow problem because all it would take is for a single payment to be reversed (or worse, to have a charge back issued on the credit card) then you're immediately out of pocket.

So make sure you've always got a persistent balance available at all times, at least 10% of your monthly revenue should be put to one side each month to allow for either sudden costs that could jeopardize the server or just month-to-month inconsistencies. Just like real life you don't want to be living paycheque-to-paycheque. If you can't afford to do this then you should start either finding new revenue sources, or consider downsizing your server if you're not able/willing to make up the difference out of your own pocket.

Also like a business, look after your 'customers'. Consider rewarding those who donate regularly by sending them real-life gifts (or even just a thank you card) or other benefits to make them feel good about donating and keep them donating. Good will is an asset.

In addition, making your expenses public to your users will help build trust that their money isn't being squandered. Let them see how much your server bill is, and any other costs associated. Transparency is key to building a good relationship with players who are giving you money to run your server.

 

Don't let users buy their way into power

While letting users buy ranks that give them influence over other players is a near sure-fire way to get extra donations, it's also the best way to stop anyone else from donating and increase the number of chargebacks and disputes you get. This may seem really obvious but it's still something that far too many servers try and do.

The reasoning for this is pretty straightforward. It makes it too easy for one user to put themselves in a position where they can abuse other players, which will very quickly reduce your servers population and the number of people willing to contribute financially. Then when you find out that someone has abused their power and you revoke it - you can be reasonably sure that they will file a dispute out of spite.

This shouldn't even need to be a point here. It's suicide for your server. Don't do it.

 

Do keep an eye on the tax situation

This varies a lot from country to country (or even state to state in the US) so I'm not going to talk about this too much. The main thing is that you consult a tax adviser and make yourself familiar with your local tax laws to check what you need to do.

In the UK for example, if you're running the server like a business then you may need to declare yourself as self-employed (in addition to any normal day job you have) and you will likely have to pay taxes on your profits (income minus costs) - you still need to do this even if you don't make any profit. This also means filling in a self-assessment tax at the end of the year to declare your earnings and cost from the business.

Posted in: Minecraft

Tags: , , , ,

Announcing McMyAdmin XS - manage multiple McMyAdmin servers from a single interface.

January 26, 2013 at 8:02 PMPhonicUK

 

McMyAdmin XS allows you to manage multiple McMyAdmin instances from a single web interface. Like McMyAdmin it is entirely self contained with everything it needs to operate. You will be able to:

  • View average CPU+RAM usage across all monitored servers
  • Group servers into arbitrary categories (for example, you could group all the servers on a single physical machine together)
  • Perform mass operations such as restarts or updates across either all servers, or all servers in a categories.
  • View an individual servers panel from within the same interface to access all of that servers settings.
  • Auto-add any existing Pro servers by supplying your McMyAdmin Pro licence key.
  • Auto-add servers by scanning a subnet for instances (Only available to McMyAdmin Enterprise users).
A few notes about the restrictions surrounding McMyAdmin XS:
  • 32-bit systems are entirely unsupported. McMyAdmin XS will not start on any 32 bit system.
  • McMyAdmin XS will not permit running as root/administrator. It must be run as a restricted user.
  • McMyAdmin Personal servers cannot be managed via McMyAdmin XS. Only McMyAdmin Pro and Enterprise servers may be managed.
Like McMyAdmin itself, McMyAdmin XS includes a scheduler. It will allows you to schedule certain tasks across all managed servers.
 
McMyAdmin XS will be made freely available to all McMyAdmin Pro/Enterprise users.
 
Screenshots and further details to follow.

Posted in: McMyAdmin | McMyAdmin XS

Tags:

The development principals behind McMyAdmin.

December 24, 2012 at 2:54 PMPhonicUK

I'm often asked how I decide to do things in McMyAdmin, or why I chose to implement some things or not others. So I'm going to try and give a little insight into how I do things or why I do things a certain way.

So these are some of the principles and ideas behind developing McMyAdmin:

"If users are hand-editing configuration files as part of day-to-day administration, you are doing something wrong".

Bare in mind that the context for this is in terms of your average user. Not a seasoned server administrator, but someone who doesn't know their FTP from their SCP and doesn't have a clue what a public and private key are.

It's quite a basic idea when it comes down to it - keep things simple. But this has several implications. What do you do when there is a configuration structure that doesn't translate well into a graphical interface?

What this usually means is that certain functionality is omitted in order to keep the user interface simple. Take the Users and Groups management for example, there is no per-user management at the moment. Why? Well you get the same result by creating a single group just for that one user, and it keeps the user interface and mental model very simple. Users belong to groups, and groups determine what the members of that group can and can't do. In addition it translates well into most other permission models relatively easily.

Similarly McMyAdmin deliberately lacks a file editor at the moment. I could at any moment put in a file browser (with safety restrictions to only allow editing of configuration files, etc) with a basic text editor, but for anyone but an experienced user this would deliver a very poor user experience when compared to the rest of McMyAdmin. Everywhere you look in McMyAdmin there are small indications about what something does. If you look at the settings for example each setting has a small description next to it explaining what the setting does, and it is impossible to give a 'wrong' value (since you're usually just picking from a predefined set of values). A 'dumb' text editor however leaves the user with no clue what is expected of them. In addition users who are advanced enough to know how to manage plain-text configuration files by hand are often quite happy to do so outside of the web interface (via SFTP/SCP).

In an ideal world, plugins/mods could include a meta-configuration file that specifies the format and acceptable values for a configuration file that a UI can be automatically derived from (and the feasibility of this is being investigated) but this does have an interesting set of challenges.

"Keeping 95% of your users very happy is more important than keeping 100% of your users marginally happy".

If you are but a mere mortal, time is a finite resource. So making sure that it's being used optimally is very important in the world of software development. In terms of McMyAdmin development what this translates to is having fewer features by only implementing those that the majority of users would use, but making sure they are well presented and thoroughly polished. Adding more features that very few users would use means less time making sure existing features are well rounded and pleasant to use.

Of course this comes with some trade offs. Power users would likely be more tolerant of features being slightly rough around the edges and would accept that if it meant getting an interesting new feature, but sometimes the cost of implementing a feature only used by a small number of users makes it uneconomical. 

Sometimes however what happens is the feature appears much much later, with many alterations to the original idea in order to make it user friendly and something that feels pleasant to use. For example the new MCMA scheduler that allows tasks to be executed in response to certain events is very simple to use and allows for a lot of flexibility, but it went though many iterations before something usable came out as the end result.

"Consistency is key"

One of the things I'm often asked is why some settings from the server.properties file (like the server IP and port) are omitted from the web interface. The answer of course is for the hosting companies who don't want users to be trying to mess around with those settings. I'm then subsequently asked why I don't allow those settings normally and just hide them for those on hosting companies.

The issue here is consistency. If a user uses McMyAdmin locally or on a server to which they have full access and sees what can be done via the web interface, they would have a poor user experience if they used McMyAdmin on a managed host and found that certain features weren't there. This doesn't apply quite so much to the server IP and port since those are usually things that you set once and never need to touch again, but the idea is the same - keep things as similar as possible between different versions so that users have a consistent experience no matter what environment they use MCMA in.

There are a few exceptions to this of course, but with the sole exception of server sleeping (hosting providers can force sleeping to be enabled and disable the ability to turn it off) they are features that you never actually see in the web interface (things like using LDAP authentication)

Questions from Visitors

Ben asks:

"Couldn't you put in a Advanced mode in the panel which does allow you to go more in depth with plugin configs?"

Well Ben, yes I could. But I don't for a moment think that 'normal' users would be discouraged from going and trying to use it and possibly making mistakes that negatively impact their server. Warnings don't go too far except to be a 'I told you so' point after the user has done something daft - for example the Permissions exporter setting gives you a massive full screen warning telling the user that their data is about to be overwritten and to take a backup if they want to keep it, and some still fail to do so only to be made to look really silly when you point out they were warned.

There is also the issue again of consistency. Hosting providers would almost certainly disable any advanced mode to keep support costs in check, so it'd deliver a poor experience to find that certain features were only sometimes available.

LACDH asks:

"So basically it's your way or the highway?"

That's a slightly blunt way of looking at it but it's parly true. I ultimately decide what goes into McMyAdmin and how, although Enterprise providers get a very heavy say in terms of features they need to run their businesses effectively.

But again extensions allow you to add things that I either haven't thought of, or have for whatever reason decided not to add (yet).

Jimmy asks:

"I heard previously that MCMA will support multi-world backups. I've noticed that this hasn't been implemented yet. Is there something you're waiting on or another thing that's preventing this feature from being implemented?"

It is indeed getting it. It has been slow because it's been tricky to come up with a model for how users will configure multiple worlds. Multi-world support in McMyAdmin also includes support for permissions exporting and not just backups so that's been the bottleneck. I've been reluctant to add one but not the other due to user expectations.

The initial approach was to let users add worlds, then they'd add groups to the worlds, and users to the groups. The problem with this was it meant duplicating identical groups for different worlds too often and it was very laborious.

What I've settled for instead is that when you're editing a group you get to specify which worlds it's going to be applied to with a list of tick boxes for each world configured, and MCMA will automatically handle any configuration duplication as necessary to make it work. It's a tad tricky under the hood but it gives a very nice end-user experience.

 

If you have any more questions about why I decide to do things a certain way, please feel free to post a comment and I'll update this post with as good an answer as I can manage.

Posted in: McMyAdmin

Tags: ,

Why the Minecraft community picking YAML as the standard configuration file format was a mistake.

December 8, 2012 at 8:13 PMPhonicUK

This is a mixture of opinion and rant about why YAML is not well suited for the way the Minecraft community uses it, and how bad plugin developers are making the problem worse.

YAML (Yet Another Markup Language) is a relatively new markup language. It's goal is to be human friendly way to serialize data. With YAML you can represent a piece of data that can be understood easily by a piece of software and also easily readable by a human. As something for humans to write however, it's not so great.

Compare the following three snippets:

1)

Joe:
    interests: [video games, movies]
    full name: Joe Bloggs
    age: 25

2)

Joe:
    interests: 
       - 'video games'
       - 'movies'
    'full name': 'Joe Bloggs'
    age: 25

3)

{
  "Joe": {
    "interests": [
      "video games", 
      "movies"
    ], 
    "age": 25, 
    "full name": "Joe Bloggs"
  }
}

So right away there are a number of problems:

  • All three of them represent exactly the same data, yet they look very different. A YAML parser will give the exact same result for all 3 of them.
  • You can't tell just by looking at it whether or not I used tabs or spaces unless you're using a text editor which specifically highlights the difference.
  • You can't mix-and-match certain styles in the same document, even though they may look very similar.
The keen eyed among you will notice that #3 is also valid JSON as well as YAML. Also note that in example #2, you can increase the amount of indentation for Joe's interests to any amount you like, and it's absolutely fine as long as they are both the same. The single quotes are also entirely optional, you could have 'video games' with quotes and movies without quotes and it'd be perfectly valid.
 
The problem is that with so much variation and style, writing proper YAML can get tricky very quickly, especially for larger documents. With something like XML it's harder to go wrong as the format is much more rigid.
 
Largely the community as a whole has settled on the 2nd style shown, and you'd think that'd be the end of it.
 
The remaining problems are not so much down to YAML, but the behaviour of Minecraft plugin developers.
 
A number of plugins, instead of using a full YAML parser - instead have their own parser that only works with a very specific style. They are no longer using YAML but merely a extremely restricted subset.
 
The following are the kind of bad behaviours exhibited by some plugins:
 
  • Mandating certain levels of indentation (2/4 spaces) even though the YAML spec doesn't care as long as it's consistent within the document.
  • Failing for lists if they either do or don't have enclosing single quotes (even though it's valid regardless)
  • Not supporting the square bracket syntax for lists (as seen in example #1)
  • Insisting that strings either don't or do have single quotes around them, despite the spec allowing either (or even for you to mix freely, as you may need to quote integer values that are meant to be strings, but not something that is definitely a string)
  • Requiring that elements are in a certain order (swapping around the age and full name for example causing the plugin to crash)
YAML is a very flexible format, deliberately so because it's made for humans. Yet some plugin developers feel the need to completely throw that out the window.
 
If a more rigid format like XML was used then it seems less likely that developers would be trying to write poor implementations based on the subset of YAML they happen to like.

Posted in: Minecraft | Servers

Tags:

Things that suck about McMyAdmin right now, and what's being done about them.

November 13, 2012 at 3:37 PMPhonicUK

I would be a very poor developer if I didn't acknowledge that my software has it's weaknesses, because unless as a developer you are aware of your software's shortcomings you can never improve upon them.

So here are the areas that I think most urgently need the most improvement, and what I intend to do about it:

Backups

While only being able to backup the main world was fine in McMyAdmin's early days with vanilla servers, it has become woefully inadequate for most users today.

So to sort this, a whole new backup system is being built for use in McMyAdmin 2.4. It will be able to:

  • Selectively backup and restore multiple worlds (you could back up all worlds, but only restore 1 if you wished).
  • Backup and restore your McMyAdmin permissions configuration.
  • Backup and restore all of your plugins and their configuration data.
The new backup format contains an archive manifest detailing what it contains, as well as information such a unique identifier, its name and when it was taken.
 
While initially these will only be full backups, the new format allows for incremental backups by tracking which backup ID it was based on. This functionality will be added down the line after 2.4.
 

Multiple world Support

Before even getting to user added worlds, the standard game has 3 worlds - the main world, the nether and the end. McMyAdmin needs to be better aware of all of these, plus user added worlds.

So starting with McMyAdmin 2.4 - you'll be able to:

  • Select which worlds will be included in automatic backups
  • Select which worlds will be available for permissions exporting
  • Automatically populate McMyAdmin with new worlds
McMyAdmin won't be trying to manage multiworld plugins for you, but it will detect worlds as you create and remove them.
 

Documentation

Arguably, the best software doesn't require documentation. It should be so intuitive and simple that the user understands how everything works just by playing with it.

Of course this is something of a pipe dream, some concepts such as handling permissions or some advanced scheduling mechanisms require some explanation, and forums do not constitute documentation.

So McMyAdmin 2.5 will be getting a new in-panel help mechanism to explain new concepts to the user, in addition to this a new 'welcome' guide will be made available to new users to help them get started faster.

 

Of course if there's something you think really sucks and would like to know what I plan to do about it, leave a comment! I'll try and address as many as I can.

Posted in: McMyAdmin | Minecraft

Tags:

Mandatory McMyAdmin Update

October 27, 2012 at 10:25 PMPhonicUK

The SSL certificate that McMyAdmin uses to securely communicate with the McMyAdmin licencing and management servers has been changed (as it has been recently renewed). McMyAdmin verifies the certificate used to ensure communications aren't intercepted and to prevent a man-in-the-middle-attack.

Versions of McMyAdmin older than 2.2.4.4 do not have information about the new certificate, and as such will not be able to communicate with the management servers.

Because of this, all versions of McMyAdmin prior to 2.2.4.4 will be forcibly updated on the 1st of December 2012 to the latest version at that time.

It is strongly advised that you update to 2.2.4.4 (or newer as applicable) as soon as possible to avoid being caught short by the update.

Apologies for any inconvenience caused.

Posted in: McMyAdmin

Tags:

Why the official modding API will be the best thing to ever happen to the Minecraft community.

October 25, 2012 at 10:13 AMPhonicUK

"Minecraft Community" is a slight misnomer, in practice Minecraft players are fragmented into a large number of different communities.

While there are lots of splits between different play styles (RP, PvP, PvE, etc) - the real point of division is between those using the Official server, CraftBukkit, Spout, Forge, and any other number of 3rd party modifications and servers. And this causes a number of problems:

Keeping up-to-date

First is the issue that all server administrators are familiar with whereby mods can take considerable time to be updated after the release of the official server. This means frustrated players who want to use new features or see other improvements and bug fixes. The demand from players pushes server admins to use buggy and unstable versions of mods that aren't ready yet. Worse yet, the demand from server admins on the mod developers to get things done quickly runs a higher risk of lower quality code.

Having the large majority of people using a single, stable, and centrally managed API sidesteps all of this. Of course 3rd party mods are pretty unlikely to disappear entirely, but with any luck they will be the exception - not the norm.

Being locked into a single mod

If you've set up a server and a community around a particular mod, switching from that is a lot of effort. At the very least you've got to find equivalent plugins to keep all of your existing functionality, and at the worst you end up with less than you started off with. Having all extra functionality implemented as plugins instead of as a completely different flavor of the server prevents this entirely, allowing you to swap out functionality much more easily.

Fragmentation of skill

The fragmentation within the community means that the skill pool available for interesting new plugins is divided, since developers on the large prefer to write plugins for a single mod. By having everyone on the same book, there will hopefully be a greater number of high quality plugins available.

Dwindling interest in the game

It's been a long time since Minecraft has had any kind of 'major' development - and while the modding community has managed to largely keep the ball rolling, it only has so much momentum but its effectiveness is dimished by a fragmented community. If you're starting a new public server, building up a decent sized and regular community is a challenge. Major new functionality with lots of potential rekindles interest and gets people playing again.

 

It's not all sunshine and roses though, the community is going to have a set of interesting challenges in its way, which I shall detail in a separate article.

Posted in: Minecraft

Tags: , ,

Debunking Common McMyAdmin Myths

October 6, 2012 at 6:38 PMPhonicUK

I'd like to take a few moments just to talk about some common comments I see regarding McMyAdmin on my travels, ranging from the outdated, to the misinformed.

It is only really made for Windows

While the first versions of McMyAdmin (2 years ago when Minecraft was still in Alpha) were originally built for Windows, it is no longer at all true that McMyAdmin treats Linux as second class.

Once it became apparent that McMyAdmin was going to be a hit, I started focusing on Linux support. First this was just getting McMyAdmin to run in Mono, then dealing with some of the Linux-specific issues that came with this. And while this worked very well there were a number of issues:

  • Server administrators were not happy installing the large Mono framework to use a single application (and with the source weighing in at over 500MB uncompressed, I don't blame them either)
  • Many distributions had outdated versions of Mono in their repositories, resulting in bugs, performance issues and other headaches
  • Compiling a 'modern' version of mono was a long and complicated process
  • McMyAdmin still 'looked' like a Windows application (having a .exe file extension), adding to the feel that Linux was an afterthought
  • It was difficult to track down and debug issues with such a large variety of libraries and configurations

So with these issues in mind and since McMyAdmin was being rewritten for McMyAdmin 2 - a native Linux version was developed for 64 bit systems on Linux systems using Linux development tools. It doesn't require the Mono runtime to be installed and is just a single binary that only depends on the standard Linux libraries.

There's no point using McMyAdmin if you know how to use the command line

McMyAdmin makes it possible to automate a great deal of tasks that would be very difficult to achieve using the command line alone, at the very least you'd end up writing some persistent scripts and at that point you're more or less reinventing the wheel.

A few examples of things that would be non-trivial without McMyAdmin or similar:

  • Being able to restart the server at the same time each day, but only do so if there aren't currently any players online.
  • Changing the type of whitelisting currently applied to the server on a schedule.
  • Restarting the server based on its RAM usage.
  • Safely taking a backup (requires sending save-off before copying and save-on afterwards, and waiting until the save-off had completed before actually performing the backup)

In addition to the above, McMyAdmin also makes it much faster to perform day-to-day administration tasks.

So I present a selection of tasks that would be slower to perform on the command line:

  • Updating the server (a single button click safely stops the server and fetches the latest version)
  • Swapping from one permissions plugin to another (McMyAdmin writes out its permission data in whatever format you'd like)
  • Setting up a regular scheduled event (which ordinarily would require editing your crontab, McMyAdmin just takes care of the schedule for you)
It doesn't matter if you're an experienced user or a novice, McMyAdmin has features that will benefit you. And if you don't want to use a particular feature, it's not forced upon you.

It stops you from being able to do things on the command line if you prefer to do it that way

Not at all true, when the Minecraft server is running - what you see on the command line is the same as you would without McMyAdmin. You see the output of the Minecraft server, and anything you enter is sent to the Minecraft server same as normal. McMyAdmin even has some of its own commands to make life easier, for example /restart to quickly restart the server, or /setconfig [key] [value] which allows you to change settings of either McMyAdmin or the Minecraft server.

It isn't extensible / you can't add your own features to it

Since McMyAdmin 2.1, it has been possible to write your own extensions for McMyAdmin. They allow you to add your own tabs to McMyAdmin's main web interface to extend its functionality. Some people use them to integrate DynMap into their panel, and many hosting companies use it to integrate their support page or other functionality into the panel to deliver a seamless experience for their users.

In addition McMyAdmin has a powerful JSON based API which makes it easy to integrate McMyAdmin with your own software, or leverage its functionality in new ways. Anything that can be done from the panel can be done from the API (since the panel uses that same API!) - Have a peek at the API reference.

McMyAdmin also has a branding mechanism which allows hosts to alter its appearance so that it matches their corporate image.

It has to be updated every time a new version of Minecraft is released

It is very rare that a new release of Minecraft requires McMyAdmin to be updated to keep its current functionality. Generally speaking an update is only required in order to take advantage of any new functionality/settings added to the Minecraft server since the previous release.

The only major exception to this has been when Minecraft 1.3 came out as the format of some messages was changed. Much of McMyAdmin still worked if it wasn't updated and only the chat was affected.

It's heavy on resources

A typical running McMyAdmin instance with 50 online players consumes roughly 45-55MB of RAM (With no activity it can consume as little as 15MB) and too little CPU usage to measure. Compared to the hundreds of megabytes a Minecraft server of that size would need, it's a drop in the ocean.

The Windows version is shown for ease of grabbing a quick screenshot with everything in (The numbers are very similar with the Linux version), showing several running McMyAdmin instances and their CPU/Memory usage after 12 days of uptime (the amount of time my main test server had been online when I took this)

It has an outdated, ugly user interface

What?

Just one of the themes that McMyAdmin 2 ships with.

 

If you have any other myths or things you've heard that you'd like me to comment on, feel free just to leave them as comments and I'll update this post.

Posted in: Linux | McMyAdmin

Tags:

Why restarting the server on multiple "read time out" errors is a really bad idea.

September 4, 2012 at 3:28 PMPhonicUK

One of the most frequent feature requests for McMyAdmin over the last couple of months has been the ability to make McMyAdmin automatically restart the server if a "read time out" happens (or if many of them happen in a short time frame)

The short and sweet answer to why this is a bad idea is simple - it's too easy to exploit to deliberately make the server restart excessively, and it would be almost impossible to protect against.

So let's go over what's happening here:

A 'read time out' occurs when you are trying to read a piece of data (in this case, from a network socket) and it takes too long to read the data. Normally this happens because the sending party has stopped sending data unexpectedly (due to a connection issue or a software failure) and the receiving party is still expecting data.

Normally a read timeout isn't an issue and the server just carries on its merry way (and in fact the minecraft server does indeed do this during a 'legitimate' read timeout) - but for one reason or another Craftbukkit has a bug whose symptoms are large numbers of these happening in rapid succession, followed by users being disconnected and the server becoming unresponsive.

Why this keeps happening in Craftbukkit I don't know - but what I do know is that it would be very easy to trigger deliberately. Simply connect to the minecraft server, and midway through sending a packet - simply stop.

So if McMyAdmin were to (have the option to) restart servers automatically in this situation - It'd be very trivial to keep large numbers of servers in a restart loop with a very small amount of traffic, a griefers wet dream.

Posted in: McMyAdmin

Tags:

Running Mac OS X 10.8 'Mountain Lion' in VMware ESXi 5

July 30, 2012 at 7:27 PMPhonicUK

Recently I bought a Mac Mini to use as a ESXi rig to host Mac VMs for development purposes.

Getting Lion running in ESXi 5 is a marginally annoying but entirely doable task. However if you try to follow the same steps with Mountain Lion, you'll very quickly get stuck at a "Waiting for root device..." message and find you're going nowhere.

Thankfully it's actually a pretty simple (if inconvenient thing) to work around:

  • Install OS X 10.7 (Lion) in a VM
  • Upgrade 10.7 to 10.8 after it's up and running
  • Done
That's it. Upgrading works, clean install doesn't.
 
Point of note: During the Mountain Lion installation, the screen may go black/white with a small box in it. If this happens just press any key on the keyboard to wake it up again. It's not dead.

Posted in: Servers | VMware

Tags: , , ,