From whitis@dbd.com Wed Mar 11 21:15:56 1998 Date: Tue, 18 Nov 1997 09:02:01 -0500 (EST) From: Mark Whitis To: bugs@redhat.com Cc: Jeff Uphoff Subject: Symbolic link bugs Some of these bugs were reported when 4.0 was released but are still present in 4.2 and new ones were discovered trying to upgrade from 4.0 to 4.2. The problem was minor under 3.3 but the 4.x install program broke things more severely. The system configuration which I use is the result of serious consideration and years of experience and is a general continuation of the trend of putting things where they belong in the un*x filesystem over the years (getting writeable crap out of /usr, for example) and separating the logical filesystem from the underlying physical filesystems. I have used variations of this system for a decade on SunOS, Solaris, and linux boxes. The various configurations used by most DECENT un*x system administrators on systems of any reasonable size move in the same direction as my configuration and will break the redhat installer. Note that the impact of these redhat bugs is sufficent to waste days of an experienced system administrators time. Also note that the bugs are seriously exacerbated by redhat announcements that to fix security bug "X", administrators should upgrade to 4.2 instead of just listing ALL the packages that need to be upgraded (perhaps in single user mode), if necessary. Sample system configuration: - Root partition small (50mb), has almost nothing which is normally written during system operation, this reduces the possibility of normal defragmentation corrupting essential system utilities, etc. - swap partition - big partition /disk0 (additional partions /disk1, /disk2) on successive drives. - a small scratch partition which can be reconfigured as necessary to deal with the occasional need to put certain files (such as /tmp) on a filesystem with odd permissions). /usr --> /disk0/usr /var --> /disk0/var /tmp --> /disk0/var/tmp /local --> /disk0/local /usr/local --> /disk0/local /home/user1 --> /disk0/home/user1 /home/user2 --> /disk0/home/user1 /home/user3 --> /disk0/home/user1 Redhat bugs: - Redhat 3.x and 4.x installers do not let you specify your disk layout adequately, particularly symlinks. Under 3.x, it was fairly easy to trick the system into doing the right thing by switching consoles to a shell window and rearranging things partway during the install. Under 4.x, you have to mount the partition as /usr during the initial install and move things using the attached 'movestuff' shell script as a crude workaround. After the partioning stage of the install, there should be a screen which lets you add symbolic links. - 4.2 upgrade fails to find the rpm database on the system to be upgraded until you create a symlink from "/disk0" --> "/mnt/disk0" as soon as possible in a shell window. - When performing an upgrade to 4.2, the system overwrites existing symlinks (such as "/usr" --> "/disk0/usr") with new directories instead of following them as it should (they are now valid in either the install ramdisk or chroot to /mnt environments). THIS IS THE MOST SERIOUS PROBLEM right now. - Redhat misuses relative symbolic links in many places, perhaps, in some cases, as a kludge to make your installation system work. Relative symbolic links should never try to cross traditional mount points (such as from somewhere in /usr to somewhere in /etc). These should be absolute links. The relative links break if you move them to another disk and they are evaluated on the wrong machine in a NFS environment. You certainly do not want /etc/X11/XF86Config evaluated on the server instead of the client, for example. Relative symbolic links are usually appropriate within the same package and section of the filesystem. Note that many of the broken links appear to have been created specifically by redhat and not just inherited from the default install for the packages. Most of the broken symbolic links are linking from somewhere in /usr to "/bin", "/etc", and "/lib" as relative symbolic links; as a kludgy workaround, I have put symbolic links from /disk0/bin --> /bin /disk0/etc --> /etc /disk0/lib --> /lib If you need to use links that will mean the same thing in your chroot()ed environment, use "/sysroot --> /" in a normal system and "/sysroot --> /mnt" during install and include /sysroot where appropriate. Reproducing the upgrade problem: - install 4.0 on a scratch machine (I use a jaz drive) - boot single user - copy and run movestuff (see attachment to this message) - shutdown - install 4.2 Some system configurations NOT to use, which are widely used by amateur system administrators: - Make /home, /tmp, /usr, /local, /var all on different partitions This is the "traditional" method that causes all kinds of problems, including: - Not enough room in the partition table, particularly on a multiboot system - your space is broken up into small pieces, all of which turn out to be the wrong size :-) - eventually, as a result of the previous problem and the so called "solutions" to the problem, you end up with a gordeon knot of cross linked file systems. You ran out of room for /home/yourboss in the /home partition but you had room in /usr so you move his home directory to /usr where it doesn't belong. Then you need to install "bigpackage" but you are out of room in /usr so you end up putting it in /var. The new mailing list fills up your /var system so you take advantage of some newly freed space in /home. And then "yourboss" deletes an important file. No problem, although you only backup /usr once a month or after major installs, you backup /home daily, right? Only he isn't in /home, is he. - One partition fits all. System defragmentation causes essential files (kernel, /etc/*, /bin/*, /sbin/*) to be at risk of being lost during power outage, crash, or other mishap even though they haven't been modified. This increases the possibility that your system won't boot and makes it more difficult to fix the problem when it doesn't. Note that the configuration I use also adapts easily to having two partitions "/writeable" and "/readonly". One negative side-effect of the system I use is that it occasionally breaks buggy code (usually shell scripts) that makes mistakes like find /tmp -blah -blah -blah instead of find /tmp/ -blah -blah -blah Fortunately, this is not much of a problem with most of the stuff supplied with Redhat 4.x. Most of the code which would make mistakes like this has already been taken out and shot for other offenses. --------------------------------------------------------------------------- --- Mark Whitis WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- --------------------------------------------------------------------------- [Part 2, "movestuff" Text/PLAIN 34 lines] [Unable to print this part]