where to put binaries so they are always in path and can be found easily

Question

I am making quite some binaries, scripts etc that I want to install easily (using my own rpms). Since I want them accessible for everyone, my intuition would be to put them in /usr/bin;

• no need to change PATH

however; my executables now disappear in a pool of all the others; how can I find back all the executables I put there in an easy way. I was thinking of:

• a subdirectory in /usr/bin (I know I cannot do this; just to illustrate my thinking)
• another directory (/opt/myself/bin) and linking each executable to /usr/bin (lots of work)
• another directory (/opt/myself/bin) and linking the directory to /usr/bin (is this possible?)

what would be the "best, most linux-compliant way" to do this?

EDIT: we had a discussion on this in the company and came up with this sub-optimal option: put binaries in /usr/bin/company with a symbolic link from /usr/bin. I'm not thrilled with this solution (disussion ongoing)

Answer 1

If you bundle your binaries into your own RPMs then it's trivial to get a list of what they are and where they were installed.

Example

$ rpm -ql httpd| head -10
/etc/httpd
/etc/httpd/conf
/etc/httpd/conf.d
/etc/httpd/conf.d/README
/etc/httpd/conf.d/autoindex.conf
/etc/httpd/conf.d/userdir.conf
/etc/httpd/conf.d/welcome.conf
/etc/httpd/conf.modules.d
/etc/httpd/conf.modules.d/00-base.conf

I would suggest putting your executables in either /usr/bin or /usr/local/bin and rolling your own RPM. It's pretty trivial to do this and by managing your software deployment using an RPM you'll be able to label a bundle with a version number further easing the configuration management of your software as you deploy it.

Determining which RPMs are "mine"?

You can build your RPMs using some known information that could then be agreed upon prior to doing the building. I often build packages on systems that are owned by my domain so it's trivial to find RPMs by simply searching through all the RPMs that were built on host X.mydom.com.

Example

$ rpm -qi httpd
Name        : httpd
Version     : 2.4.7
Release     : 1.fc19
Architecture: x86_64
Install Date: Mon 17 Feb 2014 01:53:15 AM EST
Group       : System Environment/Daemons
Size        : 3865725
License     : ASL 2.0
Signature   : RSA/SHA256, Mon 27 Jan 2014 11:00:08 AM EST, Key ID 07477e65fb4b18e6
Source RPM  : httpd-2.4.7-1.fc19.src.rpm
Build Date  : Mon 27 Jan 2014 08:39:13 AM EST
Build Host  : buildvm-20.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://httpd.apache.org/
Summary     : Apache HTTP Server
Description :
The Apache HTTP Server is a powerful, efficient, and extensible
web server.

This would be the Build Host line within the RPMs.

The use of /usr/bin/company?

I would probably discourage the use of a location such as this. Mainly because it requires all your systems to have their $PATH augmented to include it and is non-standard. Customizing things has always been a "right of passage" for every wannabee Unix admin, but I always discourage it unless absolutely necessary.

The biggest issue with customization's like this is that they become a burden in both maintaining your environment and in bringing new people up to speed on how to use your environment.

Can I just get a list of files from RPM?

Yes you can achieve this but it will require 2 calls to RPM. The first will build a list of packages that were built on host X.mydom.com. After getting this list you'll need to re-call RPM querying for the files owned by each of these packages. You can achieve this using this one liner:

$ rpm -ql $(rpm -qa --queryformat "%-30{NAME}%{BUILDHOST}\n" | \
    grep X.mydom.com | awk '{print $1}') | head -10
/etc/pam.d/run_init
/etc/sestatus.conf
/usr/bin/secon
/usr/bin/semodule_deps
/usr/bin/semodule_expand
/usr/bin/semodule_link
/usr/bin/semodule_package
/usr/bin/semodule_unpackage
/usr/sbin/fixfiles
/usr/sbin/genhomedircon

Answer 2

An obvious suggestions is to name your binaries or your packages in a special way. So for example you could prefix them with cm-, per your initials as given in this post. If you are installing rpms they need to go into /usr/bin (if they are user level executables), per the FHS. They should not go into /usr/local/bin for example. That is for local installs only.

For the record, I don't find the idea of putting binaries in a special directory and linking them appealing at all, though I suppose such things are sometimes done. Bear in mind also that if you need to find out which binaries belong to which package, you can just query the packaging system.

Answer 3

Binaries not part of the system or distribution are usually in

/usr/local/bin

the directory is usually in the standard $PATH so that your binaries will be found.