Source vs Package Managers on the job

I always go for the package manager first. However, instances where I compile from source:

• The package is woefully out of date. This is more common than it should be.
• I want to install to a different location than the package defaults. I do this a lot on my Amazon EC2 instances so I can install to my EBS device rather than ephemeral, local storage.
• The app needs to be compiled using different options or with a source patch. PHP is the most common culprit here.
• The app is a dependency of something else you want to install and your package manager doesn't have a matching headers/development package. Not all that common, but it does happen from time-to-time.

As a system admin should you know how to deal with source...sure. In a production environment is it advisable to use packages from source. I would say only under certain situations where the distro's version doesn't support your requirements.

The problem with source is that you are then responsible for making sure that you apply any security patches to the code for the application and any library it relies on. Or you have to continually version bump to stay with the latest secure code which isn't a good option for a production server most of the time. While a distro will back port security patches to the version they support for many years. So simply by telling your package manager to update the system will keep it up to date with security patches. This is much more manageable in the long run.

As a system admin you also have to think about who comes behind you. Inheriting a system with a mishmash of source packages is not much fun and will cost the company more money in the long run.

I have come across a few places, which seems to say today's admins really don't know what they are doing, because they don't do things from scratch and instead prefer package management.

I believe that this statement is not accurate. Surely, a system administrator has to know how to compile from source, and it is very rare that one has not done it at least once.

However, as everything in life, deciding which method one should use, is based on one's requirements:

1) If the official distribution's package versions cover your needs for features, then the answer is clear: Use the package system. There is no excuse to the ease the package system provides. It installs automatically all dependencies, and your work is limited in the configuration files. Most famous distributions (Redhat, Centos, debian) keep the official packages constantly updated, since they backport all security patches, and you don't have to worry about security updates, since they can be updated automatically. This is very useful in a production server, since you spend your time in system administration, auditing etc, rather than constantly checking if a package has a new update.

2) If your project needs the latest features that only the latest versions - of the applications you need - provide, then you have to compile everything from source. It is time consuming, and you have to constantly monitor if a new version gets out with security bugs. Then you have to recompile everything. The disadvantage is clear. However the problem is bigger if you have to administer more than 1 server. In this case the easiest way is to build a repository of your own, build your own packages based on the source code of the latest version, and then use again the package manager on each server to update the packages using your repository.

If you are going to use any kind of automated configuration management, like puppet, chef, cfadmin, et al, then you'll need to be comfortable with how your *nix's packages work. Also know where the good 3rd party repositories are as they generally contain updated packages if you are using an Enterprise or LTS distribution.

If you need to compile something from source then I recommend using a consistent layout and naming scheme. Read up on how autoconf works and make use of the --prefix directive.

Personally, I like to install my custom compiled stuff in /opt, for example

/opt/nginx/nginx-0.6.44

then I create a current symlink

/opt/nginx/current

then symlink all the binaries from the package in a known location like

/opt/bin

for example

cd /opt/bin && find /opt/nginx/current/bin -type f -exec ln {} \;

Will allow me to add /opt/bin to my $PATH and switching between versions of nginx is as simple as installing the new version into /opt/nginx/nginx-$VERSION and updating the symlink

today's admins really don't know what they are doing, because they don't do things from scratch and instead prefer package management.

I don't think an admin doesn't know what they are doing because they don't choose to use package management. There are many good reasons to use a package manager. I think they don't know what they are doing when they don't take to to understand; how their package management system works, how to build their own packages, or when they should build their own packages.

You can usually get commercial support from distributions like Redhat, and Ubuntu. You will find getting support is a lot easier if you are using the officially supported packages and not something you built yourself.

There are also a few commercial applications out there that require you use the official supported packages to actually make the product function.

If one were a UNIX/Linux administrator, is it fair to use package managers and is it trustworthy

The advantages of packages from official major distributions like Redhat, Ubuntu, Debian, and others is that lots of people are using them, there is strength in numbers. All major distributors offer the source you need to rebuild the package yourself. But if you don't trust the distributors to build a package, how can you even trust that there is nothing wrong in the source you downloaded? Do you have the skills to perform a code audit of the source code? Will you be able to detect a back door in the source or an exploitable bug? At a certain point you are going to have to trust someone because you probably won't have time to review every line of code that goes into an operating system.

on a job interview if asked to set up Apache, does one reach for the source or the package manager?

To answer the question you need to take some time to study the requirements. Frequently asking the right types of questions on your job interview will be more impressive then a simple response. You could also, just pick one method, and tell them a few reasons why that method is good, and a few reasons why that method is bad.

• Do they need a stable commercial support
• Do they need some unusual feature that is not enabled
• Do expect to support multiple servers in the future
• Do you have enough hosts running apache on your network that you can afford do your own monitoring of the upstream security feeds, and security lists.

I am a bit confused, as there are two ways to install applications. One being to configure and make from source and the other from a package manager.

You skipped the third, option. Build your own packages and maintain a local repository referenced by a package manager. Building your own packages, is preferable because what you have built will be part of the standard system. Someone familiar with the package manager will know how to uninstall it. They will be able to get information about it.

If you're getting your packages from a reputable location, you're probably ok. I wouldn't have any particular qualms about installing Apache with apt-get, but I should qualify that with noting that we mostly use Linux for non-critical functions.