1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/previous-work/more_control_and_pkg_man.txt	Tue Jan 08 11:45:01 2013 +0000
     1.3 @@ -0,0 +1,1916 @@
     1.4 + 
     1.5 +AUTHOR: Matthias S. Benkmann <article at winterdrache dot de>
     1.6 +
     1.7 +DATE: 2007-10-20
     1.8 +
     1.9 +LICENSE: Creative Commons Attribution-Share Alike 3.0
    1.10 +         (http://creativecommons.org/licenses/by-sa/3.0/)
    1.11 +
    1.12 +SYNOPSIS: More Control and Package Management using Package Users (v1.4)
    1.13 +
    1.14 +DESCRIPTION:
    1.15 +-You want to know which packages your files belong to ?                 
    1.16 +-You want to deinstall software that doesn't have make uninstall ?      
    1.17 +-You are bothered by programs installed setuid root behind your back ?  
    1.18 +-You don't like packages quietly overwriting files from other packages ?
    1.19 +-You don't like package managers like RPM ?                             
    1.20 +-YOU WANT TOTAL CONTROL USING ONLY UNIX BUILTINS ?                      
    1.21 +
    1.22 +ATTACHMENTS:
    1.23 +http://www.linuxfromscratch.org/hints/downloads/attachments/more_control_and_pkg_man/more_control_helpers.tar.bz2
    1.24 +
    1.25 +PREREQUISITES:
    1.26 +For use with LFS book 6.2: Brain.
    1.27 +For use with LFS book later than 6.2: Brain (awake, good working condition).
    1.28 +
    1.29 +HINT:
    1.30 +
    1.31 +########################################################################### 
    1.32 + Contents
    1.33 +###########################################################################
    1.34 +
    1.35 +1. Preface
    1.36 +2. Overview
    1.37 +
    1.38 +- PART 1: General Information -
    1.39 +
    1.40 +3. Package Users
    1.41 +  3.1 Introduction
    1.42 +  3.2 User Name
    1.43 +  3.3 Groups
    1.44 +  3.4 Home Directory
    1.45 +4. Common Problems
    1.46 +  4.1 Introduction
    1.47 +  4.2 General Procedure
    1.48 +  4.3 Permission Changes
    1.49 +  4.4 Ownership Changes
    1.50 +  4.5 Write to Non-Install Directory
    1.51 +  4.6 Delete or Overwrite File
    1.52 +  4.7 /sbin/ldconfig
    1.53 +  4.8 What Commands to Run as a Package User
    1.54 +5. The more_control_helpers Archive
    1.55 +  5.1 Overview
    1.56 +  5.2 The Wrappers
    1.57 +  5.3 add_package_user/install_package
    1.58 +  5.4 forall_direntries_from
    1.59 +  5.5 uninstall_package
    1.60 +  5.6 list_suspicious_files/list_suspicious_files_from
    1.61 +  5.7 list_package
    1.62 +  5.8 grep_all_regular_files_for
    1.63 +  5.9 The etc Directory
    1.64 +  5.10 Temporary Files
    1.65 +  
    1.66 +- PART 2: LFS Specifics -
    1.67 +
    1.68 +6. Pre-Chroot Phase (Chapter 5)
    1.69 +7. Chroot Phase (Chapter 6)
    1.70 +  7.1 Preparations
    1.71 +  7.2 Walkthrough: Installing linux-libc-headers
    1.72 +  7.3 Known Issues with LFS Packages
    1.73 +8. Sanity Checks
    1.74 +  8.1 Suspicious Files
    1.75 +  8.2 References to Temporary Files
    1.76 +
    1.77 +- APPENDICES -
    1.78 +
    1.79 +A. Security Issues
    1.80 +  A.1 NFS
    1.81 +  A.2 Daemons
    1.82 +B. Package Categories
    1.83 +C. Acknowledgements and Changelog
    1.84 +  
    1.85 +
    1.86 +########################################################################### 
    1.87 + 1. Preface
    1.88 +###########################################################################
    1.89 +
    1.90 +Let's say I have written a program that you would like to use. To make it
    1.91 +easier for you I come over to install it for you. Would you give me the root
    1.92 +account and then leave the room ? No ? Then why do you give it to complete
    1.93 +strangers who you have never seen in your life, to install software packages
    1.94 +pulled from some Internet server, that come with no warranty and don't even 
    1.95 +list their contents in the README, although they will happily spread them all 
    1.96 +over your system ?
    1.97 +
    1.98 +It is a mystery why Unix admins who wouldn't even trust their employer with
    1.99 +more than a normal user account carelessly execute complex and incomprehensible
   1.100 +installation scripts with full root rights.
   1.101 +
   1.102 +Users and groups are the basic security principle in a Unix system. They have
   1.103 +been used successfully for a long time to monitor who has created a file and 
   1.104 +to control who is allowed to delete or change it. But this control has only 
   1.105 +been imposed on the files of ordinary users. What a waste! I suggest to extend
   1.106 +this control to all system files. 
   1.107 +
   1.108 +The general idea is to create package users, i.e. user accounts with restricted
   1.109 +rights, to build and install software packages, rather than doing these tasks 
   1.110 +as root. Not only does this give you more control over what build and install 
   1.111 +scripts may or may not do, it can also serve as a quite useful package 
   1.112 +management system.
   1.113 +
   1.114 +
   1.115 +#############################################################################
   1.116 + 2. Overview
   1.117 +#############################################################################
   1.118 +
   1.119 +This hint is divided into 3 parts. The first part contains general information
   1.120 +about the package user method. This part is the most important part of the
   1.121 +hint. Read it thoroughly. The second part explains how to apply the package 
   1.122 +user method to the building of an LFS system. 
   1.123 +Finally, part 3 of this hint is the Appendix with information that would not
   1.124 +fit anywhere else or that is not of general interest.
   1.125 +
   1.126 +It is inevitable that part 2 will become outdated with time as the LFS book 
   1.127 +changes and new versions of the software packages used with LFS are released. 
   1.128 +I make no attempt to track these changes. 
   1.129 +When someone reports an issue with a package I will incorporate
   1.130 +it into the hint, but larger changes that might be required due to changes in
   1.131 +the LFS build methodology could take a long time to get included. The reason 
   1.132 +for this (aside from lack of time) is that I consider part 2 as bonus material 
   1.133 +that helps people get started but is not essential. Part 1 describes the 
   1.134 +concepts, which are independent of package versions or the LFS book, and you 
   1.135 +will have to rely on this information whenever part 2 fails. Don't forget 
   1.136 +that part 2 only deals with the packages used by the LFS book. For all the 
   1.137 +other packages you install on your system after that even an up-to-date 
   1.138 +part 2 would offer no aid anyway.
   1.139 +
   1.140 +The previous paragraph might sound discouraging, and as you read more from the
   1.141 +hint it is possible that you get the impression that the package user
   1.142 +method is complicated, causes lots of difficult problems and is overall too
   1.143 +much trouble for anyone but a real hardcore admin with programming experience.
   1.144 +But you would be mistaken. 
   1.145 +First of all, many things experienced as installation problems when working
   1.146 +with the package user system are in fact desirable features. 
   1.147 +If `make install' fails for some package, because it attempts to install a
   1.148 +file with the same name as a pre-existing file from another package, you
   1.149 +should not curse the fact that you have to spend additional time to resolve
   1.150 +this issue. Instead you should be happy that you have been alerted of this
   1.151 +collision that, had it gone unnoticed, could have messed up your system in
   1.152 +more or less subtle ways.
   1.153 +Secondly, the package user system is not an all-or-nothing approach. It
   1.154 +works on a per-package basis. If a package gives you too much trouble, you
   1.155 +can always decide to chicken out and finish the installation as root.
   1.156 +Finally, the more_control_helpers archive provided with this hint contains
   1.157 +several useful scripts that automate many aspects of software installation
   1.158 +as a package user and, together with the tips given in this hint, add a lot 
   1.159 +of value to the package user system. 
   1.160 +So do not pass judgement until you have read at least the complete part 1,
   1.161 +including the description of the more_control_helpers.
   1.162 +
   1.163 +
   1.164 +---------------------- PART 1: General Information --------------------------
   1.165 +
   1.166 +
   1.167 +#############################################################################
   1.168 + 3. Package Users
   1.169 +#############################################################################
   1.170 +
   1.171 + 3.1 Introduction
   1.172 + ----------------
   1.173 +
   1.174 +The basic idea of this scheme is easily explained. Every package belongs to a 
   1.175 +certain "package user". When you install a package, you build and install
   1.176 +the package as this package user, causing all files that are installed to be 
   1.177 +owned by the package user. As a consequence all the usual package management 
   1.178 +tasks can be comfortably achieved through the use of standard command line 
   1.179 +utilities. A simple `ls -l <file>' will tell you, for instance, what package 
   1.180 +<file> belongs to and a `find -user ...' command allows you to perform an 
   1.181 +operation on all the files belonging to a certain package, e.g. delete them 
   1.182 +to uninstall the package.
   1.183 +
   1.184 +But package management is not all that package users are good for. Because
   1.185 +package users do not have root-rights, the installation of a package is
   1.186 +limited in what it can do. One thing that a package user is not allowed to do,
   1.187 +for example, is to overwrite files from a different package user. Clashes
   1.188 +between different packages that want to install a binary, library or header 
   1.189 +file of the same name are more common than you might think. With package users
   1.190 +you never run the risk of package B's installation destroying files from 
   1.191 +package A silently without you noticing. Every attempt of doing this during
   1.192 +package B's installation will cause a "Permission denied" or
   1.193 +"Operation not permitted" error so that you have the chance of taking 
   1.194 +appropriate steps.
   1.195 +Another thing that package users are not allowed to do is install setuid root 
   1.196 +binaries. The decision to make a binary setuid root is also something that a 
   1.197 +prudent admin does not want to leave up to the creator of a software package.
   1.198 +
   1.199 +Usually package user accounts have no valid password so that only root can su 
   1.200 +to a package user, which ensures that package users do not open an additional 
   1.201 +way into the system and undermine security. But you *may* set passwords 
   1.202 +anyway to allow a co-admin who you want to be able to install and maintain 
   1.203 +certain software packages to do so without having access to the actual root 
   1.204 +account. This co-admin could for instance install, delete, change additional 
   1.205 +libraries which might be necessary for his workgroup. He would be unable, 
   1.206 +though, to remove or modify libraries which don't belong to him/her, such as 
   1.207 +libc.
   1.208 +
   1.209 +
   1.210 + 3.2 User Name
   1.211 + -------------
   1.212 +
   1.213 +You don't need to drive yourself nuts trying to come up with 8 character
   1.214 +names for the package users. I always use the name of the package without 
   1.215 +the version number, including dashes and possibly exceeding 8 characters in 
   1.216 +length, e.g. "util-linux", and in the several years that I've been using this 
   1.217 +scheme I have not encountered any problems, nor has anyone else reported 
   1.218 +trouble. The 8-character limit on user names seems to be a thing of the past.
   1.219 +
   1.220 +TIP:
   1.221 +  You can use bash's programmable completion feature to save yourself some 
   1.222 +  typing when entering commands that take a user name as an argument, such as
   1.223 +  su, finger or pinky. The command 
   1.224 +  
   1.225 +      complete -o default -o nospace -A user su finger pinky
   1.226 +      
   1.227 +  tells bash to tab-complete words as user names for the commands su,
   1.228 +  finger and pinky.
   1.229 +  With this in place you can simply type `su linux-li<TAB>' and bash
   1.230 +  will complete this to `su linux-libc-headers' (assuming that you have a
   1.231 +  package user named "linux-libc-headers").
   1.232 +  "-o default" tells bash that if a suitable user name does not exist, the 
   1.233 +  default completion shall be attempted. 
   1.234 +  "-o nospace" prevents the addition of a space after the completed word.
   1.235 +  
   1.236 +  This is a very useful command to put into root's .bashrc and .bash_profile.
   1.237 +  
   1.238 +  BTW, at http://freshmeat.net/projects/bashcompletion/
   1.239 +  you can find a project that offers sophisticated completions for many
   1.240 +  other commands.
   1.241 +  
   1.242 +  Or switch to zsh (http://freshmeat.net/projects/zsh/). It's more powerful
   1.243 +  and less buggy than bash.
   1.244 +
   1.245 +
   1.246 + 3.3 Groups
   1.247 + ----------
   1.248 +
   1.249 +Every package user belongs to at least 2 groups. One of these groups is
   1.250 +the "install" group, which all package users (and only package users) belong
   1.251 +to. All directories that packages are allowed to install stuff in belong to 
   1.252 +the install group. This includes directories such as /bin and /usr/bin but 
   1.253 +excludes directories like /root or /. 
   1.254 +The directories owned by the install group are always group-writable. 
   1.255 +This would be enough for the package management aspects, but without further 
   1.256 +preparation this would not give added security or control because every 
   1.257 +package could replace the files from a different package (the change would 
   1.258 +be visible in the output from `ls -l', though).
   1.259 +For this reason all install directories get the sticky attribute. This
   1.260 +allows users to create new files and delete or modify their own files in
   1.261 +the directory, but files from other users can not be modified or removed.
   1.262 +In the rest of this hint, whenever the term "install directory" is used, it
   1.263 +refers to a directory that belongs to group install, is group-writable and
   1.264 +sticky. IOW, to turn <dir> into an install directory you would do
   1.265 +
   1.266 +    chgrp install <dir> && chmod g+w,o+t <dir>
   1.267 +
   1.268 +Although the install group is crucial for the package user system, it is 
   1.269 +implemented as a supplementary group, rather than as the primary group for
   1.270 +package users. This has at least 2 advantages. 
   1.271 +One advantage is that this makes it easy to get a list of all packages 
   1.272 +installed on the system with the command
   1.273 +
   1.274 +    grep install /etc/group
   1.275 +
   1.276 +A more important point, however, is that the primary group is the
   1.277 +one that files created by the package user will belong to. So it will be 
   1.278 +printed in the output of `ls -l' and is subject to find's "-group" test. 
   1.279 +This makes it very useful for organizational purposes. 
   1.280 +Following are some suggestions for how to use the primary group. 
   1.281 +
   1.282 +1. group name = user name
   1.283 +
   1.284 +   Under this scheme the package user for the bash package would be
   1.285 +   bash:bash. `ls -l /bin/bash' would show something like this
   1.286 +   
   1.287 +   -rwxr-xr-x    1 bash     bash    1731859 Feb 30  2005 /bin/bash
   1.288 +   
   1.289 +   An important advantage of this scheme is that the user information is
   1.290 +   not lost when you make a file setuid root, which requires changing
   1.291 +   the file's owner. Because of this advantage, this scheme is the one
   1.292 +   recommended by this hint. However, the hint's instructions will work
   1.293 +   fine if you choose a different scheme.
   1.294 +
   1.295 +2. group name = package category
   1.296 +
   1.297 +   Under this scheme, you would have certain package categories, such as
   1.298 +   games, system, net,... and bash, being a system program, would possibly
   1.299 +   belong to the system group, so that `ls -l /bin/bash' would show something 
   1.300 +   like this
   1.301 +   
   1.302 +   -rwxr-xr-x    1 bash     system    1731859 Jul  4  1776 /bin/bash
   1.303 +   
   1.304 +   This system is nice, but probably not as useful as #1 above, unless you
   1.305 +   have a real use for this categorization.
   1.306 +   For a possible categorization see Appendix B at the end of this hint.
   1.307 +
   1.308 +3. group name = identifier for a real group of people
   1.309 +   
   1.310 +   Under this scheme, the group would correspond to a real group of people in 
   1.311 +   meatspace, e.g. the group of admins responsible for the package. 
   1.312 +   If you need something like this you'll know best what it looks like and how
   1.313 +   to implement it, so no further discussion of this method will be given here. 
   1.314 +   
   1.315 +
   1.316 + 3.4 Home Directory
   1.317 + ------------------
   1.318 + 
   1.319 +Although it is well possible not to have a valid home directory for package
   1.320 +users or to have just one home directory shared by all package users, that
   1.321 +would be a wasted opportunity. Having individual home directories for the
   1.322 +package users offers a nice way to organize tarballs, patches, build scripts,
   1.323 +notes and all the other per-package information that you accumulate with time.
   1.324 +
   1.325 +I suggest to use the home directory /usr/src/<package> for a package user
   1.326 +called <package> with the contents detailed below. The more_control_helpers 
   1.327 +archive contains scripts and skeleton files that implement this suggestion.
   1.328 +
   1.329 +  .bash_profile: 
   1.330 +           You will usually want to have the same environment for all package
   1.331 +           users, so it is a good idea to make .bash_profile a symbolic link
   1.332 +           to a file in a central location. The more_control_helpers example
   1.333 +           uses /etc/pkgusr/bash_profile for this purpose.
   1.334 +           
   1.335 +  .bashrc: 
   1.336 +           As for .bash_profile a symlink is a good idea for .bashrc. The
   1.337 +           more_control_helpers example uses /etc/pkgusr/bashrc as link target.
   1.338 +           Under normal circumstances package users are not 
   1.339 +           (and even can not be) used for logging into the system, so there 
   1.340 +           is little reason to distinguish between login and non-login shells 
   1.341 +           for package users. Therefore, the example bashrc from 
   1.342 +           more_control_helpers simply sources .bash_profile.
   1.343 +           This makes sure that the same environment will be used, regardless
   1.344 +           of whether `su <package>' or `su - <package>' is used to become
   1.345 +           the package user.
   1.346 +           
   1.347 +  .project: 
   1.348 +           The contents of this file are printed by the commands
   1.349 +           `finger -l <user>' and 'pinky -l <user>' so .project is a
   1.350 +           good place for putting information about a package. You should 
   1.351 +           keep the contents of the .project files for your package users 
   1.352 +           up-to-date.
   1.353 +                       
   1.354 +  source code:
   1.355 +           The package user's home directory is the perfect place for storing
   1.356 +           a package's source code. This includes tarballs for different
   1.357 +           versions, CVS checkouts, unpacked source trees for building,...
   1.358 +           
   1.359 +  build script(s):
   1.360 +           Package user installations require more careful examination of build 
   1.361 +           and install messages than installations done as root, because of
   1.362 +           the package user-specific problems that can occur. Therefore it is
   1.363 +           unwise to simply copy'n'paste installation instructions from the
   1.364 +           LFS book. Build scripts allow you to use sophisticated output
   1.365 +           redirection for logging purposes that is impractical for direct
   1.366 +           entry on the command line. The build script skeleton included in
   1.367 +           the more_control_helpers archive demonstrates this.
   1.368 +                       
   1.369 +
   1.370 +############################################################################
   1.371 + 4. Common Problems
   1.372 +############################################################################
   1.373 +
   1.374 + 4.1 Introduction
   1.375 + ----------------
   1.376 +
   1.377 +Software installation is the crux of the package user system. Because 
   1.378 +installation scripts are often written under the assumption that they will be 
   1.379 +executed as root, they sometimes fail when executed by a package user.
   1.380 +Once this hurdle is passed and a package has been installed, there's usually no 
   1.381 +difference to a root-installation. A few programs insist that certain 
   1.382 +security-sensitive files be owned by root and will not execute otherwise,
   1.383 +but this is the rare exception. 
   1.384 +This chapter presents some more or less common problems that you will 
   1.385 +encounter when using package user accounts to install software, together with
   1.386 +guidelines on how to deal with these issues. 
   1.387 +Although I've said it before I will say it again: Many of the problems you
   1.388 +encounter during a package user installation are desirable features of the
   1.389 +package user system. You want installation to fail rather than have 
   1.390 +potentially dangerous actions performed behind your back with root rights.
   1.391 +
   1.392 + 
   1.393 + 4.2 General Procedure
   1.394 + ---------------------
   1.395 + 
   1.396 +When an installation fails it is almost always due to a "Permission denied"
   1.397 +or "Operation not permitted" error while executing a command during
   1.398 +`make install'. The first thing you have to do is identify the command that
   1.399 +is causing the problem. Usually you will find this in the make output right
   1.400 +before the error message. Once you have identified the culprit, you have to
   1.401 +decide whether the action that is attempted is illegitimate, partially
   1.402 +legitimate or completely legitimate. Illegitimate commands can simply be
   1.403 +removed from the Makefile. The other 2 possibilities are more difficult to 
   1.404 +deal with. You either have to change the condition that makes the command fail
   1.405 +or you have to change or sometimes remove the command and make a note if your
   1.406 +change suppresses a legitimate action.
   1.407 +
   1.408 +After you've made changes to solve a certain problem, you reattempt the
   1.409 +installation and solve any remaining problems until the installation
   1.410 +succeeds. Once you've reached that point it is time to perform any remaining
   1.411 +legitimate actions that you've had to disable, such as make certain binaries
   1.412 +setuid root.
   1.413 +
   1.414 +Note that often Makefiles are generated during the configure step, sometimes
   1.415 +even later in the build process. If you want to apply changes before the
   1.416 +configure step you will usually have to edit files called "Makefile.in".
   1.417 +
   1.418 + 
   1.419 + 4.3 Permission Changes
   1.420 + ----------------------
   1.421 +
   1.422 +Some unsophisticated build systems that don't use the mkinstalldirs script to 
   1.423 +create installation target directories are very poorly written. Instead of 
   1.424 +testing whether a target directory exists, they simply attempt to create 
   1.425 +it with default permissions. This problem usually manifests as a line such
   1.426 +as "install -d $(prefix)/bin" in the Makefile. In the common case where 
   1.427 +prefix=/usr this would attempt to create the /usr/bin directory. If the target
   1.428 +directory already exists, as in this case, install will attempt to change its
   1.429 +permissions to the default permissions (or those passed on the command line).
   1.430 +Of course a package user is not allowed to change the permissions of
   1.431 +/usr/bin and so the command fails with a message like
   1.432 +"install: cannot change permissions of `/usr/bin': Operation not permitted"
   1.433 +This is an example of a completely illegitimate command. Just remove it from
   1.434 +the Makefile and everything's fine.
   1.435 +
   1.436 + 
   1.437 + 4.4 Ownership Changes
   1.438 + ---------------------
   1.439 +
   1.440 +The most common situation when a package wants to change the ownership of
   1.441 +files during installation is when it wants to install setuid root binaries.
   1.442 +A common command to do this would be something like
   1.443 +"install -c -m 4755 -o root name /usr/bin/name" and the error message would
   1.444 +look like this:
   1.445 +"install: cannot change ownership of `name': Operation not permitted"
   1.446 +The change of ownership is hidden in the "-o root" switch to install, which
   1.447 +tells it to make the target file owned by root.
   1.448 +The command is at least partially legitimate, because you probably want the 
   1.449 +binary to be installed. Whether you actually want it to be setuid root is 
   1.450 +a different matter. The fact that a binary is commonly installed as setuid
   1.451 +root doesn't mean that you should make it so. You'll have to ask yourself if
   1.452 +normal users absolutely need to execute that binary. If you think they can
   1.453 +live without it you're better off not making it setuid root, because every
   1.454 +setuid root binary is a potential security hole. In any case you will
   1.455 +have to edit the Makefile and remove the offending switch, "-o root" in this 
   1.456 +case, so that the installation can succeed. Note that this will cause the
   1.457 +binary to be installed setuid <package>, which of course makes no sense at all.
   1.458 +If you don't intend to make the binary setuid root after the installation, it
   1.459 +is best to change the "-m 4755" to "-m 755", so that it won't be installed
   1.460 +setuid at all.
   1.461 +
   1.462 +TIP:
   1.463 +  When you make a binary setuid root after the installation, use
   1.464 +  `chown root /usr/bin/name' and not `chown root:root /usr/bin/name'.
   1.465 +  This way you can keep original group of the file (i.e. the group of the 
   1.466 +  package user) intact. With the user name = group name scheme recommended for
   1.467 +  package users this makes sure that you can identify the source package of
   1.468 +  the binary even after making it setuid root.
   1.469 +  Note that as a security measure chown resets the setuid bit,
   1.470 +  so you will have to do `chmod u+s /usr/bin/name' after the chown.
   1.471 +
   1.472 + 
   1.473 + 4.5 Write to Non-Install Directory
   1.474 + ----------------------------------
   1.475 +
   1.476 +Sometimes packages want to create files or directories in non-install 
   1.477 +directories. 3 situations have to be distinguished in this case. The 1st
   1.478 +possibility is that the target directory should be an install directory.
   1.479 +An example of this is /usr/share/aclocal. This directory is not among the
   1.480 +standard system directories created when building an LFS system. It will be
   1.481 +created by the first package that has files to install there and will be
   1.482 +owned by the corresponding package user. The next package that wants to write
   1.483 +in it will fail to install. The remedy is simple. Just make the directory an
   1.484 +install directory. You don't even need to be root to do it. The package user
   1.485 +that owns the directory has the rights to make that change.
   1.486 +
   1.487 +The 2nd possible reason for a package wanting to write to a non-install
   1.488 +directory is that the failing command is only partially legitimate, i.e. you
   1.489 +do want to have installed whatever it is meant to install, but you want it in
   1.490 +a different location. For example some packages install binaries that are not
   1.491 +meant to be called directly. The default location for these binaries is
   1.492 +sometimes called libexec and with prefix=/usr the package will attempt to 
   1.493 +create /usr/libexec. In cases such as this you often don't have to change 
   1.494 +any Makefiles. There is either a configure switch to change the directory in
   1.495 +question or it is just a matter of overriding a Makefile variable as in
   1.496 +`make libexecdir=/usr/lib install'.
   1.497 +
   1.498 +The 3rd possible reason for an attempt to write to a non-install directory is
   1.499 +that the command in question is illegitimate, i.e. you don't want to have
   1.500 +installed whatever the package wants to install. As usual with illegitimate
   1.501 +commands you can edit the Makefile and just remove them. In the case of
   1.502 +a whole directory whose installation you want to suppress it could be too
   1.503 +much effort to remove all of the offending commands that want to install
   1.504 +files there. In this case an approach similar to that from the previous
   1.505 +paragraph can be more effective. Either through configure switches or 
   1.506 +overriding of variables you change the directory in question to something
   1.507 +like <builddir>/foobar, where <builddir> is the directory in which build 
   1.508 +commands are run (i.e. usually the top of the unpackaged source
   1.509 +tree). This will cause the package to create the unwanted directory inside
   1.510 +the build tree, which doesn't cause any permission problems and has the nice
   1.511 +side effect that it'll be deleted together with the build directory when you
   1.512 +clean up after the build.
   1.513 +
   1.514 +
   1.515 + 4.6 Delete or Overwrite File
   1.516 + ----------------------------
   1.517 +
   1.518 +In a perfect world one package should not mess with another package's files,
   1.519 +but in the real world conflicts do happen occasionally. While a normal
   1.520 +sysadmin installing as root won't notice this until it's too late, an admin
   1.521 +employing the package user system will have to deal with conflicts right away.
   1.522 +When a package tries to overwrite or delete a file or directory that is owned
   1.523 +by another package the attempt will fail. It will fail even inside install
   1.524 +directories because of the sticky bit.
   1.525 +Although sometimes difficult to implement, the solution to such a conflict is
   1.526 +easy to describe. You need to either remove (or rename) the old file or 
   1.527 +directory before installing, or suppress the installation of the new file or 
   1.528 +directory. The installation of individual binaries is sometimes easy to
   1.529 +prevent. If you find a line such as "PROGRAMS=foo bar fubar barfu" in the
   1.530 +Makefile and "foo" is the name of the conflicting binary, just try removing
   1.531 +it from that list. That may be sufficient to prevent it from being installed.
   1.532 +
   1.533 + 
   1.534 + 4.7 /sbin/ldconfig
   1.535 + ------------------
   1.536 + 
   1.537 +Packages that install libraries sometimes run /sbin/ldconfig as part of their
   1.538 +installation so that the dynamic libraries are properly registered on the 
   1.539 +system. Because a package user is not allowed to overwrite /etc/ld.so.cache
   1.540 +ldconfig fails. This failure is commonly ignored in Makefiles, but you should
   1.541 +take note of it anyway, because you need to run ldconfig as root after
   1.542 +the installation. Alternatively, the more_control_helpers contain a wrapper 
   1.543 +program that calls /sbin/ldconfig and can be made setuid root.
   1.544 +
   1.545 +
   1.546 + 4.8 What Commands to Run as a Package User  
   1.547 + ------------------------------------------
   1.548 +
   1.549 +A common problem that new users of this hint have is to decide which commands
   1.550 +to run as a package user and which commands to run as root. The general rule
   1.551 +is that the only commands to run as a package user are those for building,
   1.552 +installing, removing and modifying the files that belong to *that* package 
   1.553 +user's package. Everything else should be run as root as usual. 
   1.554 +Some things you CAN/SHOULD NOT DO as a package user include
   1.555 +
   1.556 +    - starting daemons
   1.557 +    - running udevstart
   1.558 +    - stripping /lib/*
   1.559 +
   1.560 + 
   1.561 +############################################################################
   1.562 + 5. The more_control_helpers Archive
   1.563 +############################################################################
   1.564 +
   1.565 + 5.1 Overview
   1.566 + ------------
   1.567 +
   1.568 +The more_control_helpers archive contains files to help you with building and
   1.569 +maintaining a system that uses the package user method. One thing that the
   1.570 +more_control_helpers archive contains are some LFS-specific temporary files 
   1.571 +that are only needed for the building of your LFS system and will not remain 
   1.572 +installed in a permanent location. Then there are the previously mentioned 
   1.573 +example files that demonstrate the suggested use of the package user home 
   1.574 +directories discussed earlier. Another group of files contained in the archive 
   1.575 +is a set of scripts that help with package management aspects, such as
   1.576 +creating new package users and checking which files a particular package has 
   1.577 +installed. Finally the more_control_helpers archive contains wrapper scripts
   1.578 +for some commands that handle many of the common problems discussed in the
   1.579 +previous chapter and make package user installations a lot easier.
   1.580 + 
   1.581 + 
   1.582 + 5.2 The Wrappers
   1.583 + ----------------
   1.584 + 
   1.585 +The previous chapter discussed some common problems encountered during
   1.586 +package user builds and how to solve them. The solution to an installation
   1.587 +failure usually requires editing of one or more Makefiles. Making such changes
   1.588 +manually is annoying, even if it happens only occasionally, and whenever you
   1.589 +reinstall a package you have to make the changes again. Sed scripts and patches
   1.590 +can help with the latter problem, but they still have to be custom fitted to 
   1.591 +every package that needs them. There is a better solution, though. While there
   1.592 +exist countless ways to install files, only very few are commonly used by
   1.593 +packages. The 5 commands mkdir, chgrp, chown, chmod and install are responsible 
   1.594 +for most of the problems that arise during an LFS installation. This
   1.595 +prompted me to write wrapper scripts for these 5 commands that recognize
   1.596 +certain problematic patterns and deal with them automatically.
   1.597 +
   1.598 +The instructions given in this hint in the LFS-specific part will instruct you
   1.599 +to install these wrappers in /usr/lib/pkgusr. If you do that and make sure 
   1.600 +that this directory is the first entry in the PATH of every package user, then
   1.601 +they will save you a lot of time and effort in dealing with recurring issues.
   1.602 +Note that if you want to choose a directory other than /usr/lib/pkgusr for
   1.603 +the wrappers, you need to be careful. Some configure scripts ignore certain
   1.604 +locations. A subdirectory of /etc would not work, for instance, because /etc
   1.605 +is one of these locations.  
   1.606 +
   1.607 +It is important that you understand the limitations of the wrapper scripts.
   1.608 +They can fix some problems without user intervention, such as turning
   1.609 +newly created directories in /usr/share/locale into install directories.
   1.610 +But other problems by their very nature require manual intervention. When a 
   1.611 +program tries to install a setuid root binary, for instance, the wrapper 
   1.612 +scripts will suppress the attempt to change ownership of an installed file to 
   1.613 +root. While that allows `make install' to complete without error, it is only 
   1.614 +a partial solution. The wrapper scripts can not (and should not) take away
   1.615 +your responsibility for deciding whether the program in question should be
   1.616 +setuid root and to make it so, if necessary. To account for this, the
   1.617 +wrapper scripts will output warning lines to standard error that start with
   1.618 +"***" whenever they encounter a situation that needs to be reviewed.
   1.619 +Following the "***" in the message will be the original command that the
   1.620 +installation attempted to perform. 
   1.621 +You *must* check these "***" lines, examine the affected files or directories
   1.622 +and take appropriate action. Because of this it is imperative that you log
   1.623 +the messages output during a package installation and check these logs
   1.624 +religiously. The `build' script contained in the more_control_helpers archive
   1.625 +demonstrates some useful output redirection tricks to be used for this purpose.
   1.626 +The following 3 examples shall illustrate what kind of things you will have to
   1.627 +look for:
   1.628 +
   1.629 +Example 1: "*** install -c rsh -o root -m 4775 /usr/bin/rsh"
   1.630 +   This message is output by the install wrapper during the installation of
   1.631 +   inetutils. The package wants to install the rsh binary setuid root. The
   1.632 +   install wrapper removes the "-o root" and changes the "-m 4775" to
   1.633 +   "-m 755" before passing the command on to the real install program.
   1.634 +   The important thing here is the "-m 4xxx", because this wants to set the
   1.635 +   setuid bit. Some install scripts throw in a "-o root" for good measure
   1.636 +   when installing an otherwise normal binary. In that case it's enough that
   1.637 +   the install wrapper strips out the "-o root" and you don't have to take
   1.638 +   further action. But when, as in the case of inetutils, the permissions
   1.639 +   indicate an attempt to make a binary setuid or setgid, then you will have to
   1.640 +   investigate. You need to decide if you want rsh to be setuid root and
   1.641 +   if you decide you do, you need to become root and issue commands like this:
   1.642 +       
   1.643 +       chown root /usr/bin/rsh
   1.644 +       chmod u+s /usr/bin/rsh
   1.645 +  
   1.646 +TIP:
   1.647 +   Be conservative with making binaries setuid. If you're unsure whether you
   1.648 +   will ever use a program (as non-root), you probably don't want it to be 
   1.649 +   setuid root. Keep in mind that you can always make the change later when
   1.650 +   you need it. When you apply this reasoning to rsh, for instance, you'll 
   1.651 +   probably end up not making it setuid root.
   1.652 +
   1.653 +
   1.654 +Example 2: "*** chgrp tty /usr/bin/write" 
   1.655 +   This is output by the chgrp wrapper during the util-linux installation.
   1.656 +   The util-linux package wants to install the write program as setgid tty,
   1.657 +   so that it is allowed to access other users' terminals. The chgrp wrapper
   1.658 +   prevents the changing of the group and the chmod wrapper prevents the
   1.659 +   setting of the setgid bit. You need to decide if you want the
   1.660 +   program to be setgid and if you decide in favor of this, do as root
   1.661 +   
   1.662 +       chgrp tty /usr/bin/write
   1.663 +       chmod g+s /usr/bin/write
   1.664 +   
   1.665 +    
   1.666 +Example 3: "*** install -d -m 755 /sbin"
   1.667 +   This is also from the util-linux installation. Util-linux, for no good
   1.668 +   reason, tries to recreate the /sbin directory. The install wrapper
   1.669 +   prevents this and you don't have to take any further action.
   1.670 +
   1.671 + 
   1.672 + 5.3 add_package_user/install_package
   1.673 + ------------------------------------
   1.674 +  
   1.675 +Whenever you install a new package on your system, you first have to create
   1.676 +a new user account, possibly create a new group and if you follow the advice
   1.677 +from this hint about making productive use of a package user's home directory,
   1.678 +you will have to set up that one, too. If you were to do all of this manually,
   1.679 +it would be a lot of work. The add_package_user and install_package scripts
   1.680 +in the more_control_helpers archive were written to automate this.
   1.681 +
   1.682 +The install_package script is the one you will normally use to prepare for
   1.683 +installing a new package. It takes 3 parameters: the description of the 
   1.684 +package, the name of the package user account to create and the name of the
   1.685 +package user's primary group. So if you use the user=group scheme recommended 
   1.686 +by this hint and are as creative with your package descriptions as I am, then 
   1.687 +the command you'll use to prepare for installing package "foo" will be
   1.688 +
   1.689 +    install_package foo foo foo
   1.690 +
   1.691 +This command does 2 things. First it calls the add_package_user script with
   1.692 +the provided name, group and description plus sensible default values for 
   1.693 +add_package_user's other parameters. Then, after add_package_user has created 
   1.694 +the package user account, install_package automatically uses the su-command
   1.695 +to switch to the newly created account. If the default .bashrc and
   1.696 +.bash_profile scripts you use for package users contain the command "cd" as do
   1.697 +the examples in the more_control_helpers archive, you will be put right into
   1.698 +your package user's home directory so that you can start installing right away.
   1.699 +
   1.700 +TIP:
   1.701 +  The install_package script can be called with a single argument that will
   1.702 +  be used as user name, group name and description. So instead of the above
   1.703 +  command a simple `install_package foo' would have sufficed.
   1.704 +
   1.705 +The add_package_user script is responsible for the actual work of creating
   1.706 +a new package user account. Given a name, a group name and a description, it
   1.707 +will create a new user account with the provided primary group and the install
   1.708 +group as supplementary group. The groups will be created if necessary. 
   1.709 +add_package_user takes several arguments that determine the numeric ranges from
   1.710 +which it will pick the new user's UID and the GIDs for groups it needs to
   1.711 +create. add_package_user does not only create the package user account. It
   1.712 +will set up a home directory for it, too. You can either specify the directory
   1.713 +or go with the default, which is /usr/src/<name>, where <name> is the name
   1.714 +provided for the new account. If the home directory already exists, its
   1.715 +ownership and that of any existing contents will be changed to the new user.
   1.716 +If it doesn't exist, it will be created. 
   1.717 +
   1.718 +The contents of /etc/pkgusr/skel-package will be copied into the new package
   1.719 +user's home directory (without overwriting pre-existing files). 
   1.720 +The more_control_helpers archive contains an example of a useful skel-package
   1.721 +directory. Note that symlinks are copied as symlinks, so skel-package is the
   1.722 +perfect place to put .bashrc and .bash_profile symlinks to a central location
   1.723 +that will ensure that all package user accounts have the same environment.
   1.724 +This is especially useful to make sure that all package users have the
   1.725 +wrappers directory in their PATH.
   1.726 +
   1.727 +  
   1.728 + 5.4 forall_direntries_from
   1.729 + --------------------------
   1.730 +
   1.731 +The forall_direntries_from script is a very useful tool for common package
   1.732 +management tasks. It can roughly be described as a shortcut for 
   1.733 +"find / -user <name> -or -group <name>  <commands>", where <name> is the
   1.734 +first parameter to forall_direntries_from and <commands> are the remaining
   1.735 +parameters. However, forall_direntries_from takes care of making sure that
   1.736 +only relevant filesystems are scanned and shields you from certain unpleasant
   1.737 +surprises such as "Oops, I forgot that -depth negates -prune and have 
   1.738 +accidentally wiped out my home directory." or "Oops, I forgot to -prune /proc
   1.739 +and now I'm getting parity errors on my SCSI bus.". 
   1.740 +
   1.741 +IMPORTANT NOTE: By default the forall_direntries_from script will only scan
   1.742 +the / filesystem and will not traverse other filesystems. If you have
   1.743 +relevant directories that need to be scanned on other filesystems, you will 
   1.744 +need to edit the script and add the respective mount point(s) to the
   1.745 +fs_to_scan list at the beginning of the script. The most likely candidate for
   1.746 +addition is "/usr".
   1.747 +
   1.748 +Application examples:
   1.749 +
   1.750 +Example 1: Create a tar.gz archive of all files that belong to <package>, e.g.
   1.751 +           for installing <package> on another machine without having to 
   1.752 +           recompile it there.
   1.753 +
   1.754 +  forall_direntries_from <package> -fprint0 /tmp/files.lst
   1.755 +  tar --null -P -czf /tmp/archive.tar.gz --files-from=/tmp/files.lst
   1.756 +
   1.757 +
   1.758 +Example 2: Print out all setuid root binaries installed by <package>.
   1.759 +           (This only works if you use the user=group scheme.)
   1.760 +  
   1.761 +  forall_direntries_from <package> -perm +u+s -print
   1.762 +
   1.763 +
   1.764 +Example 3: List all binaries in /bin and /usr/bin belonging to "me" (i.e. the 
   1.765 +           package user executing the command) in alphabetical order.
   1.766 +
   1.767 +  forall_direntries_from $(whoami) -path "*/bin/*" -printf "%f\n" | sort
   1.768 +
   1.769 +
   1.770 +Example 4: Uninstall <package>.
   1.771 +          
   1.772 +  See following section about the uninstall_package script.
   1.773 + 
   1.774 +                                   
   1.775 + 5.5 uninstall_package
   1.776 + ---------------------
   1.777 +
   1.778 +The uninstall_package script is basically a forall_direntries_from
   1.779 +application example in script form. The command `uninstall_package foo'
   1.780 +prints out the forall_direntries_from call that you have to use to delete
   1.781 +all the files of package "foo" (except for those in directories that 
   1.782 +forall_direntries_from is instructed not to scan) together with some
   1.783 +explanations. So in order to delete the files from package foo, you would 
   1.784 +execute `uninstall_package foo' and then copy'n'paste the command it prints
   1.785 +to the command line. As a safeguard the forall_direntries_from call has an 
   1.786 +"echo" in front of the "rm" and "rmdir" calls, so if you execute it, the files 
   1.787 +will not actually be deleted unless you remove both instances of "echo". 
   1.788 +It is recommended that you execute the command once with the echos and check 
   1.789 +the output to make sure that only the files you intend to be deleted are in 
   1.790 +the list. After you've confirmed that, you can use the shell's history to 
   1.791 +recall the command, edit out the instances of "echo" and remove the files 
   1.792 +for real.
   1.793 +
   1.794 +
   1.795 + 5.6 list_suspicious_files/list_suspicious_files_from
   1.796 + ----------------------------------------------------
   1.797 +
   1.798 +list_suspicious_files looks for filesystem entries that are out of the ordinary
   1.799 +in some way and prints a categorized list of them. Things that qualify as
   1.800 +suspicious include setuid and setgid binaries, world-writable files, symlinks 
   1.801 +that are possibly broken, hard links, install directories with unusual 
   1.802 +permissions and other stuff. You should run this script after you've finished 
   1.803 +your new LFS system and in regular intervals after that. Investigate the
   1.804 +listing closely.
   1.805 +
   1.806 +TIP: 
   1.807 +  When you check the list of setuid and setgid files, don't forget to
   1.808 +  look at the actual user or group ownership of the file. It's easy to forget
   1.809 +  that, especially in the setuid case, because we often equate setuid with
   1.810 +  setuid root since setuid is seldom used with other user accounts.
   1.811 +
   1.812 +list_suspicious_files_from takes a user or group name or a UID/GID as an 
   1.813 +argument and reports suspicious entries only when they are owned by the given 
   1.814 +user or group. Usually you would not call this script directly but instead
   1.815 +use list_package (described in the next section), whose output includes that 
   1.816 +from list_suspicious_files_from.
   1.817 +
   1.818 +IMPORTANT NOTE: By default the list_suspicious_files script will only scan
   1.819 +the / filesystem and will not traverse other filesystems. If you have
   1.820 +relevant directories that need to be scanned on other filesystems, you will 
   1.821 +need to edit the script and add the respective mount point(s) to the
   1.822 +fs_to_scan list at the beginning of the script. The most likely candidate for
   1.823 +addition is "/usr".
   1.824 +
   1.825 +
   1.826 + 5.7 list_package
   1.827 + ----------------
   1.828 +
   1.829 +list_package tells you everything about a package's installed files. In
   1.830 +general you will want to execute something like 
   1.831 +
   1.832 +   list_package $(whoami) >pkg.lst
   1.833 +   
   1.834 +right after installing a package and you can forget about the chronically
   1.835 +inaccurate content listings in the (B)LFS book. 
   1.836 +The following (shortened) output for util-linux speaks for itself:
   1.837 +
   1.838 +PS1> list_package util-linux
   1.839 +
   1.840 +EXECUTABLES (in */bin or */sbin)
   1.841 +  agetty, arch, blockdev, cal, cfdisk, [...] vidmode(->rdev), whereis, write
   1.842 +
   1.843 +EXECUTABLES WITH NO MANPAGE (in */bin or */sbin)
   1.844 +  fsck.cramfs, mkfs.cramfs
   1.845 +
   1.846 +MANPAGE SUMMARIES OF EXECUTABLES (in */bin or */sbin)
   1.847 +  agetty: alternative Linux getty
   1.848 +  arch: print machine architecture
   1.849 +  blockdev: call block device ioctls from the command line
   1.850 +  cal: displays a calendar
   1.851 +  cfdisk: Curses based disk partition table manipulator for Linux
   1.852 +  chkdupexe: find duplicate executables
   1.853 +  col: filter reverse line feeds from input
   1.854 +  [...]
   1.855 +  swapon: enable/disable devices and files for paging and swapping
   1.856 +  tailf: follow the growth of a log file
   1.857 +  tunelp: set various parameters for the lp device
   1.858 +  ul: do underlining
   1.859 +  umount: unmount file systems
   1.860 +  vidmode: query/set image root device, RAM disk size, or video mode
   1.861 +  whereis: locate the binary, source, and manual page files for a command
   1.862 +  write: send a message to another user
   1.863 +
   1.864 +EXTRA MANPAGES
   1.865 +  /usr/share/man/man5/fstab.5
   1.866 +  /usr/share/man/man5/nfs.5
   1.867 +  /usr/share/man/man8/sln.8
   1.868 +
   1.869 +EXTRA EXECUTABLES (not in */bin or */sbin)
   1.870 +  /usr/share/misc/getopt/getopt-parse.bash
   1.871 +  /usr/share/misc/getopt/getopt-parse.tcsh
   1.872 +  /usr/share/misc/getopt/getopt-test.bash
   1.873 +  /usr/share/misc/getopt/getopt-test.tcsh
   1.874 +
   1.875 +ALL FILES
   1.876 +  /etc/fdprm
   1.877 +  /sbin/agetty
   1.878 +  /sbin/blockdev
   1.879 +  /sbin/cfdisk
   1.880 +  /sbin/ctrlaltdel
   1.881 +  /sbin/elvtune
   1.882 +  /sbin/fdisk
   1.883 +  /sbin/fsck.cramfs
   1.884 +  /sbin/fsck.minix
   1.885 +  /sbin/hwclock
   1.886 +  /sbin/losetup
   1.887 +  /sbin/mkfs
   1.888 +  /sbin/mkfs.bfs
   1.889 +  [...]
   1.890 +  /usr/share/man/man8/rootflags.8
   1.891 +  /usr/share/man/man8/setfdprm.8
   1.892 +  /usr/share/man/man8/setsid.8
   1.893 +  /usr/share/man/man8/sfdisk.8
   1.894 +  /usr/share/man/man8/sln.8
   1.895 +  /usr/share/man/man8/swapoff.8
   1.896 +  /usr/share/man/man8/swapon.8
   1.897 +  /usr/share/man/man8/tunelp.8
   1.898 +  /usr/share/man/man8/umount.8
   1.899 +  /usr/share/man/man8/vidmode.8
   1.900 +  /usr/share/misc/getopt
   1.901 +  /usr/share/misc/getopt/getopt-parse.bash
   1.902 +  /usr/share/misc/getopt/getopt-parse.tcsh
   1.903 +  /usr/share/misc/getopt/getopt-test.bash
   1.904 +  /usr/share/misc/getopt/getopt-test.tcsh
   1.905 +
   1.906 +SETUID FILES
   1.907 +  -rwsr-xr-x "/usr/bin/mount"  root:util-linux
   1.908 +  -rwsr-xr-x "/usr/bin/umount"  root:util-linux
   1.909 +
   1.910 +SETGID FILES
   1.911 +  -rwxr-sr-x "/usr/bin/write"  util-linux:tty
   1.912 +
   1.913 +FILES WITH UNUSUAL PERMISSIONS
   1.914 +  -rwsr-xr-x "/usr/bin/mount"  root:util-linux
   1.915 +  -rwsr-xr-x "/usr/bin/umount"  root:util-linux
   1.916 +  -rwxr-sr-x "/usr/bin/write"  util-linux:tty
   1.917 +
   1.918 +
   1.919 +Note: list_package works regardless of the prefix you've installed the package
   1.920 +      with, so you can for instance configure with --prefix=/opt/package and
   1.921 +      list_package will work just fine (provided that /opt is on a
   1.922 +      filesystem configured to be scanned by forall_direntries_from and
   1.923 +      list_suspicious_files).
   1.924 +
   1.925 +Note: list_package only considers manpages actually owned by the package to 
   1.926 +      list. It will not consider manpages installed by another package. This
   1.927 +      means that you may see executables identified as not having a manpage
   1.928 +      although they do have one courtesy of another package 
   1.929 +      (usually man-pages).
   1.930 +
   1.931 +
   1.932 + 5.8 grep_all_regular_files_for
   1.933 + ------------------------------
   1.934 +
   1.935 +This script is not really related to the package user system, but because of
   1.936 +its similarity to the other scripts I've included it anyway. The sole purpose
   1.937 +of this script is to identify files that store references to the build 
   1.938 +environment, specifically the /tools directory. Such references may point out
   1.939 +problems, since the /tools directory is supposed to be transient.
   1.940 +Don't forget that results for unstripped binaries and libraries are not 
   1.941 +reliable, because debugging information often includes references to the
   1.942 +build environment. These do not cause trouble (unless you're trying to debug
   1.943 +the objects in question after deleting /tools).
   1.944 +  
   1.945 +IMPORTANT NOTE: By default the grep_all_regular_files_for script will only scan
   1.946 +the / filesystem and will not traverse other filesystems. If you have
   1.947 +relevant directories that need to be scanned on other filesystems, you will 
   1.948 +need to edit the script and add the respective mount point(s) to the
   1.949 +fs_to_scan list at the beginning of the script. The most likely candidate for
   1.950 +addition is "/usr".  
   1.951 +  
   1.952 +  
   1.953 + 5.9 The etc Directory
   1.954 + ---------------------
   1.955 + 
   1.956 +If you follow the instructions provided in the LFS-specific part of this hint,
   1.957 +the contents of the etc directory will be installed in /etc/pkgusr. The
   1.958 +directory contains a bashrc and bash_profile for package users that takes
   1.959 +care of package user specific details such as putting the wrappers directory
   1.960 +at the beginning of the PATH and calling cd, so that `su <package>' will
   1.961 +put you right into the package user's home directory. Also contained in the
   1.962 +etc directory is a skel-package directory as used by 
   1.963 +install_package/add_package_user to populate the home directories of newly
   1.964 +created package users.
   1.965 + 
   1.966 + 
   1.967 + 5.10 ldconfig.c
   1.968 + --------------------
   1.969 +
   1.970 +A lot of packages contain libraries. Having to manually call /sbin/ldconfig
   1.971 +as root after installing these packages can become annoying. It would be
   1.972 +much easier if one could grant package users permission to use /sbin/ldconfig.
   1.973 +Making ldconfig setuid root would be a simple and effective solution, but
   1.974 +there are some pitfalls. First of all it is imperative that ordinary users
   1.975 +be prohibited from executing ldconfig with elevated privileges. Otherwise
   1.976 +an ordinary user can overwrite and possibly read arbitrary files on the 
   1.977 +system. This can be prevented by making ldconfig owned by group install and
   1.978 +removing the o+x bit from the file mode. While this setup is no less secure
   1.979 +than running `make install' as root, one reason why we're using package users
   1.980 +is because we don't feel safe doing that. To protect against the (admittedly
   1.981 +very theoretical) danger of a malicious package user, the more_control_helpers
   1.982 +provide ldconfig.c. The only thing this program does is to call 
   1.983 +`/sbin/ldconfig -v' with an empty environment. Because it doesn't evaluate
   1.984 +any user input and doesn't pass any user-provided data to ldconfig, it can
   1.985 +safely be made setuid root. 
   1.986 +
   1.987 +
   1.988 + 5.11 Temporary Files 
   1.989 + --------------------
   1.990 +
   1.991 +3 files in the more_control_helpers archive are only used during the 
   1.992 +installation of the base LFS system and are not installed permanently.
   1.993 +The first of them is the installdirs.lst file that contains a list of 
   1.994 +directories that should be install directories. 
   1.995 +The second file is sbin/useradd, which is a very primitive shell script that
   1.996 +adds a new entry to /etc/passwd. It allows us to add package users before
   1.997 +we have installed shadow, which provides a real useradd.
   1.998 +Finally there is groupadd, which is like useradd, only for /etc/group.
   1.999 +Both scripts, useradd as well as groupadd, do very little error checking and
  1.1000 +only support the syntax needed by install_package/add_package_user. So don't
  1.1001 +try anything funky with them.
  1.1002 +
  1.1003 +  
  1.1004 +------------------------ PART 2: LFS Specifics ------------------------------
  1.1005 +
  1.1006 +
  1.1007 +#############################################################################
  1.1008 + 6. Pre-Chroot Phase (Chapter 5)
  1.1009 +#############################################################################
  1.1010 +
  1.1011 +Build Chapter 5 explained by the LFS book with the following changes:
  1.1012 +
  1.1013 +coreutils:
  1.1014 +  After running `make install' for the coreutils
  1.1015 +  package, issue the following command (still from within the coreutils
  1.1016 +  build directory):
  1.1017 +
  1.1018 +    cp src/su /tools/bin
  1.1019 +    
  1.1020 +  This installs the su binary. Coreutils doesn't install su when working as
  1.1021 +  non-root (which we do in Chapter 5), because su needs to be setuid root for
  1.1022 +  normal operation and a non-root user cannot install setuid root binaries. 
  1.1023 +  But for our purposes (i.e. su'ing from root to a package user) a non-setuid 
  1.1024 +  su is enough, so we just copy coreutils' su to /tools/bin without making it
  1.1025 +  setuid root.
  1.1026 +  
  1.1027 +more_control_helpers:
  1.1028 +  When you have reached the end of Chapter 5, before you begin with Chapter 6 
  1.1029 +  you will need to install the helper scripts in the /tools directory so that
  1.1030 +  they are available once you've entered the chroot environment. Use the
  1.1031 +  following commands to install the more_control_helpers in /tools:
  1.1032 +
  1.1033 +    cd /tools &&
  1.1034 +    tar xjf /path/to/more_control_helpers.tar.bz2 &&
  1.1035 +    cd  more_control_helpers &&
  1.1036 +    cp ./sbin/* /tools/bin
  1.1037 +    
  1.1038 +  Note that the target directory is "/tools/bin" in the cp command and 
  1.1039 +  *not* "/tools/sbin", although the latter location would be more appropriate.
  1.1040 +  The reason for this is simply that the LFS instructions do not add 
  1.1041 +  "/tools/sbin" to the PATH (and neither do the instructions in this hint).
  1.1042 +
  1.1043 +
  1.1044 +#############################################################################
  1.1045 + 7. Chroot Phase (Chapter 6)
  1.1046 +#############################################################################
  1.1047 +
  1.1048 + 7.1 Preparations
  1.1049 + ----------------
  1.1050 +
  1.1051 +Enter the chroot environment and follow the instructions from the book up to
  1.1052 +but *not* including the installation of the first package (which at the time of
  1.1053 +this writing is linux-libc-headers). Now install the more_control_helpers
  1.1054 +files in their proper locations on the new LFS system:
  1.1055 +
  1.1056 +    cp -a /tools/more_control_helpers/etc /etc/pkgusr &&
  1.1057 +    chown -R 0:0 /etc/pkgusr &&
  1.1058 +    cp -a /tools/more_control_helpers/lib /usr/lib/pkgusr &&
  1.1059 +    chown -R 0:0 /usr/lib/pkgusr &&
  1.1060 +    cp /tools/more_control_helpers/bin/* /usr/bin &&
  1.1061 +    cp /tools/more_control_helpers/sbin/* /usr/sbin &&
  1.1062 +    rm /usr/sbin/{useradd,groupadd}
  1.1063 +
  1.1064 +Note that the useradd and groupadd scripts are not installed on the new LFS 
  1.1065 +system. These scripts are just temporary workarounds we will use as long as 
  1.1066 +the real useradd and groupadd are not available. Therefore they should only 
  1.1067 +be in /tools/bin.
  1.1068 +
  1.1069 +ATTENTION! If you decide to use a different directory than /usr/lib/pkgusr
  1.1070 +for the wrappers, you have to be careful, because at least the glibc
  1.1071 +configure script ignores certain directories when looking for programs. The
  1.1072 +list of ignored directories for glibc includes, among others, everything that 
  1.1073 +starts with "/etc", "/usr/etc" and "/sbin". Wrappers put into a directory that
  1.1074 +matches any of these patterns would be ineffective.
  1.1075 +
  1.1076 +Now it's time to create the install group:
  1.1077 +
  1.1078 +    groupadd -g 9999 install
  1.1079 +
  1.1080 +The GID 9999 has been chosen because the default range used by 
  1.1081 +add_package_user for package user GIDs starts at 10000. Choose whatever number
  1.1082 +you like.
  1.1083 +
  1.1084 +Once the install group has been created you have to turn all the directories
  1.1085 +that packages will install files in into install directories. To make this
  1.1086 +easier I have compiled a list of install directories that can be found in
  1.1087 +the file /tools/more_control_helpers/installdirs.lst. The following command
  1.1088 +uses this list to assign the necessary directories to the install group.
  1.1089 +Note that you will get several error messages because of non-existent
  1.1090 +directories. This is because the list contains some directories not created
  1.1091 +by LFS.
  1.1092 +
  1.1093 +    chown 0:9999 $(cat /tools/more_control_helpers/installdirs.lst)
  1.1094 +
  1.1095 +To be usable by package users, the directories will have to be group-writable
  1.1096 +and should be sticky as has been explained in the beginning of this hint.
  1.1097 +The following command sets the permissions appropriately.
  1.1098 +You will get the same error messages as for the previous command.
  1.1099 +
  1.1100 +    chmod ug=rwx,o=rxt $(cat /tools/more_control_helpers/installdirs.lst)
  1.1101 +
  1.1102 +
  1.1103 + 7.2 Walkthrough: Installing linux-libc-headers
  1.1104 + ----------------------------------------------
  1.1105 +
  1.1106 +At this point everything has been set up for creating the first package
  1.1107 +user. At the time of this writing the first package installed in the LFS
  1.1108 +book is Linux-Libc-Headers, so this package will serve as an example for how 
  1.1109 +things are done. The command
  1.1110 +
  1.1111 +     install_package 'Linux Headers' linux-libc-headers linux-libc-headers
  1.1112 +
  1.1113 +will create a package user with user and group name linux-libc-headers.
  1.1114 +If you don't want to use the user=group scheme, change the last argument to
  1.1115 +the desired group name. The description is arbitrary but needs to meet the
  1.1116 +requirements for the description field of an /etc/passwd entry.
  1.1117 +
  1.1118 +TIP:
  1.1119 +  Remember that you can call install_package with just one argument, if you
  1.1120 +  want user name, group name and description to be the same.
  1.1121 +
  1.1122 +The directory /usr/src/linux-libc-headers will be set up as the home directory
  1.1123 +for the package user, automatically populated with the contents of 
  1.1124 +/etc/pkgusr/skel-package. The install_package command also issues the command
  1.1125 +`su - linux-libc-headers' to assume the identity of the newly created package
  1.1126 +user. If you're using the bashrc and bash_profile scripts from the
  1.1127 +more_control_helpers archive, you will be put straight into the directory 
  1.1128 +/usr/src/linux-libc-headers and your prompt will look like this
  1.1129 +
  1.1130 +package linux-libc-headers:/usr/src/linux-libc-headers>
  1.1131 +     
  1.1132 +to show you that you're working as package user linux-libc-headers and
  1.1133 +that your current working directory is /usr/src/linux-libc-headers.
  1.1134 +
  1.1135 +Use the command 
  1.1136 +   
  1.1137 +     echo $PATH
  1.1138 +
  1.1139 +to verify that your PATH starts with "/usr/lib/pkgusr", the directory that 
  1.1140 +contains the wrappers, and ends with "/tools/bin".
  1.1141 +
  1.1142 +Now everything is prepared for installing the package according to the
  1.1143 +instructions in the LFS book. Note that at the time of this writing the 
  1.1144 +LFS book tells you to execute a chown command to make sure that the headers 
  1.1145 +are owned by root. This is just because the packager has made a very common 
  1.1146 +mistake when creating the tarball for the headers: He has archived the files 
  1.1147 +with a non-root user/group assignment. When unpacking such a tarball as root, 
  1.1148 +the files end up being owned by some weird user/group combination, which may 
  1.1149 +open a security hole. When you're working as a package user this can not 
  1.1150 +happen and you don't want to chown the headers to root:root, because that 
  1.1151 +would defeat the whole point of installing the headers with a package user.
  1.1152 +This is one of the small points on which you will have to deviate from the 
  1.1153 +standard LFS instructions when using package users. More package user related
  1.1154 +issues with the current LFS book can be found in the next section.
  1.1155 +
  1.1156 +After you've installed the headers, simply issue the command
  1.1157 +
  1.1158 +    exit
  1.1159 +    
  1.1160 +to become root again. Now would be a good time to think about useful
  1.1161 +customizations for /etc/pkgusr/{bash_profile,bashrc} and/or 
  1.1162 +/etc/pkgusr/skel-package, if you've not already customized them.
  1.1163 +Once you're satisfied with your setup, install the rest of the packages.
  1.1164 +The following section will help you with some problems that you will run into.
  1.1165 +
  1.1166 +
  1.1167 + 7.3 Known Issues with LFS Packages
  1.1168 + ----------------------------------
  1.1169 +
  1.1170 +This section has details on the package user related problems you will face
  1.1171 +when building your LFS system. You should copy the information from this
  1.1172 +section to the INSTALL NOTES of the relevant .project files for the packages 
  1.1173 +concerned, together with any of your own notes.
  1.1174 +
  1.1175 +NOTE: If you're building by an LFS book later than 6.2 it is recommended that
  1.1176 +      you read this complete chapter before you start building any packages.
  1.1177 +      If your LFS version is 6.2 then it's fine to read this section package
  1.1178 +      by package as you progress with your build.
  1.1179 +
  1.1180 +
  1.1181 +linux-libc-headers:
  1.1182 +    At the time of this writing the LFS book tells you to execute a chown 
  1.1183 +    command to make sure that the headers are owned by root. This is just 
  1.1184 +    because the packager has made a very common mistake when creating the 
  1.1185 +    tarball for the headers: He has archived the files with a non-root 
  1.1186 +    user/group assignment. When unpacking such a tarball as root, the files 
  1.1187 +    end up being owned by some weird user/group combination, which may open 
  1.1188 +    a security hole. When you're working as a package user this can not happen 
  1.1189 +    and you don't want to chown the headers to root:root, because that would 
  1.1190 +    defeat the whole point of installing the headers with a package user.
  1.1191 +    
  1.1192 +    There used to be another packaging error in the linux-libc-headers. 
  1.1193 +    Version 2.6.12.0 (current as of this writing) doesn't have it anymore,
  1.1194 +    but older versions used to contain files with permissions set incorrectly. 
  1.1195 +    All headers are supposed to be world-readable, but they weren't. More about
  1.1196 +    this later in the glibc notes.
  1.1197 +
  1.1198 +
  1.1199 +man-pages:
  1.1200 +    If the name you use for the man-pages package user is not exactly 
  1.1201 +    "man-pages", then you will have to change the variable "manpagesowner"
  1.1202 +    right at the beginning of the wrapper script `install'.
  1.1203 +
  1.1204 +    Recent versions of man-pages contain POSIX manpages that the package
  1.1205 +    tries to install in /usr/share/man/man{0,1,3}p. There's also a manpage
  1.1206 +    that man-pages wants to install to /usr/share/man/man9.
  1.1207 +    As /usr/share/man is
  1.1208 +    not an install directory and the LFS book does not have instructions to
  1.1209 +    create these directories at the time of this writing, the installation 
  1.1210 +    will fail and the respective man-pages will not be installed.
  1.1211 +    Possible remedies:
  1.1212 +      1. Make /usr/share/man an install directory. 
  1.1213 +         Consequence: All Packages will be able to create new subdirectories
  1.1214 +         in /usr/share/man. I find this undesirable because there are packages
  1.1215 +         that create directories for manpages in foreign languages that I
  1.1216 +         don't want. YMMV.
  1.1217 +      2. Ignore the problem and live without the POSIX manpages. Unless
  1.1218 +         you are a developer (including script writer) who is interested
  1.1219 +         in writing portable programs/scripts this is a good solution.
  1.1220 +      3. Create the directories /usr/share/man/man{0,1,3}p and man9 as root
  1.1221 +         prior to installing man-pages. You'll have to either chown them
  1.1222 +         to the man-pages package user or make them install directories.
  1.1223 +         This is my preferred solution.
  1.1224 +
  1.1225 +
  1.1226 +glibc:
  1.1227 +    It is kind of unfortunate that the packaging error of libc-linux-headers 
  1.1228 +    concerning the permissions doesn't exist in the current version. It 
  1.1229 +    provided for a great learning experience. I've kept the following section
  1.1230 +    in the hint for this reason even though it doesn't apply anymore. Please
  1.1231 +    take the time to read it.
  1.1232 +    
  1.1233 +--------------------- old stuff start ----------------------------------------
  1.1234 +    Because of the error, the headers in /tools/include
  1.1235 +    are not world-readable. Unfortunately the LFS book (as of this writing)
  1.1236 +    does not correct this in Chapter 5 like it does in Chapter 6. For a
  1.1237 +    standard LFS build this is no problem, because glibc is built as root and
  1.1238 +    root can access everything regardless of permissions.
  1.1239 +    The glibc package user, however, does not have permission to access
  1.1240 +    these headers. This will cause several configure tests to fail, because
  1.1241 +    the respective test programs can not be compiled.
  1.1242 +    The end result is the error message "/lib/cpp fails sanity check", which
  1.1243 +    is completely nonsensical as we don't have a /lib/cpp.
  1.1244 +    
  1.1245 +    This is the perfect opportunity to introduce rule #1 of error diagnostics:
  1.1246 +    
  1.1247 +       NEVER TRUST DIAGNOSTIC MESSAGES !
  1.1248 +       
  1.1249 +    There are 2 kinds of diagnostic messages:
  1.1250 +    
  1.1251 +      1. Those that are unnecessary, because once you see which component has
  1.1252 +         failed, the source of the problem is obvious.
  1.1253 +      2. Those that grossly misdiagnose the source of the problem and lead
  1.1254 +         you to draw the wrong conclusions.
  1.1255 +    
  1.1256 +    No, there is no other kind. Trust me ;-)
  1.1257 +    In this case, /lib/cpp has nothing to do with the problem. It doesn't
  1.1258 +    exist and that's fine. The message just wants to trick you into doing
  1.1259 +    something stupid such as create a symlink /lib/cpp -> /tools/bin/cpp.
  1.1260 +    But that would be totally wrong. Before you jump to any premature 
  1.1261 +    conclusions you should always try to get as much *low-level* information 
  1.1262 +    as you can. Diagnostic messages are *high-level* information. They 
  1.1263 +    represent a filtered view of the problem, which is usually of little help.
  1.1264 +    Fortunately the message (the complete one, not the part quoted above) also
  1.1265 +    points at the source for the necessary low-level information. In this 
  1.1266 +    case that is the file config.log (not to be confused with configure.log, 
  1.1267 +    the file created by the build script included in the more_control_helpers 
  1.1268 +    archive).
  1.1269 +    config.log is created by all autoconf-created configures (not just that 
  1.1270 +    of glibc) and it contains, among other things, the test programs used by 
  1.1271 +    configure and messages output while building and running them. Whenever a 
  1.1272 +    configure script fails or gives weird results, check config.log. And 
  1.1273 +    always remember rule #2 of error diagnostics
  1.1274 +    
  1.1275 +       ALWAYS START AT THE FIRST ERROR
  1.1276 +       
  1.1277 +    This seems pretty obvious, but nevertheless people commonly do the exact
  1.1278 +    opposite. It's just too tempting to start at the point of the final 
  1.1279 +    failure and try to work backwards. In this case many people would open 
  1.1280 +    config.log and scroll to the point of the failed /lib/cpp sanity check.
  1.1281 +    After all, that's what caused configure to abort and so that's what needs
  1.1282 +    to be fixed, right?  WRONG! Someone who takes this approach just sees the 
  1.1283 +    error message "/lib/cpp: No such file or directory" and is even more 
  1.1284 +    convinced that a missing /lib/cpp symlink (or program) is the problem.
  1.1285 +    
  1.1286 +    The correct way to approach such a problem is to start at the beginning
  1.1287 +    of config.log, to scroll down to first error message and to check if it
  1.1288 +    is an issue that needs to be fixed (error messages in config.log are
  1.1289 +    not always signs for a problem). If the issue needs to be fixed, then
  1.1290 +    it needs to be fixed first, because all later errors could be rooted in
  1.1291 +    this issue (even if, no, *especially* if you don't believe this is the 
  1.1292 +    case).
  1.1293 +    If we apply this advice to the problem at hand, we quickly get to the first
  1.1294 +    serious error in config.log: 
  1.1295 +
  1.1296 +      "/tools/include/linux/limits.h: Permission denied"
  1.1297 +    
  1.1298 +    A quick check with ls reveals that indeed the directory with the linux
  1.1299 +    headers is not world-readable, which is obviously wrong. The fix is
  1.1300 +    easy. Just make (as root) the header directories /tools/include/{linux,asm} 
  1.1301 +    world-readable with commands similar to those the LFS book presents 
  1.1302 +    in Chapter 6 for the installation of linux-libc-headers.
  1.1303 +    Once this change has been made, glibc's configure succeeds.
  1.1304 +--------------------- old stuff end -----------------------------------------    
  1.1305 +
  1.1306 +TIP:
  1.1307 +    Even when configure completes successfully, you should still check the
  1.1308 +    output carefully to see if there is anything odd. E.g. if you're using
  1.1309 +    the wrappers, you should check that configure outputs the line
  1.1310 +    
  1.1311 +       checking for a BSD-compatible install... /usr/lib/pkgusr/install -c
  1.1312 +    
  1.1313 +    If configure detects a different install, such as /tools/bin/install,
  1.1314 +    something is wrong. Maybe there's a typo in the PATH for the package
  1.1315 +    user, or you've put the wrappers into a directory that is ignored by
  1.1316 +    configure.
  1.1317 +    
  1.1318 +
  1.1319 +    With the wrappers the glibc build and install should work smoothly. 
  1.1320 +    The wrapper script for install makes sure that the /usr/share/locale/* 
  1.1321 +    directories become install directories so that other programs can install 
  1.1322 +    their localized messages. 
  1.1323 +    One thing that the wrappers do not take care of, 
  1.1324 +    however, is the file /usr/share/info/dir. Because in the current LFS build
  1.1325 +    order glibc is the first package that installs info files, dir is owned by 
  1.1326 +    and only writable by glibc. In order to allow other packages to install 
  1.1327 +    info pages, execute the following commands as root:
  1.1328 +    
  1.1329 +       chown root:install /usr/share/info/dir &&
  1.1330 +       chmod ug=rw,o=r /usr/share/info/dir
  1.1331 +
  1.1332 +NOTE:
  1.1333 +    glibc wants to install the program pt_chown as setuid root. If you install
  1.1334 +    as a package user, the program will get installed but not given root
  1.1335 +    privileges (because of the install wrapper). 
  1.1336 +    The following info is from the glibc docs:
  1.1337 +          
  1.1338 +       One auxiliary program, `/usr/libexec/pt_chown', is installed setuid
  1.1339 +       `root'.  This program is invoked by the `grantpt' function; it sets the
  1.1340 +       permissions on a pseudoterminal so it can be used by the calling
  1.1341 +       process.  This means programs like `xterm' and `screen' do not have to
  1.1342 +       be setuid to get a pty.  (There may be other reasons why they need
  1.1343 +       privileges.)  If you are using a 2.1 or newer Linux kernel with the
  1.1344 +       `devptsfs' or `devfs' filesystems providing pty slaves, you don't need
  1.1345 +       this program; otherwise you do.  The source for `pt_chown' is in
  1.1346 +       `login/programs/pt_chown.c'.
  1.1347 +                               
  1.1348 +    So unless you're building a system that does not use devpts (which would
  1.1349 +    be quite unusual), this does not need to concern you.
  1.1350 +
  1.1351 +TIP:
  1.1352 +    In case you were wondering if you should create /etc/nsswitch.conf and
  1.1353 +    /etc/ld.so.conf as root or glibc, I recommend to assign all files that 
  1.1354 +    you manually create or manually edit to the root account. That way you can
  1.1355 +    distinguish between those files that can be regenerated automatically and
  1.1356 +    those that can not. Assigning even automatically generated files to
  1.1357 +    root once you make the first manual edit, ensures that a later 
  1.1358 +    reinstallation of a package won't silently do away with your manual tweaks.
  1.1359 +
  1.1360 +ldconfig:
  1.1361 +    Now that glibc has installed /sbin/ldconfig you can activate the ldconfig
  1.1362 +    wrapper if you want to. Perform the following steps as root 
  1.1363 +    AFTER re-adjusting the toolchain, 
  1.1364 +    just before starting with binutils:
  1.1365 +    
  1.1366 +       cd /usr/lib/pkgusr
  1.1367 +       gcc -O2 -W -Wall -o ldconfig ldconfig.c
  1.1368 +       chown root:install ldconfig
  1.1369 +       chmod u=rwxs,g=rxs,o= ldconfig
  1.1370 +  
  1.1371 +    These instructions make the ldconfig wrapper setuid root and setgid install
  1.1372 +    and prevent non-root users not in the install group from executing it. 
  1.1373 +    The setuid root is required so that it can replace /etc/ld.so.cache. 
  1.1374 +    The setgid install is not strictly required, but without it 
  1.1375 +    /etc/ld.so.cache will end up with the group of the last package user that 
  1.1376 +    touched it. If you use the user name=group name scheme this will cause the 
  1.1377 +    more_control_helpers scripts to believe that /etc/ld.so.cache belongs to 
  1.1378 +    the package in question which can be confusing.
  1.1379 +
  1.1380 +binutils:
  1.1381 +    Have you make /usr/share/info/dir group-writable as explained above in
  1.1382 +    the glibc notes? If you've missed that part, go back and do it now.
  1.1383 +    The installation of binutils should complete without problems. 
  1.1384 +    It does however cause minor conflicts with autoconf (see later).
  1.1385 +    
  1.1386 +NOTE:
  1.1387 +    At the time of this writing the version of bash used in the LFS book has
  1.1388 +    a bug that causes the list_package script to spit out errors and to list
  1.1389 +    all manpages of binutils (and other packages) as Broken. This bug is 
  1.1390 +    already fixed by the bash patch used by the book but the patch is not
  1.1391 +    applied in chapter 5. Since the manpage summary functionality of 
  1.1392 +    list_package requires man which is not installed until after bash is
  1.1393 +    rebuilt, this doesn't really matter, because while patching the
  1.1394 +    chapter 5 bash would get rid of the error messages, it wouldn't result
  1.1395 +    in usable manpage summaries.
  1.1396 +    
  1.1397 +    
  1.1398 +gcc:
  1.1399 +    Because the /usr/lib/libgcc_s.so* symlinks created at the beginning of
  1.1400 +    Chapter 6 is owned by root, gcc's installation cannot remove it. 
  1.1401 +    So you will have to remove it as root before `make install'.
  1.1402 +    Alternatively use
  1.1403 +    
  1.1404 +       chown -h gcc: /usr/lib/libgcc*
  1.1405 +       
  1.1406 +    to change ownership of the files in question after creating the gcc
  1.1407 +    package user. Note the -h option which has to be used to change 
  1.1408 +    ownership of the symlinks themselves rather than their target files.
  1.1409 +
  1.1410 +db:
  1.1411 +    It should be obvious that you don't want to change the ownership of the
  1.1412 +    installed files.
  1.1413 +    
  1.1414 +    
  1.1415 +coreutils:
  1.1416 +    Because the /bin/cat, /bin/pwd and /bin/stty symlinks are owned by root,
  1.1417 +    coreutils' installation cannot remove them. So you will have to remove 
  1.1418 +    them manually before `make install'. Alternatively use the command
  1.1419 +    
  1.1420 +       chown -h coreutils: /bin/{cat,pwd,stty}
  1.1421 +       
  1.1422 +    after creating the coreutils package user. Note the -h switch that makes
  1.1423 +    chown change the ownership of the symlinks themselves rather than their 
  1.1424 +    target files.
  1.1425 +    
  1.1426 +    The chapter 6 instructions move the coreutils binaries to /bin, including
  1.1427 +    the mv binary itself. You need to make sure that hashing is turned off
  1.1428 +    for this to work. The LFS book does this by putting `set +h' into the
  1.1429 +    LFS user's .bashrc. If you're following this hint, you're likely using
  1.1430 +    build scripts, so you need to put this command into the build script
  1.1431 +    before the mv commands.
  1.1432 +
  1.1433 +NOTE:
  1.1434 +    The man-pages package has already installed manpages for the binaries
  1.1435 +    from coreutils. The install wrapper will prevent coreutils from overwriting
  1.1436 +    those. This is done because the manpages from the man-pages package are 
  1.1437 +    of superior quality (although not necessarily uptodate). 
  1.1438 +    It also prevents errors during `make install' that
  1.1439 +    would otherwise occur because the coreutils package user cannot overwrite 
  1.1440 +    manpages owned by another user.
  1.1441 +    If you don't like the above behaviour and would rather have the original 
  1.1442 +    package manpages (because they are uptodate), you can set the variable 
  1.1443 +    manpagesowner at the beginning of the install wrapper to a string that
  1.1444 +    doesn't correspond to a package user name (it must not be empty, though!).
  1.1445 +    If you do this, you will have to resolve manpage conflicts in another way. 
  1.1446 +    The easiest way to handle this is probably to not install the man-pages 
  1.1447 +    package at the beginning of Chapter 6 but at the end, after all the other
  1.1448 +    packages have already installed their manpages. Then you need only deal 
  1.1449 +    with the conflicts once, when installing man-pages.
  1.1450 +
  1.1451 +
  1.1452 +ncurses:
  1.1453 +    The installation of ncurses (like that of other packages that include 
  1.1454 +    libraries) wants to run /sbin/ldconfig to update /etc/ld.so.cache. 
  1.1455 +    This fails because the package user doesn't have permission to replace 
  1.1456 +    /etc/ld.so.cache.
  1.1457 +    Making /etc/ld.so.cache group-writable by the install group doesn't help, 
  1.1458 +    because the permissions would be reset on the next call to /sbin/ldconfig.
  1.1459 +    This error will usually not abort the installation and you can just
  1.1460 +    run /sbin/ldconfig manually as root afterwards.
  1.1461 +    Alternatively you can use the ldconfig wrapper as described earlier.
  1.1462 +
  1.1463 +
  1.1464 +aclocal directory:
  1.1465 +    At the time of this writing the directory /usr/share/aclocal is
  1.1466 +    created during the bison installation. This directory contains
  1.1467 +    macros for autoconf. Other packages want to install 
  1.1468 +    files into this directory, so you should make it writable by the install 
  1.1469 +    group and sticky. 
  1.1470 +
  1.1471 +
  1.1472 +perl:
  1.1473 +    Before you do `make install', you will have to 
  1.1474 +    `chown -h perl: /usr/bin/perl' so that the perl package user is allowed to
  1.1475 +    remove the /usr/bin/perl symlink.
  1.1476 +    
  1.1477 +    If you will install add-on packages for perl as their own package users
  1.1478 +    into /usr/lib/perl5/site_perl, then you will need to turn 
  1.1479 +    /usr/lib/perl5/site_perl/ and its subdirectories into 
  1.1480 +    install directories. You don't need to do this now as you'll notice it
  1.1481 +    anyway when installing a perl add-on fails. 
  1.1482 +
  1.1483 +
  1.1484 +autoconf:
  1.1485 +    The autoconf package wants to install its own copy of standards.info,
  1.1486 +    which fails because binutils has already installed this file. You can 
  1.1487 +    either ignore the error or remove the binutils version of standards.info 
  1.1488 +    before `make install'.
  1.1489 +
  1.1490 +
  1.1491 +bash:
  1.1492 +  configure:
  1.1493 +    The bash configure script tests for the presence of the special devices
  1.1494 +    /dev/std* and /dev/fd/*. Unfortunately at the time of this writing the
  1.1495 +    test for /dev/fd/* is buggy (the test for /dev/stdin used to be broke, too
  1.1496 +    in bash-2.x, but has been fixed since). It ends up testing read access to 
  1.1497 +    standard input, 
  1.1498 +    which is the (pseudo)terminal you're building your system in. 
  1.1499 +    Unfortunately su doesn't change ownership of the terminal device, so when
  1.1500 +    you're su'd to a package user account, the terminal still belongs to the
  1.1501 +    login user. As the package user doesn't have read access to the device,
  1.1502 +    the tests fail.
  1.1503 +    
  1.1504 +    There is a simple way to get around this. Simply run ./configure like this
  1.1505 +    
  1.1506 +      ./configure ....  </dev/null
  1.1507 +    
  1.1508 +    The trick here is to redirect standard input (note, that this is a '<' not
  1.1509 +    a '>' !) to refer to /dev/null. Unlike the terminal device, /dev/null is
  1.1510 +    world-readable and world-writable, so the tests succeed as they should.
  1.1511 +    If you don't like this trick, you can also chown the terminal device in
  1.1512 +    question (see `ls -la /dev/fd/0') to the package user before building
  1.1513 +    bash.
  1.1514 +    
  1.1515 +  make check:
  1.1516 +    When running the test suite as a package user, the test "run-test" will 
  1.1517 +    fail with the output like this:
  1.1518 +
  1.1519 +      33d32
  1.1520 +      < *** chmod g+s /tmp/test.setgid
  1.1521 +      35c34
  1.1522 +      < 1
  1.1523 +      ---
  1.1524 +      > 0
  1.1525 +      64d62
  1.1526 +      < *** chmod u+s /tmp/test.setuid
  1.1527 +      66c64
  1.1528 +      < 1
  1.1529 +      ---
  1.1530 +      > 0
  1.1531 +      154c152
  1.1532 +      < 1
  1.1533 +      ---
  1.1534 +      > 0
  1.1535 +      160c158
  1.1536 +      < 1
  1.1537 +      ---
  1.1538 +      > 0
  1.1539 +    
  1.1540 +    The first 2 failures are caused by the chmod wrapper which prevents the
  1.1541 +    test from setting the setuid and setgid bits and outputs the *** warning.
  1.1542 +    The failures are harmless. You can get rid of them by removing the wrappers
  1.1543 +    directory from the PATH before running the tests.
  1.1544 +    
  1.1545 +    The last 2 failures are not specific to package users but will occur 
  1.1546 +    whenever you run the tests su'd to another user. The reasons are the same
  1.1547 +    as for the configure problem described earlier. The same solutions apply.
  1.1548 +    Either use chown (if you chowned before configure you're already 
  1.1549 +    done, of course) or run make check like this
  1.1550 +       
  1.1551 +      make check </dev/null
  1.1552 +    
  1.1553 +  make install:
  1.1554 +    Before you can `make install' you need to `chown -h bash: /bin/bash' as
  1.1555 +    root so that the bash installation can replace the /bin/bash symlink that
  1.1556 +    you manually created at the beginning of chapter 6.
  1.1557 +
  1.1558 +
  1.1559 +pkgconfig directory:
  1.1560 +    At the time of this writing the directory /usr/lib/pkgconfig is
  1.1561 +    created during the e2fsprogs installation. This directory contains
  1.1562 +    build information used by the pkg-config tool. Other packages want to 
  1.1563 +    install files into this directory, so you should make it writable by the
  1.1564 +    install group and sticky. 
  1.1565 +
  1.1566 +
  1.1567 +grub:
  1.1568 +    The commands to create and populate /boot/grub have to be executed as
  1.1569 +    root.
  1.1570 +    
  1.1571 +    
  1.1572 +grep:
  1.1573 +    Before you can `make install' you need to `chown -h grep: /bin/grep' as
  1.1574 +    root so that the grep installation can replace the /bin/grep symlink that
  1.1575 +    you manually created at the beginning of chapter 6.
  1.1576 +    
  1.1577 +
  1.1578 +inetutils:
  1.1579 +    This package contains some programs that it wants to be setuid root:
  1.1580 +    rsh, rcp, rlogin and ping
  1.1581 +    The install wrapper prevents these programs from being installed
  1.1582 +    setuid root. You must decide which of these programs you want to be 
  1.1583 +    setuid root and manually make them so. Be conservative. Don't make a
  1.1584 +    binary setuid root unless you *know* that ordinary users can't live
  1.1585 +    without it. Every setuid root binary is a potential security hole.
  1.1586 +
  1.1587 +
  1.1588 +iproute2:
  1.1589 +    This package tries to change the permissions of /usr/sbin and some man
  1.1590 +    directories. The install wrappers take care of this.
  1.1591 +
  1.1592 +
  1.1593 +man-db:
  1.1594 +    Even after installing man-db you won't get manpage summaries from
  1.1595 +    list_package, because the way list_package calls man it needs col
  1.1596 +    to work and col is from util-linux. You may however install util-linux
  1.1597 +    right away. The alphabetical sort is the only reason it is at the end
  1.1598 +    of Chapter 6.
  1.1599 +
  1.1600 +
  1.1601 +shadow:
  1.1602 +    By default shadow wants to install non-English manpages. This fails
  1.1603 +    because the /usr/share/man directory is not an install directory and
  1.1604 +    therefore package users are not allowed to create new subdirectories in it.
  1.1605 +    To solve this problem, before you `make install', open the file
  1.1606 +    man/Makefile, find the line 
  1.1607 +    
  1.1608 +      SUBDIRS = cs de es fr hu id it ja ko pl pt_BR ru zh_CN zh_TW
  1.1609 +    
  1.1610 +    and remove all the languages that you don't want to install. For those
  1.1611 +    languages that you do want to install, create directories with the
  1.1612 +    respective names in /usr/share/man as root and make them install
  1.1613 +    directories (i.e. group install, group-writable, sticky).
  1.1614 +    
  1.1615 +    There is yet another issue with shadow concerning manpages. The shadow
  1.1616 +    package contains a passwd.5 and a getspnam.3 manpage. 
  1.1617 +    Installation of these manpages is
  1.1618 +    automatically suppressed by the install wrapper, because it would 
  1.1619 +    overwrite the manpages provided by the man-pages package. As usual
  1.1620 +    the man-pages version is better, so you can simply ignore this issue.
  1.1621 +
  1.1622 +    shadow wants to install the programs su, chage, chfn, chsh, expiry, 
  1.1623 +    gpasswd, newgrp and passwd as setuid root. You will need to decide which 
  1.1624 +    of these programs you want to be setuid root and manually make them so. 
  1.1625 +
  1.1626 +
  1.1627 +sysklogd:
  1.1628 +    sysklogd's Makefile has /usr/bin/install hardwired as the install
  1.1629 +    program, which circumvents the install wrapper. The wrapper is needed 
  1.1630 +    for sysklogd because it tries to make its manpages owned by root 
  1.1631 +    (which obviously a package user is not allowed to do). 
  1.1632 +    Therefore, install with
  1.1633 +    
  1.1634 +      make INSTALL=install install
  1.1635 +
  1.1636 +
  1.1637 +udev:
  1.1638 +    udev wants to install files into the directory /usr/lib/pkgconfig. If
  1.1639 +    you've followed the instructions given further above you've already made
  1.1640 +    this an install directory. If you haven't, do so now or the udev 
  1.1641 +    installation will fail.
  1.1642 +    
  1.1643 +    The LFS instructions for installing udev tell you to execute the command
  1.1644 +      
  1.1645 +      mknod -m0666 /lib/udev/devices/null c 1 3
  1.1646 +      
  1.1647 +    Because a package user is not allowed to create device nodes, execute this
  1.1648 +    command as root.
  1.1649 +    
  1.1650 +
  1.1651 +util-linux:
  1.1652 +    util-linux wants to install write as setgid tty and u/mount as
  1.1653 +    setuid root. The wrappers catch this, so it doesn't cause the install to
  1.1654 +    fail, but as usual you'll have to decide if you want these programs to
  1.1655 +    have special privileges and take manual action as root if you do.
  1.1656 +
  1.1657 +
  1.1658 +##########################################################################  
  1.1659 + 8. Sanity Checks 
  1.1660 +##########################################################################
  1.1661 +
  1.1662 + 8.1 Suspicious Files
  1.1663 + --------------------
  1.1664 + 
  1.1665 +You probably ran the `list_package' command for each package and reviewed
  1.1666 +the results which include the suspicious files owned by that package. But even
  1.1667 +if you did that it's still a good idea to run the non-package specific 
  1.1668 +`list_suspicious_files' command once your build is complete. There could be
  1.1669 +something you overlooked the first time, or maybe you created a file as root
  1.1670 +with the wrong permissions. It doesn't hurt to check again and this will also
  1.1671 +give you the opportunity to review any setuid/setgid decisions you made with
  1.1672 +respect to the installed binaries.
  1.1673 +
  1.1674 +TIP: 
  1.1675 +  When you check the list of setuid and setgid files, don't forget to
  1.1676 +  look at the actual user or group ownership of the file. It's easy to forget
  1.1677 +  that, especially in the setuid case, because we often equate setuid with
  1.1678 +  setuid root since setuid is seldom used with other user accounts.
  1.1679 +
  1.1680 +  
  1.1681 + 8.2 References to Temporary Files
  1.1682 + ---------------------------------
  1.1683 +
  1.1684 +One big concern when building an LFS system is independence of the new LFS
  1.1685 +system from the files installed in /tools. The /tools directory is intended 
  1.1686 +to be temporary and it should be possible to delete it after building your
  1.1687 +LFS system with no adverse side effects. The `grep_all_regular_files_for'
  1.1688 +script from the more_control_helpers package can help you verify that your
  1.1689 +new LFS system is indeed clean. The command
  1.1690 +
  1.1691 +     grep_all_regular_files_for /tools
  1.1692 +
  1.1693 +will give you a list of all files that contain the string "/tools". Review the
  1.1694 +files in the list to make sure that no dependencies on the temporary files in
  1.1695 +/tools have crept in. But remember that results from binaries and libraries 
  1.1696 +are only meaningful after stripping away the debug information, because
  1.1697 +debug information necessarily includes references to the build environment.
  1.1698 +Of course, if you are a developer who will potentially run gdb on system
  1.1699 +libraries/binaries, your position will be that stripping away debug information
  1.1700 +is the wrong way to do away with /tools references. The other way to deal with
  1.1701 +them is to rebuild packages for which /tools references are reported. The new
  1.1702 +build will not involve any files from /tools and so the new debug information
  1.1703 +will not refer to /tools. Note that the LFS build instructions for glibc
  1.1704 +make glibc compile against /tools/glibc-kernheaders. Unless you copy the
  1.1705 +glibc-kernheaders directory to a location outside of /tools and compile glibc
  1.1706 +against that copy, you won't get rid of the /tools references in glibc's 
  1.1707 +debug information.
  1.1708 +No matter what means you choose to deal with the debug information issue, in 
  1.1709 +the end you should have a system where the above command produces only false 
  1.1710 +positives (such as "perlfaq3.1", which includes the URL
  1.1711 +"http://www.research.att.com/sw/tools/uwin/") and files that legitimately
  1.1712 +refer to /tools (such as a copy of this hint file).
  1.1713 +
  1.1714 +
  1.1715 +----------------------------- APPENDICES ----------------------------------
  1.1716 +
  1.1717 +
  1.1718 +###########################################################################
  1.1719 + Appendix A: Security Issues
  1.1720 +###########################################################################
  1.1721 +
  1.1722 + A.1 NFS
  1.1723 + -------
  1.1724 +
  1.1725 +If you use the network filesystem NFS, there are some things you need to
  1.1726 +look out for when using the package user system. A fundamental security 
  1.1727 +problem with NFS is that it blindly trusts the UID and GID of the client. 
  1.1728 +If an attacker can get access to the root account on a system in your network 
  1.1729 +that is allowed to mount NFS shares from your server, or if the attacker can 
  1.1730 +attach his own computer to your network, then this attacker can pretend to be 
  1.1731 +anyone. NFS will happily allow the attacker to work in the NFS exported 
  1.1732 +directory as any user he wants to be. The only exception is the root account. 
  1.1733 +By default NFS exports directories with the root_squash option that maps all 
  1.1734 +incoming requests from uid 0 to anonuid (65534 unless set in /etc/exports) 
  1.1735 +and gid 0 to anongid (65534 unless set in /etc/exports). This protects files 
  1.1736 +owned by root:root. On a normal system this includes most files in /bin, /etc,
  1.1737 +/lib and most other directories except /home. If you use the package user 
  1.1738 +scheme, however, most of these files are owned by package users. These files 
  1.1739 +are not protected by the root_squash option. In order to make NFS exports 
  1.1740 +secure, you have to add the option "all_squash" to every entry in /etc/exports 
  1.1741 +that exports a directory that contains files owned by package users. Note that 
  1.1742 +all_squash is always a good idea because even systems that don't use package 
  1.1743 +users often have some programs owned by other users or groups, because they 
  1.1744 +need to be setuid or setgid.
  1.1745 +
  1.1746 +
  1.1747 + A.2 Daemons
  1.1748 + -----------
  1.1749 +
  1.1750 +It is a common practice to run daemons under special user accounts rather
  1.1751 +than as root as a security measure. If you feel tempted to use a package 
  1.1752 +user account for this purpose, resist the temptation. It would be a very
  1.1753 +stupid idea. Although they are deliberately less powerful than root, package 
  1.1754 +user accounts are still privileged and need to be considered as equivalent to 
  1.1755 +root as far as security is concerned. Do not do anything with a package user 
  1.1756 +that on a system without package users you would not do with the root account.
  1.1757 +
  1.1758 +
  1.1759 +###########################################################################
  1.1760 + Appendix B: Package Categories
  1.1761 +###########################################################################
  1.1762 +
  1.1763 +Although the user name = group name scheme is recommended by this hint, it is
  1.1764 +not the only possible one. Another scheme that has some appeal is to define
  1.1765 +package categories and to use the group for the purpose of categorizing the
  1.1766 +packages. Following is a suggested set of categories that can serve as a
  1.1767 +guideline for implementing this scheme.
  1.1768 +
  1.1769 +devel: development related stuff, e.g. compilers. This is not restricted to
  1.1770 +       software development. TeX for instance would belong in this group.
  1.1771 +       
  1.1772 +utils: Most software fits into this category, even somewhat essential software 
  1.1773 +       like grep or text editors.
  1.1774 +      
  1.1775 +net: network related stuff such as an ftp daemon or a web browser. This
  1.1776 +     group overlaps with other groups to a large extent. It should be used
  1.1777 +     in preference of the other groups whenever a package is clearly focused
  1.1778 +     towards Internet, LAN, WWW,... A utility like wget for instance would
  1.1779 +     go in net rather than utils. Exceptions from this rule are the groups
  1.1780 +     docs, addons, games and mmedia. If a package fits into one of those 
  1.1781 +     groups, use the respective group instead of net.
  1.1782 +     
  1.1783 +docs: Documentation related packages, such as a tarball with Linux howtos.
  1.1784 +      Note that software to create documentation such as XML processors should
  1.1785 +      probably go in devel and software to view or post-process documentation
  1.1786 +      such as man or groff should probably go in utils.
  1.1787 +      
  1.1788 +system: important system software, such as bash. This group should be used
  1.1789 +        only for really essential packages. Most packages you would put in 
  1.1790 +        this group are better put in "utils". Vi for instance belongs in 
  1.1791 +        utils. 
  1.1792 +        It is unlikely that any package not part of basic LFS belongs in the
  1.1793 +        system group.
  1.1794 +        
  1.1795 +libs: What utils is for executables, libs is for libraries. Libraries that are
  1.1796 +      not strongly related to any of the other categories should go here, such
  1.1797 +      as zlib or libpng.
  1.1798 +      Essential system libraries such as glibc, ncurses or gettext should
  1.1799 +      go in system instead.
  1.1800 +      The libs group is also used for run-time environments such as the
  1.1801 +      Java Virtual Machine, dosemu and wine. Other emulators like MAME for
  1.1802 +      instance should probably go into games instead. 
  1.1803 +     
  1.1804 +games: what do you expect ;-)
  1.1805 +
  1.1806 +mmedia: This is the group for audio and video editors, mp3 players etc.
  1.1807 +
  1.1808 +apps: Applications such as spreadsheets and word processors (not text editors)
  1.1809 +      but also CAD software and graphics software such as Gimp.
  1.1810 +      The apps group is a bit like utils, but apps are usually more user 
  1.1811 +      friendly and more streamlined and feel less nerdish than utils. 
  1.1812 +      
  1.1813 +addons: plugins, filters and similar that are meant to be used in conjunction
  1.1814 +       with another package.
  1.1815 +       
  1.1816 +x: software that relates to the X Window System in general and does not fit
  1.1817 +   into any of the other categories, such as the X server itself or window 
  1.1818 +   managers.
  1.1819 +   Most X software should be put into other more specific groups.
  1.1820 +   A game like xmines would go in games for instance and a text editor for
  1.1821 +   X would go in utils.
  1.1822 +   
  1.1823 +kde: Software that relates to KDE and does not fit into
  1.1824 +     any other category. This group should be used with care. 
  1.1825 +     Do *not* use it for all KDE software. K Office for instance belongs in
  1.1826 +     apps. Konqueror belongs in net.
  1.1827 +     
  1.1828 +gnome: Software that relates to GNOME and does not fit into
  1.1829 +       any other category. This group should be used with care. 
  1.1830 +       Do *not* use it for all GNOME software. Gimp for instance belongs 
  1.1831 +       in apps. A GNOME-aware window manager that works with plain X should
  1.1832 +       go in the x group.
  1.1833 +
  1.1834 +
  1.1835 +###########################################################################
  1.1836 + Appendix C: Acknowledgements and Changelog
  1.1837 +###########################################################################
  1.1838 +
  1.1839 +ACKNOWLEDGEMENTS:
  1.1840 +  * Matthias Benkmann for writing the original version of this hint
  1.1841 +  * Tushar Teredesai for suggesting the user=group scheme.
  1.1842 +  * Markus Laire for reporting the 2005-01-01 build bug
  1.1843 +
  1.1844 +CHANGELOG:
  1.1845 +
  1.1846 +2007-10-20 Matthias Benkmann
  1.1847 +           -relicensed under CC-BY-SA (previously CC-BY-ND).
  1.1848 +           -added name tags to changelog entries in preparation for having the
  1.1849 +            hint continued by different authors.
  1.1850 +           -added workaround to list_package for bug in man-db that causes
  1.1851 +            some manpages to show up as "Weird manpage" in the summary.
  1.1852 +           -chmod wrapper now prevents shadow from installing files setuid 
  1.1853 +            shadow.
  1.1854 +           -added a wrapper to solve ldconfig issue.
  1.1855 +           -install_package now works when called with just a single argument. 
  1.1856 +            That argument is used for user name, group name and description.
  1.1857 +           -bash_profile of more_control_helpers now has /sbin and /usr/sbin 
  1.1858 +            in the PATH to match the PATH used by root when building.
  1.1859 +           -install_package does su - <name> now (i.e. start a login shell).
  1.1860 +           -build script now handles unpacking of tarballs and allows calling 
  1.1861 +            the different stages individually.
  1.1862 +           -useradd uses the -s provided shell and no longer hardwires bash.
  1.1863 +           -chapter 6 bash notes now properly address the configure and 
  1.1864 +            make check issues.
  1.1865 +
  1.1866 +2007-03-21 Matthias Benkmann
  1.1867 +           -changed forall_direntries_from to avoid warning message from find
  1.1868 +            when -depth is used.
  1.1869 +           -added 4.8 What Commands to Run as a Package User  
  1.1870 +
  1.1871 +2005-12-22 Matthias Benkmann
  1.1872 +           -added advice on how to cope with the moving mv problem to
  1.1873 +            coreutils note.
  1.1874 +
  1.1875 +2005-11-13 Matthias Benkmann
  1.1876 +           -fixed list_suspicious_files and list_package to work with
  1.1877 +            recent more POSIX-conforming versions of GNU find
  1.1878 +           -released version 1.2 
  1.1879 +
  1.1880 +2005-01-01 Matthias Benkmann
  1.1881 +            -fixed bug in skel-package/build script that caused it to report
  1.1882 +             all steps as successful, even if they failed 
  1.1883 +            -released version 1.1
  1.1884 +
  1.1885 +2004-11-01 Matthias Benkmann
  1.1886 +            -capitalized title
  1.1887 +            -released version 1.0
  1.1888 +            
  1.1889 +2004-10-14 Matthias Benkmann
  1.1890 +            -started developing the more_control_helpers utilities
  1.1891 +            
  1.1892 +2004-08-14 Matthias Benkmann
  1.1893 +            -started major rewrite (update for new LFS version, new hint 
  1.1894 +             format, textual improvements,...)
  1.1895 +
  1.1896 +2002-04-20 Matthias Benkmann
  1.1897 +            -changed LFS VERSION header to be more conservative
  1.1898 +            -added <br> tags to the synopsis for the sake of the hints 
  1.1899 +             index
  1.1900 +            -added group mmedia to the list of suggested groups 
  1.1901 +            -submitted v0.8
  1.1902 +
  1.1903 +2002-03-16 Matthias Benkmann  
  1.1904 +            -added note, that on Linux make doesn't need to be setgid kmem
  1.1905 +
  1.1906 +2002-02-18 Matthias Benkmann
  1.1907 +            -added section "Security issues with NFS"
  1.1908 +            -submitted v0.7
  1.1909 +
  1.1910 +2002-01-30 Matthias Benkmann
  1.1911 +            -added Changelog
  1.1912 +            -moved "chown 0.10000 `cat /tmp/installdirs`" command up (before
  1.1913 +             glibc package user is created)
  1.1914 +            -add_package_user: create home directory with "mkdir -p"
  1.1915 +                               use $grpfile everywhere instead of /etc/group
  1.1916 +            -improved mammoth sentence in Introduction
  1.1917 +            -added note about possibility to have user name==group name
  1.1918 +            -source bashrc_basic in bashrc_package
  1.1919 +            -minor textual changes