4

I'd like to install software from source (e.g., third-party GitHub repos) to my machine. Generally /usr/local/bin and /usr/local/src are for non-distribution-specific software, right?

Taking ownership of /usr/local seems risky: anything running with my privileges could make nefarious changes to executables in /usr/local/bin, or to sources in /usr/local/src.

But the alternative, building and installing as root (sudo), doesn't make sense to me. GitHub warns against running git as root. Even if I copied the sources from a local repo elsewhere, I'd have to run make and make install as sudo, meaning the software I'm installing could hijack the rest of my machine.

I could just put everything in /home, but that seems like a cop-out -- isn't this what /usr/local is for?

  • 1
    You only have to run make install as root, the compiling (make) can be done as normal user . The same holds for git – luckyrumo Jul 13 '15 at 21:57
  • @luckyrumo: How does that work if my user doesn't have write privileges for /usr/local/src? – mgiuffrida Jul 13 '15 at 22:05
  • Hm okay, you're right. I always download and compile in my home directory since I don't see a reason to use /usr/local/src. – luckyrumo Jul 13 '15 at 22:08
  • 2
    Then don't build in /usr/local/src. Keep a pristine copy there, and then copy to another directory (say /tmp, or your home directory) and build there. – muru Jul 13 '15 at 22:28
  • Please remember to mark an answer... – eyoung100 Jul 14 '15 at 3:13
6

Don't take ownership of /usr/local. Use sudo to install software. But use your own account to build it.

git clone …    # or tar -x or …
cd …
./configure
make
sudo make install

Why not take ownership of /usr/local? You nailed it. That would allow any program running on your account to write there. Against a malicious program, you've lost anyway — infecting a local account is the big step, escalating to root isn't difficult (e.g. by piggybacking on the next time you run sudo). But against a badly configured program, it's better not to have writable bits in the system-wide directories.

As for the choice between /usr/local and your home directory: your home directory is for things you only want for your account, /usr/local is for things that are installed system-wide.

  • don't forget about checkinstall. CheckInstall keeps track of all the files created or modified by your installation script ("make" "make install" "make install_modules", "setup", etc), builds a standard binary package and installs it in your system giving you the ability to uninstall it with your distribution's standard package. unix.stackexchange.com/tags/checkinstall/info – Evgeny Vereshchagin Jul 15 '15 at 3:01
1

Approaches

There are 2 approaches to this solution.

  1. /usr/local/{src,bin} is for custom built software installed by the System Admin, ie, root, in which case sudo or su - should always be used, making this question a moot point.
  2. Install pre-compiled binary updates, i.e those found in your distributions package management mechanism, but unsupported versions in /opt. Also in this case, done by the system admin.

Reasoning

In both cases the software installed in these locations are not supported upstream by your distribution, and therefore require root privileges to override potentially dangerous actions. Also, /usr/local/src is not where source is compiled. It's where source is stored. Remembering these two items ensures that things like Using Awesome window manager on CentOS 7 don't happen.


Don't Be Confused

If you're only looking to update software that's already installed, you should do it through the preferred method for adding testing software to your distribution. Some of the major methods:

  • Arch Based - The AUR, aka Arch User Repository
  • Debian Based - The PPA, aka Personal Package Archive
  • Redhat Based - The EPEL, aka a Third Party Repository
0

Most build systems honor --prefix=$path where /usr/local is usually the default.

So normally you build + test + install, where the build + test step can occur anywhere you have write permission + the install step is usually...

sudo make install (installs into --prefix)

One way to setup your build environment is to have a build directory with a work + attic subdirectory.

My build environment is...

/smartbuild/work - where packages build (from tarball or git/svn/etc)
/smartbuild/attic - where tarballs cache (so rebuilds skip tarball download)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.