[[PageOutline]] = 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 [http://debian.org/ 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 }}} Replace "fubar" with the name of the package you are interested in. 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 [/newticket?keywords=sharedsoftware 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 [/newticket ask for help] first. If you want to go ahead and try, read this entire page 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 install the software to a location that you have permission to write to. You can use the `--prefix` option to configure most 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 [/newticket 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 [/newticket 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.