Installing software on an MFPL shared server

This FAQ documents what should do if you realize that you need a software package available to your MFPL shared server account, and it's not already available.

As an example, say you need a software package called fubar, and it's not on your shared server.

check if it is available in debian

A good first step would be to check if the package is available within ​debian, the operating system we use at May First/People Link. You can do this from the command line on your shared server with:

apt-cache search fubar

This just checks to see if the package is available within the debian system. If it is, then it's almost always the case that you should ask to have it installed system-wide on your server by opening a ticket. Remember to explain in your ticket why you want the software installed.

If there's some reason why a particular package shouldn't be installed on a particular server, that discussion can take place in the ticket. And remember that the more packages we have installed on a shared server, the more maintenance (and therefore administrative time and attention) that server needs. So don't be surprised if there's a general resistance to installing new packages. That resistance helps keep our shared infrastructure stable.

build it yourself

If the package isn't available in debian, but it looks like it could be built on a standard GNU/Linux system, you could try installing it yourself. If you're not comfortable with that already, it's probably worthwhile ask for help first.

If you want to go ahead and try, read this entire section first!

typical install process

the typical build/install process for software on GNU/Linux is:

• set up a build directory, so that your work is contained in it:

  mkdir ~/src/fubar
  cd ~/src/fubar
  

• download the source:

  wget http://example.com/fubar/downloads/fubar-1.14.tgz
  

• unpack the downloaded "tarball", and switch into the directory it creates:

  tar xzf fubar-1.14.tgz
  cd fubar-1.14
  

• build the package:

  ./configure
  make
  

• install the package on the server:

  make install
  

installing on a shared server from a non-privileged account

But! On a shared server, the system-wide locations for software are locked down, and you can't put new tools there. This is to provide a stable, reliable environment for everyone using the server: if anyone could add or update any tool on the system, you wouldn't be able to trust that your web server would keep running the same way it does now.

So those last two steps need to change; you need to installing the software to a location that you have permission to write to. You can use the --prefix option to most configure scripts to declare this. A common choice is to install the software to a common subdirectory of your home directory. In this example, the user will install the fubar package to the sw subdirectory of their home directory. So that would make those last two steps look like this:

• build the package:

  ./configure --prefix=$HOME/sw
  make
  

• install the package:

  make install
  

But this is still not quite done, because you want to be able to run fubar by just typing:

fubar

But the computer doesn't know where to find fubar, which has probably been installed in $HOME/sw/bin/fubar now. You can tell it to search in $HOME/sw/bin when it is looking for files by doing:

PATH=$PATH:$HOME/sw/bin

If you want that to happen at each boot, you might want to add it to the end of your ~/.bashrc file, like so:

echo 'PATH=$PATH:$HOME/sw/bin' >> ~/.bashrc

maintaining packages built yourself

Be aware that simply installing a package is not sufficient to keep it reliable and stable, particularly when you're operating on a network. updates (security and otherwise) are frequent in modern, free software, and you should pay attention to the updates available for any packages you've installed. Some new versions fix bugs that could otherwise cause you serious problems, up to and including hijacking your account and snooping on, tampering with, or destroying your data.

Most software projects have an RSS feed or an announcement mailing list that you can subscribe to to be alerted of new versions. If you're doing anything unusual with the tool, you should probably also subscribe to any forum or mailing list that they have for users.

troubleshooting build errors

Sometimes, even the ./configure step will fail, because the package needs certain build tools that aren't available to you on a shared host. If this happens, you should probably open a ticket explaining what you are trying to do, and asking for those build tools to be installed.

Other times, make will fail. You should make a copy of the output of the run where it seems to be failing, and ask about that. If you want, you can easily store the output of an entire make session using the script command. To do this, instead of running make, run:

script -c make build.log

When the make is complete, you'll see a full copy of what just happened in build.log

ask for help

Above all, if you have trouble with any of this, you should ask for help! The easiest way to ask for help is to open a new ticket concerning the software involved. Be prepared to explain why you need the software, not just what it is. Often, other people will have suggestions for ways you can accomplish your goal that are worth considering, even if you really want to figure out the tool you were halfway to using.