linuxmafia.com 2016/linuxmafia.com.tar/linuxmafia.com/pub/linux/tips-for-redhat-4.2-sysadmins.txt

Text File | 1998-03-13 | 25KB | 504 lines

   Notes on Red Hat 4.2 for Intel, by Rick Moen <[e-mail]>
                    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<tab>") 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 <permissions> <devicename> <devtype> <major#> <minor#>, 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 <[e-mail]> 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."