Making room for new chapter and a few minor modifications.

1 files changed, 100 insertions, 356 deletions

diff --git a/chapter_18.xml b/chapter_18.xml
index bc49aed..ea3035c 100644
--- a/chapter_18.xml
+++ b/chapter_18.xml
@@ -3,375 +3,119 @@
   "/usr/share/xml/docbook/xml-dtd-4.5/docbookx.dtd">
 
 <chapter>
-<title>The Linux Kernel</title>
+<title>Keeping Track of Updates</title>
 
 <section>
-<title>What Does the Kernel Do?</title>
-
-<para>
-You've probably heard people talking about compiling the kernel or
-building a kernel, but what exactly is the kernel and what does it do?
-The kernel is the center of your computer. It is the foundation for the
-entire operating system. The kernel acts as a bridge between the
-hardware and the applications. This means that the kernel is (usually)
-the sole piece of software responsible for ordering around the hardware
-components of your computer. It is the kernel that instructs the hard
-drive to search for a certain data stream. It is the kernel that
-instructs your network card to transmit rapid changes in voltage. The
-kernel also listens to hardware as well. When the network card detects
-a remote computer sending information, it forwards that information to
-the kernel. This makes the kernel both the single most important piece
-of software on your computer and the most complex.
-</para>
+<title>The -stable Branch</title>
+
+<para>
+Whenever a new version of Slackware is released, the Slackware team will,
+as needed, release updated packages to fix serious security vulnerabilities
+and particularly nasty bugs.  Therefore, it's important to keep up with all
+of the patches for your version of Slackware, which is referred to as the
+"-stable" branch.  There is also a "-current" branch, which is where we do
+our development work toward the next stable release (and as such, there are
+often intrusive changes there), but unless you're willing to work with a 
+possibly broken system and are able to fix things on your own, we strongly
+recommend that you stick with the "-stable" branch.
+</para>
+
+<para>
+Since -stable updates aren't distributed on the disks, you'll need to obtain 
+them from the Internet.  Many people and organizations offer mirrors from 
+which you can download the entire Slackware tree (or only the
+<filename>patches/</filename> directory) in any number of ways.  While some 
+mirrors offer web access, the most common ways of obtaining updates are via 
+ftp and/or rsync servers.  The Slackware project maintains a small list 
+(organized by country) of known mirrors.  If you're unsure which mirror you
+should use, simply consult 
+<ulink url="http://www.slackware.com/getslack/">http://www.slackware.com/getslack/</ulink>
+for suggestions.  If you have a major university near you, there's a good 
+chance that they offer a mirror of numerous open source projects, and
+Slackware may be among them.  The only real requirement for a mirror is that 
+it be complete, but usually it's best to use a mirror near where you live in 
+order to achieve the fastest transfer times and use the least amount of 
+Internet resources.
+</para>
+
+<para>
+So how do you know when there are updates?  The best way is to consult the 
+<filename>ChangeLog.txt</filename> on any up-to-date mirror.  You can always 
+find the latest changelogs for the "-current" and most recent "-stable" 
+branch on the Slackware Project's web page, but if you're running an older 
+version of Slackware, you'll need to check a mirror.
+</para>
+
+<screen><prompt>darkstar:~# </prompt><userinput>wget -O - \
+ftp://slackware.osuosl.org/pub/slackware/slackware-13.0/ChangeLog.txt \
+| less</userinput>
+Sun Jan 24 20:22:46 UTC 2010
+patches/packages/httpd-2.2.14-i486-1_slack12.1.tgz:  Upgraded.
+  This fixes a couple of security bugs when using mod_proxy_ftp.
+  For more information, see:
+    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3094
+    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3095
+  (* Security fix *)</screen>
 
 </section>
 
 <section>
-<title>Working with Modules</title>
-
-<para>
-The complexity of a modern linux kernel is staggering. The source code
-for the kernel weighs in at nearly 400MB uncompressed. There are
-thousands of developers, hundreds of options, and if everything were
-built together, the kernel would soon pass 100MB in size itself. In
-order to keep the size of the kernel down (as well as the amount of RAM
-needed for the kernel), most of the kernel options are built as
-modules. You can think of these modules as device drivers which can be
-inserted or removed from a running kernel at will. In truth, many of
-them aren't device drivers at all, but contain support for things such
-as network protocols, security measures, and even filesystems. In
-short, nearly any piece of the linux kernel can be built as a loadable
-module.
-</para>
-
-<para>
-It's important to realize that Slackware will automatically handle
-loading most modules for you. When your system boots,
-<application>udevd</application>(8) is started and begins to probe your
-system's hardware. For each device it finds, it loads the proper module
-and created a device node in <filename>/dev</filename>. This usually
-means that you will not need to load any modules in order to use your
-computer, but occasionally this is necessary.
-</para>
-
-<para>
-So what modules are currently loaded on your computer and how do we
-load and unload them? Fortunately we have a full suite of tools for
-handling this. As you might have guessed, the tool for listing modules
-is <application>lsmod</application>(8).
-</para>
-
-<screen><prompt>darkstar:~# </prompt><userinput>lsmod</userinput>
-Module                  Size  Used by
-nls_utf8                1952  1 
-cifs                  240600  2 
-i915                  168584  2 
-drm                   168128  3 i915
-i2c_algo_bit            6468  1 i915
-tun                    12740  1 
-... many more lines ommitted ...
-</screen>
-
-<para>
-In addition to showing you what modules are loaded, it displays the
-size of each module and tells you what other modules are using it.
-</para>
-
-<para>
-There are two applications for loading modules:
-<application>insmod</application>(8) and
-<application>modprobe</application>(8). Both will load modules and
-report any errors (such as loading a module for a device that isn't
-present in your system), but <application>modprobe</application> is
-preferred because it can load any module dependencies. Using either is
-straight-forward.
-</para>
-
-<screen><prompt>darkstar:~# </prompt><userinput>insmod ext3</userinput>
-<prompt>darkstar:~# </prompt><userinput>modprobe ext4</userinput>
-<prompt>darkstar:~# </prompt><userinput>lsmod | grep ext</userinput>
-ext4                  239928  1 
-jbd2                   59088  1 ext4
-crc16                   1984  1 ext4
-ext3                  139408  0 
-jbd                    48520  1 ext3
-mbcache                 8068  2 ext4,ext3
-</screen>
+<title>Security Update Mailing List</title>
 
 <para>
-Removing modules can be a tricky process, and once again we have two
-programs for removing them: <application>rmmod</application>(8) and
-<application>modprobe</application>.  In order to remove a module with
-modprobe, you'll need to use the <arg>-r</arg> argument.
+While the Slackware team does release updated bugfix-only packages (i.e. 
+not security fixes) occasionally, you're probably most interested in 
+security fixes for vulnerabilities discovered after the -stable release.
+The Slackware Project maintains a mailing list that will notify you of any 
+updated packages for such serious issues.  In order to subscribe to the
+mailing list, send an e-mail to <email>majordomo@slackware.com</email> 
+with the words 'subscribe slackware-security' in the body of the message. 
+The majordomo will be happy to add your name to the list, and when new 
+packages are released, it will mail an advisory to you.
 </para>
 
-<screen><prompt>darkstar:~# </prompt><userinput>rmmod ext3</userinput>
-<prompt>darkstar:~# </prompt><userinput>modprobe -r ext4</userinput>
-<prompt>darkstar:~# </prompt><userinput>lsmod | grep ext</userinput>
-</screen>
-
 </section>
 
 <section>
-<title>Compiling A Kernel and Why to do So</title>
-
-<para>
-Most Slackware users will never need to compile a kernel. The huge and
-generic kernels contain virtually all the support you will need.
-However, some users may need to compile a kernel. If your computer
-contains bleeding edge hardware, a newer kernel may offer improved
-support. Sometimes a kernel patch my be available that corrects a
-problem you are experiencing. In these cases a kernel compile is
-probably warranted.  Users who simply want the latest and greatest
-version or who believe using a custom compiled kernel will give them
-greater performance can certainly upgrade, but are unlikely to notice
-any major changes. If you still think compiling your own kernel is
-something you want or need to do, this section should walk you through
-the many steps.
-Compiling and installing a kernel is not that difficult, but there are
-a number of mistakes that can be made along the way, many of which can
-prevent your computer from booting and cause major frustration.
-</para>
-
-<para>
-The first step is ensuring you have the kernel source code installed on
-your system.  The kernel source package is included in the "k" disk set
-in the Slackware installer, or you can download another version from
-<ulink url="http://www.kernel.org/">http://www.kernel.org/</ulink>.
-Traditionally, the kernel source is located in
-<filename>/usr/src/linux</filename>, a symbolic link that points to the
-specific kernel release used, but this is by no means set in stone. You
-can place the kernel source code virtually anywhere without
-encountering any problems.
-</para>
-
-<screen><prompt>darkstar:~# </prompt><userinput>ls -l /usr/src</userinput>
-lrwxrwxrwx  1 root root   14 2009-07-22 19:59 linux -> linux-2.6.29.6/
-drwxr-xr-x 23 root root 4096 2010-03-17 19:00 linux-2.6.29.6/
-</screen>
-
-<para>
-The most difficult part of any kernel compile is the kernel
-configuration. There are hundreds of options, many of which can
-optionally be compiled into modules. This means there are thousands of
-ways to configure a kernel. Fortunately, there are a few handy tricks
-that can keep you from running into too much trouble.  The kernel
-configuration file is <filename>.config</filename>. If you are very
-brave, you can manually edit this file with a text editor, but I highly
-recommend you use the kernel's built-in tools for manipulating
-<filename>.config</filename>.
-</para>
-
-<para>
-Unless you are very familiar with configuring kernels, you should
-always start with a solid base configuration and modify it. This
-prevents you from skipping an important option that might force you to
-compile the kernel again and again until you get it right.  The best
-kernel <filename>.config</filename> files to start with are those used
-by Slackware's default kernels. You can find them on your Slackware
-install disks or at your favorite mirror in the
-<filename>kernels/</filename> directory.
-</para>
-
-<screen><prompt>darkstar:~# </prompt><userinput>mount /mnt/cdrom</userinput>
-<prompt>darkstar:~# </prompt><userinput>cd /mnt/cdrom/kernels</userinput>
-<prompt>darkstar:/mnt/cdrom/kernels# </prompt><userinput>ls</userinput>
-VERSIONS.TXT  huge.s/  generic.s/ speakup.s/
-<prompt>darkstar:/mnt/cdrom/kernels# </prompt><userinput>ls genric.s</userinput>
-System.map.gz  bzImage  config
-</screen>
-
-<para>
-You can replace the default <filename>.config</filename> file easily by
-copying or downloading the <filename>config</filename> file for the
-kernel you wish to use as a base. Here I am using Slackware's
-recommended generic.s kernel for a base, but you may wish to use the
-huge.s config file. The generic kernel builds more things as modules
-and thus creates a smaller kernel image, but it usually requires the
-use of an initrd.
-</para>
-
-<screen><prompt>darkstar:/mnt/cdrom/kernels# </prompt><userinput>cp generic.s/config /usr/src/linux/.config</userinput>
-</screen>
-
-<note><para>
-The Slackware kernel file lacks the "dot" while the kernel
-file includes it. If you forget, or simply copy the
-<filename>config</filename> to <filename>/usr/src</filename> whatever
-<filename>.config</filename> file was already present will be used
-instead.
-</para></note>
-
-<para>
-If you want to use the configuration for the currently running kernel
-as your base, you may be able to locate it at
-<filename>/proc/config.gz</filename>. This is a special kernel-related
-file that includes the entire kernel configuration in a compressed
-format and requires that your kernel was built to support it.
-</para>
-
-<screen><prompt>darkstar:~# </prompt><userinput>zcat /proc/config.gz > /usr/src/linux/.config</userinput>
-</screen>
-
-<para>
-Now that we've created a solid base configuration, it's time to make
-any configuration changes we want. The entire kernel build process from
-configuration to compilation is performed with the
-<application>make</application>(1) command and special arguments to it.
-Each argument performs a different function.
-</para>
-
-<para>
-If you are upgrading to a newer kernel release, you will definitely
-want to use the <arg>oldconfig</arg> argument. This will step through
-your base <filename>.config</filename> and look for missing elements
-that usually indicates that the new kernel release contains additional
-options. Since options are added at virtually every kernel release,
-this is generally a good thing to do.
-</para>
-
-<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>make oldconfig</userinput>
-scripts/kconfig/conf -o arch/x86/Kconfig
-*
-* Restart config...
-*
-*
-* File systems
-*
-Second extended fs support (EXT2_FS) [M/n/y/?] m
-  Ext2 extended attributes (EXT2_FS_XATTR) [N/y/?] n
-  Ext2 execute in place support (EXT2_FS_XIP) [N/y/?] n
-Ext3 journalling file system support (EXT3_FS) [M/n/y/?] m
-  Ext3 extended attributes (EXT3_FS_XATTR) [Y/n/?] y
-    Ext3 POSIX Access Control Lists (EXT3_FS_POSIX_ACL) [Y/n/?] y
-    Ext3 Security Labels (EXT3_FS_SECURITY) [Y/n/?] y
-The Extended 4 (ext4) filesystem (EXT4_FS) [N/m/y/?] (NEW) <userinput>m</userinput>
-</screen>
-
-<para>
-Here you can see that I the new kernel I am compiling has added support
-for a new filesystem: ext4. <arg>oldconfig</arg> has gone through my
-original configuration, kept all the old options exactly as they were
-set, and prompted me on what to do with new options. Typically it is
-save to choose the default option, but you may wish change this.
-<arg>oldconfig</arg> is a very handy tool for presenting you with only
-new configuration options, making it ideal for users who simply have to
-try out the latest kernel release.
-</para>
-
-<para>
-For more serious configuration tasks, there are a multitude of options.
-The linux kernel can be configured in three primary ways. The first is
-<arg>config</arg>, which will step through each and every option one by
-one and ask what you would like to do. This is so tedious that hardly
-anyone ever uses it anymore.
-</para>
-
-<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>make config</userinput>
-scripts/kconfig/conf arch/x86/Kconfig
-*
-* Linux Kernel Configuration
-*
-*
-* General setup
-*
-Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] <userinput>Y</userinput>
-Local version - append to kernel release (LOCALVERSION) [] <userinput>-test</userinput>
-Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] <userinput>n</userinput>
-Support for paging of anonymous memory (swap) (SWAP) [Y/n/?]
-</screen>
-
-<para>
-Fortunately, there are two much easier ways to configure your kernel,
-<arg>menuconfig</arg> and <arg>xconfig</arg>. Both of these create a
-menu-driven program that lets you select and de-select options without
-having to step through each one. <arg>menuconfig</arg> is the most
-commonly used method, and the one I recommend. <arg>xconfig</arg> is
-only useful if you are attempting to compile the kernel from a
-graphical user interface within <application>X</application>. Both are
-so similar however, that we are only going to document
-<arg>menuconfig</arg>.
-</para>
-
-<para>
-Running <userinput>make menuconfig</userinput> from a terminal will
-present you with the friendly curses-driven interface you see below.
-Each kernel section is given its own submenu, and you can navigate with
-the arrow keys.
-</para>
-
-<imagedata fileref="img/make-menuconfig-w.png" format="PNG"/>
-
-<warning><para>
-If you are compiling a kernel that is the same release as the stock
-Slackware kernel, you must set the "Local version" option. This is
-found on the "General setup" submenu. Failure to set this will result
-in your kernel compile over-writing all the modules used by the stock
-kernels. This can quickly render your system unbootable.
-</para></warning>
-
-<para>
-Once you've finished configuring the kernel, it's time to begin
-compiling it. There are many different methods for this, but the most
-reliable is to use <arg>bzImage</arg>. When you pass this argument to
-<application>make</application>, the kernel compilation will begin and
-you will see lots of data scroll through the terminal until either the
-compile process is complete or a fatal error is encountered.
-</para>
-
-<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>make bzImage</userinput>
-scripts/kconfig/conf -s arch/x86/Kconfig
-  CHK     include/linux/version.h
-  CHK     include/linux/utsrelease.h
-  SYMLINK include/asm -> include/asm-x86
-  CALL    scripts/checksyscalls.sh
-  CC      scripts/mod/empty.o
-  HOSTCC  scripts/mod/mk_elfconfig
-  MKELF   scripts/mod/elfconfig.h
-  HOSTCC  scripts/mod/file2alias.o
-... many hundreds of lines ommitted ...
-</screen>
-
-<para>
-If the process ends in an error, you should check your kernel
-configuration first. Compile errors are usually caused by a fault
-<filename>.config</filename> file. Assuming everything went alright,
-we're still not entirely finished, as we need to build the modules.
-</para>
-
-<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>make modules</userinput>
-  CHK     include/linux/version.h
-  CHK     include/linux/utsrelease.h
-  SYMLINK include/asm -> include/asm-x86
-  CALL    scripts/checksyscalls.sh
-  HOSTCC  scripts/mod/file2alias.o
-... many thousands of lines omitted ...
-</screen>
-
-<para>
-If both the kernel and the modules compiles finished sucessfully, we're
-ready to install them. The kernel image needs to be copied into a safe
-location, typically the <filename>/boot</filename> directory, and you
-should give it a unique name to avoid overwriting any other kernel
-images located there. Traditionaly kernel images are named
-<filename>vmlinuz</filename> with the kernel release and local version
-appended.
-</para>
-
-<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>cat arch/x86/boot/bzImage > /boot/vmlinuz-release_number-local_version</userinput>
-<prompt>darkstar:/usr/src/linux# </prompt><userinput>make modules_install</userinput>
-</screen>
-
-<para>
-Once these steps have been completed, you will have a new kernel image
-located under <filename>/boot</filename> and a new kernel modules
-directory under <filename>/lib/modules</filename>. In order to use
-this new kernel, you will need to edit <filename>lilo.conf</filename>,
-create an initrd for it (only if you need to load one or more of this
-kernel's modules to boot), and run <application>lilo</application> to
-update the boot loader. When you reboot, if all went according to plan,
-you should have an option to boot with your newly compiled kernel. If
-something went wrong, you may be spending some time fixing the problem.
+<title>Upgrading Slackware Versions</title>
+
+<para>
+Now that we've gone this far, you should feel reasonably competent in your 
+ability to manage your Slackware system.  But what do we do with it when 
+there's a new release?  Updating from one release of Slackware to another 
+is a lot more complicated than simply updating a few packages.  Each release 
+changes a lot of things, and while many of these changes are small, some of
+them can completely break your system if you haven't prepared for them and/or
+don't understand what is changing and why.  While some Linux distributions 
+provide highly automated tools that attempt to handle every tiny detail for 
+you, Slackware takes a much more hands-on approach to things.
+</para>
+
+<para>
+The very first thing you should do before attempting an upgrade is the one
+that many people neglect: decide if it's really necessary to upgrade.  If 
+the old system is stable and doing everything you want it to do, there may 
+be no need to do an operating system upgrade at all.  Assuming you decide
+to do the upgrade, then the second thing you should do is read the 
+<filename>CHANGES_AND_HINTS.TXT</filename> file on your upgrade discs or 
+a mirror.  This file is updated during the development period before every
+release, and it lists lots of helpful hints and tips to aid you in dealing 
+with the changes.  Finally, read the <filename>UPGRADE.TXT</filename> file 
+before proceeding.  After doing these things, you may decide that it's less
+trouble and potential for problems to backup your configuration files and 
+data and do a fresh installation of the new Slackware release rather than 
+attempt a possibly tricky upgrade.  However, if you still wish to continue, 
+make backups of your data and configuration files first.  At a minimum, 
+it's good practice to backup the <filename>/etc</filename> and <filename>/home</filename>
+directories.  This will give you a chance to perform a reinstall if something 
+goes wrong with the upgrade.
+</para>
+
+<para>
+Since every new version of Slackware has a few differences, giving complete 
+instructions here is not only futile but potentially misleading.  You should
+always consult the documentation included on your Slackware disks or your
+favorite mirror.
 </para>
 
 </section>