linux

by Tim Robinson on Uncategorized

Fixing node-gyp: Permission Denied when running as root

This node-gyp permission denied issue happens when, as the root user, you globally install node modules that require compilation with node-gyp. As root is the default user on Digital Ocean this seems to affect many people and should probably be fixed at the root cause.

Luckily there is a pretty simple workaround for this:

npm config set user 0

The other solution is to create a regular user and install everything as them. This is safer as installing modules as root means they could do anything to your system. I’d recommend installing all node modules as a normal user without root access if you’re on a machine with anything important on it.

 
by Tim Robinson on Uncategorized

Linux Traffic control hfsc what is [default $CLASSID]

While learning our traffic control setup at Cloud9 I came across this line:

tc qdisc add dev $IFACE root handle 1: hfsc default 12

Most of it is explained by these great in depth guides to tc and hfsc traffic shaping:

http://linux-tc-notes.sourceforge.net/tc/doc/sch_hfsc.txt
http://linux-ip.net/articles/hfsc.en/

And the man page at:

http://manpages.ubuntu.com/manpages/trusty/man8/tc-hfsc.8.html

The only thing I couldn’t figure out was what default 12 means. I originally thought it was some inbuilt default policy that comes included with tc. But it actually refers to the class that you’ve defined that it should fall back to using when nothing else matches.

So in our case we had the following other classes defined:

tc class add dev $IFACE parent 1:1 classid 1:10 hfsc rt m1 $HALF_MAXUP d 10ms m2 $MAX_UPRATE
tc class add dev $IFACE parent 1:1 classid 1:11 hfsc ls m2 $HALF_MAXUP ul m2 $MAX_UPRATE
tc class add dev $IFACE parent 1:1 classid 1:12 hfsc ls m2 $LOW_MAXUP ul m2 $LOW_MAXUP
tc class add dev $IFACE parent 1:1 classid 1:13 hfsc ls m2 $VERY_LOW_MAXUP ul m2 $VERY_LOW_MAXUP

$IFACE is the interface we’re running the rules on and the rates such as $HALF_MAXUP are network speeds in kbps that we’ve set and are still experimenting with.

Below this we then had a bunch of rules that prioritize different traffic types which look like below:

# prioritize SSH
$TC filter add dev $IFACE protocol ip parent 1: prio 1 u32 match ip sport 22 0xffff flowid 1:10
$TC filter add dev $IFACE protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:10

# prioritize DNS
$TC filter add dev $IFACE protocol ip parent 1: prio 2 u32 match ip sport 53 0xffff match ip protocol 0x6 0xff flowid 1:10
$TC filter add dev $IFACE protocol ip parent 1: prio 2 u32 match ip dport 53 0xffff match ip protocol 0x6 0xff flowid 1:10

# prioritize application traffic
$TC filter add dev $IFACE protocol ip parent 1: prio 3 u32 match ip sport 8080 0xffff flowid 1:11
$TC filter add dev $IFACE protocol ip parent 1: prio 3 u32 match ip sport 8081 0xffff flowid 1:11
$TC filter add dev $IFACE protocol ip parent 1: prio 3 u32 match ip sport 8082 0xffff flowid 1:11

# Make UDP and ICMP really slow, they are rarely used for legitimate purposes
$TC filter add dev $IFACE protocol ip parent 1: prio 4 u32 match ip protocol 17 0xff flowid 1:13
$TC filter add dev $IFACE protocol ip parent 1: prio 4 u32 match ip protocol 1 0xff flowid 1:13

These rules ensure our users are able to ssh, resolve sites and host their applications at full speed, while throttling those who may be attempting to use Cloud9 for nefarious reasons. We also have other blocking rules not included here for security reasons.

So all outbound traffic that doesn’t match these rules is subject to the rules of class 1:12 which gives users $LOW_MAXUP bandwidth with a $LOW_MAXUP burst speed for uploads. That’s what the default 12 at the end means.

Let me know if you have any questions about this or suggestions on how to improve our traffic shaping. I’m no expert on this and didn’t write most of these rules, but just sharing what I’ve learnt to help others having the same confusions.