rlm@1:  
rlm@1: AUTHOR: Matthias S. Benkmann <article at winterdrache dot de>
rlm@1: 
rlm@1: DATE: 2007-10-20
rlm@1: 
rlm@1: LICENSE: Creative Commons Attribution-Share Alike 3.0
rlm@1:          (http://creativecommons.org/licenses/by-sa/3.0/)
rlm@1: 
rlm@1: SYNOPSIS: More Control and Package Management using Package Users (v1.4)
rlm@1: 
rlm@1: DESCRIPTION:
rlm@1: -You want to know which packages your files belong to ?                 
rlm@1: -You want to deinstall software that doesn't have make uninstall ?      
rlm@1: -You are bothered by programs installed setuid root behind your back ?  
rlm@1: -You don't like packages quietly overwriting files from other packages ?
rlm@1: -You don't like package managers like RPM ?                             
rlm@1: -YOU WANT TOTAL CONTROL USING ONLY UNIX BUILTINS ?                      
rlm@1: 
rlm@1: ATTACHMENTS:
rlm@1: http://www.linuxfromscratch.org/hints/downloads/attachments/more_control_and_pkg_man/more_control_helpers.tar.bz2
rlm@1: 
rlm@1: PREREQUISITES:
rlm@1: For use with LFS book 6.2: Brain.
rlm@1: For use with LFS book later than 6.2: Brain (awake, good working condition).
rlm@1: 
rlm@1: HINT:
rlm@1: 
rlm@1: ########################################################################### 
rlm@1:  Contents
rlm@1: ###########################################################################
rlm@1: 
rlm@1: 1. Preface
rlm@1: 2. Overview
rlm@1: 
rlm@1: - PART 1: General Information -
rlm@1: 
rlm@1: 3. Package Users
rlm@1:   3.1 Introduction
rlm@1:   3.2 User Name
rlm@1:   3.3 Groups
rlm@1:   3.4 Home Directory
rlm@1: 4. Common Problems
rlm@1:   4.1 Introduction
rlm@1:   4.2 General Procedure
rlm@1:   4.3 Permission Changes
rlm@1:   4.4 Ownership Changes
rlm@1:   4.5 Write to Non-Install Directory
rlm@1:   4.6 Delete or Overwrite File
rlm@1:   4.7 /sbin/ldconfig
rlm@1:   4.8 What Commands to Run as a Package User
rlm@1: 5. The more_control_helpers Archive
rlm@1:   5.1 Overview
rlm@1:   5.2 The Wrappers
rlm@1:   5.3 add_package_user/install_package
rlm@1:   5.4 forall_direntries_from
rlm@1:   5.5 uninstall_package
rlm@1:   5.6 list_suspicious_files/list_suspicious_files_from
rlm@1:   5.7 list_package
rlm@1:   5.8 grep_all_regular_files_for
rlm@1:   5.9 The etc Directory
rlm@1:   5.10 Temporary Files
rlm@1:   
rlm@1: - PART 2: LFS Specifics -
rlm@1: 
rlm@1: 6. Pre-Chroot Phase (Chapter 5)
rlm@1: 7. Chroot Phase (Chapter 6)
rlm@1:   7.1 Preparations
rlm@1:   7.2 Walkthrough: Installing linux-libc-headers
rlm@1:   7.3 Known Issues with LFS Packages
rlm@1: 8. Sanity Checks
rlm@1:   8.1 Suspicious Files
rlm@1:   8.2 References to Temporary Files
rlm@1: 
rlm@1: - APPENDICES -
rlm@1: 
rlm@1: A. Security Issues
rlm@1:   A.1 NFS
rlm@1:   A.2 Daemons
rlm@1: B. Package Categories
rlm@1: C. Acknowledgements and Changelog
rlm@1:   
rlm@1: 
rlm@1: ########################################################################### 
rlm@1:  1. Preface
rlm@1: ###########################################################################
rlm@1: 
rlm@1: Let's say I have written a program that you would like to use. To make it
rlm@1: easier for you I come over to install it for you. Would you give me the root
rlm@1: account and then leave the room ? No ? Then why do you give it to complete
rlm@1: strangers who you have never seen in your life, to install software packages
rlm@1: pulled from some Internet server, that come with no warranty and don't even 
rlm@1: list their contents in the README, although they will happily spread them all 
rlm@1: over your system ?
rlm@1: 
rlm@1: It is a mystery why Unix admins who wouldn't even trust their employer with
rlm@1: more than a normal user account carelessly execute complex and incomprehensible
rlm@1: installation scripts with full root rights.
rlm@1: 
rlm@1: Users and groups are the basic security principle in a Unix system. They have
rlm@1: been used successfully for a long time to monitor who has created a file and 
rlm@1: to control who is allowed to delete or change it. But this control has only 
rlm@1: been imposed on the files of ordinary users. What a waste! I suggest to extend
rlm@1: this control to all system files. 
rlm@1: 
rlm@1: The general idea is to create package users, i.e. user accounts with restricted
rlm@1: rights, to build and install software packages, rather than doing these tasks 
rlm@1: as root. Not only does this give you more control over what build and install 
rlm@1: scripts may or may not do, it can also serve as a quite useful package 
rlm@1: management system.
rlm@1: 
rlm@1: 
rlm@1: #############################################################################
rlm@1:  2. Overview
rlm@1: #############################################################################
rlm@1: 
rlm@1: This hint is divided into 3 parts. The first part contains general information
rlm@1: about the package user method. This part is the most important part of the
rlm@1: hint. Read it thoroughly. The second part explains how to apply the package 
rlm@1: user method to the building of an LFS system. 
rlm@1: Finally, part 3 of this hint is the Appendix with information that would not
rlm@1: fit anywhere else or that is not of general interest.
rlm@1: 
rlm@1: It is inevitable that part 2 will become outdated with time as the LFS book 
rlm@1: changes and new versions of the software packages used with LFS are released. 
rlm@1: I make no attempt to track these changes. 
rlm@1: When someone reports an issue with a package I will incorporate
rlm@1: it into the hint, but larger changes that might be required due to changes in
rlm@1: the LFS build methodology could take a long time to get included. The reason 
rlm@1: for this (aside from lack of time) is that I consider part 2 as bonus material 
rlm@1: that helps people get started but is not essential. Part 1 describes the 
rlm@1: concepts, which are independent of package versions or the LFS book, and you 
rlm@1: will have to rely on this information whenever part 2 fails. Don't forget 
rlm@1: that part 2 only deals with the packages used by the LFS book. For all the 
rlm@1: other packages you install on your system after that even an up-to-date 
rlm@1: part 2 would offer no aid anyway.
rlm@1: 
rlm@1: The previous paragraph might sound discouraging, and as you read more from the
rlm@1: hint it is possible that you get the impression that the package user
rlm@1: method is complicated, causes lots of difficult problems and is overall too
rlm@1: much trouble for anyone but a real hardcore admin with programming experience.
rlm@1: But you would be mistaken. 
rlm@1: First of all, many things experienced as installation problems when working
rlm@1: with the package user system are in fact desirable features. 
rlm@1: If `make install' fails for some package, because it attempts to install a
rlm@1: file with the same name as a pre-existing file from another package, you
rlm@1: should not curse the fact that you have to spend additional time to resolve
rlm@1: this issue. Instead you should be happy that you have been alerted of this
rlm@1: collision that, had it gone unnoticed, could have messed up your system in
rlm@1: more or less subtle ways.
rlm@1: Secondly, the package user system is not an all-or-nothing approach. It
rlm@1: works on a per-package basis. If a package gives you too much trouble, you
rlm@1: can always decide to chicken out and finish the installation as root.
rlm@1: Finally, the more_control_helpers archive provided with this hint contains
rlm@1: several useful scripts that automate many aspects of software installation
rlm@1: as a package user and, together with the tips given in this hint, add a lot 
rlm@1: of value to the package user system. 
rlm@1: So do not pass judgement until you have read at least the complete part 1,
rlm@1: including the description of the more_control_helpers.
rlm@1: 
rlm@1: 
rlm@1: ---------------------- PART 1: General Information --------------------------
rlm@1: 
rlm@1: 
rlm@1: #############################################################################
rlm@1:  3. Package Users
rlm@1: #############################################################################
rlm@1: 
rlm@1:  3.1 Introduction
rlm@1:  ----------------
rlm@1: 
rlm@1: The basic idea of this scheme is easily explained. Every package belongs to a 
rlm@1: certain "package user". When you install a package, you build and install
rlm@1: the package as this package user, causing all files that are installed to be 
rlm@1: owned by the package user. As a consequence all the usual package management 
rlm@1: tasks can be comfortably achieved through the use of standard command line 
rlm@1: utilities. A simple `ls -l <file>' will tell you, for instance, what package 
rlm@1: <file> belongs to and a `find -user ...' command allows you to perform an 
rlm@1: operation on all the files belonging to a certain package, e.g. delete them 
rlm@1: to uninstall the package.
rlm@1: 
rlm@1: But package management is not all that package users are good for. Because
rlm@1: package users do not have root-rights, the installation of a package is
rlm@1: limited in what it can do. One thing that a package user is not allowed to do,
rlm@1: for example, is to overwrite files from a different package user. Clashes
rlm@1: between different packages that want to install a binary, library or header 
rlm@1: file of the same name are more common than you might think. With package users
rlm@1: you never run the risk of package B's installation destroying files from 
rlm@1: package A silently without you noticing. Every attempt of doing this during
rlm@1: package B's installation will cause a "Permission denied" or
rlm@1: "Operation not permitted" error so that you have the chance of taking 
rlm@1: appropriate steps.
rlm@1: Another thing that package users are not allowed to do is install setuid root 
rlm@1: binaries. The decision to make a binary setuid root is also something that a 
rlm@1: prudent admin does not want to leave up to the creator of a software package.
rlm@1: 
rlm@1: Usually package user accounts have no valid password so that only root can su 
rlm@1: to a package user, which ensures that package users do not open an additional 
rlm@1: way into the system and undermine security. But you *may* set passwords 
rlm@1: anyway to allow a co-admin who you want to be able to install and maintain 
rlm@1: certain software packages to do so without having access to the actual root 
rlm@1: account. This co-admin could for instance install, delete, change additional 
rlm@1: libraries which might be necessary for his workgroup. He would be unable, 
rlm@1: though, to remove or modify libraries which don't belong to him/her, such as 
rlm@1: libc.
rlm@1: 
rlm@1: 
rlm@1:  3.2 User Name
rlm@1:  -------------
rlm@1: 
rlm@1: You don't need to drive yourself nuts trying to come up with 8 character
rlm@1: names for the package users. I always use the name of the package without 
rlm@1: the version number, including dashes and possibly exceeding 8 characters in 
rlm@1: length, e.g. "util-linux", and in the several years that I've been using this 
rlm@1: scheme I have not encountered any problems, nor has anyone else reported 
rlm@1: trouble. The 8-character limit on user names seems to be a thing of the past.
rlm@1: 
rlm@1: TIP:
rlm@1:   You can use bash's programmable completion feature to save yourself some 
rlm@1:   typing when entering commands that take a user name as an argument, such as
rlm@1:   su, finger or pinky. The command 
rlm@1:   
rlm@1:       complete -o default -o nospace -A user su finger pinky
rlm@1:       
rlm@1:   tells bash to tab-complete words as user names for the commands su,
rlm@1:   finger and pinky.
rlm@1:   With this in place you can simply type `su linux-li<TAB>' and bash
rlm@1:   will complete this to `su linux-libc-headers' (assuming that you have a
rlm@1:   package user named "linux-libc-headers").
rlm@1:   "-o default" tells bash that if a suitable user name does not exist, the 
rlm@1:   default completion shall be attempted. 
rlm@1:   "-o nospace" prevents the addition of a space after the completed word.
rlm@1:   
rlm@1:   This is a very useful command to put into root's .bashrc and .bash_profile.
rlm@1:   
rlm@1:   BTW, at http://freshmeat.net/projects/bashcompletion/
rlm@1:   you can find a project that offers sophisticated completions for many
rlm@1:   other commands.
rlm@1:   
rlm@1:   Or switch to zsh (http://freshmeat.net/projects/zsh/). It's more powerful
rlm@1:   and less buggy than bash.
rlm@1: 
rlm@1: 
rlm@1:  3.3 Groups
rlm@1:  ----------
rlm@1: 
rlm@1: Every package user belongs to at least 2 groups. One of these groups is
rlm@1: the "install" group, which all package users (and only package users) belong
rlm@1: to. All directories that packages are allowed to install stuff in belong to 
rlm@1: the install group. This includes directories such as /bin and /usr/bin but 
rlm@1: excludes directories like /root or /. 
rlm@1: The directories owned by the install group are always group-writable. 
rlm@1: This would be enough for the package management aspects, but without further 
rlm@1: preparation this would not give added security or control because every 
rlm@1: package could replace the files from a different package (the change would 
rlm@1: be visible in the output from `ls -l', though).
rlm@1: For this reason all install directories get the sticky attribute. This
rlm@1: allows users to create new files and delete or modify their own files in
rlm@1: the directory, but files from other users can not be modified or removed.
rlm@1: In the rest of this hint, whenever the term "install directory" is used, it
rlm@1: refers to a directory that belongs to group install, is group-writable and
rlm@1: sticky. IOW, to turn <dir> into an install directory you would do
rlm@1: 
rlm@1:     chgrp install <dir> && chmod g+w,o+t <dir>
rlm@1: 
rlm@1: Although the install group is crucial for the package user system, it is 
rlm@1: implemented as a supplementary group, rather than as the primary group for
rlm@1: package users. This has at least 2 advantages. 
rlm@1: One advantage is that this makes it easy to get a list of all packages 
rlm@1: installed on the system with the command
rlm@1: 
rlm@1:     grep install /etc/group
rlm@1: 
rlm@1: A more important point, however, is that the primary group is the
rlm@1: one that files created by the package user will belong to. So it will be 
rlm@1: printed in the output of `ls -l' and is subject to find's "-group" test. 
rlm@1: This makes it very useful for organizational purposes. 
rlm@1: Following are some suggestions for how to use the primary group. 
rlm@1: 
rlm@1: 1. group name = user name
rlm@1: 
rlm@1:    Under this scheme the package user for the bash package would be
rlm@1:    bash:bash. `ls -l /bin/bash' would show something like this
rlm@1:    
rlm@1:    -rwxr-xr-x    1 bash     bash    1731859 Feb 30  2005 /bin/bash
rlm@1:    
rlm@1:    An important advantage of this scheme is that the user information is
rlm@1:    not lost when you make a file setuid root, which requires changing
rlm@1:    the file's owner. Because of this advantage, this scheme is the one
rlm@1:    recommended by this hint. However, the hint's instructions will work
rlm@1:    fine if you choose a different scheme.
rlm@1: 
rlm@1: 2. group name = package category
rlm@1: 
rlm@1:    Under this scheme, you would have certain package categories, such as
rlm@1:    games, system, net,... and bash, being a system program, would possibly
rlm@1:    belong to the system group, so that `ls -l /bin/bash' would show something 
rlm@1:    like this
rlm@1:    
rlm@1:    -rwxr-xr-x    1 bash     system    1731859 Jul  4  1776 /bin/bash
rlm@1:    
rlm@1:    This system is nice, but probably not as useful as #1 above, unless you
rlm@1:    have a real use for this categorization.
rlm@1:    For a possible categorization see Appendix B at the end of this hint.
rlm@1: 
rlm@1: 3. group name = identifier for a real group of people
rlm@1:    
rlm@1:    Under this scheme, the group would correspond to a real group of people in 
rlm@1:    meatspace, e.g. the group of admins responsible for the package. 
rlm@1:    If you need something like this you'll know best what it looks like and how
rlm@1:    to implement it, so no further discussion of this method will be given here. 
rlm@1:    
rlm@1: 
rlm@1:  3.4 Home Directory
rlm@1:  ------------------
rlm@1:  
rlm@1: Although it is well possible not to have a valid home directory for package
rlm@1: users or to have just one home directory shared by all package users, that
rlm@1: would be a wasted opportunity. Having individual home directories for the
rlm@1: package users offers a nice way to organize tarballs, patches, build scripts,
rlm@1: notes and all the other per-package information that you accumulate with time.
rlm@1: 
rlm@1: I suggest to use the home directory /usr/src/<package> for a package user
rlm@1: called <package> with the contents detailed below. The more_control_helpers 
rlm@1: archive contains scripts and skeleton files that implement this suggestion.
rlm@1: 
rlm@1:   .bash_profile: 
rlm@1:            You will usually want to have the same environment for all package
rlm@1:            users, so it is a good idea to make .bash_profile a symbolic link
rlm@1:            to a file in a central location. The more_control_helpers example
rlm@1:            uses /etc/pkgusr/bash_profile for this purpose.
rlm@1:            
rlm@1:   .bashrc: 
rlm@1:            As for .bash_profile a symlink is a good idea for .bashrc. The
rlm@1:            more_control_helpers example uses /etc/pkgusr/bashrc as link target.
rlm@1:            Under normal circumstances package users are not 
rlm@1:            (and even can not be) used for logging into the system, so there 
rlm@1:            is little reason to distinguish between login and non-login shells 
rlm@1:            for package users. Therefore, the example bashrc from 
rlm@1:            more_control_helpers simply sources .bash_profile.
rlm@1:            This makes sure that the same environment will be used, regardless
rlm@1:            of whether `su <package>' or `su - <package>' is used to become
rlm@1:            the package user.
rlm@1:            
rlm@1:   .project: 
rlm@1:            The contents of this file are printed by the commands
rlm@1:            `finger -l <user>' and 'pinky -l <user>' so .project is a
rlm@1:            good place for putting information about a package. You should 
rlm@1:            keep the contents of the .project files for your package users 
rlm@1:            up-to-date.
rlm@1:                        
rlm@1:   source code:
rlm@1:            The package user's home directory is the perfect place for storing
rlm@1:            a package's source code. This includes tarballs for different
rlm@1:            versions, CVS checkouts, unpacked source trees for building,...
rlm@1:            
rlm@1:   build script(s):
rlm@1:            Package user installations require more careful examination of build 
rlm@1:            and install messages than installations done as root, because of
rlm@1:            the package user-specific problems that can occur. Therefore it is
rlm@1:            unwise to simply copy'n'paste installation instructions from the
rlm@1:            LFS book. Build scripts allow you to use sophisticated output
rlm@1:            redirection for logging purposes that is impractical for direct
rlm@1:            entry on the command line. The build script skeleton included in
rlm@1:            the more_control_helpers archive demonstrates this.
rlm@1:                        
rlm@1: 
rlm@1: ############################################################################
rlm@1:  4. Common Problems
rlm@1: ############################################################################
rlm@1: 
rlm@1:  4.1 Introduction
rlm@1:  ----------------
rlm@1: 
rlm@1: Software installation is the crux of the package user system. Because 
rlm@1: installation scripts are often written under the assumption that they will be 
rlm@1: executed as root, they sometimes fail when executed by a package user.
rlm@1: Once this hurdle is passed and a package has been installed, there's usually no 
rlm@1: difference to a root-installation. A few programs insist that certain 
rlm@1: security-sensitive files be owned by root and will not execute otherwise,
rlm@1: but this is the rare exception. 
rlm@1: This chapter presents some more or less common problems that you will 
rlm@1: encounter when using package user accounts to install software, together with
rlm@1: guidelines on how to deal with these issues. 
rlm@1: Although I've said it before I will say it again: Many of the problems you
rlm@1: encounter during a package user installation are desirable features of the
rlm@1: package user system. You want installation to fail rather than have 
rlm@1: potentially dangerous actions performed behind your back with root rights.
rlm@1: 
rlm@1:  
rlm@1:  4.2 General Procedure
rlm@1:  ---------------------
rlm@1:  
rlm@1: When an installation fails it is almost always due to a "Permission denied"
rlm@1: or "Operation not permitted" error while executing a command during
rlm@1: `make install'. The first thing you have to do is identify the command that
rlm@1: is causing the problem. Usually you will find this in the make output right
rlm@1: before the error message. Once you have identified the culprit, you have to
rlm@1: decide whether the action that is attempted is illegitimate, partially
rlm@1: legitimate or completely legitimate. Illegitimate commands can simply be
rlm@1: removed from the Makefile. The other 2 possibilities are more difficult to 
rlm@1: deal with. You either have to change the condition that makes the command fail
rlm@1: or you have to change or sometimes remove the command and make a note if your
rlm@1: change suppresses a legitimate action.
rlm@1: 
rlm@1: After you've made changes to solve a certain problem, you reattempt the
rlm@1: installation and solve any remaining problems until the installation
rlm@1: succeeds. Once you've reached that point it is time to perform any remaining
rlm@1: legitimate actions that you've had to disable, such as make certain binaries
rlm@1: setuid root.
rlm@1: 
rlm@1: Note that often Makefiles are generated during the configure step, sometimes
rlm@1: even later in the build process. If you want to apply changes before the
rlm@1: configure step you will usually have to edit files called "Makefile.in".
rlm@1: 
rlm@1:  
rlm@1:  4.3 Permission Changes
rlm@1:  ----------------------
rlm@1: 
rlm@1: Some unsophisticated build systems that don't use the mkinstalldirs script to 
rlm@1: create installation target directories are very poorly written. Instead of 
rlm@1: testing whether a target directory exists, they simply attempt to create 
rlm@1: it with default permissions. This problem usually manifests as a line such
rlm@1: as "install -d $(prefix)/bin" in the Makefile. In the common case where 
rlm@1: prefix=/usr this would attempt to create the /usr/bin directory. If the target
rlm@1: directory already exists, as in this case, install will attempt to change its
rlm@1: permissions to the default permissions (or those passed on the command line).
rlm@1: Of course a package user is not allowed to change the permissions of
rlm@1: /usr/bin and so the command fails with a message like
rlm@1: "install: cannot change permissions of `/usr/bin': Operation not permitted"
rlm@1: This is an example of a completely illegitimate command. Just remove it from
rlm@1: the Makefile and everything's fine.
rlm@1: 
rlm@1:  
rlm@1:  4.4 Ownership Changes
rlm@1:  ---------------------
rlm@1: 
rlm@1: The most common situation when a package wants to change the ownership of
rlm@1: files during installation is when it wants to install setuid root binaries.
rlm@1: A common command to do this would be something like
rlm@1: "install -c -m 4755 -o root name /usr/bin/name" and the error message would
rlm@1: look like this:
rlm@1: "install: cannot change ownership of `name': Operation not permitted"
rlm@1: The change of ownership is hidden in the "-o root" switch to install, which
rlm@1: tells it to make the target file owned by root.
rlm@1: The command is at least partially legitimate, because you probably want the 
rlm@1: binary to be installed. Whether you actually want it to be setuid root is 
rlm@1: a different matter. The fact that a binary is commonly installed as setuid
rlm@1: root doesn't mean that you should make it so. You'll have to ask yourself if
rlm@1: normal users absolutely need to execute that binary. If you think they can
rlm@1: live without it you're better off not making it setuid root, because every
rlm@1: setuid root binary is a potential security hole. In any case you will
rlm@1: have to edit the Makefile and remove the offending switch, "-o root" in this 
rlm@1: case, so that the installation can succeed. Note that this will cause the
rlm@1: binary to be installed setuid <package>, which of course makes no sense at all.
rlm@1: If you don't intend to make the binary setuid root after the installation, it
rlm@1: is best to change the "-m 4755" to "-m 755", so that it won't be installed
rlm@1: setuid at all.
rlm@1: 
rlm@1: TIP:
rlm@1:   When you make a binary setuid root after the installation, use
rlm@1:   `chown root /usr/bin/name' and not `chown root:root /usr/bin/name'.
rlm@1:   This way you can keep original group of the file (i.e. the group of the 
rlm@1:   package user) intact. With the user name = group name scheme recommended for
rlm@1:   package users this makes sure that you can identify the source package of
rlm@1:   the binary even after making it setuid root.
rlm@1:   Note that as a security measure chown resets the setuid bit,
rlm@1:   so you will have to do `chmod u+s /usr/bin/name' after the chown.
rlm@1: 
rlm@1:  
rlm@1:  4.5 Write to Non-Install Directory
rlm@1:  ----------------------------------
rlm@1: 
rlm@1: Sometimes packages want to create files or directories in non-install 
rlm@1: directories. 3 situations have to be distinguished in this case. The 1st
rlm@1: possibility is that the target directory should be an install directory.
rlm@1: An example of this is /usr/share/aclocal. This directory is not among the
rlm@1: standard system directories created when building an LFS system. It will be
rlm@1: created by the first package that has files to install there and will be
rlm@1: owned by the corresponding package user. The next package that wants to write
rlm@1: in it will fail to install. The remedy is simple. Just make the directory an
rlm@1: install directory. You don't even need to be root to do it. The package user
rlm@1: that owns the directory has the rights to make that change.
rlm@1: 
rlm@1: The 2nd possible reason for a package wanting to write to a non-install
rlm@1: directory is that the failing command is only partially legitimate, i.e. you
rlm@1: do want to have installed whatever it is meant to install, but you want it in
rlm@1: a different location. For example some packages install binaries that are not
rlm@1: meant to be called directly. The default location for these binaries is
rlm@1: sometimes called libexec and with prefix=/usr the package will attempt to 
rlm@1: create /usr/libexec. In cases such as this you often don't have to change 
rlm@1: any Makefiles. There is either a configure switch to change the directory in
rlm@1: question or it is just a matter of overriding a Makefile variable as in
rlm@1: `make libexecdir=/usr/lib install'.
rlm@1: 
rlm@1: The 3rd possible reason for an attempt to write to a non-install directory is
rlm@1: that the command in question is illegitimate, i.e. you don't want to have
rlm@1: installed whatever the package wants to install. As usual with illegitimate
rlm@1: commands you can edit the Makefile and just remove them. In the case of
rlm@1: a whole directory whose installation you want to suppress it could be too
rlm@1: much effort to remove all of the offending commands that want to install
rlm@1: files there. In this case an approach similar to that from the previous
rlm@1: paragraph can be more effective. Either through configure switches or 
rlm@1: overriding of variables you change the directory in question to something
rlm@1: like <builddir>/foobar, where <builddir> is the directory in which build 
rlm@1: commands are run (i.e. usually the top of the unpackaged source
rlm@1: tree). This will cause the package to create the unwanted directory inside
rlm@1: the build tree, which doesn't cause any permission problems and has the nice
rlm@1: side effect that it'll be deleted together with the build directory when you
rlm@1: clean up after the build.
rlm@1: 
rlm@1: 
rlm@1:  4.6 Delete or Overwrite File
rlm@1:  ----------------------------
rlm@1: 
rlm@1: In a perfect world one package should not mess with another package's files,
rlm@1: but in the real world conflicts do happen occasionally. While a normal
rlm@1: sysadmin installing as root won't notice this until it's too late, an admin
rlm@1: employing the package user system will have to deal with conflicts right away.
rlm@1: When a package tries to overwrite or delete a file or directory that is owned
rlm@1: by another package the attempt will fail. It will fail even inside install
rlm@1: directories because of the sticky bit.
rlm@1: Although sometimes difficult to implement, the solution to such a conflict is
rlm@1: easy to describe. You need to either remove (or rename) the old file or 
rlm@1: directory before installing, or suppress the installation of the new file or 
rlm@1: directory. The installation of individual binaries is sometimes easy to
rlm@1: prevent. If you find a line such as "PROGRAMS=foo bar fubar barfu" in the
rlm@1: Makefile and "foo" is the name of the conflicting binary, just try removing
rlm@1: it from that list. That may be sufficient to prevent it from being installed.
rlm@1: 
rlm@1:  
rlm@1:  4.7 /sbin/ldconfig
rlm@1:  ------------------
rlm@1:  
rlm@1: Packages that install libraries sometimes run /sbin/ldconfig as part of their
rlm@1: installation so that the dynamic libraries are properly registered on the 
rlm@1: system. Because a package user is not allowed to overwrite /etc/ld.so.cache
rlm@1: ldconfig fails. This failure is commonly ignored in Makefiles, but you should
rlm@1: take note of it anyway, because you need to run ldconfig as root after
rlm@1: the installation. Alternatively, the more_control_helpers contain a wrapper 
rlm@1: program that calls /sbin/ldconfig and can be made setuid root.
rlm@1: 
rlm@1: 
rlm@1:  4.8 What Commands to Run as a Package User  
rlm@1:  ------------------------------------------
rlm@1: 
rlm@1: A common problem that new users of this hint have is to decide which commands
rlm@1: to run as a package user and which commands to run as root. The general rule
rlm@1: is that the only commands to run as a package user are those for building,
rlm@1: installing, removing and modifying the files that belong to *that* package 
rlm@1: user's package. Everything else should be run as root as usual. 
rlm@1: Some things you CAN/SHOULD NOT DO as a package user include
rlm@1: 
rlm@1:     - starting daemons
rlm@1:     - running udevstart
rlm@1:     - stripping /lib/*
rlm@1: 
rlm@1:  
rlm@1: ############################################################################
rlm@1:  5. The more_control_helpers Archive
rlm@1: ############################################################################
rlm@1: 
rlm@1:  5.1 Overview
rlm@1:  ------------
rlm@1: 
rlm@1: The more_control_helpers archive contains files to help you with building and
rlm@1: maintaining a system that uses the package user method. One thing that the
rlm@1: more_control_helpers archive contains are some LFS-specific temporary files 
rlm@1: that are only needed for the building of your LFS system and will not remain 
rlm@1: installed in a permanent location. Then there are the previously mentioned 
rlm@1: example files that demonstrate the suggested use of the package user home 
rlm@1: directories discussed earlier. Another group of files contained in the archive 
rlm@1: is a set of scripts that help with package management aspects, such as
rlm@1: creating new package users and checking which files a particular package has 
rlm@1: installed. Finally the more_control_helpers archive contains wrapper scripts
rlm@1: for some commands that handle many of the common problems discussed in the
rlm@1: previous chapter and make package user installations a lot easier.
rlm@1:  
rlm@1:  
rlm@1:  5.2 The Wrappers
rlm@1:  ----------------
rlm@1:  
rlm@1: The previous chapter discussed some common problems encountered during
rlm@1: package user builds and how to solve them. The solution to an installation
rlm@1: failure usually requires editing of one or more Makefiles. Making such changes
rlm@1: manually is annoying, even if it happens only occasionally, and whenever you
rlm@1: reinstall a package you have to make the changes again. Sed scripts and patches
rlm@1: can help with the latter problem, but they still have to be custom fitted to 
rlm@1: every package that needs them. There is a better solution, though. While there
rlm@1: exist countless ways to install files, only very few are commonly used by
rlm@1: packages. The 5 commands mkdir, chgrp, chown, chmod and install are responsible 
rlm@1: for most of the problems that arise during an LFS installation. This
rlm@1: prompted me to write wrapper scripts for these 5 commands that recognize
rlm@1: certain problematic patterns and deal with them automatically.
rlm@1: 
rlm@1: The instructions given in this hint in the LFS-specific part will instruct you
rlm@1: to install these wrappers in /usr/lib/pkgusr. If you do that and make sure 
rlm@1: that this directory is the first entry in the PATH of every package user, then
rlm@1: they will save you a lot of time and effort in dealing with recurring issues.
rlm@1: Note that if you want to choose a directory other than /usr/lib/pkgusr for
rlm@1: the wrappers, you need to be careful. Some configure scripts ignore certain
rlm@1: locations. A subdirectory of /etc would not work, for instance, because /etc
rlm@1: is one of these locations.  
rlm@1: 
rlm@1: It is important that you understand the limitations of the wrapper scripts.
rlm@1: They can fix some problems without user intervention, such as turning
rlm@1: newly created directories in /usr/share/locale into install directories.
rlm@1: But other problems by their very nature require manual intervention. When a 
rlm@1: program tries to install a setuid root binary, for instance, the wrapper 
rlm@1: scripts will suppress the attempt to change ownership of an installed file to 
rlm@1: root. While that allows `make install' to complete without error, it is only 
rlm@1: a partial solution. The wrapper scripts can not (and should not) take away
rlm@1: your responsibility for deciding whether the program in question should be
rlm@1: setuid root and to make it so, if necessary. To account for this, the
rlm@1: wrapper scripts will output warning lines to standard error that start with
rlm@1: "***" whenever they encounter a situation that needs to be reviewed.
rlm@1: Following the "***" in the message will be the original command that the
rlm@1: installation attempted to perform. 
rlm@1: You *must* check these "***" lines, examine the affected files or directories
rlm@1: and take appropriate action. Because of this it is imperative that you log
rlm@1: the messages output during a package installation and check these logs
rlm@1: religiously. The `build' script contained in the more_control_helpers archive
rlm@1: demonstrates some useful output redirection tricks to be used for this purpose.
rlm@1: The following 3 examples shall illustrate what kind of things you will have to
rlm@1: look for:
rlm@1: 
rlm@1: Example 1: "*** install -c rsh -o root -m 4775 /usr/bin/rsh"
rlm@1:    This message is output by the install wrapper during the installation of
rlm@1:    inetutils. The package wants to install the rsh binary setuid root. The
rlm@1:    install wrapper removes the "-o root" and changes the "-m 4775" to
rlm@1:    "-m 755" before passing the command on to the real install program.
rlm@1:    The important thing here is the "-m 4xxx", because this wants to set the
rlm@1:    setuid bit. Some install scripts throw in a "-o root" for good measure
rlm@1:    when installing an otherwise normal binary. In that case it's enough that
rlm@1:    the install wrapper strips out the "-o root" and you don't have to take
rlm@1:    further action. But when, as in the case of inetutils, the permissions
rlm@1:    indicate an attempt to make a binary setuid or setgid, then you will have to
rlm@1:    investigate. You need to decide if you want rsh to be setuid root and
rlm@1:    if you decide you do, you need to become root and issue commands like this:
rlm@1:        
rlm@1:        chown root /usr/bin/rsh
rlm@1:        chmod u+s /usr/bin/rsh
rlm@1:   
rlm@1: TIP:
rlm@1:    Be conservative with making binaries setuid. If you're unsure whether you
rlm@1:    will ever use a program (as non-root), you probably don't want it to be 
rlm@1:    setuid root. Keep in mind that you can always make the change later when
rlm@1:    you need it. When you apply this reasoning to rsh, for instance, you'll 
rlm@1:    probably end up not making it setuid root.
rlm@1: 
rlm@1: 
rlm@1: Example 2: "*** chgrp tty /usr/bin/write" 
rlm@1:    This is output by the chgrp wrapper during the util-linux installation.
rlm@1:    The util-linux package wants to install the write program as setgid tty,
rlm@1:    so that it is allowed to access other users' terminals. The chgrp wrapper
rlm@1:    prevents the changing of the group and the chmod wrapper prevents the
rlm@1:    setting of the setgid bit. You need to decide if you want the
rlm@1:    program to be setgid and if you decide in favor of this, do as root
rlm@1:    
rlm@1:        chgrp tty /usr/bin/write
rlm@1:        chmod g+s /usr/bin/write
rlm@1:    
rlm@1:     
rlm@1: Example 3: "*** install -d -m 755 /sbin"
rlm@1:    This is also from the util-linux installation. Util-linux, for no good
rlm@1:    reason, tries to recreate the /sbin directory. The install wrapper
rlm@1:    prevents this and you don't have to take any further action.
rlm@1: 
rlm@1:  
rlm@1:  5.3 add_package_user/install_package
rlm@1:  ------------------------------------
rlm@1:   
rlm@1: Whenever you install a new package on your system, you first have to create
rlm@1: a new user account, possibly create a new group and if you follow the advice
rlm@1: from this hint about making productive use of a package user's home directory,
rlm@1: you will have to set up that one, too. If you were to do all of this manually,
rlm@1: it would be a lot of work. The add_package_user and install_package scripts
rlm@1: in the more_control_helpers archive were written to automate this.
rlm@1: 
rlm@1: The install_package script is the one you will normally use to prepare for
rlm@1: installing a new package. It takes 3 parameters: the description of the 
rlm@1: package, the name of the package user account to create and the name of the
rlm@1: package user's primary group. So if you use the user=group scheme recommended 
rlm@1: by this hint and are as creative with your package descriptions as I am, then 
rlm@1: the command you'll use to prepare for installing package "foo" will be
rlm@1: 
rlm@1:     install_package foo foo foo
rlm@1: 
rlm@1: This command does 2 things. First it calls the add_package_user script with
rlm@1: the provided name, group and description plus sensible default values for 
rlm@1: add_package_user's other parameters. Then, after add_package_user has created 
rlm@1: the package user account, install_package automatically uses the su-command
rlm@1: to switch to the newly created account. If the default .bashrc and
rlm@1: .bash_profile scripts you use for package users contain the command "cd" as do
rlm@1: the examples in the more_control_helpers archive, you will be put right into
rlm@1: your package user's home directory so that you can start installing right away.
rlm@1: 
rlm@1: TIP:
rlm@1:   The install_package script can be called with a single argument that will
rlm@1:   be used as user name, group name and description. So instead of the above
rlm@1:   command a simple `install_package foo' would have sufficed.
rlm@1: 
rlm@1: The add_package_user script is responsible for the actual work of creating
rlm@1: a new package user account. Given a name, a group name and a description, it
rlm@1: will create a new user account with the provided primary group and the install
rlm@1: group as supplementary group. The groups will be created if necessary. 
rlm@1: add_package_user takes several arguments that determine the numeric ranges from
rlm@1: which it will pick the new user's UID and the GIDs for groups it needs to
rlm@1: create. add_package_user does not only create the package user account. It
rlm@1: will set up a home directory for it, too. You can either specify the directory
rlm@1: or go with the default, which is /usr/src/<name>, where <name> is the name
rlm@1: provided for the new account. If the home directory already exists, its
rlm@1: ownership and that of any existing contents will be changed to the new user.
rlm@1: If it doesn't exist, it will be created. 
rlm@1: 
rlm@1: The contents of /etc/pkgusr/skel-package will be copied into the new package
rlm@1: user's home directory (without overwriting pre-existing files). 
rlm@1: The more_control_helpers archive contains an example of a useful skel-package
rlm@1: directory. Note that symlinks are copied as symlinks, so skel-package is the
rlm@1: perfect place to put .bashrc and .bash_profile symlinks to a central location
rlm@1: that will ensure that all package user accounts have the same environment.
rlm@1: This is especially useful to make sure that all package users have the
rlm@1: wrappers directory in their PATH.
rlm@1: 
rlm@1:   
rlm@1:  5.4 forall_direntries_from
rlm@1:  --------------------------
rlm@1: 
rlm@1: The forall_direntries_from script is a very useful tool for common package
rlm@1: management tasks. It can roughly be described as a shortcut for 
rlm@1: "find / -user <name> -or -group <name>  <commands>", where <name> is the
rlm@1: first parameter to forall_direntries_from and <commands> are the remaining
rlm@1: parameters. However, forall_direntries_from takes care of making sure that
rlm@1: only relevant filesystems are scanned and shields you from certain unpleasant
rlm@1: surprises such as "Oops, I forgot that -depth negates -prune and have 
rlm@1: accidentally wiped out my home directory." or "Oops, I forgot to -prune /proc
rlm@1: and now I'm getting parity errors on my SCSI bus.". 
rlm@1: 
rlm@1: IMPORTANT NOTE: By default the forall_direntries_from script will only scan
rlm@1: the / filesystem and will not traverse other filesystems. If you have
rlm@1: relevant directories that need to be scanned on other filesystems, you will 
rlm@1: need to edit the script and add the respective mount point(s) to the
rlm@1: fs_to_scan list at the beginning of the script. The most likely candidate for
rlm@1: addition is "/usr".
rlm@1: 
rlm@1: Application examples:
rlm@1: 
rlm@1: Example 1: Create a tar.gz archive of all files that belong to <package>, e.g.
rlm@1:            for installing <package> on another machine without having to 
rlm@1:            recompile it there.
rlm@1: 
rlm@1:   forall_direntries_from <package> -fprint0 /tmp/files.lst
rlm@1:   tar --null -P -czf /tmp/archive.tar.gz --files-from=/tmp/files.lst
rlm@1: 
rlm@1: 
rlm@1: Example 2: Print out all setuid root binaries installed by <package>.
rlm@1:            (This only works if you use the user=group scheme.)
rlm@1:   
rlm@1:   forall_direntries_from <package> -perm +u+s -print
rlm@1: 
rlm@1: 
rlm@1: Example 3: List all binaries in /bin and /usr/bin belonging to "me" (i.e. the 
rlm@1:            package user executing the command) in alphabetical order.
rlm@1: 
rlm@1:   forall_direntries_from $(whoami) -path "*/bin/*" -printf "%f\n" | sort
rlm@1: 
rlm@1: 
rlm@1: Example 4: Uninstall <package>.
rlm@1:           
rlm@1:   See following section about the uninstall_package script.
rlm@1:  
rlm@1:                                    
rlm@1:  5.5 uninstall_package
rlm@1:  ---------------------
rlm@1: 
rlm@1: The uninstall_package script is basically a forall_direntries_from
rlm@1: application example in script form. The command `uninstall_package foo'
rlm@1: prints out the forall_direntries_from call that you have to use to delete
rlm@1: all the files of package "foo" (except for those in directories that 
rlm@1: forall_direntries_from is instructed not to scan) together with some
rlm@1: explanations. So in order to delete the files from package foo, you would 
rlm@1: execute `uninstall_package foo' and then copy'n'paste the command it prints
rlm@1: to the command line. As a safeguard the forall_direntries_from call has an 
rlm@1: "echo" in front of the "rm" and "rmdir" calls, so if you execute it, the files 
rlm@1: will not actually be deleted unless you remove both instances of "echo". 
rlm@1: It is recommended that you execute the command once with the echos and check 
rlm@1: the output to make sure that only the files you intend to be deleted are in 
rlm@1: the list. After you've confirmed that, you can use the shell's history to 
rlm@1: recall the command, edit out the instances of "echo" and remove the files 
rlm@1: for real.
rlm@1: 
rlm@1: 
rlm@1:  5.6 list_suspicious_files/list_suspicious_files_from
rlm@1:  ----------------------------------------------------
rlm@1: 
rlm@1: list_suspicious_files looks for filesystem entries that are out of the ordinary
rlm@1: in some way and prints a categorized list of them. Things that qualify as
rlm@1: suspicious include setuid and setgid binaries, world-writable files, symlinks 
rlm@1: that are possibly broken, hard links, install directories with unusual 
rlm@1: permissions and other stuff. You should run this script after you've finished 
rlm@1: your new LFS system and in regular intervals after that. Investigate the
rlm@1: listing closely.
rlm@1: 
rlm@1: TIP: 
rlm@1:   When you check the list of setuid and setgid files, don't forget to
rlm@1:   look at the actual user or group ownership of the file. It's easy to forget
rlm@1:   that, especially in the setuid case, because we often equate setuid with
rlm@1:   setuid root since setuid is seldom used with other user accounts.
rlm@1: 
rlm@1: list_suspicious_files_from takes a user or group name or a UID/GID as an 
rlm@1: argument and reports suspicious entries only when they are owned by the given 
rlm@1: user or group. Usually you would not call this script directly but instead
rlm@1: use list_package (described in the next section), whose output includes that 
rlm@1: from list_suspicious_files_from.
rlm@1: 
rlm@1: IMPORTANT NOTE: By default the list_suspicious_files script will only scan
rlm@1: the / filesystem and will not traverse other filesystems. If you have
rlm@1: relevant directories that need to be scanned on other filesystems, you will 
rlm@1: need to edit the script and add the respective mount point(s) to the
rlm@1: fs_to_scan list at the beginning of the script. The most likely candidate for
rlm@1: addition is "/usr".
rlm@1: 
rlm@1: 
rlm@1:  5.7 list_package
rlm@1:  ----------------
rlm@1: 
rlm@1: list_package tells you everything about a package's installed files. In
rlm@1: general you will want to execute something like 
rlm@1: 
rlm@1:    list_package $(whoami) >pkg.lst
rlm@1:    
rlm@1: right after installing a package and you can forget about the chronically
rlm@1: inaccurate content listings in the (B)LFS book. 
rlm@1: The following (shortened) output for util-linux speaks for itself:
rlm@1: 
rlm@1: PS1> list_package util-linux
rlm@1: 
rlm@1: EXECUTABLES (in */bin or */sbin)
rlm@1:   agetty, arch, blockdev, cal, cfdisk, [...] vidmode(->rdev), whereis, write
rlm@1: 
rlm@1: EXECUTABLES WITH NO MANPAGE (in */bin or */sbin)
rlm@1:   fsck.cramfs, mkfs.cramfs
rlm@1: 
rlm@1: MANPAGE SUMMARIES OF EXECUTABLES (in */bin or */sbin)
rlm@1:   agetty: alternative Linux getty
rlm@1:   arch: print machine architecture
rlm@1:   blockdev: call block device ioctls from the command line
rlm@1:   cal: displays a calendar
rlm@1:   cfdisk: Curses based disk partition table manipulator for Linux
rlm@1:   chkdupexe: find duplicate executables
rlm@1:   col: filter reverse line feeds from input
rlm@1:   [...]
rlm@1:   swapon: enable/disable devices and files for paging and swapping
rlm@1:   tailf: follow the growth of a log file
rlm@1:   tunelp: set various parameters for the lp device
rlm@1:   ul: do underlining
rlm@1:   umount: unmount file systems
rlm@1:   vidmode: query/set image root device, RAM disk size, or video mode
rlm@1:   whereis: locate the binary, source, and manual page files for a command
rlm@1:   write: send a message to another user
rlm@1: 
rlm@1: EXTRA MANPAGES
rlm@1:   /usr/share/man/man5/fstab.5
rlm@1:   /usr/share/man/man5/nfs.5
rlm@1:   /usr/share/man/man8/sln.8
rlm@1: 
rlm@1: EXTRA EXECUTABLES (not in */bin or */sbin)
rlm@1:   /usr/share/misc/getopt/getopt-parse.bash
rlm@1:   /usr/share/misc/getopt/getopt-parse.tcsh
rlm@1:   /usr/share/misc/getopt/getopt-test.bash
rlm@1:   /usr/share/misc/getopt/getopt-test.tcsh
rlm@1: 
rlm@1: ALL FILES
rlm@1:   /etc/fdprm
rlm@1:   /sbin/agetty
rlm@1:   /sbin/blockdev
rlm@1:   /sbin/cfdisk
rlm@1:   /sbin/ctrlaltdel
rlm@1:   /sbin/elvtune
rlm@1:   /sbin/fdisk
rlm@1:   /sbin/fsck.cramfs
rlm@1:   /sbin/fsck.minix
rlm@1:   /sbin/hwclock
rlm@1:   /sbin/losetup
rlm@1:   /sbin/mkfs
rlm@1:   /sbin/mkfs.bfs
rlm@1:   [...]
rlm@1:   /usr/share/man/man8/rootflags.8
rlm@1:   /usr/share/man/man8/setfdprm.8
rlm@1:   /usr/share/man/man8/setsid.8
rlm@1:   /usr/share/man/man8/sfdisk.8
rlm@1:   /usr/share/man/man8/sln.8
rlm@1:   /usr/share/man/man8/swapoff.8
rlm@1:   /usr/share/man/man8/swapon.8
rlm@1:   /usr/share/man/man8/tunelp.8
rlm@1:   /usr/share/man/man8/umount.8
rlm@1:   /usr/share/man/man8/vidmode.8
rlm@1:   /usr/share/misc/getopt
rlm@1:   /usr/share/misc/getopt/getopt-parse.bash
rlm@1:   /usr/share/misc/getopt/getopt-parse.tcsh
rlm@1:   /usr/share/misc/getopt/getopt-test.bash
rlm@1:   /usr/share/misc/getopt/getopt-test.tcsh
rlm@1: 
rlm@1: SETUID FILES
rlm@1:   -rwsr-xr-x "/usr/bin/mount"  root:util-linux
rlm@1:   -rwsr-xr-x "/usr/bin/umount"  root:util-linux
rlm@1: 
rlm@1: SETGID FILES
rlm@1:   -rwxr-sr-x "/usr/bin/write"  util-linux:tty
rlm@1: 
rlm@1: FILES WITH UNUSUAL PERMISSIONS
rlm@1:   -rwsr-xr-x "/usr/bin/mount"  root:util-linux
rlm@1:   -rwsr-xr-x "/usr/bin/umount"  root:util-linux
rlm@1:   -rwxr-sr-x "/usr/bin/write"  util-linux:tty
rlm@1: 
rlm@1: 
rlm@1: Note: list_package works regardless of the prefix you've installed the package
rlm@1:       with, so you can for instance configure with --prefix=/opt/package and
rlm@1:       list_package will work just fine (provided that /opt is on a
rlm@1:       filesystem configured to be scanned by forall_direntries_from and
rlm@1:       list_suspicious_files).
rlm@1: 
rlm@1: Note: list_package only considers manpages actually owned by the package to 
rlm@1:       list. It will not consider manpages installed by another package. This
rlm@1:       means that you may see executables identified as not having a manpage
rlm@1:       although they do have one courtesy of another package 
rlm@1:       (usually man-pages).
rlm@1: 
rlm@1: 
rlm@1:  5.8 grep_all_regular_files_for
rlm@1:  ------------------------------
rlm@1: 
rlm@1: This script is not really related to the package user system, but because of
rlm@1: its similarity to the other scripts I've included it anyway. The sole purpose
rlm@1: of this script is to identify files that store references to the build 
rlm@1: environment, specifically the /tools directory. Such references may point out
rlm@1: problems, since the /tools directory is supposed to be transient.
rlm@1: Don't forget that results for unstripped binaries and libraries are not 
rlm@1: reliable, because debugging information often includes references to the
rlm@1: build environment. These do not cause trouble (unless you're trying to debug
rlm@1: the objects in question after deleting /tools).
rlm@1:   
rlm@1: IMPORTANT NOTE: By default the grep_all_regular_files_for script will only scan
rlm@1: the / filesystem and will not traverse other filesystems. If you have
rlm@1: relevant directories that need to be scanned on other filesystems, you will 
rlm@1: need to edit the script and add the respective mount point(s) to the
rlm@1: fs_to_scan list at the beginning of the script. The most likely candidate for
rlm@1: addition is "/usr".  
rlm@1:   
rlm@1:   
rlm@1:  5.9 The etc Directory
rlm@1:  ---------------------
rlm@1:  
rlm@1: If you follow the instructions provided in the LFS-specific part of this hint,
rlm@1: the contents of the etc directory will be installed in /etc/pkgusr. The
rlm@1: directory contains a bashrc and bash_profile for package users that takes
rlm@1: care of package user specific details such as putting the wrappers directory
rlm@1: at the beginning of the PATH and calling cd, so that `su <package>' will
rlm@1: put you right into the package user's home directory. Also contained in the
rlm@1: etc directory is a skel-package directory as used by 
rlm@1: install_package/add_package_user to populate the home directories of newly
rlm@1: created package users.
rlm@1:  
rlm@1:  
rlm@1:  5.10 ldconfig.c
rlm@1:  --------------------
rlm@1: 
rlm@1: A lot of packages contain libraries. Having to manually call /sbin/ldconfig
rlm@1: as root after installing these packages can become annoying. It would be
rlm@1: much easier if one could grant package users permission to use /sbin/ldconfig.
rlm@1: Making ldconfig setuid root would be a simple and effective solution, but
rlm@1: there are some pitfalls. First of all it is imperative that ordinary users
rlm@1: be prohibited from executing ldconfig with elevated privileges. Otherwise
rlm@1: an ordinary user can overwrite and possibly read arbitrary files on the 
rlm@1: system. This can be prevented by making ldconfig owned by group install and
rlm@1: removing the o+x bit from the file mode. While this setup is no less secure
rlm@1: than running `make install' as root, one reason why we're using package users
rlm@1: is because we don't feel safe doing that. To protect against the (admittedly
rlm@1: very theoretical) danger of a malicious package user, the more_control_helpers
rlm@1: provide ldconfig.c. The only thing this program does is to call 
rlm@1: `/sbin/ldconfig -v' with an empty environment. Because it doesn't evaluate
rlm@1: any user input and doesn't pass any user-provided data to ldconfig, it can
rlm@1: safely be made setuid root. 
rlm@1: 
rlm@1: 
rlm@1:  5.11 Temporary Files 
rlm@1:  --------------------
rlm@1: 
rlm@1: 3 files in the more_control_helpers archive are only used during the 
rlm@1: installation of the base LFS system and are not installed permanently.
rlm@1: The first of them is the installdirs.lst file that contains a list of 
rlm@1: directories that should be install directories. 
rlm@1: The second file is sbin/useradd, which is a very primitive shell script that
rlm@1: adds a new entry to /etc/passwd. It allows us to add package users before
rlm@1: we have installed shadow, which provides a real useradd.
rlm@1: Finally there is groupadd, which is like useradd, only for /etc/group.
rlm@1: Both scripts, useradd as well as groupadd, do very little error checking and
rlm@1: only support the syntax needed by install_package/add_package_user. So don't
rlm@1: try anything funky with them.
rlm@1: 
rlm@1:   
rlm@1: ------------------------ PART 2: LFS Specifics ------------------------------
rlm@1: 
rlm@1: 
rlm@1: #############################################################################
rlm@1:  6. Pre-Chroot Phase (Chapter 5)
rlm@1: #############################################################################
rlm@1: 
rlm@1: Build Chapter 5 explained by the LFS book with the following changes:
rlm@1: 
rlm@1: coreutils:
rlm@1:   After running `make install' for the coreutils
rlm@1:   package, issue the following command (still from within the coreutils
rlm@1:   build directory):
rlm@1: 
rlm@1:     cp src/su /tools/bin
rlm@1:     
rlm@1:   This installs the su binary. Coreutils doesn't install su when working as
rlm@1:   non-root (which we do in Chapter 5), because su needs to be setuid root for
rlm@1:   normal operation and a non-root user cannot install setuid root binaries. 
rlm@1:   But for our purposes (i.e. su'ing from root to a package user) a non-setuid 
rlm@1:   su is enough, so we just copy coreutils' su to /tools/bin without making it
rlm@1:   setuid root.
rlm@1:   
rlm@1: more_control_helpers:
rlm@1:   When you have reached the end of Chapter 5, before you begin with Chapter 6 
rlm@1:   you will need to install the helper scripts in the /tools directory so that
rlm@1:   they are available once you've entered the chroot environment. Use the
rlm@1:   following commands to install the more_control_helpers in /tools:
rlm@1: 
rlm@1:     cd /tools &&
rlm@1:     tar xjf /path/to/more_control_helpers.tar.bz2 &&
rlm@1:     cd  more_control_helpers &&
rlm@1:     cp ./sbin/* /tools/bin
rlm@1:     
rlm@1:   Note that the target directory is "/tools/bin" in the cp command and 
rlm@1:   *not* "/tools/sbin", although the latter location would be more appropriate.
rlm@1:   The reason for this is simply that the LFS instructions do not add 
rlm@1:   "/tools/sbin" to the PATH (and neither do the instructions in this hint).
rlm@1: 
rlm@1: 
rlm@1: #############################################################################
rlm@1:  7. Chroot Phase (Chapter 6)
rlm@1: #############################################################################
rlm@1: 
rlm@1:  7.1 Preparations
rlm@1:  ----------------
rlm@1: 
rlm@1: Enter the chroot environment and follow the instructions from the book up to
rlm@1: but *not* including the installation of the first package (which at the time of
rlm@1: this writing is linux-libc-headers). Now install the more_control_helpers
rlm@1: files in their proper locations on the new LFS system:
rlm@1: 
rlm@1:     cp -a /tools/more_control_helpers/etc /etc/pkgusr &&
rlm@1:     chown -R 0:0 /etc/pkgusr &&
rlm@1:     cp -a /tools/more_control_helpers/lib /usr/lib/pkgusr &&
rlm@1:     chown -R 0:0 /usr/lib/pkgusr &&
rlm@1:     cp /tools/more_control_helpers/bin/* /usr/bin &&
rlm@1:     cp /tools/more_control_helpers/sbin/* /usr/sbin &&
rlm@1:     rm /usr/sbin/{useradd,groupadd}
rlm@1: 
rlm@1: Note that the useradd and groupadd scripts are not installed on the new LFS 
rlm@1: system. These scripts are just temporary workarounds we will use as long as 
rlm@1: the real useradd and groupadd are not available. Therefore they should only 
rlm@1: be in /tools/bin.
rlm@1: 
rlm@1: ATTENTION! If you decide to use a different directory than /usr/lib/pkgusr
rlm@1: for the wrappers, you have to be careful, because at least the glibc
rlm@1: configure script ignores certain directories when looking for programs. The
rlm@1: list of ignored directories for glibc includes, among others, everything that 
rlm@1: starts with "/etc", "/usr/etc" and "/sbin". Wrappers put into a directory that
rlm@1: matches any of these patterns would be ineffective.
rlm@1: 
rlm@1: Now it's time to create the install group:
rlm@1: 
rlm@1:     groupadd -g 9999 install
rlm@1: 
rlm@1: The GID 9999 has been chosen because the default range used by 
rlm@1: add_package_user for package user GIDs starts at 10000. Choose whatever number
rlm@1: you like.
rlm@1: 
rlm@1: Once the install group has been created you have to turn all the directories
rlm@1: that packages will install files in into install directories. To make this
rlm@1: easier I have compiled a list of install directories that can be found in
rlm@1: the file /tools/more_control_helpers/installdirs.lst. The following command
rlm@1: uses this list to assign the necessary directories to the install group.
rlm@1: Note that you will get several error messages because of non-existent
rlm@1: directories. This is because the list contains some directories not created
rlm@1: by LFS.
rlm@1: 
rlm@1:     chown 0:9999 $(cat /tools/more_control_helpers/installdirs.lst)
rlm@1: 
rlm@1: To be usable by package users, the directories will have to be group-writable
rlm@1: and should be sticky as has been explained in the beginning of this hint.
rlm@1: The following command sets the permissions appropriately.
rlm@1: You will get the same error messages as for the previous command.
rlm@1: 
rlm@1:     chmod ug=rwx,o=rxt $(cat /tools/more_control_helpers/installdirs.lst)
rlm@1: 
rlm@1: 
rlm@1:  7.2 Walkthrough: Installing linux-libc-headers
rlm@1:  ----------------------------------------------
rlm@1: 
rlm@1: At this point everything has been set up for creating the first package
rlm@1: user. At the time of this writing the first package installed in the LFS
rlm@1: book is Linux-Libc-Headers, so this package will serve as an example for how 
rlm@1: things are done. The command
rlm@1: 
rlm@1:      install_package 'Linux Headers' linux-libc-headers linux-libc-headers
rlm@1: 
rlm@1: will create a package user with user and group name linux-libc-headers.
rlm@1: If you don't want to use the user=group scheme, change the last argument to
rlm@1: the desired group name. The description is arbitrary but needs to meet the
rlm@1: requirements for the description field of an /etc/passwd entry.
rlm@1: 
rlm@1: TIP:
rlm@1:   Remember that you can call install_package with just one argument, if you
rlm@1:   want user name, group name and description to be the same.
rlm@1: 
rlm@1: The directory /usr/src/linux-libc-headers will be set up as the home directory
rlm@1: for the package user, automatically populated with the contents of 
rlm@1: /etc/pkgusr/skel-package. The install_package command also issues the command
rlm@1: `su - linux-libc-headers' to assume the identity of the newly created package
rlm@1: user. If you're using the bashrc and bash_profile scripts from the
rlm@1: more_control_helpers archive, you will be put straight into the directory 
rlm@1: /usr/src/linux-libc-headers and your prompt will look like this
rlm@1: 
rlm@1: package linux-libc-headers:/usr/src/linux-libc-headers>
rlm@1:      
rlm@1: to show you that you're working as package user linux-libc-headers and
rlm@1: that your current working directory is /usr/src/linux-libc-headers.
rlm@1: 
rlm@1: Use the command 
rlm@1:    
rlm@1:      echo $PATH
rlm@1: 
rlm@1: to verify that your PATH starts with "/usr/lib/pkgusr", the directory that 
rlm@1: contains the wrappers, and ends with "/tools/bin".
rlm@1: 
rlm@1: Now everything is prepared for installing the package according to the
rlm@1: instructions in the LFS book. Note that at the time of this writing the 
rlm@1: LFS book tells you to execute a chown command to make sure that the headers 
rlm@1: are owned by root. This is just because the packager has made a very common 
rlm@1: mistake when creating the tarball for the headers: He has archived the files 
rlm@1: with a non-root user/group assignment. When unpacking such a tarball as root, 
rlm@1: the files end up being owned by some weird user/group combination, which may 
rlm@1: open a security hole. When you're working as a package user this can not 
rlm@1: happen and you don't want to chown the headers to root:root, because that 
rlm@1: would defeat the whole point of installing the headers with a package user.
rlm@1: This is one of the small points on which you will have to deviate from the 
rlm@1: standard LFS instructions when using package users. More package user related
rlm@1: issues with the current LFS book can be found in the next section.
rlm@1: 
rlm@1: After you've installed the headers, simply issue the command
rlm@1: 
rlm@1:     exit
rlm@1:     
rlm@1: to become root again. Now would be a good time to think about useful
rlm@1: customizations for /etc/pkgusr/{bash_profile,bashrc} and/or 
rlm@1: /etc/pkgusr/skel-package, if you've not already customized them.
rlm@1: Once you're satisfied with your setup, install the rest of the packages.
rlm@1: The following section will help you with some problems that you will run into.
rlm@1: 
rlm@1: 
rlm@1:  7.3 Known Issues with LFS Packages
rlm@1:  ----------------------------------
rlm@1: 
rlm@1: This section has details on the package user related problems you will face
rlm@1: when building your LFS system. You should copy the information from this
rlm@1: section to the INSTALL NOTES of the relevant .project files for the packages 
rlm@1: concerned, together with any of your own notes.
rlm@1: 
rlm@1: NOTE: If you're building by an LFS book later than 6.2 it is recommended that
rlm@1:       you read this complete chapter before you start building any packages.
rlm@1:       If your LFS version is 6.2 then it's fine to read this section package
rlm@1:       by package as you progress with your build.
rlm@1: 
rlm@1: 
rlm@1: linux-libc-headers:
rlm@1:     At the time of this writing the LFS book tells you to execute a chown 
rlm@1:     command to make sure that the headers are owned by root. This is just 
rlm@1:     because the packager has made a very common mistake when creating the 
rlm@1:     tarball for the headers: He has archived the files with a non-root 
rlm@1:     user/group assignment. When unpacking such a tarball as root, the files 
rlm@1:     end up being owned by some weird user/group combination, which may open 
rlm@1:     a security hole. When you're working as a package user this can not happen 
rlm@1:     and you don't want to chown the headers to root:root, because that would 
rlm@1:     defeat the whole point of installing the headers with a package user.
rlm@1:     
rlm@1:     There used to be another packaging error in the linux-libc-headers. 
rlm@1:     Version 2.6.12.0 (current as of this writing) doesn't have it anymore,
rlm@1:     but older versions used to contain files with permissions set incorrectly. 
rlm@1:     All headers are supposed to be world-readable, but they weren't. More about
rlm@1:     this later in the glibc notes.
rlm@1: 
rlm@1: 
rlm@1: man-pages:
rlm@1:     If the name you use for the man-pages package user is not exactly 
rlm@1:     "man-pages", then you will have to change the variable "manpagesowner"
rlm@1:     right at the beginning of the wrapper script `install'.
rlm@1: 
rlm@1:     Recent versions of man-pages contain POSIX manpages that the package
rlm@1:     tries to install in /usr/share/man/man{0,1,3}p. There's also a manpage
rlm@1:     that man-pages wants to install to /usr/share/man/man9.
rlm@1:     As /usr/share/man is
rlm@1:     not an install directory and the LFS book does not have instructions to
rlm@1:     create these directories at the time of this writing, the installation 
rlm@1:     will fail and the respective man-pages will not be installed.
rlm@1:     Possible remedies:
rlm@1:       1. Make /usr/share/man an install directory. 
rlm@1:          Consequence: All Packages will be able to create new subdirectories
rlm@1:          in /usr/share/man. I find this undesirable because there are packages
rlm@1:          that create directories for manpages in foreign languages that I
rlm@1:          don't want. YMMV.
rlm@1:       2. Ignore the problem and live without the POSIX manpages. Unless
rlm@1:          you are a developer (including script writer) who is interested
rlm@1:          in writing portable programs/scripts this is a good solution.
rlm@1:       3. Create the directories /usr/share/man/man{0,1,3}p and man9 as root
rlm@1:          prior to installing man-pages. You'll have to either chown them
rlm@1:          to the man-pages package user or make them install directories.
rlm@1:          This is my preferred solution.
rlm@1: 
rlm@1: 
rlm@1: glibc:
rlm@1:     It is kind of unfortunate that the packaging error of libc-linux-headers 
rlm@1:     concerning the permissions doesn't exist in the current version. It 
rlm@1:     provided for a great learning experience. I've kept the following section
rlm@1:     in the hint for this reason even though it doesn't apply anymore. Please
rlm@1:     take the time to read it.
rlm@1:     
rlm@1: --------------------- old stuff start ----------------------------------------
rlm@1:     Because of the error, the headers in /tools/include
rlm@1:     are not world-readable. Unfortunately the LFS book (as of this writing)
rlm@1:     does not correct this in Chapter 5 like it does in Chapter 6. For a
rlm@1:     standard LFS build this is no problem, because glibc is built as root and
rlm@1:     root can access everything regardless of permissions.
rlm@1:     The glibc package user, however, does not have permission to access
rlm@1:     these headers. This will cause several configure tests to fail, because
rlm@1:     the respective test programs can not be compiled.
rlm@1:     The end result is the error message "/lib/cpp fails sanity check", which
rlm@1:     is completely nonsensical as we don't have a /lib/cpp.
rlm@1:     
rlm@1:     This is the perfect opportunity to introduce rule #1 of error diagnostics:
rlm@1:     
rlm@1:        NEVER TRUST DIAGNOSTIC MESSAGES !
rlm@1:        
rlm@1:     There are 2 kinds of diagnostic messages:
rlm@1:     
rlm@1:       1. Those that are unnecessary, because once you see which component has
rlm@1:          failed, the source of the problem is obvious.
rlm@1:       2. Those that grossly misdiagnose the source of the problem and lead
rlm@1:          you to draw the wrong conclusions.
rlm@1:     
rlm@1:     No, there is no other kind. Trust me ;-)
rlm@1:     In this case, /lib/cpp has nothing to do with the problem. It doesn't
rlm@1:     exist and that's fine. The message just wants to trick you into doing
rlm@1:     something stupid such as create a symlink /lib/cpp -> /tools/bin/cpp.
rlm@1:     But that would be totally wrong. Before you jump to any premature 
rlm@1:     conclusions you should always try to get as much *low-level* information 
rlm@1:     as you can. Diagnostic messages are *high-level* information. They 
rlm@1:     represent a filtered view of the problem, which is usually of little help.
rlm@1:     Fortunately the message (the complete one, not the part quoted above) also
rlm@1:     points at the source for the necessary low-level information. In this 
rlm@1:     case that is the file config.log (not to be confused with configure.log, 
rlm@1:     the file created by the build script included in the more_control_helpers 
rlm@1:     archive).
rlm@1:     config.log is created by all autoconf-created configures (not just that 
rlm@1:     of glibc) and it contains, among other things, the test programs used by 
rlm@1:     configure and messages output while building and running them. Whenever a 
rlm@1:     configure script fails or gives weird results, check config.log. And 
rlm@1:     always remember rule #2 of error diagnostics
rlm@1:     
rlm@1:        ALWAYS START AT THE FIRST ERROR
rlm@1:        
rlm@1:     This seems pretty obvious, but nevertheless people commonly do the exact
rlm@1:     opposite. It's just too tempting to start at the point of the final 
rlm@1:     failure and try to work backwards. In this case many people would open 
rlm@1:     config.log and scroll to the point of the failed /lib/cpp sanity check.
rlm@1:     After all, that's what caused configure to abort and so that's what needs
rlm@1:     to be fixed, right?  WRONG! Someone who takes this approach just sees the 
rlm@1:     error message "/lib/cpp: No such file or directory" and is even more 
rlm@1:     convinced that a missing /lib/cpp symlink (or program) is the problem.
rlm@1:     
rlm@1:     The correct way to approach such a problem is to start at the beginning
rlm@1:     of config.log, to scroll down to first error message and to check if it
rlm@1:     is an issue that needs to be fixed (error messages in config.log are
rlm@1:     not always signs for a problem). If the issue needs to be fixed, then
rlm@1:     it needs to be fixed first, because all later errors could be rooted in
rlm@1:     this issue (even if, no, *especially* if you don't believe this is the 
rlm@1:     case).
rlm@1:     If we apply this advice to the problem at hand, we quickly get to the first
rlm@1:     serious error in config.log: 
rlm@1: 
rlm@1:       "/tools/include/linux/limits.h: Permission denied"
rlm@1:     
rlm@1:     A quick check with ls reveals that indeed the directory with the linux
rlm@1:     headers is not world-readable, which is obviously wrong. The fix is
rlm@1:     easy. Just make (as root) the header directories /tools/include/{linux,asm} 
rlm@1:     world-readable with commands similar to those the LFS book presents 
rlm@1:     in Chapter 6 for the installation of linux-libc-headers.
rlm@1:     Once this change has been made, glibc's configure succeeds.
rlm@1: --------------------- old stuff end -----------------------------------------    
rlm@1: 
rlm@1: TIP:
rlm@1:     Even when configure completes successfully, you should still check the
rlm@1:     output carefully to see if there is anything odd. E.g. if you're using
rlm@1:     the wrappers, you should check that configure outputs the line
rlm@1:     
rlm@1:        checking for a BSD-compatible install... /usr/lib/pkgusr/install -c
rlm@1:     
rlm@1:     If configure detects a different install, such as /tools/bin/install,
rlm@1:     something is wrong. Maybe there's a typo in the PATH for the package
rlm@1:     user, or you've put the wrappers into a directory that is ignored by
rlm@1:     configure.
rlm@1:     
rlm@1: 
rlm@1:     With the wrappers the glibc build and install should work smoothly. 
rlm@1:     The wrapper script for install makes sure that the /usr/share/locale/* 
rlm@1:     directories become install directories so that other programs can install 
rlm@1:     their localized messages. 
rlm@1:     One thing that the wrappers do not take care of, 
rlm@1:     however, is the file /usr/share/info/dir. Because in the current LFS build
rlm@1:     order glibc is the first package that installs info files, dir is owned by 
rlm@1:     and only writable by glibc. In order to allow other packages to install 
rlm@1:     info pages, execute the following commands as root:
rlm@1:     
rlm@1:        chown root:install /usr/share/info/dir &&
rlm@1:        chmod ug=rw,o=r /usr/share/info/dir
rlm@1: 
rlm@1: NOTE:
rlm@1:     glibc wants to install the program pt_chown as setuid root. If you install
rlm@1:     as a package user, the program will get installed but not given root
rlm@1:     privileges (because of the install wrapper). 
rlm@1:     The following info is from the glibc docs:
rlm@1:           
rlm@1:        One auxiliary program, `/usr/libexec/pt_chown', is installed setuid
rlm@1:        `root'.  This program is invoked by the `grantpt' function; it sets the
rlm@1:        permissions on a pseudoterminal so it can be used by the calling
rlm@1:        process.  This means programs like `xterm' and `screen' do not have to
rlm@1:        be setuid to get a pty.  (There may be other reasons why they need
rlm@1:        privileges.)  If you are using a 2.1 or newer Linux kernel with the
rlm@1:        `devptsfs' or `devfs' filesystems providing pty slaves, you don't need
rlm@1:        this program; otherwise you do.  The source for `pt_chown' is in
rlm@1:        `login/programs/pt_chown.c'.
rlm@1:                                
rlm@1:     So unless you're building a system that does not use devpts (which would
rlm@1:     be quite unusual), this does not need to concern you.
rlm@1: 
rlm@1: TIP:
rlm@1:     In case you were wondering if you should create /etc/nsswitch.conf and
rlm@1:     /etc/ld.so.conf as root or glibc, I recommend to assign all files that 
rlm@1:     you manually create or manually edit to the root account. That way you can
rlm@1:     distinguish between those files that can be regenerated automatically and
rlm@1:     those that can not. Assigning even automatically generated files to
rlm@1:     root once you make the first manual edit, ensures that a later 
rlm@1:     reinstallation of a package won't silently do away with your manual tweaks.
rlm@1: 
rlm@1: ldconfig:
rlm@1:     Now that glibc has installed /sbin/ldconfig you can activate the ldconfig
rlm@1:     wrapper if you want to. Perform the following steps as root 
rlm@1:     AFTER re-adjusting the toolchain, 
rlm@1:     just before starting with binutils:
rlm@1:     
rlm@1:        cd /usr/lib/pkgusr
rlm@1:        gcc -O2 -W -Wall -o ldconfig ldconfig.c
rlm@1:        chown root:install ldconfig
rlm@1:        chmod u=rwxs,g=rxs,o= ldconfig
rlm@1:   
rlm@1:     These instructions make the ldconfig wrapper setuid root and setgid install
rlm@1:     and prevent non-root users not in the install group from executing it. 
rlm@1:     The setuid root is required so that it can replace /etc/ld.so.cache. 
rlm@1:     The setgid install is not strictly required, but without it 
rlm@1:     /etc/ld.so.cache will end up with the group of the last package user that 
rlm@1:     touched it. If you use the user name=group name scheme this will cause the 
rlm@1:     more_control_helpers scripts to believe that /etc/ld.so.cache belongs to 
rlm@1:     the package in question which can be confusing.
rlm@1: 
rlm@1: binutils:
rlm@1:     Have you make /usr/share/info/dir group-writable as explained above in
rlm@1:     the glibc notes? If you've missed that part, go back and do it now.
rlm@1:     The installation of binutils should complete without problems. 
rlm@1:     It does however cause minor conflicts with autoconf (see later).
rlm@1:     
rlm@1: NOTE:
rlm@1:     At the time of this writing the version of bash used in the LFS book has
rlm@1:     a bug that causes the list_package script to spit out errors and to list
rlm@1:     all manpages of binutils (and other packages) as Broken. This bug is 
rlm@1:     already fixed by the bash patch used by the book but the patch is not
rlm@1:     applied in chapter 5. Since the manpage summary functionality of 
rlm@1:     list_package requires man which is not installed until after bash is
rlm@1:     rebuilt, this doesn't really matter, because while patching the
rlm@1:     chapter 5 bash would get rid of the error messages, it wouldn't result
rlm@1:     in usable manpage summaries.
rlm@1:     
rlm@1:     
rlm@1: gcc:
rlm@1:     Because the /usr/lib/libgcc_s.so* symlinks created at the beginning of
rlm@1:     Chapter 6 is owned by root, gcc's installation cannot remove it. 
rlm@1:     So you will have to remove it as root before `make install'.
rlm@1:     Alternatively use
rlm@1:     
rlm@1:        chown -h gcc: /usr/lib/libgcc*
rlm@1:        
rlm@1:     to change ownership of the files in question after creating the gcc
rlm@1:     package user. Note the -h option which has to be used to change 
rlm@1:     ownership of the symlinks themselves rather than their target files.
rlm@1: 
rlm@1: db:
rlm@1:     It should be obvious that you don't want to change the ownership of the
rlm@1:     installed files.
rlm@1:     
rlm@1:     
rlm@1: coreutils:
rlm@1:     Because the /bin/cat, /bin/pwd and /bin/stty symlinks are owned by root,
rlm@1:     coreutils' installation cannot remove them. So you will have to remove 
rlm@1:     them manually before `make install'. Alternatively use the command
rlm@1:     
rlm@1:        chown -h coreutils: /bin/{cat,pwd,stty}
rlm@1:        
rlm@1:     after creating the coreutils package user. Note the -h switch that makes
rlm@1:     chown change the ownership of the symlinks themselves rather than their 
rlm@1:     target files.
rlm@1:     
rlm@1:     The chapter 6 instructions move the coreutils binaries to /bin, including
rlm@1:     the mv binary itself. You need to make sure that hashing is turned off
rlm@1:     for this to work. The LFS book does this by putting `set +h' into the
rlm@1:     LFS user's .bashrc. If you're following this hint, you're likely using
rlm@1:     build scripts, so you need to put this command into the build script
rlm@1:     before the mv commands.
rlm@1: 
rlm@1: NOTE:
rlm@1:     The man-pages package has already installed manpages for the binaries
rlm@1:     from coreutils. The install wrapper will prevent coreutils from overwriting
rlm@1:     those. This is done because the manpages from the man-pages package are 
rlm@1:     of superior quality (although not necessarily uptodate). 
rlm@1:     It also prevents errors during `make install' that
rlm@1:     would otherwise occur because the coreutils package user cannot overwrite 
rlm@1:     manpages owned by another user.
rlm@1:     If you don't like the above behaviour and would rather have the original 
rlm@1:     package manpages (because they are uptodate), you can set the variable 
rlm@1:     manpagesowner at the beginning of the install wrapper to a string that
rlm@1:     doesn't correspond to a package user name (it must not be empty, though!).
rlm@1:     If you do this, you will have to resolve manpage conflicts in another way. 
rlm@1:     The easiest way to handle this is probably to not install the man-pages 
rlm@1:     package at the beginning of Chapter 6 but at the end, after all the other
rlm@1:     packages have already installed their manpages. Then you need only deal 
rlm@1:     with the conflicts once, when installing man-pages.
rlm@1: 
rlm@1: 
rlm@1: ncurses:
rlm@1:     The installation of ncurses (like that of other packages that include 
rlm@1:     libraries) wants to run /sbin/ldconfig to update /etc/ld.so.cache. 
rlm@1:     This fails because the package user doesn't have permission to replace 
rlm@1:     /etc/ld.so.cache.
rlm@1:     Making /etc/ld.so.cache group-writable by the install group doesn't help, 
rlm@1:     because the permissions would be reset on the next call to /sbin/ldconfig.
rlm@1:     This error will usually not abort the installation and you can just
rlm@1:     run /sbin/ldconfig manually as root afterwards.
rlm@1:     Alternatively you can use the ldconfig wrapper as described earlier.
rlm@1: 
rlm@1: 
rlm@1: aclocal directory:
rlm@1:     At the time of this writing the directory /usr/share/aclocal is
rlm@1:     created during the bison installation. This directory contains
rlm@1:     macros for autoconf. Other packages want to install 
rlm@1:     files into this directory, so you should make it writable by the install 
rlm@1:     group and sticky. 
rlm@1: 
rlm@1: 
rlm@1: perl:
rlm@1:     Before you do `make install', you will have to 
rlm@1:     `chown -h perl: /usr/bin/perl' so that the perl package user is allowed to
rlm@1:     remove the /usr/bin/perl symlink.
rlm@1:     
rlm@1:     If you will install add-on packages for perl as their own package users
rlm@1:     into /usr/lib/perl5/site_perl, then you will need to turn 
rlm@1:     /usr/lib/perl5/site_perl/ and its subdirectories into 
rlm@1:     install directories. You don't need to do this now as you'll notice it
rlm@1:     anyway when installing a perl add-on fails. 
rlm@1: 
rlm@1: 
rlm@1: autoconf:
rlm@1:     The autoconf package wants to install its own copy of standards.info,
rlm@1:     which fails because binutils has already installed this file. You can 
rlm@1:     either ignore the error or remove the binutils version of standards.info 
rlm@1:     before `make install'.
rlm@1: 
rlm@1: 
rlm@1: bash:
rlm@1:   configure:
rlm@1:     The bash configure script tests for the presence of the special devices
rlm@1:     /dev/std* and /dev/fd/*. Unfortunately at the time of this writing the
rlm@1:     test for /dev/fd/* is buggy (the test for /dev/stdin used to be broke, too
rlm@1:     in bash-2.x, but has been fixed since). It ends up testing read access to 
rlm@1:     standard input, 
rlm@1:     which is the (pseudo)terminal you're building your system in. 
rlm@1:     Unfortunately su doesn't change ownership of the terminal device, so when
rlm@1:     you're su'd to a package user account, the terminal still belongs to the
rlm@1:     login user. As the package user doesn't have read access to the device,
rlm@1:     the tests fail.
rlm@1:     
rlm@1:     There is a simple way to get around this. Simply run ./configure like this
rlm@1:     
rlm@1:       ./configure ....  </dev/null
rlm@1:     
rlm@1:     The trick here is to redirect standard input (note, that this is a '<' not
rlm@1:     a '>' !) to refer to /dev/null. Unlike the terminal device, /dev/null is
rlm@1:     world-readable and world-writable, so the tests succeed as they should.
rlm@1:     If you don't like this trick, you can also chown the terminal device in
rlm@1:     question (see `ls -la /dev/fd/0') to the package user before building
rlm@1:     bash.
rlm@1:     
rlm@1:   make check:
rlm@1:     When running the test suite as a package user, the test "run-test" will 
rlm@1:     fail with the output like this:
rlm@1: 
rlm@1:       33d32
rlm@1:       < *** chmod g+s /tmp/test.setgid
rlm@1:       35c34
rlm@1:       < 1
rlm@1:       ---
rlm@1:       > 0
rlm@1:       64d62
rlm@1:       < *** chmod u+s /tmp/test.setuid
rlm@1:       66c64
rlm@1:       < 1
rlm@1:       ---
rlm@1:       > 0
rlm@1:       154c152
rlm@1:       < 1
rlm@1:       ---
rlm@1:       > 0
rlm@1:       160c158
rlm@1:       < 1
rlm@1:       ---
rlm@1:       > 0
rlm@1:     
rlm@1:     The first 2 failures are caused by the chmod wrapper which prevents the
rlm@1:     test from setting the setuid and setgid bits and outputs the *** warning.
rlm@1:     The failures are harmless. You can get rid of them by removing the wrappers
rlm@1:     directory from the PATH before running the tests.
rlm@1:     
rlm@1:     The last 2 failures are not specific to package users but will occur 
rlm@1:     whenever you run the tests su'd to another user. The reasons are the same
rlm@1:     as for the configure problem described earlier. The same solutions apply.
rlm@1:     Either use chown (if you chowned before configure you're already 
rlm@1:     done, of course) or run make check like this
rlm@1:        
rlm@1:       make check </dev/null
rlm@1:     
rlm@1:   make install:
rlm@1:     Before you can `make install' you need to `chown -h bash: /bin/bash' as
rlm@1:     root so that the bash installation can replace the /bin/bash symlink that
rlm@1:     you manually created at the beginning of chapter 6.
rlm@1: 
rlm@1: 
rlm@1: pkgconfig directory:
rlm@1:     At the time of this writing the directory /usr/lib/pkgconfig is
rlm@1:     created during the e2fsprogs installation. This directory contains
rlm@1:     build information used by the pkg-config tool. Other packages want to 
rlm@1:     install files into this directory, so you should make it writable by the
rlm@1:     install group and sticky. 
rlm@1: 
rlm@1: 
rlm@1: grub:
rlm@1:     The commands to create and populate /boot/grub have to be executed as
rlm@1:     root.
rlm@1:     
rlm@1:     
rlm@1: grep:
rlm@1:     Before you can `make install' you need to `chown -h grep: /bin/grep' as
rlm@1:     root so that the grep installation can replace the /bin/grep symlink that
rlm@1:     you manually created at the beginning of chapter 6.
rlm@1:     
rlm@1: 
rlm@1: inetutils:
rlm@1:     This package contains some programs that it wants to be setuid root:
rlm@1:     rsh, rcp, rlogin and ping
rlm@1:     The install wrapper prevents these programs from being installed
rlm@1:     setuid root. You must decide which of these programs you want to be 
rlm@1:     setuid root and manually make them so. Be conservative. Don't make a
rlm@1:     binary setuid root unless you *know* that ordinary users can't live
rlm@1:     without it. Every setuid root binary is a potential security hole.
rlm@1: 
rlm@1: 
rlm@1: iproute2:
rlm@1:     This package tries to change the permissions of /usr/sbin and some man
rlm@1:     directories. The install wrappers take care of this.
rlm@1: 
rlm@1: 
rlm@1: man-db:
rlm@1:     Even after installing man-db you won't get manpage summaries from
rlm@1:     list_package, because the way list_package calls man it needs col
rlm@1:     to work and col is from util-linux. You may however install util-linux
rlm@1:     right away. The alphabetical sort is the only reason it is at the end
rlm@1:     of Chapter 6.
rlm@1: 
rlm@1: 
rlm@1: shadow:
rlm@1:     By default shadow wants to install non-English manpages. This fails
rlm@1:     because the /usr/share/man directory is not an install directory and
rlm@1:     therefore package users are not allowed to create new subdirectories in it.
rlm@1:     To solve this problem, before you `make install', open the file
rlm@1:     man/Makefile, find the line 
rlm@1:     
rlm@1:       SUBDIRS = cs de es fr hu id it ja ko pl pt_BR ru zh_CN zh_TW
rlm@1:     
rlm@1:     and remove all the languages that you don't want to install. For those
rlm@1:     languages that you do want to install, create directories with the
rlm@1:     respective names in /usr/share/man as root and make them install
rlm@1:     directories (i.e. group install, group-writable, sticky).
rlm@1:     
rlm@1:     There is yet another issue with shadow concerning manpages. The shadow
rlm@1:     package contains a passwd.5 and a getspnam.3 manpage. 
rlm@1:     Installation of these manpages is
rlm@1:     automatically suppressed by the install wrapper, because it would 
rlm@1:     overwrite the manpages provided by the man-pages package. As usual
rlm@1:     the man-pages version is better, so you can simply ignore this issue.
rlm@1: 
rlm@1:     shadow wants to install the programs su, chage, chfn, chsh, expiry, 
rlm@1:     gpasswd, newgrp and passwd as setuid root. You will need to decide which 
rlm@1:     of these programs you want to be setuid root and manually make them so. 
rlm@1: 
rlm@1: 
rlm@1: sysklogd:
rlm@1:     sysklogd's Makefile has /usr/bin/install hardwired as the install
rlm@1:     program, which circumvents the install wrapper. The wrapper is needed 
rlm@1:     for sysklogd because it tries to make its manpages owned by root 
rlm@1:     (which obviously a package user is not allowed to do). 
rlm@1:     Therefore, install with
rlm@1:     
rlm@1:       make INSTALL=install install
rlm@1: 
rlm@1: 
rlm@1: udev:
rlm@1:     udev wants to install files into the directory /usr/lib/pkgconfig. If
rlm@1:     you've followed the instructions given further above you've already made
rlm@1:     this an install directory. If you haven't, do so now or the udev 
rlm@1:     installation will fail.
rlm@1:     
rlm@1:     The LFS instructions for installing udev tell you to execute the command
rlm@1:       
rlm@1:       mknod -m0666 /lib/udev/devices/null c 1 3
rlm@1:       
rlm@1:     Because a package user is not allowed to create device nodes, execute this
rlm@1:     command as root.
rlm@1:     
rlm@1: 
rlm@1: util-linux:
rlm@1:     util-linux wants to install write as setgid tty and u/mount as
rlm@1:     setuid root. The wrappers catch this, so it doesn't cause the install to
rlm@1:     fail, but as usual you'll have to decide if you want these programs to
rlm@1:     have special privileges and take manual action as root if you do.
rlm@1: 
rlm@1: 
rlm@1: ##########################################################################  
rlm@1:  8. Sanity Checks 
rlm@1: ##########################################################################
rlm@1: 
rlm@1:  8.1 Suspicious Files
rlm@1:  --------------------
rlm@1:  
rlm@1: You probably ran the `list_package' command for each package and reviewed
rlm@1: the results which include the suspicious files owned by that package. But even
rlm@1: if you did that it's still a good idea to run the non-package specific 
rlm@1: `list_suspicious_files' command once your build is complete. There could be
rlm@1: something you overlooked the first time, or maybe you created a file as root
rlm@1: with the wrong permissions. It doesn't hurt to check again and this will also
rlm@1: give you the opportunity to review any setuid/setgid decisions you made with
rlm@1: respect to the installed binaries.
rlm@1: 
rlm@1: TIP: 
rlm@1:   When you check the list of setuid and setgid files, don't forget to
rlm@1:   look at the actual user or group ownership of the file. It's easy to forget
rlm@1:   that, especially in the setuid case, because we often equate setuid with
rlm@1:   setuid root since setuid is seldom used with other user accounts.
rlm@1: 
rlm@1:   
rlm@1:  8.2 References to Temporary Files
rlm@1:  ---------------------------------
rlm@1: 
rlm@1: One big concern when building an LFS system is independence of the new LFS
rlm@1: system from the files installed in /tools. The /tools directory is intended 
rlm@1: to be temporary and it should be possible to delete it after building your
rlm@1: LFS system with no adverse side effects. The `grep_all_regular_files_for'
rlm@1: script from the more_control_helpers package can help you verify that your
rlm@1: new LFS system is indeed clean. The command
rlm@1: 
rlm@1:      grep_all_regular_files_for /tools
rlm@1: 
rlm@1: will give you a list of all files that contain the string "/tools". Review the
rlm@1: files in the list to make sure that no dependencies on the temporary files in
rlm@1: /tools have crept in. But remember that results from binaries and libraries 
rlm@1: are only meaningful after stripping away the debug information, because
rlm@1: debug information necessarily includes references to the build environment.
rlm@1: Of course, if you are a developer who will potentially run gdb on system
rlm@1: libraries/binaries, your position will be that stripping away debug information
rlm@1: is the wrong way to do away with /tools references. The other way to deal with
rlm@1: them is to rebuild packages for which /tools references are reported. The new
rlm@1: build will not involve any files from /tools and so the new debug information
rlm@1: will not refer to /tools. Note that the LFS build instructions for glibc
rlm@1: make glibc compile against /tools/glibc-kernheaders. Unless you copy the
rlm@1: glibc-kernheaders directory to a location outside of /tools and compile glibc
rlm@1: against that copy, you won't get rid of the /tools references in glibc's 
rlm@1: debug information.
rlm@1: No matter what means you choose to deal with the debug information issue, in 
rlm@1: the end you should have a system where the above command produces only false 
rlm@1: positives (such as "perlfaq3.1", which includes the URL
rlm@1: "http://www.research.att.com/sw/tools/uwin/") and files that legitimately
rlm@1: refer to /tools (such as a copy of this hint file).
rlm@1: 
rlm@1: 
rlm@1: ----------------------------- APPENDICES ----------------------------------
rlm@1: 
rlm@1: 
rlm@1: ###########################################################################
rlm@1:  Appendix A: Security Issues
rlm@1: ###########################################################################
rlm@1: 
rlm@1:  A.1 NFS
rlm@1:  -------
rlm@1: 
rlm@1: If you use the network filesystem NFS, there are some things you need to
rlm@1: look out for when using the package user system. A fundamental security 
rlm@1: problem with NFS is that it blindly trusts the UID and GID of the client. 
rlm@1: If an attacker can get access to the root account on a system in your network 
rlm@1: that is allowed to mount NFS shares from your server, or if the attacker can 
rlm@1: attach his own computer to your network, then this attacker can pretend to be 
rlm@1: anyone. NFS will happily allow the attacker to work in the NFS exported 
rlm@1: directory as any user he wants to be. The only exception is the root account. 
rlm@1: By default NFS exports directories with the root_squash option that maps all 
rlm@1: incoming requests from uid 0 to anonuid (65534 unless set in /etc/exports) 
rlm@1: and gid 0 to anongid (65534 unless set in /etc/exports). This protects files 
rlm@1: owned by root:root. On a normal system this includes most files in /bin, /etc,
rlm@1: /lib and most other directories except /home. If you use the package user 
rlm@1: scheme, however, most of these files are owned by package users. These files 
rlm@1: are not protected by the root_squash option. In order to make NFS exports 
rlm@1: secure, you have to add the option "all_squash" to every entry in /etc/exports 
rlm@1: that exports a directory that contains files owned by package users. Note that 
rlm@1: all_squash is always a good idea because even systems that don't use package 
rlm@1: users often have some programs owned by other users or groups, because they 
rlm@1: need to be setuid or setgid.
rlm@1: 
rlm@1: 
rlm@1:  A.2 Daemons
rlm@1:  -----------
rlm@1: 
rlm@1: It is a common practice to run daemons under special user accounts rather
rlm@1: than as root as a security measure. If you feel tempted to use a package 
rlm@1: user account for this purpose, resist the temptation. It would be a very
rlm@1: stupid idea. Although they are deliberately less powerful than root, package 
rlm@1: user accounts are still privileged and need to be considered as equivalent to 
rlm@1: root as far as security is concerned. Do not do anything with a package user 
rlm@1: that on a system without package users you would not do with the root account.
rlm@1: 
rlm@1: 
rlm@1: ###########################################################################
rlm@1:  Appendix B: Package Categories
rlm@1: ###########################################################################
rlm@1: 
rlm@1: Although the user name = group name scheme is recommended by this hint, it is
rlm@1: not the only possible one. Another scheme that has some appeal is to define
rlm@1: package categories and to use the group for the purpose of categorizing the
rlm@1: packages. Following is a suggested set of categories that can serve as a
rlm@1: guideline for implementing this scheme.
rlm@1: 
rlm@1: devel: development related stuff, e.g. compilers. This is not restricted to
rlm@1:        software development. TeX for instance would belong in this group.
rlm@1:        
rlm@1: utils: Most software fits into this category, even somewhat essential software 
rlm@1:        like grep or text editors.
rlm@1:       
rlm@1: net: network related stuff such as an ftp daemon or a web browser. This
rlm@1:      group overlaps with other groups to a large extent. It should be used
rlm@1:      in preference of the other groups whenever a package is clearly focused
rlm@1:      towards Internet, LAN, WWW,... A utility like wget for instance would
rlm@1:      go in net rather than utils. Exceptions from this rule are the groups
rlm@1:      docs, addons, games and mmedia. If a package fits into one of those 
rlm@1:      groups, use the respective group instead of net.
rlm@1:      
rlm@1: docs: Documentation related packages, such as a tarball with Linux howtos.
rlm@1:       Note that software to create documentation such as XML processors should
rlm@1:       probably go in devel and software to view or post-process documentation
rlm@1:       such as man or groff should probably go in utils.
rlm@1:       
rlm@1: system: important system software, such as bash. This group should be used
rlm@1:         only for really essential packages. Most packages you would put in 
rlm@1:         this group are better put in "utils". Vi for instance belongs in 
rlm@1:         utils. 
rlm@1:         It is unlikely that any package not part of basic LFS belongs in the
rlm@1:         system group.
rlm@1:         
rlm@1: libs: What utils is for executables, libs is for libraries. Libraries that are
rlm@1:       not strongly related to any of the other categories should go here, such
rlm@1:       as zlib or libpng.
rlm@1:       Essential system libraries such as glibc, ncurses or gettext should
rlm@1:       go in system instead.
rlm@1:       The libs group is also used for run-time environments such as the
rlm@1:       Java Virtual Machine, dosemu and wine. Other emulators like MAME for
rlm@1:       instance should probably go into games instead. 
rlm@1:      
rlm@1: games: what do you expect ;-)
rlm@1: 
rlm@1: mmedia: This is the group for audio and video editors, mp3 players etc.
rlm@1: 
rlm@1: apps: Applications such as spreadsheets and word processors (not text editors)
rlm@1:       but also CAD software and graphics software such as Gimp.
rlm@1:       The apps group is a bit like utils, but apps are usually more user 
rlm@1:       friendly and more streamlined and feel less nerdish than utils. 
rlm@1:       
rlm@1: addons: plugins, filters and similar that are meant to be used in conjunction
rlm@1:        with another package.
rlm@1:        
rlm@1: x: software that relates to the X Window System in general and does not fit
rlm@1:    into any of the other categories, such as the X server itself or window 
rlm@1:    managers.
rlm@1:    Most X software should be put into other more specific groups.
rlm@1:    A game like xmines would go in games for instance and a text editor for
rlm@1:    X would go in utils.
rlm@1:    
rlm@1: kde: Software that relates to KDE and does not fit into
rlm@1:      any other category. This group should be used with care. 
rlm@1:      Do *not* use it for all KDE software. K Office for instance belongs in
rlm@1:      apps. Konqueror belongs in net.
rlm@1:      
rlm@1: gnome: Software that relates to GNOME and does not fit into
rlm@1:        any other category. This group should be used with care. 
rlm@1:        Do *not* use it for all GNOME software. Gimp for instance belongs 
rlm@1:        in apps. A GNOME-aware window manager that works with plain X should
rlm@1:        go in the x group.
rlm@1: 
rlm@1: 
rlm@1: ###########################################################################
rlm@1:  Appendix C: Acknowledgements and Changelog
rlm@1: ###########################################################################
rlm@1: 
rlm@1: ACKNOWLEDGEMENTS:
rlm@1:   * Matthias Benkmann for writing the original version of this hint
rlm@1:   * Tushar Teredesai for suggesting the user=group scheme.
rlm@1:   * Markus Laire for reporting the 2005-01-01 build bug
rlm@1: 
rlm@1: CHANGELOG:
rlm@1: 
rlm@1: 2007-10-20 Matthias Benkmann
rlm@1:            -relicensed under CC-BY-SA (previously CC-BY-ND).
rlm@1:            -added name tags to changelog entries in preparation for having the
rlm@1:             hint continued by different authors.
rlm@1:            -added workaround to list_package for bug in man-db that causes
rlm@1:             some manpages to show up as "Weird manpage" in the summary.
rlm@1:            -chmod wrapper now prevents shadow from installing files setuid 
rlm@1:             shadow.
rlm@1:            -added a wrapper to solve ldconfig issue.
rlm@1:            -install_package now works when called with just a single argument. 
rlm@1:             That argument is used for user name, group name and description.
rlm@1:            -bash_profile of more_control_helpers now has /sbin and /usr/sbin 
rlm@1:             in the PATH to match the PATH used by root when building.
rlm@1:            -install_package does su - <name> now (i.e. start a login shell).
rlm@1:            -build script now handles unpacking of tarballs and allows calling 
rlm@1:             the different stages individually.
rlm@1:            -useradd uses the -s provided shell and no longer hardwires bash.
rlm@1:            -chapter 6 bash notes now properly address the configure and 
rlm@1:             make check issues.
rlm@1: 
rlm@1: 2007-03-21 Matthias Benkmann
rlm@1:            -changed forall_direntries_from to avoid warning message from find
rlm@1:             when -depth is used.
rlm@1:            -added 4.8 What Commands to Run as a Package User  
rlm@1: 
rlm@1: 2005-12-22 Matthias Benkmann
rlm@1:            -added advice on how to cope with the moving mv problem to
rlm@1:             coreutils note.
rlm@1: 
rlm@1: 2005-11-13 Matthias Benkmann
rlm@1:            -fixed list_suspicious_files and list_package to work with
rlm@1:             recent more POSIX-conforming versions of GNU find
rlm@1:            -released version 1.2 
rlm@1: 
rlm@1: 2005-01-01 Matthias Benkmann
rlm@1:             -fixed bug in skel-package/build script that caused it to report
rlm@1:              all steps as successful, even if they failed 
rlm@1:             -released version 1.1
rlm@1: 
rlm@1: 2004-11-01 Matthias Benkmann
rlm@1:             -capitalized title
rlm@1:             -released version 1.0
rlm@1:             
rlm@1: 2004-10-14 Matthias Benkmann
rlm@1:             -started developing the more_control_helpers utilities
rlm@1:             
rlm@1: 2004-08-14 Matthias Benkmann
rlm@1:             -started major rewrite (update for new LFS version, new hint 
rlm@1:              format, textual improvements,...)
rlm@1: 
rlm@1: 2002-04-20 Matthias Benkmann
rlm@1:             -changed LFS VERSION header to be more conservative
rlm@1:             -added <br> tags to the synopsis for the sake of the hints 
rlm@1:              index
rlm@1:             -added group mmedia to the list of suggested groups 
rlm@1:             -submitted v0.8
rlm@1: 
rlm@1: 2002-03-16 Matthias Benkmann  
rlm@1:             -added note, that on Linux make doesn't need to be setgid kmem
rlm@1: 
rlm@1: 2002-02-18 Matthias Benkmann
rlm@1:             -added section "Security issues with NFS"
rlm@1:             -submitted v0.7
rlm@1: 
rlm@1: 2002-01-30 Matthias Benkmann
rlm@1:             -added Changelog
rlm@1:             -moved "chown 0.10000 `cat /tmp/installdirs`" command up (before
rlm@1:              glibc package user is created)
rlm@1:             -add_package_user: create home directory with "mkdir -p"
rlm@1:                                use $grpfile everywhere instead of /etc/group
rlm@1:             -improved mammoth sentence in Introduction
rlm@1:             -added note about possibility to have user name==group name
rlm@1:             -source bashrc_basic in bashrc_package
rlm@1:             -minor textual changes