Stats Server and Client API with support for SQL, and NoSQL databases

[micovery 2]

What is this ?

---

It's a stats/persistence system for Linux or Windows Arma 3 dedicated server. The following database/storage systems are supported:

• MongoDB
  
• CouchDB
  
• Cassandra
  
• MySQL
  
• Redis
  
• File-System (if you don't have a database)
  

At its core, the stats server exposes a key-value store that has this kind of structure:

{
 "player1_id" : {
   "name": "player1",
   "money":  1000
 },
 "player2_id" : {
   "name": "player2",
   "money": 3000
 }
}

Essentially, it is a big hash-map, with smaller nested hash-maps. The nested hash-maps are referred to as scopes.

There is no limit to how many scopes you can have, or what a scope is. It's up to you.

One possible design pattern is to have a scope for each player, using their UID as the scope name.

Another pattern is to have a scope for each player/faction combination. (e.g. "player1_civ", "player1_bluefor", "player1_west", etc);

The only restriction is that all scope names, and keys must be strings, but values can be pretty much anything (except an in-game object)

Prerequisites

---

1. Visual C++ Runtime (http://www.microsoft.com/en-us/download/details.aspx?id=26999) (if using Windows)
   
2. lib32stdc++6 libc6-i386 lib32gcc1 (if using Linux)
   
3. Node.js (http://nodejs.org/download/)
   

Architecture

---

It's made of three parts:

1. Stats server, implemented using Node.js (source and documentation at: https://bitbucket.org/micovery/sock-rpc-stats)
   
2. sock extension for Arma 3 (source and documentation at: https://bitbucket.org/micovery/sock.dll)
   
3. Sample mission that contains the Client SQF API (source and documentation at: https://bitbucket.org/micovery/sock-rpc-stats.mission)
   

The Client SQF API

---

It has two main functions stats_set, and stats_get for setting, and getting key-value pairs

Here are a few examples:

//set key1,value1 within "scope"
["scope", "key1", "value1"] call stats_set;

//set a single key-value pair
["scope", ["key1", "value1"]] call stats_set;

//set multiple key-value pairs
["scope", ["key1", "value1"], ["key2", "value2"]] call stats_set;

//get the value for "key1"
["scope", "key1"] call stats_get;

//get the value for "key1", or return "default1" if not found
["scope", "key1", "default1"] call stats_get;

//get the values for all keys within "scope"
["scope"] call stats_get;

//get the values for "key1", "key2", and "key3" (note no default value given for "key3")
["scope", ["key1", "default1"], [key2, "default2"], ["key3"]] call stats_get;

See the full Client SQF API documentation here.

REPL for managing the key-value store

---

Unless you know what you are doing, I would not recommend manipulating the data directly at the database level.

To make the job easier, I have included an interactive REPL (Read-Eval-Print loop) that allows you to manipulate the data with simple set/get functions, in the same way as the Client SQF API.

See the REPL documentation here.

Fast read/write

---

Once the data for a scope is read from the underlying storage system, it is cached in memory (until flushed). All read/write operations performed through the Client SQF API happen exclusively in-memory. By default, the data from memory is persisted to the underlying storage system every minute (you can modify the interval). However, it only persists the scopes that were modified in-memory since the last save.

Automatic backups

---

When the data for a scope is read from the underlying storage system, a backup is automatically created (you can disable this). This is mainly to help mitigate situations where a hacker tampers with the stats of the players in-game.

The list of existing backups for a scope is kept within its meta-data. Server administrators can use the meta command in the REPL to view this information. The backups are stored in the same way as any other scope. The scope name for backups follows this format:

  originalScope + "." + timeStamp + ".bak"

For now, restoring data from backup has to be done manually using the set/get commands. (I will be adding a restore command to the REPL to help with bulk restore).

Extra goodies in the sample mission

---

As proof of concept, I implemented a player stats system, and included it sample mission. The player stats system (pstats.sqf), saves the following information when a player disconnects:

• primary weapon (including items, and magazine with ammo count)
  
• secondary weapon (including items, and magazine with ammo count)
  
• handgun weapon (including items, and magazine with ammo count)
  
• position (above terrain level)
  
• stance
  
• damage
  
• fatigue
  
• goggles
  
• headgear
  
• assigned_items (Compass, GPS, Radio, Watch, Map, etc)
  
• backpack (with magazines and items)
  
• vest (with magazines and items)
  
• uniform (with magazines and items)
  
• Selected weapon
  

The saved stats are by player UID, and faction.

When the player reconnects, his faction specific stats are loaded, and restored.

As long as the player is in-game, the saved stats will stay in memory (on the Node.js Stats Sever) ... but on-disconnect, his stats are flushed.

Configuration Guide

---

See the full instructions here for how to setup the Node.js Stats Server, the sock extension, and the sample mission.

Here are a couple of demo videos I recorded following the steps in the configuration guide.

First video shows me installing, and playing around with the REPL of the Node.js Stats server (connected to a remote MongoDB instance).

Second video shows me configuring the Arma 3 dedicated server to use the sample mission, and sock extension for connecting to the Node.js Stats Server.

Edited October 2, 2014 by micovery

[tupolov 520]

Congrats! We also use a similar approach in ALiVE mod for full mission persistence and stats.

[.kju 3244]

This is very impressive work micovery! Kudos to you. :bounce3:

If you don't mind asking, you are using this also for other projects of your own?

[micovery 2]

Congrats! We also use a similar approach in ALiVE mod for full mission persistence and stats.

Thanks Tupolov. Been checking out the ALiVE mod, looks awesome.

;2789134']This is very impressive work micovery! Kudos to you. :bounce3:

If you don't mind asking' date=' you are using this also for other projects of your own?[/quote']

Thank .kju ... I started porting the old Takistan Life: Revolution to Arma 3, a few months back ... but stopped because I was busy with work. Here is some of the stuff I had made for it (in Stratis) so far:

Underwater Base for Opfor

Oil Rig for Independents

Civilian Underground Bunker

Anyways, when I came back to the mission, I got fed up with using Java for the persistence, and decided to give Node.js a try. That's where this Stats server was born.

The bases I made using my own 3d editor, I promised I am going to release it as well, along with these 3 bases ... but it's kind of rough right now, you have to know the exact class names of the stuff you want to spawn, but it has precision manipulation of objects, as well as free-hand rotation, lift, and displacement.

[Guest]

Thanks for informing us of the update :cool:

Release frontpaged on the Armaholic homepage.

Stats Server and Client API with support for SQL and NoSQL databases v0.0.1

================================================

We have also "connected" these pages to your account on Armaholic.

This means in the future you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

[clanrising 10]

good job :)

Edited October 8, 2014 by clanrising

[clanrising 10]

hello, thank you for the job, I wanted to know if it is functional with wastland mod? if so what file is to be added? thank you

[micovery 2]

good job :)

hello, thank you for the job, I wanted to know if it is functional with wastland mod? if so what file is to be added? thank you

Thanks, I have not integrated it with Wasteland ... but it should be technically feasible. I can lend some help. Where do I grab the wasteland mission from, is it this: https://github.com/A3Wasteland/Release_Files ?

Edit:

Going through the source, seems that it would not be too complex. Looks like it;s using iniDB, and all calls for set/get values go through two main functions:

iniDB_read;
initDB_write;

I think that all it would take would be to take the functions in the file: fn_inidb_custom.sqf, and simply forward the calls to stats_get, and stats_set as needed (I could be underestimating the work).

Edited October 9, 2014 by micovery

[clanrising 10]

yes , version : A3Wasteland_v0.9g.Stratis.pbo .

I am willing to help, thank you

[micovery 2]

yes , version : A3Wasteland_v0.9g.Stratis.pbo .

I am willing to help, thank you

Ok, on the topic of porting Wasteland ... looks like iniDB has the concept of accessing separate files as independent databases, as well as a concept of sections within a database.

In order to map that data model to the JSON data-model, I think easiest way would be to do something like this:

{
  "database1": {
    "section1": {

     },
    "section2": {

     }
  },
 "database2": {
   "section1": {

    }
 }
}

This way each "database" becomes a scope, and the underlying sections become keys within the scope.

In order to make it easier for manipulating data, and accessing the data ... I will add support for JavaScript style dot-notation, on stats_set, and stats_get function.

e.g.

["player1", ".money.bank", 100] call stats_set;
["player1", ".money.cash", 200] call stats_set;
["player2", ".vest.items[0]", "ItemRadio"] call stats_set;

Would turn into:

{
 "player1": {
   "money": {
      "bank": 100,
      "cash": 200
   }
 },

 "player2": {
   "vest": {
      "items": ["ItemRadio"]
   }
 }
}

I also noticed that iniDB has a function for deleting a database ... which seems kind of dangerous to me, even with backups enabled. So I think I will not allow an entire scope to be deleted. However, a "section" under a scope can be deleted simply by setting it to nil like this.

 ["database", "section1", nil] call stats_set;

I'll update this thread once I make the "dot-notation" improvement to the Node.js module.

I will need with provisioning a box to host the wasteland mission for live testing.

Edited October 9, 2014 by micovery

[clanrising 10]

thank you for your support, my knowledge is limited.

here is my final mission Edited:

https://mega.co.nz/#!ZNNXmLAR!no9gSVVN05erlCvcPwvLfwxDH-9u-PbQuCV87Y7ECTU

---------- Post added at 11:15 ---------- Previous post was at 10:34 ----------

Also i forgot to tell you that we are on a linux based decated server

[.kju 3244]

Pretty cool projects micovery - thanks for sharing! :bounce3:

[micovery 2]

Alright, so new release of sock-rpc-stats v0.0.5 now available on NPM

Here is the change-log:

• 0.0.5
  
  • Defect: Fix major problem where the interval function was always disabled
    
  • Defect: Fix issue with default values 0, and empty string, being treated as undefined
    

  [*] 0.0.4

  • Enhancement: add support for pop, push, shift, and unshift array operations
    
  • Enhancement: add support for JavaScript/JSON dot notation on keys
    

  [*] 0.0.3

  • Defect: Fixed issue with line endings for Linux
    

  [*] 0.0.2

  • Enhancement: meta function added for viewing scope meta-data
    

  [*] 0.0.1 - Initial release

Also, added support on the Client SQF API within the sock-rpc-stats.mission for the new array manipulation functions, as well as a wrapper/adapter for iniDB. That should make it easier to port missions that are using iniDB (I used that for Wasteland).

;2791310']Pretty cool projects micovery - thanks for sharing! :bounce3:

Hopefully I can keep working more on tools for Arma 3 :)

thank you for your support' date=' my knowledge is limited.

here is my final mission Edited:

[url']https://mega.co.nz/#!ZNNXmLAR!no9gSVVN05erlCvcPwvLfwxDH-9u-PbQuCV87Y7ECTU[/url]

---------- Post added at 11:15 ---------- Previous post was at 10:34 ----------

Also i forgot to tell you that we are on a linux based decated server

I took the conversation about porting Wasteland over to their forums ... please use this thread over there now:

http://forums.a3wasteland.com/index.php?topic=565.msg3468#msg3468

I have forked their Wasteland Altis source, and ported it to use sock-rpc-stats with minimal changes.

Edited October 12, 2014 by micovery

[Guest]

Updated release frontpaged on the Armaholic homepage.

Stats Server and Client API with support for SQL and NoSQL databases v0.0.5

================================================

We have also "connected" these pages to your account on Armaholic.

This means in the future you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

[Lachesis580 10]

Hi good work.

Are there any benefits between your work and Arma2Net? Positive/Negative?

[micovery 2]

Updated release frontpaged on the Armaholic homepage.

Thanks for that!

Hi good work.

Are there any benefits between your work and Arma2Net? Positive/Negative?

This project (sock-rpc-stats) is not specifically meant to be a replacement for Arma2Net. Its single purpose is to work as stats server, with a simple JSON abstraction for storing and retrieving data. You can think of it as an alternative to other persistence solutions like extDB, and iniDB.

However, sock-rpc-stats is built on top of the sock-rpc Node.js module, which could technically be a replacement for Arma2Net extensions.

I have released the sock-rpc module on a different thread over at Node.js Extension for Arma 3 (sock.sqf, sock.dll, sock-rpc).

Here is a break-down of the main differences between Arma2Net, and sock-rpc.

I've tried to make it as factual, and unbiased as possible.

For folks who are knowledgeable about Arma2Net, feel free to correct me, whereever I make inaccurate statements (I will incorporate the corrections as edits).

[table=align: left, class: grid, width: 1200]

[tr]

[th][/th]

[th]Arma2Net[/th]

[th]Node.js sock-rpc[/th]

[/tr]

[tr]

[td=width: 150]Architecture[/td]

[td]As I understand Arma2Net works as a bridge between C,C++ unmanaged land, and the .NET managed land. You have to write code, and compile it into a DLL. [/td]

[td]RPC stands for: Remote Procedure Call. You are technically invoking remote JavaScript functions from within SQF. There is no compiling at all. You just make the code changes, and restart the RPC server. Meanwhile the game server itself can still be running.[/td]

[/tr]

[tr]

[td]Language[/td]

[td]You can use any language that can be compiled into Microsoft's Common Intermediate Language (see the list at http://en.wikipedia.org/wiki/List_of_CLI_languages)[/td]

[td]It's a Node.js application, so you write the code in JavaScript. JavaScript, has been around since the release of Netscape Navigator 2.0 in September 1995 ... and nearly 20 years later, it's still going.[/td]

[/tr]

[tr]

[td]callExtension buffer size limitation[/td]

[td]In Arma 3, the callExtension response buffer size is 10240 bytes. With Arma2Net, I think you have to manually work-around this limitation. [/td]

[td]When using sock-rpc, this is handled transparently for you. As a developer, you don't have to worry about it. You simply worry about writing your misison's SQF code, and JavaScript functions.[/td]

[/tr]

[tr]

[td]Debugging[/td]

[td] When using Arma2Net (or any extension), in Arma 3, debugging is not easy (at least on Windows). You have to have write print statements to trace the logic you are debugging.

---

Back in Arma 2, you could attach Visual Studio to the game process, and load the symbols for the DLLs, and literally step through the extension code while the game was waiting for the callExtension invocation to exit. This does not work anymore in Arma 3, maybe the BIS developers have put some traps to prevent hackers from attaching debuggers to the game client. Today, once you attach a debugger to A3, and stop at a breakpoint ... the game simply crashes.

---

In Linux, you can still attach GDB to the server process ... without it crashing. [/td]

[td]With sock-rpc, debugging is a breeze, or as easy as in any Node.js application. Node.js (based on Google's V8 engine), comes with its own built-in debugger. You can start a node application in debug mode, and step through the code, or attach a remote debugger to it. Some popular ones are node-inspector (see

), and the debugger inside IntelliJ's WebStorm IDE (available at https://www.jetbrains.com/webstorm/) [/td]

[/tr]

[tr]

[td]Peformance[/td]

[td]While Arm2Net acts a bridge, the performance of the callExtension invocations is not hindered much ... as the call never leaves the Arma process.[/td]

[td]With sock-rpc, the calls technically exit the Arma process, and go over TCP to the RPC server Node.js process. This adds some overhead, however, when the RPC server listens on the loop-back address (127.0.0.1), most TCP stacks handle the routing internally, so it's not a big hit. I would not recommend running the RPC server on a different machine.[/td]

[/tr]

[tr]

[td]Ease of use, and community support[/td]

[td]Well, you have to know your way around the .NET libraries, and be able to write code in one of the CLI languages. There is a lot of community support, as .NET is very popular. Folks coming from a traditional OO (object oriented) background/education tend to gravitate towards this.[/td]

[td]JavaScript is very easy to learn for beginners. There is no lack of support there either ... Node.js, though not as old as .NET, is very popular as well. Also, you get to re-use any NPM (https://www.npmjs.org/) module you want. [/td]

[/tr]

[tr]

[td]Cross platform support[/td]

[td]With Arm2Net, Windows is the main platform being targeted. Writing Arma2Net "addins" that work in Linux can be tricky. Not sure if anyone has gotten it work in Linux. Maybe using Wine, or mono?[/td]

[td]sock-rpc supports both Windows, and Linux (sock.dll, and sock.so) ... your actual application code is in JavaScript which itself is platform agnostic. Node.js is officially supported on both Windows, and Linux (http://nodejs.org/download/)[/td]

[/tr]

[tr]

[td]Addins support[/td]

[td]This is a concept specific to Arma2Net. It supports bridging to multiple "addins"[/td]

[td]sock-rpc does not have the concept of "addins" ... but does not mean it's not possible. You can technically expose functionality from multiple independent Node.js modules, by creating a wrapper module that "requires" the dependent modules, and registers their functions as RPC calls.[/td]

[/tr]

[tr]

[td]Client side SQF libraries[/td]

[td]With Arma2Net, you have to deal with the low-level "callExtension" calls directly.[/td]

[td]sock-rpc provides a layer of abstraction with a single SQF function (sock_rpc) that you can call from anywhere (client or server). If invoked from client-side, the call is automatically routed to the server side, where the sock.dll/sock.so extension is normally installed.[/td]

[/tr]

[/table]

Edited October 12, 2014 by micovery

[Lachesis580 10]

Thank you for the information.

[armatech 8]

how about extDB how does this compare to that

[[BL] Hannibal 16]

Thanks micovery this is a really interesting project.

[torndeco 128]

Very nice project + looks like very easy from mission maker to implement aswell :)

Personally i like you are getting the command line arguments.

Think i have to implement something similar myself.

Just random idea i had,

Add ability to retrieve set command line parameters from SQF that follow a regrex rule.

arma3server.exe ........... --missionVarInstance=1

That way mission maker can ask extension for all variable with pattern --missionVar* it returns Instance 1

Its a small feature, but it could be useful. Anyway just a random idea i had.

Nice to see more linux extensions

[micovery 2]

how about extDB how does this compare to that

Gotta play around more with extDB first, so that I can make a good side-by-side comparison.

The main difference I believe is that extDB relies on having a pre-defined SQL schema, and queries, and procedures.

Sock-rpc-stats on the other hand is schema-less ... which means it does not force a schema on you.

However, at the end of the day ... the schema definition really lives in your mission code.

For example, here is how I organized the information for the proof of concept player stats (pstats.sqf) that I included in the sample mission.

{
 "76561198015751465_civ": {
   "createdAt_": 1413312842050,
   "updatedAt_": 1413313170677,
   "signature_": "gBV5BbuEFQDGR8q9JXS1fg==",
   "primary_weapon": "srifle_EBR_ACO_F",
   "primary_weapon_magazine": [
     "20Rnd_762x51_Mag",
     10,
     "true",
     1,
     "srifle_EBR_ACO_F"
   ],
   "primary_weapon_items": [
     "muzzle_snds_B",
     "",
     "optic_Arco"
   ],
   "secondary_weapon": "launch_I_Titan_short_F",
   "secondary_weapon_magazine": null,
   "secondary_weapon_items": [
     "",
     "",
     ""
   ],
   "handgun_weapon": "hgun_Pistol_Signal_F",
   "handgun_weapon_magazine": [
     "6Rnd_RedSignal_F",
     4,
     "true",
     2,
     "hgun_Pistol_Signal_F"
   ],
   "handgun_weapon_items": [
     "",
     "",
     ""
   ],
   "pos_atl": [
     16081.4,
     17047.8,
     0.00139951
   ],
   "dir": 259.019,
   "animation": "amovpercmstpsraswpstdnon",
   "damage": 0,
   "fatigue": 0,
   "uniform": "U_C_HunterBody_grn",
   "goggles": "G_Balaclava_combat",
   "headgear": "H_Booniehat_grn",
   "assigned_items": [
     "ItemWatch",
     "ItemRadio",
     "ItemGPS",
     "Rangefinder"
   ],
   "backpack": "B_BergenC_blu",
   "vest": "V_Chestrig_blk",
   "magazines": [
     [
       "7Rnd_408_Mag",
       7,
       "false",
       -1,
       "Vest"
     ],
     [
       "20Rnd_762x51_Mag",
       10,
       "true",
       1,
       "srifle_EBR_ACO_F"
     ],
     [
       "6Rnd_RedSignal_F",
       4,
       "true",
       2,
       "hgun_Pistol_Signal_F"
     ]
   ],
   "backpack_items": null,
   "vest_items": null,
   "uniform_items": null,
   "current_weapon": "hgun_Pistol_Signal_F"
 }
}

Add ability to retrieve set command line parameters from SQF that follow a regrex rule.

Ty, good idea ... though if you have too many mission variables, it can be hard to manage. But, it's still useful. A mission maker for example could add a command line argument like -foo=someFile.sqf. Then, as you pointed, he would ask for the value using regex, or a substring, and then read the referenced file itself from within the mission in SQF.

The one problem with this is that you have to be careful to not expose the values of parameters like -config, and -profile ... that'd be a pretty bad security exposure. People could read the contents of your config files ...or, if they know the location where the BattleEye config file is stored, they could even probe until hit the "not-so-random" renaming of BEserver.cfg.

[firefly2442 6]

Looks cool. :)

With Arm2Net, Windows is the main platform being targeted. Writing Arma2Net "addins" that work in Linux can be tricky. Not sure if anyone has gotten it work in Linux. Maybe using Wine, or mono?

There's a development branch for Arma2NET on Github that compiles and works on Linux. I ran into some dependency troubles with Mono libraries but it does seem to work.

[torndeco 128]

Thats were the regrex rule, comes in.

Extension will only return parameters that match the regrex rule (hardcoded or defined in extension configfile).

That way its impossible for SQF code or hacker to get info on an important commandline option.

Anyway just a random idea i had...

Anyway back to coding

[hannibal2210 1]

Thanks micovery for all your work on this, it is extremely useful and works very reliably.

One thing I read was that this dumps to the storage (SQL in my case) every 1 minute by default, I noticed when set up the interval seemed much longer, for example if you closed the server and then restarted it when you rejoined you would be placed back to a location you were in maybe 5 or more minutes before.

Also I wondered if you could suggest a way of saving the contents of a vehicle / storage crate using this system aswell ( for persistent coop campaign storage).

Any input on this will be greatly appreciated.

Thanks again!

[m1ndgames 10]

Hi,

i have troubles installing socks-rpc-stats:

root@m1ndfuck:/home/m1ndfuck# npm install sock-rpc-stats
npm WARN deprecated bignumber.js@2.0.0: critical bug fixed in v2.0.4

> fibers@1.0.5 install /home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/wait.for/node_modules/fibers
> node ./build.js

child_process: customFds option is deprecated, use stdio instead.
gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/0.12.2"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/wait.for/node_modules/fibers/.node-gyp"
make: Entering directory `/home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/wait.for/node_modules/fibers/build'
 CXX(target) Release/obj.target/fibers/src/fibers.o
make: g++: Command not found
make: *** [Release/obj.target/fibers/src/fibers.o] Error 127
make: Leaving directory `/home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/wait.for/node_modules/fibers/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:269:23)
gyp ERR! stack     at ChildProcess.emit (events.js:110:17)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:1074:12)
gyp ERR! System Linux 3.2.0-4-amd64
gyp ERR! command "node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--release"
gyp ERR! cwd /home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/wait.for/node_modules/fibers
gyp ERR! node -v v0.12.2
gyp ERR! node-gyp -v v1.0.3
gyp ERR! not ok
Build failed
npm WARN engine follow@0.11.4: wanted: {"node":"0.10.x || 0.8.x"} (current: {"node":"0.12.2","npm":"2.7.6"})

> kerberos@0.0.9 install /home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/mongodb/node_modules/kerberos
> (node-gyp rebuild 2> builderror.log) || (exit 0)

make: Entering directory `/home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/mongodb/node_modules/kerberos/build'
 CXX(target) Release/obj.target/kerberos/lib/kerberos.o
make: Leaving directory `/home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/mongodb/node_modules/kerberos/build'

> bson@0.2.21 install /home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/mongodb/node_modules/bson
> (node-gyp rebuild 2> builderror.log) || (exit 0)

make: Entering directory `/home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/mongodb/node_modules/bson/build'
 CXX(target) Release/obj.target/bson/ext/bson.o
make: Leaving directory `/home/m1ndfuck/node_modules/sock-rpc-stats/node_modules/mongodb/node_modules/bson/build'
npm ERR! Linux 3.2.0-4-amd64
npm ERR! argv "node" "/usr/local/bin/npm" "install" "sock-rpc-stats"
npm ERR! node v0.12.2
npm ERR! npm  v2.7.6
npm ERR! code ELIFECYCLE

npm ERR! fibers@1.0.5 install: `node ./build.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the fibers@1.0.5 install script 'node ./build.js'.
npm ERR! This is most likely a problem with the fibers package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node ./build.js
npm ERR! You can get their info via:
npm ERR!     npm owner ls fibers
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/m1ndfuck/npm-debug.log
root@m1ndfuck:/home/m1ndfuck# node -v
v0.12.2
root@m1ndfuck:/home/m1ndfuck# npm -v
2.7.6
root@m1ndfuck:/home/m1ndfuck#

Any hint?