Executive Executive Summary

A Debian/Ubuntu/Solaris server is not a Home-PC running Windows/Macintosh¹. Specifically, one does not just download and install software on such a server.

Executive Summary

1. Please do not install software on a Debian/Ubuntu/Solaris system unless it is packaged by Debian/Ubuntu/A reputed Solaris packager.

2. If you must violate (1) then install files in your home directory or under /usr/local/stow/<package_name> or /opt/<package_name>.

3. Above all do not install software "all over the disk" unless you are willing to re-install the system if it all gets "messed"-up. In particular, do not do this on a server.

4. If you must violate (1)-(3) on a server machine then send an e-mail to CC giving complete details of what changes you have made and why you have made them and how you plan to unmake them if a better solution is found.

Summary

I am quite annoyed that software has been installed on "neem" in a way that will require a considerable amount of work to clean-up. While this is not creating any immediate problems it will create problems when we want to install and remove software from neem.

There are cases when the only way to test something is to install it on a server --- and there may even be cases when such software is not packaged by Debian/Ubuntu but in such cases you must follow (4). In particular, there must be a way to remove each and every file you have installed and undo every modification that you have made to the system.

I have outlined some "Best Practices" below but there is nothing better than reading the Debian system administration guide which is available on "banyan" under /usr/share/doc/debian-reference.

In greater detail (Best Practices)

I logged onto "neem" and found that a lot of files/software related to CUPS has been installed on this machine without following accepted practices of managing Debian and Ubuntu machines. Perhaps these practices are not well understood so I am taking this opportunity to set them down here.

1. The basic principle of managing such machines is "package management" (PM). This ensures that:
   1. Files are always found in expected places on the system. (The Filesystem Heirarchy Standard prescribes where files are to be placed).
   2. Upgrades and automated intallation of dependencies are easily achieved.
   3. It is easy to remove files that are no longer required.
   4. It is easy to spot extraneous files in the case of a system breach.
2. PM is best achieved by: a. always using the prescribed tools "apt" and "dpkg" and their user interfaces like aptitude and synaptic to install software.
   2. never installing files in /usr except under /usr/local/<package_name>. It is better to use /opt/<package_name>.
   3. documenting all the changes you make in an e-mail to the CC.
3. So what do you do when you want to test a new piece of software which is not packaged by Debian/Ubuntu?
   1. Check for .deb packages created by the software developer or someone else at backports.org and other package archives. But be careful to check that these are properly created packages.
   2. It is likely that the software can be compiled and even tested by a non-root user. Do so.
   3. If there are files that must be installed as root then use a "sandbox" like:
      1. a machine with few users --- like your desktop machine.
      2. a chroot, or a virtual machine (learn to construct one using debootstrap or rootstrap or vserver).
   4. even in such cases (as (c)) you should build the package as a non-root user and see where it is trying to install files.
   5. Preferably use a tool like "stow" to ensure that it installs files in a separate heirarchy that can easily be cleaned up if necessary.