Linux Setup For Software Installations

The Mac OS is great for creative production, but for computers embedded in new media software installations, Linux gives a lot more flexibility and control, ranging from the ability to schedule automated tasks to the full-on tweaking of most every part of the operating system.

The price you pay for that control, of course, is in complexity. Setting up Linux machines can mean hours of spent in forums and lots of trial and error. This tutorial is meant to save some of those headaches. It explains how to set up a Linux computer for running software installations, and some settings that will make maintaining them easier, too.

Below are some things I’ve found helpful when setting up Linux computers for this purpose. Casey Reas has some great tips for OS X users, and Rafael Lazano-Hemmer’s best practices for new media artworks is also very useful.

We’ll cover two common Linux distributions, though this may work on other versions as well:

• Raspberry Pi computers running Raspbian – great for low-power needs, when a cheap, small computer will work
• A “regular” computer running Ubuntu – I often use old Mac Minis for this, for when you need more computing power or a more fully-featured OS

This tutorial assumes you know the basics of the command line (but really, if you don’t know how to do that, using Linux for your project might not be the best choice anyway) and that you can figure out how to install Linux on your machine.

Above: a dissected Mac Mini running Ubuntu. Less overheating = less fan noise, and looks super cool too.

UPDATE IT

Before we do anything else, it’s best to update your newly-minted computer.

Create a list of available updates:

Then install them (can take a really long time):

CHANGE YOUR PASSWORD

I like to create a piece-specific password, one that is easy to remember but hopefully pretty secure (ex: the full title of the piece, with capital letters).

Enter the new password twice and you’re set. Be sure to note this somewhere and include it with the piece’s instructions.

ENABLE SSH

SSH (Secure SHell) lets you remotely log in to the computer, either to start the piece or do maintenance. I always turn this on, and often do all the rest of the steps this way (especially for projects that will run headless). Note that for this to work, both computers must be on the same network, or directly connected by an ethernet cable. When done, you can log off your SSH session with the command logout .

RPI
Raspberry Pi makes this really easy – the option is in the raspi-config  menu!

Go to Interfacing Options  and hit return. Choose SSH  and select <Yes>  to enable it.

You can now log into your RPi from the Terminal with this command:

For example, with the default settings you’d use ssh pi@raspberry  – enter your password and you’re in!

UBUNTU
For Ubuntu, you’ll need to install SSH server:

Unlike the RPi where you can log in with your user- and host-name, for Ubuntu you’ll also need to create a static IP address.

Find something that starts with auto eth0  and modify it to look like this:

The IP address can be anything you want. This may require a restart to take effect. You now log in using:

FTP

SSH lets you run commands remotely, but you can’t (easily) send files that way. FTP (File Transfer Protocol) gives a really simple GUI that can upload to and download files from your Linux machine, just like you would for a website. These instructions use terminology for Transmit (which I use) but other programs will be very similar. Just like SSH, FTP requires you be on the same network or directly connected.

Create a new SFTP connection and put in the info below:

• Server: username@hostname  or username@ipaddress
• Enter your password (choose to save it or not)
• Remote path: path to your project files on the Linux machine (ie /home/pi/Desktop ), optional but makes transfers easier
• Local path: path to project files on your computer, optional

Log in and make sure it works. You can make folders in FTP, move project files, etc. Between SSH and FTP, you can do a lot to manage and back up your Linux machine.

RUNNING HEADLESS

Some projects don’t require a monitor, keyboard, or mouse – a setup we call “headless”. To run our Linux machine that way, we’ll need a few things set. First, we’ll want to boot to the command line.

RPi
Again, RPi makes this easy with raspi-config  – go to Boot Options > Desktop/CLI and select Console Autologin. (Note that this changes how you log in, which we’ll talk about in the next step.)

Reboot to test.

UBUNTU
We need to change some lines in this file:

First, to boot into text mode, change this line: GRUB_CMDLINE_LINUX=""  to this GRUB_CMDLINE_LINUX="text" .

Comment out this line by putting a #  in front of it – this gets rid of the purple startup screen:

Finally, un-comment (remove the # ) this line – this makes our prompt black-and-white only):

Reboot to test.

RUNNING PROCESSING HEADLESS
Processing can run headless on the full version of Ubuntu (but not RPi, sadly) using xvfb. First, install the necessary libraries:

Then run your sketch from the command line, adding xvfb-run  in front. This will nicely do all the things necessary to create a virtual window for your sketch to run in!

No need to package it as a Linux app or anything! More info on this Processing wiki page.

AUTO-LOGIN

For autonomous installations, you won’t (probably) want your computer to require a password before starting. NOTE! This is dangerous for computers connected to the internet! Do this at your own risk! A password will still be required for SSH and FTP, though.

RPI
You might have already done this for the “Headless” step – go to the raspi-config  – go to Boot Options > Desktop/CLI and select Console Autologin. You can also do this by editing this file:

Find these two lines (probably 2/3-way down) and un-comment them:

(Note that pi  here is your username, and may be different.) Save the file and run this command to make the changes go into effect:

Reboot your RPi to test.

UBUNTU
For Ubuntu, we also need to edit a file, but do this a little differently than usual:

tty0  is the main console window – we could change this for secondary consoles too, but for automatic setups that’s probably not necessary or what we want.

Add these lines:

Reboot to test.

AUTO REBOOT

A good way to ensure everything runs smoothly is a regular reboot. This can be scheduled using Cron, which is a very helpful tool for any regularly-occurring tasks (like Twitter bots, backing up files, etc).

This command will make the computer reboot every night at 4am with a 5-minute warning, in case someone was working on the machine:

For more info on the formatting of Cron commands (like how to parse its weird time syntax) see this tutorial.

RUN THE PIECE ON STARTUP

All this setup is great, but if you have to log in to start the piece every morning, that’s a pain. Fortunately, we can also specify scripts or programs to run on startup: Cron will reboot the computer and your piece will start again!

The file rc.local  lets us specify things that happen on startup:

Before the exit 0  line, add your command:

NOTE! Adding the &  at the end is really important!

Leaving it off can cause major, major problems that are very hard to fix (of course [cough] I’ve never done that). The &  means run the command in the background, so you can still SSH/FTP in, and kill the command if necessary. If you don’t include it, your entire computer can get locked up forever and it will take some serious hacking to get it back.

If you do need to kill the task, go to the console or SSH in:

This stops any process that contains a certain text – if you wanted to stop a Processing script, you’d use “processing” as the text to match.

RPi and GUI-Based Apps
While there might be other ways to do this, I found that neither rc.local  or Cron’s @reboot  worked for running GUI-based applications (like an exported Processing sketch). First, look in the /.config  folder and see if there’s a folder called autostart  – if not, create it:

In the autostart  folder, we’ll make a .desktop file that will run the app. Run sudo nano YourAppName.desktop  and add the following:

Save the file and reboot – your piece should start up after X loads!

SHORTCUT TO THE PIECE

If you want to get really fancy, or if you’re doing lots of debugging, you can make a shortcut to your piece. Instead of having to change directories and type in a long command, you can just type in your new shortcut.

To do this, we’ll add a command to the .bashrc  file:

At the top, create your command:

For example, to run a headless Processing sketch:

Now you can run your piece by just typing run  in the command line! The custom command can have several lines to it, like a shell script, in case you wanted to change directories or modify files before running the piece.

SERIAL PORT WITHOUT SUDO

You might be using hardware that connects over a serial port, a task that might require a root user. (I had this issue for a piece using an Arduino, for example.) Since our computer logs in and runs the piece automatically, we can’t input the root password manually.

To get access to serial port without sudo, run these commands:

The /dev/ttyUSB0  is the port we want access to, so you may have to do some sleuthing to figure out which ones you’ll need (try  dmesg | grep tty to list ports currently in use).

QUIET SSH LOGIN

Ok, now we’re getting really fancy here – if the copyright notice you get when you connect via SSH bothers you, or if you wanted to include custom text (like instructions on how to run the piece) it can be changed easily:

(“MOTD” stands for “message of the day”. )Type in whatever you want and save. Note this will still include the “last login” info, which is helpful for web-enabled projects so you can watch for malicious logins.

To get rid of the message entirely, use:

ANYTHING ELSE?

Hope this was helpful – if you come up with additional ideas or want to suggest best practices, please leave them in the comments!