diff options
Diffstat (limited to 'chapter_18.xml')
-rw-r--r-- | chapter_18.xml | 456 |
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> |