Notes on Red Hat 4.2 for Intel, by Rick Moen Last updated: 13 Mar 1998 This list is intended mostly for sysadmins new to Linux and Unix. Much of it won't make sense, immediately. However, print out and review it later, for it _will_ make sense soon. IMMEDIATE: -- Start a "system log" of notes on significant system changes. I use a college-type composition book. Start with your partition layout, as shown by the /sbin/fdisk utility and the contents of /etc/fstab. -- It's easiest to install _all_ of RH 4.2 (471 MB), and later remove what you're sure you don't need. Candidates (to remove): inn, inews, inn-devel, MetroX, XFree86-100dpi-fonts, pcmcia-cs (unless it's a laptop), howto-translations, howto-dvi, umsdos-progs, gn (gopher server), kterm. Remove redbaron if you're running 16 bits per pixel, since it works only at 8 bpp or 32 bpp. Remove all X servers other than the one you use plus XFree86-VGA16 (the generic VGA server). -- Apply RH updates (ftp://ftp.redhat.com/pub/redhat/redhat-4.2/updates/i386) before making any other system changes. These and other system upgrades are in many cases important for security. There are known serious security holes in many default RH 4.2 packages. Read Linux- security Web pages, for details. Since you probably don't yet have Internet access from Linux working, _if_ your machine can also run some other OS (such as Windoze), use _it_ to download the upgrades, then switch back to Linux, and move them to your Linux partition. (If your machine doesn't dual-boot, this matter may have to wait.) -- Installer lists existing Win95 partitions in /etc/fstab as type "msdos" (in error), unnecessarily precluding support for Win95 long filenames. Remedy this problem by changing "msdos" to "vfat", then remounting the Win95 filesystem(s). You'll want to fix this before, for example, moving upgrade RPMs from a Win95 partition to a Linux one. (When you recompile your kernel, don't forget to include "vfat" filesystem support.) -- Go through each /etc/rc.d/rc?.d/ directory and lower-case all symlinks of services you don't want to run. Do this for both S* and K* symlinks. (I mean, turn "S" into "s" and "K" into "k".) However, don't do this until _after_ you've installed all RH 4.2 upgrade RPMs and removed unwanted RPMs. For that matter, make _no_ other system changes (other than correcting /etc/fstab) until you've updated and removed RPMs. To change a /etc/rc.d/rc?.d/ symlink's case, type (for example) mv S62mars_nwe S62mars_nwe and left-arrow back to the second S62 to replace "S" with "s". bash's filename-completion (e.g., "S62") will let you type the initial line quickly, and then you just correct one letter and press return. Note that symlinks disabled in this fashion sort to the bottom of "ls" outputs, are easy to re-enable, and self-document their on/off state. -- Immediately after installation, "mv /tmp/install.log /root", or cron will delete it. -- Also immediately after installation, "find / -ls > /root/FILES.INSTALL &". This is a snapshot of your installation files, including inode numbers. Can make possible undeletion, later! -- As root, run "symlinks -cr / > /root/badsymlinks.log &". Read the log. Correct or delete any dangling symlinks. The "-c" parameter converts absolute symlinks to relative (which is a good idea). -- As root, run "/sbin/updatedb &", to create a starting file-location database for the ever-useful "locate" command. -- All three of the preceding commands can be started from a single shell: The ending "&" causes them to run in background. Do not close the shell from which they started, until they're reported their completion back to your console screen (or you'll close the background tasks, in closing your shell, because it's their parent process). -- Create your own account (e.g., "adduser yourname") immediately, and use it rather than the root login whenever possible. You can always type "su - " to open a root-account shell temporarily to do a necessary task, then "ctrl-d" or "exit" to revert to being "you". The root account is too powerful to use routinely, so cultivate the habit of avoiding it, now. -- For the same reason, don't spend time customising root's account, or making it comfortable. If tempted to do that, you're using it too much. NEXT: -- Read every file in /etc. If you want to edit one, save the original version first using "cp filename filename.INSTALL". Visit subdirs, too. -- To read text files without editing them, use the "more" or "less" utils. "less" scrolls both ways. "more's" display remains when you quit it. -- For editing text files, if vi and emacs seem too much for a beginner, try using simpler editors such as "joe" or "pico", for now. -- Unless you bought Official Red Hat and selected the MetroX server, you'll be using XFree86, and will require some effort to make it work well. XFree86's configuration file is /etc/X11/XF86Config, a text file. Read it. As you try to improve its contents, make backup copies, e.g. "/etc/X11/XF86Config.GOOD", in case you need to backtrack. /usr/X11R6/bin/Xconfigurator may help, as may /usr/X11R6/bin/XF86Setup. However, you should probably _read_ XF86Config, and adjust its contents using a text editor such as vi, pico, jed, joe, etc. The most important lines are HorizSync and VertRefresh, where you've declared your monitor's physical scanning-frequency limits -- safety limits that prevent X from sending any video mode outside its capabilities, which can damage it. Those lines were created when you told the Red Hat installer what monitor you have, and their accuracy is of vital importance. -- To check/debug a new XF86Config file, try "X > xerrors 2>&1" (called "starting bare X") Then kill the X server using Ctrl-Alt-Backspace, then read xerrors. In subsequently re-editing XF86Config, you may want to comment out invalid "ModeLine" lines, font paths, etc. You can get a guided tour from the "XFree86 HOWTO" document, at the Linux Documentation Project (see below), or in your own machine's Linux /usr/doc tree. -- Let's be realistic about the X Window System, OK? It was designed to run at 1024x768, minimum, and 8-bit colour (256 shades), bare minimum. Any lower resolution, and many X-based apps (e.g., Netscape) will have dialogues that extend off-screen, which is only partially fixable, with much work. Any fewer colours and you'll exhaust your colour palette every time you turn around. In fact, you really want 16-bit colour (65536 shades). 24/32-bit colour (true colour) is nice, but then your X server will take a huge amount of system RAM. Thus, you'll need a video card with at least 2MB of RAM, and a monitor capable of 1024x768 at 60 Hz or higher vertical refresh. (You really need a 17" monitor for adequate image size.) Don't try to get by with less, and you'll be a lot happier in the long term. -- Quick recipe for recompiling your kernel (which you _should_ do, ASAP): rm /usr/src/linux (a symlink) Un-tar source to be off /usr/src. (Will untar to /usr/src/linux.) mv /usr/src/linux /usr/src/linux-2.0.33 (for example) ln -s /usr/src/linux-2.0.33 /usr/src/linux (replace symlink) cd /usr/src/linux Open README in one window. Open another to /usr/src/linux, too. Follow instructions to re-create asm, linux, scsi (etc.) symlinks. make mrproper make config make dep ; make clean make zlilo > makelog 2>&1 & Watch the compile process in "tail -f makelog" mv /lib/modules/2.0.33 /lib/modules/2.0.33-old (if you run modules) make modules (if you run modules) make modules_install (if you run modules) Edit /etc/lilo.conf to make sure it's the way you want it. Make sure each kernel image in lilo.conf exists. Run "sbin/lilo -v", to make sure there're no errors. Reboot. Note that Apache 1.2.4 and up requires System V IPC support in one's kernel. So does Caldera's Looking Glass GUI-desktop app. -- Make sure /etc/lilo.conf always has an additional stanza for a known-good, older kernel file, such as /vmlinuz-2.0.30.INSTALL. (Copy your installation kernel to that filename.) Run "/sbin/lilo -v", to ensure that the older kernel is made usable. Then, if a new kernel doesn't work, you can still boot the older one. -- System attempts to activate Appletalk and IPX-networking kernel modules at startup time, even if you never compiled such modules. To prevent this, add the following to conf.modules: alias net-pf-4 off #Forget IPX alias net-pf-5 off #Forget AppleTalk -- cd /usr/bin ; mv ftp ftp.INSTALL ; ln -s ncftp ftp (ncftp is so much nicer. Why not make it the default? One possible answer why not: Conceivably, you might run scripts designed to invoke the default BSD-derived ftp client, which _might_ not work with ncftp. However, I know of no such gotchas.) -- Some other symlinks to consider (if they weren't created): /dev/mouse --> /dev/cua0 (if it's on COM1) /dev/modem --> /dev/cua1 (if it's on COM2) /dev/cdrom --> /dev/scd0 or /dev/hdd (or whatever device it is) -- Edit /usr/lib/lynx.cfg, to change default opening page, and to set "ADVANCED" mode (in which the current URL is displayed). (If you upgraded lynx to a very recent version, lynx.cfg may be in /etc, where it really belongs.) -- Put a placeholder file named "NOTHING_IS_MOUNTED_HERE" in each of your mountpoint directories. It will be visible only when nothing is mounted, there. -- Renumber the symlinks in the /etc/rc.d/rc?.d directories (especially rc3.d) to start the two "yp" scripts before cron, and (where applicable) stop the two "yp" scripts after cron. yp must start first, or cron won't work. This error is also in RH 5.0. -- Edit /etc/rc.d/rc.sysinit to zero out /etc/rmtab exactly the same way /etc/mtab is, at boot time. This error is also in RH 5.0. -- /etc/cron.weekly/makewhatis.cron is broken: Needs full path to the "makewhatis" binary, /usr/sbin/makewhatis. -- /usr/local/include directory doesn't exist. Some packages carelessly copy files to "/usr/local/include" without verifying the dir's existence. Directory should be created, to compensate. AFTER INITIAL SETUP: -- You may want to establish dial-up modem access to the Internet: You'll find _many_ recipes for this on Linux-oriented Web pages. Read out and study a number of them, and then pick and implement one. Several packages are in general use: chat, dip, pppd, and diald. (Personally, I think diald looks like a winner, but you should decide.) http://sunsite.unc.edu/LDP/HOWTO/ISP-Hookup-HOWTO.html http://www.interweft.com.au/other/rhtips/ppp/ppp-tip.html http://sunsite.unc.edu/LDP/HOWTO/mini/Diald.html http://www.loonie.net/~eschenk/diald.html http://www-callug.cs.berkeley.edu/ppp/primer.html http://www.cnw.com/~elarsen/linux/pppassis.html http://users.hol.gr/~dbouras/ http://www.gaijin.com/linux/ppp.html http://www.gslink.com/~mkb/linux/modem.html http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html, the PPP HOWTO, gives _very_ extensive general information on the subject. Generally, it goes something like this: Make your modem dial your Internet service. Log in. Start PPP or SLIP on the far end (on your Internet service). Start TCP/IP networking on your end (your Linux box). Ping 127.0.0.1 and then "localhost" to make sure it works. Configure your IP resolver (/etc/resolv.conf) for DNS nameservice. Assign an IP (network) address to your modem device. Set a default IP route out through your modem's IP address. Verify Internet connectivity using ping, traceroute, etc. Automate connection process using scripts, etc. Doing the above _a step at a time_ (instead of hastening to drop in some packaged, automated solution) makes debugging easier. -- It doesn't hurt to have several nameserver entries in /etc/resolv.conf. -- Netscape Navigator & Communicator for Linux are available and work well, but tend to crash on Java apps in particular, because Netscape linked them against an obsolete version of libc. To render Netscape's browsers rock-solid, use the simple fix technique described on the Linux-Netscape Help Page, http://members.ping.at/theofilu/netscape.html. -- To install a new RPM: "rpm -iUv foo.rpm" Binary RPMs go wherever the binaries are set to go; SRPMs (source-code RPMs) go to /usr/src/redhat/SOURCES. -- As you install either RPMs/SRPMs or ordinary tar.gz archives of programs to your system, put the original compressed archive in /usr/local/src/installed. Put _candidates_ for installation in /usr/local/src. Consider archiving a copy of this tree on occasion to tape, or Zip disk, or wherever you can. -- RPMs are a good way to get Linux running quickly. However, their convenience comes at the price of using code compiled against someone else's libs, with the installed files going to someone else's choice of directory locations -- and the quality of RPMs varies wildly, with some important ones from Red Hat Software itself (such as GNU tar) having known defects. Therefore, consider weaning yourself off them. The first step is to use SRPMs (source-code RPMs with filename extension ".src.rpm"), in place of the pre-compiled binaries in "regular" RPM packages (having extension "i386.rpm"). These unpack to /usr/src/redhat/SOURCES, where you'll find the standard ".tar.gz" source archive plus usually one or more ".patch" files to make Red-Hat-specific modifications. One applies the patches by unpacking the .tar.gz, entering the top of the package's directory tree, then typing "patch < patchname.patch" (where "patchname" is whatever). Then, compile as directed by the INSTALL or README* file(s). When you're comfortable with this process, you'll be able to compile almost any source archive, be able to stay current with security fixes, and generally be better equipped to run a well-functioning system. -- Most source archives, especially GNU ones, can be compiled like this: Unpack. Enter the top directory. Read filename INSTALL or README*. ./configure (Figures out your system, composes a Makefile.) Edit the resulting Makefile, to install to dirs you prefer. make (Does the actual compilation.) make check (You observe to see if it passes the tests.) make install (Puts the binaries, etc., where Makefile says to.) Any package that provides a "configure" script is probably a slam-dunk. -- If you have to customise a package significantly in order to compile & install it, consider tar-gz-ing up (archiving and compressing for storage) the modified source tree for safekeeping. E.g., since I put significant work into modifying the unpacked files from lynx-2.7.1-SSL.tar.gz, I stored the resulting tree separately as a lynx-2.7.1-SSL-hugin.tar.gz archive ("hugin" being my machine's hostname), and put that file in /usr/local/src/installed. -- If you upgrade a package (or replace it from source code), watch out that you may be putting new files in a different place, leaving the old ones still present (e.g., /usr/local/bin vs. /usr/bin, /usr/local/lib vs. /usr/lib). When I'm about to compile a replacement from source code, I check for this gotcha by reading the Makefile's directive for "make install", then finding what it should "replace" on my system using the locate command. You can delete the originals, _or_ rename them to *.INSTALL and put in place of the original files symbolic links to the new locations. The latter is the best approach, in case some other program has hard-coded references to the original file locations. -- Check relevant error log(s) in /var/log any time you adjust or upgrade (and then restart) any daemon. Always start daemons by invoking their script files in /etc/rc.d with a "start" or "stop" parameter. E.g., "/etc/rc.d/init.d/httpd.init stop". It's a bad habit to circumvent the /etc/rc.d scripts: Useful system maintenance (e.g., creation of lock files under /var/lock) doesn't occur when you do that. -- "ln -s" will use as default symlink name the filename of whatever you link to. E.g., if tempted to type ln -s /boot/vmlinuz-2.0.33 vmlinuz-2.0.33 you can accomplish the same thing with ln -s /boot/vmlinuz-2.0.33 -- "cd -" will toggle back and forth between your current directory and the one you were in last. -- To create a missing /dev file: mknod -m , e.g., mknod -m 644 zero c 1 5 -- Resist the urge to upgrade libc to a later major version (e.g., 5.3.12 to 5.4.x), unless you don't mind forced upgrade of other components such as ld.so, ncurses, gcc, libg++. -- Note the symlink system in /usr/lib and /lib, for filenames starting with the "lib" prefix. Visual scrutiny sometimes reveals wrong symlinks, or version-number symlinks it would be a good idea to provide. Correct using "ln -sf reallibraryfile.so.x aliasname.so.y" where x and y are version numbers. Look in particular at libmenu.so.*, libncurses.so.*, libform.so.*, libpanel.so.*, libhistory.so.* -- run "ldconfig -v". Note any cases of "sonames" not matching the library names, e.g. libistory.so.2.0 having an "soname" of "readline.so.2". If you upgrade ld.so (which you should -- the provided ld.so has a big security hole), you'll need to fix. Fix by mv'ing the library to its soname, then putting a symlink as the name the library used to be. Realign any symlinks that pointed to the old name, using "ln -sf ..." -- /home doesn't contain just home directories: httpd, ftp, gopher, samba. In my view, those should be under /usr/local/etc. -- If you move ftp's tree out of /home, edit ftp's home directory in /etc/passwd, to match. -- If you move httpd's tree out of /home, edit Apache's configuration files in /etc/httpd/conf to match. -- gopher and samba trees can also be moved out of /home, and you'll have to find their configuration files and edit them to match. -- One way to duplicate or move an entire filesystem (e.g., move "usr"): "cd /mnt/newfilesystem ; dump 0f - /usr | restore xf -" Remember to "mkfs -t ext2 /dev/xxx", first (where xxx = sdb1, hdd1, etc.). GNU tar can also do this trick, but the version shipped with RH 4.2 and prior often gets ownership wrong, when untarring. Get the newest source tree from ftp://ftp.gnu.org/, and recompile. (GNU apps are always easy to compile. See description, above.) -- "cpio" can also be used to move/duplicate entire filesystems. Jim Dennis described how in an issue of Linux Gazette, http://www.ssc.com/lg/issue22/lg_answer22.html#mvusr: "cd /usr && find . -print0 | cpio -p0vumd /mnt/newfilesystem" -- Red Linux Gazette (URL above). Subscribe to the (on-paper) magazine _Linux Journal_. Buy and read Matt Welsh's book, _Running Linux_. Visit the Linux Documentation Project at http://sunsite.unc.edu/LDP/, and explore -- especially the HOWTO and mini-HOWTO documents. Rummage through your own system's /usr/doc: There are treasures in there! -- Skim-read the File Hierarchy Standard (FHS -- formerly called File System Standard, or "FSSTND"), to understand the the Linux directory tree's basic design logic. It's somewhat obscured by backwards-compatibility (thus all the symlinks), and not always honoured, but nonetheless exists. See http://www.pathname.com/fhs/. -- Tired of having to confirm cp, rm, and mv command, when logged in as root? Comment out the aliases in "/root/.bashrc". -- If not running kernel modules, comment out the roughly ten lines in /etc/rc.d/rc.sysinit that invoke kerneld and depmod. -- lynx configuration file (lynx.cfg) is in /usr/lib, which is wrong. Should be in /etc. Newest lynx RPMs relocate it. POST-INSTALLATION SECURITY FIXES: -- Default Apache configuration files are insecure, and benefit from rewriting. See http://www.apache.org/docs/misc/security_tips.html. -- Apache runs as user "nobody", group "nobody". Should have its own username/group to run as, such as httpd. Add to passwd and group files, then edit Apache's httpd.conf, to match. -- To improve Apache security: -- Allow CGI only in ScriptAlias directory, or other directories not open to browsing by users. -- Reconfigure Apache to run in chroot environment. (How difficult to implement? Not sure.) -- Use CGIWRAP. -- Edit /etc/inetd.conf, to disable unwanted services by prepending a "#" (comment) symbol to their definition lines. Assume _all_ services to be unwanted until you have a reason to enable them. If you need to offer a network service and have it disabled, you'll figure it out with no difficulty -- so, when in any doubt whatsoever, turn them off. (If you end up commenting everything out, disable the inet daemon by lower-casing its S* and K* symlinks in /etc/rc.d/rc?.d, since it will have no work to do.) -- Unlike RH 5.0's, 4.2's sendmail is not protected against abuse by spammers using it for relaying mail. (See http://maps.vix.com/tsi/.) Get sendmail-8.8.8-0.i386.rpm from ftp.redhat.com, which incorporate's Claus Assmann's complete set of anti-spam filters. (See anti-spam links from http://www.sendmail.org/, for details.) Suggested entries for /etc/mail/deny are at http://www.sprocket.com/Security/SpamDomains. However, the RPM (above) specifies some wrong return codes in /etc/sendmail.cf. If you know what you're doing, fix sendmail.cf as follows: 501: sender hostname was invalid (no period in it) 550: returned if rejecting sender domain, IP address, hostname, or to reject relaying 551: user moved ("redirect" result) 552: reject sender's particular e-mail address Any time you put in a new sendmail, run "newaliases". Check the error log (/var/log/maillog), after restarting sendmail. -- Sendmail includes restricted shell /usr/bin/smrsh. chmod to 511. Declare this as "Mailer Program" shell in /etc/sendmail.cf. Be sure to create & populate /etc/smrsh with symlinks to programs it's allowed to run, such as answer, fastmail, formail, mailto, procmail, vacation, mail, burst, comp, dist, forw, inc, mhmail, send. -- Consider xinetd instead of tcp-wrapper (AKA tcpd). -- /usr/bin/dos (DOSemu) is 4755 (SUID). Should be 755. -- /sbin/dump and /sbin/restore are 6755 (SUID/SGID). Should be 755. -- /usr/X11R6/bin/seyon is 2755 (SGID). Should be 755. -- /bin/mount and /bin/umount are 4755 (SUID). Should be 755. -- /usr/bin/zgv is 4555 (SUID). Should be 555. -- /var/lib/games/trojka.scores is world-writable and SUID. Used by RPM packages trojka and xtrojka. Easy remedy: Remove trojka/xtrojka. -- ld.so is 1.7.4. All versions before 1.9.3 had a buffer-overflow security hole. -- /sbin/request-route script had an inherent root-exploit security hole. (Remove or archive.) -- Audit & protect system security using chkexploits, COPS, tiger, SATAN, tripwire. Available at ftp://hugin.imat.com/pub/linux/security. -- Some additional security resources: http://www.redhat.com/linux-info/security/Linux-Security-FAQ/ http://www.replay.com/redhat/ http://www.caldera.com/tech-ref/security/ http://www.trouble.org/ http://www.rootshell.com/ ftp://ftp.iss.net/pub/faq/anonftp http://www.deter.com/unix/ http://main.succeed.net/~bbuster/hacking/new/unixhack.txt http://ssh.connectnet.com/ http://www.sans.org/ http://www.stokely.com/stokely/unix.sysadm.resources/dns.email.security.html http://www.hilotek.com/Security/Security.html WHY NOT RED HAT 5.0? Strategic cowardice about libc version 6 compatibility. Maybe soon, but you can always tell the pioneers by the arrows sticking out of their backs. Prasanth Kumar has described the main problem succinctly: "...I'm not an expert at this but it is possible that when that program was compiled they might have hard coded the path to that library by giving the full pathname to gcc. It might have work for 99% of the people since libc.5 is usually in /lib but now with libc.6 the problems are cropping up. I know this is possible but don't know of any easy way to test it... This is one of the general reasons I have back-reved from Redhat 5.0 to 4.2. It was too much trouble recompiling old apps which used to work. I hope by the time 5.1 comes out most apps have been compiled to libc.6."