PermissionsEx: Anti-griefing methods for Minecraft

More Grief

If you've already installed and configured Grey Lists using PermissionsEx (as described in my earlier post) then you are well aware of the protection this provides against those pesky griefers. Yeah I know you can white-list your server but this helps you want to showcase your work without risk.

My son can be a little too trusting, and far too keen to attract new builders, and it always seems to be when we have friends of friends connected that trouble starts brewing. A few days ago the inevitable happened, a school pal and his friend paired up for an orgy of TNT abuse, dropping as many buildings as they could in full view of the regular builders. The server was downed soon as he figured out what was happening and the permissions.yml file altered to remove the offenders building rights, but ultimately damage had been done. One of the longest standing buildings was hit so hard that it was reduced to a crater, all in about a minutes chaos!

PermissionsEx Revisited

All the griefing we've experienced so far has been the result of fire or TNT, with the latter obliterating buildings well beyond repair. It made sense after this attack to limit their use, removing them from the standard 'builder' groups rights, but after well over an hour of altering permissions and testing we had only managed to remove the rights to place TNT. It's really a case of trying different modifyworld  restriction in the permissions.yml file until you get a result.

The first thing to be aware of is the order of the permission lines is important. The file is scanned top to bottom and as soon as a match is found it stops. This means restrictions must go before grants using wildcards or they'll never be reached.

Builder:

      prefix: '&0(&8Builder&0)&7 '
      permissions:
      - -modifyworld.blocks.place.46
      - -modifyworld.bucket.empty.10
      - -modifyworld.bucket.fill.10
      - -modifyworld.items.pickup.259
      - -modifyworld.items.craft.259
      - -modifyworld.items.use.259.on.block.*
      - -modifyworld.items.use.259
      - modifyworld.*
      options:
          rank: '900'

nb. Our restrictions go before modifyworld.* and use the '-' minus symbol to differentiate them from grants. The objects are listed by item/block id (46 = tnt, 10 = lava, 259 = flint and steel)

Now when TNT (46) is placed by a builder the block gets picked straight back up again, similarly the restrictions on flint and steel (259) don't allow you to pick it up or use it. The lava bucket (327) lines need to restrict filling and emptying of a liquid, in this case lava.

You will also need to enable some options in the modifyworld.yml before this works.

item-restrictions: true
use-material-names: false
drop-restricted-item: true
item-use-check: true

I set use-material-names to false so that I could use item and block numbers, but you can leave this set to 'true' and use proper names. Then your restriction would read as per the example below:-

   - -modifyworld.blocks.place.TNT

Don't mix the two up or your permissions won't work. Also be aware that the plugins are very sensitive to formatting errors, so check your server log after changing and if necessary run your config through a YAML file validator.

In the mean time I'll work on the fire problem & if anyone has any suggestions then please comment.

Automatic for the People - Part 2

Down in the Dumps

I run a few systems that use databases and these (I'd assumed) were being backed up using my weekly backup script. But just copying the system files while the database was running proved to be a great way of losing the last few records should you need to restore. And I'd invariably be forced to run myisamchk on the recovered database before mySQL was happy.

After this happened a few times I started dumping my databases on a daily basis. A dump is not something nasty, but a flat file containing the database structure and contents in an SQL format.

- Example for mySQL
For each database you have add a line as follows to your backup script:-

mysqldump wiki --password=iliketurtles --add-drop-table > /var/backups/wiki.sql

Here I'm dumping my wiki database and it assumes I have an admin user for mySQL called root with a password as 'iliketurtles'. For convenience we'll make it add drop table commands, and recovery would be as simple as:-

   pingu:=# mysql -u root -p wiki < wiki.sql

NB. You would need to ensure is that a database called wiki exists or it will thrown an error, but an empty one will do.

- Example for PostgreSQL
For each database add a line as follows to your backup script:-

pg-dump -Fc davical > /var/backups/davical.pgdump

This also assumes you have a superuser called root in Postgresql.

NB. Again the database must exist before you can recover, then you would just enter the following command:-

   pingu:=# pg_restore -d davical davical.pgdump

So two very different databases engines taken care of. Just duplicate these commands for all the databases you want to backup.

Daily Increments

The weekly backup I described last time has served me well for many years, and the few times that I've needed to recover anything have been a success. But more recently my friend Grunders (who'd been storing open office files in his home directory over a VPN) lost his files when the hard disk failed. I offered him the backup from the weekend but he said it was no good because he'd made too many changes.

Luck was with him though, that old trick of turning off the computer and powering back on brought the drive back to life long enough to retrieve his missing files. However we went on to convinced ourselves that we needed a daily incremental backup. My Initially attempt at doing this simply failed as I'd tied myself in bash script syntax knots. But a few days later Grunders came to the rescue with the following code:-

SOURCE=/home/
TARGET=$(date +%Y.%m.%d-%H%M)
RUNTIME=$(date +%Y%m%d%H%M)

cd "$SOURCE"
IFS="
"
LIST=`ls`
for i in $LIST
do
  DirUser=$(echo "$i")
  echo $DirUser
  cd /home/$DirUser
  find * \( ! -regex '.*/\..*' \) -newer /root/REFTIME -print0 | xargs -0 tar --no-recursion -cpf /DailyBackup/$DirUser/$TARGET.tar &gt;&gt; /root/dailyincbackup.log
  if [ -e /TimeMachine/DailyBackup/$DirUser/$TARGET.tar ]
  then
    mkdir /TimeMachine/DailyBackup/$DirUser/$TARGET
    tar -xvf /DailyBackup/$DirUser/$TARGET.tar -C /TimeMachine/DailyBackup/$DirUser/$TARGET
    rm /DailyBackup/$DirUser/$TARGET.tar
  fi
done
touch -t $RUNTIME /root/REFTIME

It's actually a little bit odd as the script is using find to locate files that have changed since the date held in /root/REFTIME and create a tar file of the changes. (The regex part removes hidden files, such as those that Apple Mac's add) Then to avoid tar files he's untarred the resulting file and deleted it. Obviously this is not ideal, but there is an alternative way that uses a cp command:-

find . \( ! -regex '.*/\..*' \) -newer /root/REFTIME -exec cp -Ra {} /DailyBackup/$DirUser/$TARGET \;

The receiving directory must exist for this to work, and it may leave empty directories if no changes where detected, so I'll leave the script as it is for now.

Thanks G, all it needs now is something to purge old files.

Minecraft Grey Lists

Anti-Griefing

A few weeks ago my son's Minecraft world became trashed (buildings completely obliterated) by friends of a friend who visited our server. Thankfully we had a backup to restore from and then to ensure it didn't happen again we turned on white lists in the server.properties file.

But the story doesn't end here... a few days ago number one son asked me if I knew anything about grey lists, informing me roughly what they're supposed to do. Apparently if you set up a grey list then it enables anyone to join the server but they're restricted from building. This was new to me and seems ideal, meaning he'd be able to pass about the server connection details freely without worrying about being griefed again.

Grey Lists

The vanilla server only supports black lists (to ban people) or white lists (to only allow access to those listed). There's no setting in the properties file to enable grey lists, so I googled until I found that a plugin called PermissionsEx. This enables you to define access groups with appropriate rights, and assign users to them.

But you can't add plugins to the vanilla version of Minecraft server,.. there's no plugin directory, instead you have to use the CraftBukkit server instead. (Click here for download page)

While I'm at it, here's the link for the PermissionsEx plugin. (Click here for download page)

Installing Bukkit & PermissionsEx

Here's the steps we went through:

1. Edit your server.properties file and disable white-lists if you where using them.
2. Download the craftbukkit jar file and copy it into your minecraft server directory.
3. Run the craftbukkit server program to create the extra files and folders (it also converts your world files).
4. Download the PermissionEx jar files and copy these into the newly created plugin directory.
5. Restart the server again and a PermissionEx sub-directory will be created.
6. Change to this directory but leave config.yml alone.
7. Edit the permissions.yml file and replace the contents with the following lines, then add your users into the end section (in line with the examples).

groups:
    default:
        default: true
        options:
            rank: '1000'
        permissions:
        - modifyworld.chat
    Builder:
        prefix: '&0(&8Builder&0)&7 '
        permissions:
        - modifyworld.*
        options:
            rank: '900'
    Moderator:
        prefix: '&0(&1Moderator&0)&7 '
        permissions:
        - -modifyworld.mobtarget.*
        - modifyworld.*
        options:
            rank: '100'
    Admin:
        prefix: '&0(&4Admins&0)&7 '
        permissions:
        - -modifyworld.mobtarget.*
        - modifyworld.*
        - permissions.*
        options:
            rank: '1'
users:
    SomePlayerName:
        group:
        - Builder
    YourPlayerName:
        group:
        - Admin

NB. Ensure you don't add any spaces before 'groups' or 'users' or the file will be ignored.

We found that if your name is in the ops.txt file then you automatically get admin level.

Follow this link for further details on configuration and how to type /pex commands when in the game.

Finally I updated the /etc/init.d/minecraft startup script to use the CraftBukkit jar file.

Automatic for the People - Part 1

DYBB

Many, many years ago I took over a Support Manager role at a snack factory and I inherited my predecessor's office. Chris (who I'd met a few years before when I'd worked there in my summer holidays) now worked at head office, but was around a few days a week to help me learn the systems. He'd left me a lot of his old stuff and there was an A4 (approx US letter size) page stuck to the wall above the HP Deskjet 500 printer that just had the letters 'DYBB' filling the page. I pondered for a while what this should mean (I was sure it was nothing to do with boy scouts and "Doing Your Best") and eventually I just asked him.

Chris smiled and replied, "That what I tell all my users... Do Your Bloody Backups!"

Of course this was back in the days of 386 and 486 computers running DOS, and hardly anyone stored files on the Novell file server. Therefore there was a portable Colorado Trakker tape backup unit that the finance departments looked after, and it was up to the few PC owners to run weekly backups to QIC tapes. Some did, some didn't, and many just relied on floppy disks.

Technology has a way of picking the least opportune moment to catch us out (see my previous blog entry). Over the last ten years of running a home server I've learnt that if you're passionate about keeping your data, then backups need to be automatic.

Keeping it Simple

I took the decision many years ago that I'd just perform a backup once a week for my /data, /etc, /var and /home directories. I have a 2Tb backup disk formatted with a 50Gb partition, with another partition for the remainder. There are no entries in the fstab file so it's not mounted automatically, and it uses standard EXT3 formatting.

1 - Backup of data is just a straight copy of new and updated files onto the bigger backup partition. The disk is temporarily mounted to /mnt and then a simple copy refreshes the files and directories within it. It does have a few disadvantages but I love the simplicity of it, and so far it's served me well.

Here's the bit of script that does this:-

Drive="/dev/sda2"
mount -t ext3 $Drive /mnt
# CHECK MOUNTED OK
OK=`df | awk '/[ \/]mnt/ {print $1}'`
if [ "$OK" = "$Drive" ]; then
  cp -Rvu /data /mnt
  umount /mnt
  sleep 120
  hdparm -y /dev/sda
fi

It's using df and awk to check to ensure the drive gets mounted OK before continuing, then cp to copy the data. At the end it unmounts the drive and uses hdparm to put it to sleep.

2 - The Etc, Var and Home directories contain files where I wanted to keep a few versions because file updates are common. So here I mount the smaller backup partition and implement a Grandfather, Father, Son approach to the problem. Son is a directory containing a full copy of the files, which then gets GZ Tarred the next week to become the 'father', and later 'grandfather' file. I hate untarring files so it means if needed I can retrieve recently versions of files conveniently from the /son directory. In practice I've hardly ever had to resort to plundering the older tar files.

Here's the bit of script that does this:-

Drive="/dev/sda2"
# CHECK MOUNTED OK
OK=`df | awk '/[ \/]mnt/ {print $1}'`
if [ "$OK" = "$Drive" ]; then
  # if exist father, rename to grandfather
  cd /mnt/
  if [ father.tar.gz ] ; then
    mv father.tar.gz grandfather.tar.gz
  fi

  # if exist /son then tar to father.tar.gz
  if [ son ] ; then
    tar -zcf father.tar.gz son/*
    rm son -R

  fi

  mkdir son
  cd son
  mkdir etc
  mkdir var
  mkdir home
  mkdir root

  cp /etc/* /mnt/son/etc/ -a
  cp /var/* /mnt/son/var/ -a
  cp /home/* /mnt/son/home/ -a
  cp /root/* /mnt/son/root/ -a

  # Unmount drive
  cd /
  umount /mnt
  sleep 120
  hdparm -y /dev/sda

fi

Again it's using df and awk to ensure the drive gets mounted, then performs the grandfather, father, son backup as described above. Finally it unmounts the drive and puts it to sleep.

I've completely ignored database backups and incremental backups for now, I'll continue with that next time.

Recovery Time

Happy Returns

After a week at the seaside I returned home and immediately had computer problems. My trusty laptop who's hard drive I'd suspected being on the verge of failing, finally let go. I was in the process of trying to backup my data at the time when it repeatedly failed at the same file. So I ran a disk repair... diskutility reported a B Tree error, recommended I backed up my data, and then seemed unable to remount the disk. GREAT, how was I supposed to do that now?

I have a new disk on order, a Sandisk 480Gb Extreme SSD which has a read speed of 540MB/s and a write of 460Mb/s. That's nearly as fast as the mSATA card I installed in the new server. I'm looking forward to having faster access, longer battery life and hopefully better stability.

Not So Stellar

In the mean time I downloaded and installed Stellar Phoenix Mac Data Recovery. Initially it was just the free version, but when you see your apparently fine files listed you feel the impulse to grab your credit card and purchase a full license. So, I left it churning away for 24 hours, happily pulling hundreds of Gb of files off the damaged disk. Sadly when I tested them yesterday they all turned out to be garbage.

I've powered down the machine and restarted the attempt, but after 12 hours it's still reading the disk with not a file in sight. Yikes, this might be harder than I'd thought!

I'll just have to swap the disk out, stick it into a caddy and work on it later. I need the laptop working again, apart from everything else I use it to type blogs with!! I can't cope with just an ipad because I still use an ipod nano for audio books and podcasts, and I really need a proper keyboard and decent processing power for photo editing.

Going Live

The State of Things

My four wire case fan arrived last week featuring low speed operation, rubberised frame and unique corrigated design blades. Originally I'd ordered the three wire version by mistake, but this was unsuitable if you want the system board to be able control the fan speed. Then towards the end of the week I worked out how to transfer my databases over for Davical and Mediawiki. I'd already transferred my other mySQL databases by copying the files from /var/lib/mysql, but the Wiki failed to work and Davical uses PostgreSQL. I knew next to nothing about PostgreSQL so it was a slog to work out how the security worked, how data might be transfered, and how to fix the annoying missing PHP library problems along the way. Nothing works without a battle and this was a fresh install, so it should have been easy?! Go-live was now or never, the other apps could wait, and I didn't want to go through the hassle of transferring data again.

On the hardware side, the new fan (an 80mm 'be quiet!' SHADOW WINGS SW1)
required its mounting plugs to be modified, as the plastic locking pins wouldn't go through the threaded mounting bracket. It would have been flimsy anyway, so I discarded the pins, shortened two of the mounting plugs and used a couple of long bolts and washers to secure it. The fan was then plugged into the system fan header on the motherboard and the computer started. It was immediately obvious that the fan was running very slowly, the BIOS reporting just 500 rpm.

Fan mounted using modified only the lower pegs.

Nb, always test things before you modify them, that way if it's DOA you can get it replaced!

That should be just enough to keep a small amount of air moving through the case, and if temperatures heat up, then the fan should speed up to a maximum of 2000 rpm, at a whisper quiet 16.6dB sound level.

Out With The Old

Going live essentially means moving the data and backup disks over to the new server. But before doing this I was keen to compare power usage and disk speeds, (before and after) ultimately reassuring myself that spending all that money was worthwhile.

With all drives running on the old Via C7 based machine the system was shown to draw a steady 32 watts. This dropped to 24 watts after the drives were removed, leaving just the IDE SSD and case fan as additional loads. That's higher than expected for an eleven watt system board, even allowing for power supply inefficiencies.

I used a utility called hdparm to measure the drive speeds. This is a general purpose drive tweaking tool that can perform a multitude of tasks such as optimising speeds and changing time-out parameters. The following command produces two performance measurements:

   pingu:=# hdparm -Tt /dev/sdx (where x is the drive letter to be measured)

Drive	Cached Reads	Buffered Reads
IDE SSD	225Mb/sec	28.4Mb/sec
Samsung Momentus HN-M101MBB 2½" sata disk (via IDE to SATA adapter)	225Mb/sec	29.5Mb/sec
Samsung Momentus ST1000LM024 2½" sata disk (sata port)	233Mb/sec	30.1Mb/sec
Western Digital Caviar Green 3½" sata disk (sata port)	234Mb/sec	111.5Mb/sec

It's interesting that the SSD wasn't out-performing the other drives in this test, though in practice it had certainly yielded a performance boost when I'd first installed it. I know they wear out, but I'm sure they don't go slower!

For Shiela.

In With The New

The disks where installed in the new Intel i3 based machine and mount points added to the fstab. These I added using their Block ID rather than their device name, which is a unique drive identifier rather than one that's tied to the port being used. You can find out which disks are connected by typing the following command:

   pingu:=# blkid

The address numbers are a little bit too long to write down and type in manually, so I piped the output of this file into my fstab and edited the result to the correct format.

   pingu:=# blkid >> /etc/fstab

This task completed, I re-tested the disks for speed.

Drive	Cached Reads	Buffered Reads
Intel 525 60Gb mSATA card	6470Mb/sec	247Mb/sec
Samsung Momentus HN-M101MBB 2½" sata disk	6500Mb/sec	103Mb/sec
Samsung Momentus ST1000LM024 2½" sata disk	6590Mb/sec	100Mb/sec
Western Digital Caviar Green 3½" sata disk (in SATA2 port)	6500Mb/sec	119.5Mb/sec

There's quite obviously a performance boost but it's surprising that the 3½ inch desktop drive connected to a faster sata2 port wasn't any quicker on buffered reads. To be fair this disk is designed for efficiency and low power with only a 5,400 rpm platter.

Two laptop drives on top and a desktop drive under the mounting plate.

With all disks running the power drawn was just 23 watts, a nine watt saving over the previous machine. That's like turning off a compact fluorescent light bulb that's been burning for the last four years.

Power Corrupts

Pleased to Meter

My plug-in electricity usage meter arrived from Maplin (N67FU). It cost just just a tenner and gives me the ability to see if my careful purchasing has actually delivered me an efficient server. You plug it into a mains outlet, and then the device to be measured connects to the three pin 13 amp socket in the front. It has a maximum power rating of just over 3Kw so it should be enough for an Intel i3 (laffs), and the flat-ish design means wall-warts shouldn't be a problem.

It works really well, and it's cheap as chips, but the niggle I've had with it is reading the LCD screen. Parts of the display are really tiny and my eyes aren't what they used to be. Plus mains power sockets tend to be in low, poorly lit places, making reading harder still. The only real issue has been the mode indicator, which is the smallest bit and block inverse. (Who dreamed that up?.. I can understand from a design point of view how you'd want to differentiate that a little, but they might as have well used Egyptian Hieroglyphs!)

Meter mode indicator shown top right.

Thankfully the screen layout changes enough so that you can work out which mode you're in, and it's mostly about that big number in the top left so I can get by without needing a flashlight and my reading glasses.

Measuring Up

The existing Pingu had to be shut down to install a replacement /home and /data drive. I use 2.5" laptop drives these days to keep check on the noise and heat, and this disk was the first one I'd bought after switching to the policy four years ago. Last week it started to fail big time, throwing numerous errors, making loose rattling noises and finally showing files with zero bytes size. I won't bore you with the gory details because I have regular backups, but it gave me the chance to plug in the power meter and see how much juice my trusty old server has been using all these years.

The Via system board is rated at 11 watts, there's an SSD, two laptop drives and a 2Tb desktop drive for my auto-backups, which is normally asleep. So after allowing for a power supply efficiency of 80%, I'd estimated about 25 watts in total, but found it actually used just under 27w. I'm pretty sure it's the disks that are dragging it up so high, but until I unplug them it's just an educated guess. But having the electricity meter means I can be a little more pragmatic about future disk purchases. Maybe one day SSD's will be big enough and cheap enough to fulfil my data storage requirements.

Next to be benchmarked was the new Intel i3 based machine. The bulk of the software, two database servers (Postgresql and mySQL), as well as Apache2 had already been installed but not configured. And as I blogged last time, Minecraft Server was ready to go. Turning on the machine it peaked for a few seconds at 20 watts and then dropped to a very reasonable 14.5 watts. It pretty much stayed at that value until I started the Minecraft service and then it went up by about ½ a watt. I measured CPU temperature by installing LM-Sensors and CPU utilisation was monitored using the Top utility.

With one player joining the game the power rose to about 15.5 watts and (by pressing 1 while running top) I was able to see that all four of the CPU cores had started to register light utilisation. (So I stand corrected, Minecraft Server does use multiple cores - thanks to Dr Vesuvius for that heads-up).

top - 18:47:19 up 1 day, 22:48,  1 user,  load average: 0.18, 0.12, 0.08
Tasks: 106 total,   2 running, 104 sleeping,   0 stopped,   0 zombie
%Cpu0  :  5.6 us,  0.7 sy,  0.0 ni, 93.4 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 18.6 us,  1.0 sy,  0.0 ni, 80.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  3.3 us,  0.0 sy,  0.0 ni, 96.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  6.4 us,  0.3 sy,  0.0 ni, 93.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   8127440 total,  1199480 used,  6927960 free,    19984 buffers
KiB Swap:  3090420 total,        0 used,  3090420 free,   862192 cached

Some of this could be the other services running but without the Minecraft Server there's very little utilisation on the other cores.

With the case lid removed the CPU temperature drifted up to around 45 degrees centigrade and the fan still turned at it's original lazy rate. I gotta admit, that's better than I expected.