The classic zx spectrum game lightcycles recreated in JavaScript that runs in the browser.

Sometimes, when setting up and debugging a container it is extremely useful to be able to ‘shell into’ the container to get a closer look at what’s going on. This is a quick guide on how to get shell console access into a running Docker container. UPDATE. If you are running docker version 1.3 or greater then you should use docker exec instead (see docker man pages for more info). The only use case that still requires the use of nsenter is where the user assigned to the container prevents you from doing tasks inside.

nsenter is a great command line tool for accessing docker containers. Unfortunately it isn’t available in Ubuntu 14.04 at the time of writing. Fortunately building it from source is quite simple. Get the latest version of util-linux from kernel.org https://www.kernel.org/pub/linux/utils/util-linux/ At the time of writing the latest version was v2.25, which is the version used in the examples here. Install the build dependencies sudo apt-get install build-essential libncurses5-dev libslang2-dev gettext zlib1g-dev \ libselinux1-dev debhelper lsb-release pkg-config po-debconf autoconf \ automake autopoint libtool python2.

Like most Linux users, I appreciate the power and flexibility of open source and like that my development PC runs the same software as my servers. While building a desktop PC and installing Ubuntu on it is great n’ all, I wanted my next Linux desktop to be a little more portable. Coding in the garden anyone? yes please! Now, I really like the look of Apple’s macbook air. But apple’s wonder machine is out of my budget and I’d also have had to switch from Linux to MacOX.

Using an SSH tunnel is a great way to administer remote services without having to directly expose them to the internet. You basically forward a port from your local machine (e.g. your Linux desktop) to a port on the remote server. You can then connect to the port on localhost and the magic of ssh will forward the port securely to the remote machine. To the remote server you’ve connected locally on localhost!

If you do a fair amount of tinkering on cloud servers, such as EC2 or Digital Ocean, then you’ll have noticed that each time you start a server it gets a new IP address allocated. Then when you next log on to the server via ssh the server gets added to your known_hosts file.

Before long your known_host file has dozens, if not hundreds of entries for servers that you’ve long shut down and discarded.

At first I would edit the known host file and remove the server entry once I’d done with the server, but this got tiresome after a while.  So, I decided that for the servers I’m just messing about on I’d rather not add the server into the known_hosts file at all.

Using Bitbucket from a network that does not allow ssh (port 22) connections means that doing a git push or pull using the standard git ssh remote won’t work. git remote add origin https://[email protected]/USERNAME/REPOSITORY.git Where USERNAME is your user/login name and REPOSITORY is the name of the repository you want to access. If you don’t want to enter your password every time you connect to the remote you can include the password in the remote url: git remote add origin https://USERNAME:PASSWORD@bitbucket.

How to add a swap file (not partition) to linux

A quick’ cut and paste’ tip for setting the timezone on Centos / Red Hat Linux. To set it for the UK, as the root user, enter the following: ln -sf /usr/share/zoneinfo/Europe/London /etc/localtime All of the different timezones can be found in /usr/share/zoneinfo under various subdirectories, e.g. Europe, Africa etc. To set the appropriate timezone just replace the symbolic link at /etc/localtime to point the the relevant timezone file. In the example above the symbolic link, /etc/localtime is updated to point to the London timezone file.