Version 1 (modified by 16 years ago) ( diff ) | ,
---|
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 ffmpeg
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.