How to use an external harddrive as an encrypted storage on (Arch)Linux?

This guide will tell you in details, I’ve just wanted to create a reminder for myself:

Found out which /dev is your external harddrive available:
# fdisk -l

Lets say that it is on: /dev/<sdx>

For starter just reformat your external harddrive:
# mkfs.ext2 /dev/<sdx>

Create the luksFormat on the device, that way LUKS will now what things to use by reading the headers.

# cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random --verify-passphrase luksFormat /dev/<sdx>

After queried enter the passphrases.

Create a mapper for your encrypted drive with:
# cryptsetup open --type luks /dev/<sdx> <mapped_name>

Now you got a so called mapped device on /dev/mapper/<mapped_name>, lets format it with the needed file system, I just used ext2.

# mkfs.ext2 /dev/mapper/<mapped_name>

Let’s close the mapping:
# cryptsetup close <mapped_name>

So to say, this was the last step to creating an encrypted device. Now all you need to do if you plug-in your harddrive is:

  1. Create mapping:
    # cryptsetup open --type luks /dev/<sdx> <mapped_name>
  2. Mount it:
    # mount /dev/mapper/<mapped_name> /mnt/<your_favorite_dir>
  3. Do stuff
  4. Unmount:
    # umount /dev/mapper/<mapped_name>
  5. Remove mapping:
    # cryptsetup close <mapped_name>

Browser based (M)MO game development - part 1 (infrastructure)

This post is the first part of a series about experiences of browser based multiplayer game development. The stack I’m using:


Why could this be interesting? First of all, browsers are nearly platform independent. Still let’s go a bit deeper. I would like to break up w/ flash on this move. I don’t care about old IEs so this all results in a front-end with HTML5/Canvas managed by EaselJS.

Ok, ok, nothing really special yet. So let’s expand a bit. I don’t want to implement server/client logic in different languages hence server side javascript a’la node.js. Actually this is NOT ENOUGH. I do NOT want to repeat myself, so that I don’t need to describe TWICE how the supermonster bug behaves on server/client side, that I do with socketstream.

Well, TBH the last sentence is not the perfect truth because node.js already gives me this opportunity but socketstream offers a really nice starting framework on using sockets for communication and seperating different business logics. On the other hand there are some layers which is needed by either only the client or the server side of the application, that will be a good starting point to get into tech details.

As editing/publishing this post I’ll develop a bare application which is going to set some basic logic for further use. In this git repository you can follow the project. I will always assume that the working directory is the projects root folder.

The application itself will be a simple 2d MMO with session based authentication two kind of entities: players and shootable monsters (bugz). This should be more then enough to fill the purpose of this post. Along the way, I will refer on this concept just to better express myself.

Second part of the series will be about the application specific parts. I hope the project will give (at least for me) a solid basis to start such a game project.

As I plan this post to be a kind of a guide, it makes sense to me to use chapters. Every chapter starts with a short hint if it’s in your interest. So let’s get on with it:

  1. Setting up a project
  2. Inheritence between server and client classes
  3. Communication between server and client
  4. Polymorphism to keep as DRY as possible ( A.D.A.P. lol )

Setting up a project

This chapter will be interesting for you, if you haven’t used this stack before or if you are curious how I like to structure my code in a socketstream app.

I won’t go into too much details, because this is not meant to be a tutorial about any of the components/frameworks I used, still I’ll include some basic commands and links. I assume that you managed to install node and npm.

Allright, then let’s start with using socketstream! Install it:

[sudo] npm install -g socketstream

Check available options:

socketstream -h

You choose your options I chose minimal, jade and no-coffee thanks. Let me tell you about the directories:           => (readme stuff)
  app.js              => (this is the starting point of the application)
- client              => (files for the client side)
  - code              => (client side code)
    - app             => (app specific code)
        app.js        => (default point of building up client side business logic)
        entry.js      => (entry point of the client side, socketstream needs it)
    - libs            => (vendor code)
        jquery.min.js => (our old friend)
  - css               => (client side css)
      app.styl        => (default app stylesheet)
    - libs            => (vendor css)
  - static            => (static files)
      favicon.ico     => (socketstream advertising)
    - images          => (here comes all the spritesheet pngs)
  - templates         => (did not used yet)
  - views             => (view templates)
      app.jade        => (default app view template)
  package.json        => (app node package dependencies and properties)
- server              => (files for the server side)
  - middleware        => (did not used yet)
  - rpc               => (remote procedure calls directory)

As you see the code what you write either goes into client/code/app or under server/<somewhere>. No sweat, <somewhere> will be cleared as we go along.

Lets add EaselJS minified version from GitHub CreateJS/EaselJS/lib. Where does it go? Well of course under client/code/libs.

The next step will be to add an entry point for our application on both sides. For the client socketsream already takes care about it client/code/app/entry.js, in fact this file need to exist otherwise requiring socketstream on client side will error out. But let’s just focus on the server side for now. To run a socketstream application you just run a specific .js file which loads/instantiates everything (node.js style). This is the app.js. However I like this file as it is, with its infrastructure specific instructions.
For the initializing the actual business logic I like to create a seperate server/app.js => touch server/app.js to stay in convetion with the client side. Just for fun echo "console.log('Starting app business logic')" >> server/app.js

As said, I like app.js as it comes, however we need to add a requiring instruction for our business logic entry point with:
var init = require('./server/app');

I will put every server specific code just under server or server/rpc if it has anything to do with client communication a.k.a remote procedure calls. You could structure directories under server as you like, but this is out of this projects scope.

Let’s bind in EaselJS. For this we will just go again into app.js. There is a ss.client.define function with a second object parameter. On the code keys value you can define directories which need to be loaded on the client side. Change it to code: ['libs', 'app'] for requiring everything under client/code/libs and client/code/app.

Thats it! There will be of course still more additions but to get started this is enough.

Inheritence between server and client classes

This chapter will be interesting for you if you want to know how I implement code inheritnce between client and server side. I will define superClasses which are inherited both on server and client side.

The main thing to understand here is why could we possible need this and what are the different aspects running javascript code on client or server side.

  • Why we need this?
    • Well, we got Players and Bugs in our game, right? Both are going to be moving around but still, they will have other different properties and methods. This is just simple inheritence, not a big deal. So we will have a Movable superClass for them. Let’s go a bit deeper, both the client and server side will share some functionalities of the specific Player model. For example, shooting. This gives us a Player superClass which inherits Movable superClass. Then we have a Player model for the server and the client as well, inheriting Player superClass.
    • On the first view this seems enough. Turns out not quite. We will need polymorphism as well. These are things that are weird to use in javascript. Polymorphism comes in this chapter
  • What are the different aspects running javascript code on cient or server side?
    • DO NOT forget that client code can use things declared on the window object but the server code can not do this. We need to use code in the superClasses that both side can ‘understand’. Everyone knows jQuery and everyone likes it. Add this to our package.json files dependencies block "jquery" : "latest" to be able to use jQuery on the server side.
    • node.js defines util for adding inheritence. Still we will need that on the client side, so lets copy util.inherits implementation into an util module to client/code/app/util.js. We can require that just as well on the server side.

I added playerSuper model into client/code/app. This will be the superClass of both player model on server/client side. The only tricks are the require statements path, and jQuery global ‘$’ variable definition. To use inheritnce on server side take a look on server/player.js. I define ‘$’ as global variable. This is needed when server/player.js includes the superClass from client side code. That code needs to get hold on ‘$’ variable. Thats not needed on the client side, because including jQuery will do this already.


Hello World!

So I just moved here from blogger. Tumblr got my attention on markdown support, which is like the next best thing in html editing after using vim. [:

This blog will be about my coding experiences. There will be some simple solutions for very simple problems like solution for the general hanoi problem - facebook demo interview question.