Network Bridging on Ubuntu

Install bridge-utils:

sudo apt-get install bridge-utils

Create a bridge device:

sudo brctl addbr br0

Add interfaces to bridge:

sudo brctl addif br0 eth0 eth1

Bring interfaces down and back up. Remember to bring up the bridge device as well:

sudo ifconfig eth0 down
sudo ifconfig eth1 down
sudo ifconfig eth0 up
sudo ifconfig eth1 up
sudo ifconfig br0 up

Finally, to enable internet as well:

ip route add default via <gateway-ip>

# If the above command fails, first run
dhclient br0

Rotating Display in Ubuntu

Query your list of devices:

xrandr -q

now set the desired orientation like this:

xrandr --output LVDS1 --rotate right
xrandr --output LVDS1 --rotate left
xrandr --output LVDS1 --rotate inverted
xrandr --output LVDS1 --rotate normal

Replace LVDS1 with the desired screen to rotate.

Forward remote ssh port

ssh user@10.99.99.99 -L 0.0.0.0:3333:10.99.99.99:22

This command connects to user at 10.99.99.99. Then, it connects to the local port 22 on 10.99.99.99, and makes it accessible for the remote host at port 3333.

Optionally, the argument ‘-N’ can be supplied, to avoid creating a login shell.

Adding system accounts

Some user accounts are used for running system services so they cannot interfere with files outside their user space. To create a system account, do the following:

useradd -r <username>

This creates a user with no password, and no home directory. You can optionally create a home dir by supplying the -m option.

useradd -r <username> -m

Simple upstart script

All upstart scripts must be placed in

etc/init/

and must be owned by root. The script filename must end in .conf

A simple upstart scrip can look like this

start on startup
setgid foo
setuid foo
respawn
respawn limit 15 60
exec <my-app>
start on startup

This entry tells upstart to run the application on startup. This can be a run-level specification as well.

setgid foo
setuid foo

Sets user and group id if needed.

respawn
respawn limit 15 60

Upstart will restart the application if it dies, but will stop if if restarts 15 times within 60 seconds.

authbind. Using priviledged ports in non-priviledged applications

Install authbind.

Create a file in

/etc/authbind/byport

with the port-number you wish yo expose. For example, to expose port 80, create the following file:

/etc/authbind/byport/80

Change the user of the file to the user the application is running as, and change the access rights to 755.

Now, run the application like this:

authbind <my-app>

The application now has access to port 80, without requiring sudo rights to run! Authbind can optionally be run with the –deep parameter, to allow all sub-processes access to the port as well.

Chili Chutney

  • 2 hele hvidløg
  • 1 løg
  • 1 dåse hakkede tomater
  • 1 lille dåse tomatpuré
  • 1 pose (150g) soltørrede tomater
  • chili efter smag. Mindst en håndfuld
  • 4 store spiseskeer brun farin
  • 1 sjat æblecidereddike (1/2 – 1 dl, efter smag)
  • Salt. ca. 1 teskefuld. Efter smag. Kan undlades.

Procedure:

  1. Pres hvidløg i presser.
  2. Hak løg fint
  3. Hak chili fint, med kerner og det hele
  4. Svits løg og hvidløg i olivenolie, til hvidløgene begynder at blive lidt lyst brune. Ikke ved fuld varme. Det brænder hurtigt på.
  5. Tilsæt tomatpuré og rør rundt, og lad tomatpurén svitse lidt.
  6. Tilsæt hakkede tomater, chili, soltørrede tomater, brun farin og æblecidereddike. Lad stå og simre ved svag varme i ca 30. minutter.
  7. Lad stå og køle af. Når temperaturen er nede ved håndtemperatur, gives hele blandingen en tur i blender eller med stavblender til chutneyen har den ønskede konsistens.
  8. Smag til med salt.

Javascript self-invoking functions

Example of a self-invoking javascript function. Notice the parenthesis around the entire function declaration.

(function() {
    var foo = 20;
})();

The parenthesis around the function exist to differentiate it from an actual function definition. It would not be possible to auto-invoke it with the () at the end.

Another syntax for self-invoking functions is also available:

! function() {
    var foo = 20;
}();

Again, the ‘!’ is there to show that its not a function declaration.

Spawning windows in i3 Tiling Window Manager

the i3 window manager comes pre-packaged with a tool called i3-msg, which can be used to send instructions to i3.

For example, if you want to set a vertical tiling of windows, normally you would press “mod + V”. This can be done programmatically like so:

i3-msg split v

Note that the i3-msg is maintains the state that you set. For example, if you want to spawn three windows after setting i3 to vertical splits:

i3-msg split v
xterm -e <my-command>
xterm -e <my-command2>
xterm -e <my-command3>

Useful commands:

i3-msg split v      // split vertical
i3-msg split h      // split horisontal
i3-msg workspace 5  // spawn windows at specific workspace
i3-msg kill         // kill current focused window
i3-msg focus parent // switch to containing window

Git Config

Example of useful content in the .gitconfig gile

[alias]
	st = status -sb
	br = branch
	ca = commit -a
	p = push
	pt = push --tags
	co = checkout
	subub = submodule update --init --recursive
	merge = merge --no-ff
	ls = log --pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate
	diff = diff --word-diff
	find = "!git ls-files | grep -i"
	f = "!git ls-files | grep -i"
	grep = grep -Ii
	gr = grep -Ii
[user]
	name = John Doe
	email = user@foo.com
[color]
	diff = auto
	status = auto
	branch = auto
[core]
	editor = vim
[push]
	default = tracking

Self Extracting Shell Scripts

A shell script can have a binary payload attached to it, that it can extract from itself.

Say for example that you have the following shell script format:

<some shell commands>

PAYLOAD:

<some payload>

The “PAYLOAD:” is a line, with ONLY that written on it. This is a marker, used to find the binary payload later on.

Imagine that we create the following script to append binary payloads to a shell script:


cat install.sh.in > install.sh

echo "PAYLOAD:" >> install.sh

cat $1 >> install.sh

The above script will create a new file install.sh from the install.sh.in template (makes it easier to test the script, because you do not have to rewrite install.sh everytime :))

Then the PAYLOAD: line is appended, and finally, whatever was given as an argument ($1 is the first argument to the script. $0 is the script itself) is appended.

Now we can create the install.sh.in script:


#First we find the linenumber which holds the marker-text

#We do this by grepping in text mode (-a) and we want line numbers printed (-n)

#and we grep on the script itself ($0). We then pipe this to the cut command, which splits #the output from grep on the ':' character. Then we extract the first entry from the split (-f #1). This should give us the line number.

match=$(grep -a -n '^PAYLOAD:$' $0 | cut -d ':' -f 1)

#The payload starts AFTER the PAYLOAD marker

payload_start=$((match+1))

#Now we can extract the binary part of the script itself, using the tail command.

#'-n +' means "start from line number. As a demo we pipe the binary data

#to tar to show the files inside. (given that the binary payload was a tar to begin

#with!)

tail -n +$payload_start $0 | tar -zt

#remember to exit before the payload! Otherwize the binary payload will be

#interpreted as script.

exit 0

Serial to serial over network (ser2net,socat)

This setup is a small testing example I made at work. We have a bluetooth modem on a small controller, on /dev/ttyAT3. I wanted to debug a piece of software that must interface with that serial port, but on my development PC, instead of transferring the software to the board.

First, ser2net is configured on the controller, for forwarding /dev/ttyAT3 to an IP socket:

3001:raw:0:/dev/ttyAT3:9600 NONE 1STOPBIT 8DATABITS -XONXOFF -LOCAL -RTSCTS

The above config for ser2net routes ttyAT3 to a socket on port 3001.

Now, on the development PC, I need to route the remote socket to a local, virtual serial port. For this I use socat:

socat -d -d TCP4:10.99.99.99:3001 PTY:

Now socat routes the remote socket to a /dev/pts/? device! and I can debug my application ash though it had access to the actual /dev/ttyAT3 on the controller.

socat could of course be used on the controller as well, instead of ser2net.