LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

revised old docuemnt that had been archived; converted to docbook and submitted by original author

This commit is contained in:
gferg 2002-03-10 16:41:03 +00:00
parent 44bbd74a19
commit 17019908e5
1 changed files with 326 additions and 196 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

522
LDP/howto/linuxdoc/archived/Upgrade.sgml → LDP/howto/docbook/Upgrade.sgml
View File

@ -1,28 +1,39 @@
<!doctype linuxdoc system> <!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<!-- This is the second revision of the original upgrade.how document. <!-- This is the third revision of the original upgrade.how document.
--> -->
<article> <article>
<articleinfo>
<title>Upgrading your Linux Distribution mini-HOWTO <title>Upgrading Your linux Distribution mini-HOWTO</title>
<author>Greg Louis, <tt/glouis@dynamicro.on.ca/ <authorgroup>
<date>v1.11, 6 June 1996 <author>
<firstname>Greg</firstname>
<surname>Louis</surname>
<affiliation>
<address>
<email>glouis@dynamicro.on.ca</email>
</address
</affiliation>
</author>
</authorgroup>
<pubdate>v1.2, 9 March 2002</pubdate>
<copyright>
<year>1996, 2002</year>
<holder>Dynamicro Consulting Limited</holder>
</copyright>
<abstract> <abstract>
Hints and tips on upgrading from one linux distribution to <para>
another. Hints and tips on upgrading from one linux distribution to
<p> another. This is version 1.2, 2002-03-09.
<bf>Archived Document Notice:</bf> This document has been archived by the LDP </para>
because it does not apply to modern Linux systems. It is no longer
being actively maintained.
</p>
</abstract> </abstract>
</articleinfo>
<toc> <sect1>
<title>IMPORTANT!!! Disclaimer and Copyright</title>
<sect>IMPORTANT!!! Disclaimer and Copyright <para>
<p>
The procedure to which this document attempts to be a guide is The procedure to which this document attempts to be a guide is
inherently dangerous to the programs and data stored in your computer. inherently dangerous to the programs and data stored in your computer.
You carry out any such procedure entirely at your own risk. The steps You carry out any such procedure entirely at your own risk. The steps
@ -33,60 +44,100 @@ data. You are entirely on your own in any use you may make of the
information presented herein, and the author shall not be liable in information presented herein, and the author shall not be liable in
any way whatsoever for any damage or inconvenience of any kind that any way whatsoever for any damage or inconvenience of any kind that
you may suffer in so doing. you may suffer in so doing.
</para>
This document is copyright 1996, Dynamicro Consulting Limited, and is <para>
released under the terms of the GNU General Public License. This This document is copyright © 1996, 2000 Dynamicro Consulting Limited,
and is released under the terms of the GNU General Public
License. This
basically means that you may copy and modify it at will, but may not basically means that you may copy and modify it at will, but may not
prevent others from doing likewise. prevent others from doing likewise.
</para>
<para>
Comments and questions may be directed to the author. Especially Comments and questions may be directed to the author. Especially
welcome, for use in future revisions, are accounts of successful welcome, for use in future revisions, are accounts of successful
upgrades of complex systems. upgrades of complex systems.
</para>
<sect>Changes since version 1.1 </sect1>
<sect1>
<p> <title>Changes since version 1.1</title>
<itemize> <para>
<item>Added this history section <itemizedlist>
<item>Added Zoltán Hidvégi's suggestion re mtime and ctime. <listitem>
Thanks, Zoltán! <para>
<item>Added an Acknowledgements section Converted to docbook
</itemize> </para>
</listitem>
<sect>Introduction <listitem>
<para>
<p> Corrected some obsolete information
<sect1>How to slay and reincarnate your linux box! </para
</listitem>
<p> <listitem>
<para>
Added this history section
</para>
</listitem>
<listitem>
<para>
Added Zoltán Hidvégi's suggestion re mtime and ctime.
Thanks, Zoltán!
</para>
</listitem>
<listitem>
<para>
Added an Acknowledgements section
</para>
</listitem>
</itemizedlist>
</para>
</sect1>
<sect1>
<title>Introduction</title>
<sect2>
<title>How to slay and reincarnate your linux box!</title>
<para>
The purpose of this document is to offer tips to help you through the The purpose of this document is to offer tips to help you through the
destruction and reinstallation of a linux system. It's not a destruction and reinstallation of a linux system. It's not a
foolproof cookbook by any means; but I hope it will serve as some foolproof cookbook by any means, but I hope it will serve as some
indication of what you need to think about, and of the order in which indication of what you need to think about, and of the order in which
to do things. It would have been a help to me, if someone else had to do things. It would have been a help to me, if someone else had
written something like this before I did my first upgrade; so I hope written something like this before I did my first upgrade; so I hope
it will be a help to you, if you have a linux machine to rebuild. it will be a help to you, if you have a linux machine to rebuild.
</para>
<para>
Don't take it as gospel, though: your mileage will almost certainly Don't take it as gospel, though: your mileage will almost certainly
vary. Even the directory names in this document may be different from vary. Even the directory names in this document may be different from
the ones you need to use; some people have /usr/home instead of /home, the ones you need to use; some people have /usr/home instead of /home,
for example; others call it /u, and some (delicate shudder :) even put for example; others call it /u, and some (delicate shudder :) even put
all their users directly under /usr itself! I can't be specific about all their users directly under /usr itself! I can't be specific about
your system, so I've just used the names the way they are in mine. your system, so I've just used the names the way they are in mine.
</para>
<para>
You'll also notice that I use Slackware distributions, and that I You'll also notice that I use Slackware distributions, and that I
assume you've enough RAM and hard disk space to install linux kernel assume you've enough RAM and hard disk space to install linux kernel
source and build your own kernel. If your system is different, some source and build your own kernel. If your system is different, some
of my recommendations won't apply; but I hope you'll still find the of my recommendations won't apply; but I hope you'll still find the
general outline to be of assistance in your rebuild project. general outline to be of assistance in your rebuild project.
</para>
<sect1>Why would anyone want to do that? </sect2>
<sect2>
<p> <title>Why would anyone want to do that?</title>
<para>
Good question! If it can possibly be avoided, don't do it! (That's Good question! If it can possibly be avoided, don't do it! (That's
the single most important recommendation in this whole guide!!!) But the single most important recommendation in this whole guide!!!) When
there are times when you may have to. this guide was first written, not many people had hard disks big enough
to accomodate two whole Linux installations; these days, that's by no
means uncommon. If you possibly can, build your new system in a
separate partition (or group of partitions), keeping the old one intact
till you're satisfied that the new one is just the way you want it. If
you can avoid destroying the old system to make room for the new, by
all means avoid it! But there are times when you may have no choice.
</para>
<para>
(These examples are a bit dated, but they serve to illustrate my
point:)
</para>
<para>
For example, I installed a 4Gb hard disk and then found out that For example, I installed a 4Gb hard disk and then found out that
Slackware 2.0 vintage linux didn't know a hard disk could have more Slackware 2.0 vintage linux didn't know a hard disk could have more
than 2Gb, and it got horribly confused. So I had to upgrade to the than 2Gb, and it got horribly confused. So I had to upgrade to the
@ -94,7 +145,8 @@ then-current Slackware 2.3. That upgrade was a gruelling experience,
and it's part of the reason I'm writing these notes. I did just about and it's part of the reason I'm writing these notes. I did just about
everything wrong, and only good luck and the fact that I had another everything wrong, and only good luck and the fact that I had another
running linux box beside me saved me from disaster. running linux box beside me saved me from disaster.
</para>
<para>
As another example, I found that I just couldn't succeed in building a As another example, I found that I just couldn't succeed in building a
working a.out linux kernel in the 1.3 series, using an out-of-the-box working a.out linux kernel in the 1.3 series, using an out-of-the-box
Slackware 2.3 installation (another machine, not the one I botched Slackware 2.3 installation (another machine, not the one I botched
@ -102,12 +154,20 @@ before). I took the plunge, bought Slackware 3.0 on CDROM and
converted to ELF. This time the reinstallation went better, thanks in converted to ELF. This time the reinstallation went better, thanks in
part to the previous bitter experience, and it served as the source of part to the previous bitter experience, and it served as the source of
most of the ideas I'm offering you here. most of the ideas I'm offering you here.
</para>
<sect1>Do you have to ``destroy and reinstall?'' </sect2>
<sect2>
<p> <title>Do you have to ``destroy and reinstall?''</title>
It's safer, oddly enough. If you install over top of an existing <para>
linux system, chances are you'll have a mixture of old and new See above. If you can build your new system in otherwise empty disk
space, do it! For the rest of this document, however, I'll assume that
this is one of those times when that option isn't available; you either
have to reinstall "in place," over top of the existing system, or you
have to bite the bullet and rebuild from scratch.
</para>
<para>
The latter is safer, oddly enough. If you install over top of an
existing linux system, chances are you'll have a mixture of old and new
binaries, old and new configuration files, and generally a mess to try binaries, old and new configuration files, and generally a mess to try
to administer. Wiping the system clean, and then putting back only to administer. Wiping the system clean, and then putting back only
what you know you need, is a drastic but effective way to get a clean what you know you need, is a drastic but effective way to get a clean
@ -118,18 +178,11 @@ the individual bits -- especially gcc and its libraries, and binutils
-- current. If the stuff you use is reasonably up-to-date, and you -- current. If the stuff you use is reasonably up-to-date, and you
can keep it so by bringing in, and if need be compiling, new code from can keep it so by bringing in, and if need be compiling, new code from
time to time, then there's no need for a mass upgrade.) time to time, then there's no need for a mass upgrade.)
</para>
As Patrick Volkerding points out (he too recommends the wipe-it-clean </sect2>
procedure for upgrades), installing ELF on top of a running a.out <sect2>
system is a recipe for disaster; at least, if you know enough to try <title>How long will it take?</title>
it, you needn't read this guide! <para>
Even without that complication, though, you're better to build from
scratch.
<sect1>How long will it take?
<p>
Depends, of course, on how complex your system is. But I figure that, Depends, of course, on how complex your system is. But I figure that,
for the successful upgrade (the other one? -- don't ask! :) I spent for the successful upgrade (the other one? -- don't ask! :) I spent
about ten hours making backups, six hours rebuilding the system to the about ten hours making backups, six hours rebuilding the system to the
@ -141,29 +194,41 @@ suffice for a reasonably complex rebuilding job. Maybe less if you're
reinstalling from hard disk (I used CDROM) or more if you need to reinstalling from hard disk (I used CDROM) or more if you need to
install from floppies. Maybe less if you've got a fast Pentium, more install from floppies. Maybe less if you've got a fast Pentium, more
if it's a 386. You get the idea. if it's a 386. You get the idea.
</para>
<para>
Those were the bad old days. Now, with faster disks and faster
machines and CD writers, things go better. My notebook was stolen in
December, 2002, and when the new one came, I was up and pretty near
complete -- despite having lost the old system without the chance to
save the latest changes -- after about seven hours of effort.
</para>
<para>
So much for the introduction. Here's how to set about it, once you've So much for the introduction. Here's how to set about it, once you've
decided it must be done. Arm yourself with fortitude and Jolt or decided it must be done. Arm yourself with fortitude and Jolt or
whatever, and: whatever, and:
</para>
<sect>Write down everything you do. </sect2>
</sect1>
<p> <sect1>
<title>Write down everything you do.</title>
<para>
It's extremely valuable to have a record of what you've done in the It's extremely valuable to have a record of what you've done in the
process of preparing for, and carrying out, the changeover. process of preparing for, and carrying out, the changeover.
Especially important is a list of the backups you'll be making in Especially important is a list of the backups you'll be making in
preparation for the destruction of your existing system. preparation for the destruction of your existing system.
</para>
<sect>Make a full backup of the existing system. </sect1>
<sect1>
<p> <title>Make a full backup of the existing system.</title>
Generally speaking, backups tend to be written on media that are <para>
Generally speaking, big backups tend to be written on media that are
sequentially accessed. That being so, you won't want to use this sequentially accessed. That being so, you won't want to use this
complete backup for restoring significant numbers of files; it's got complete backup for restoring significant numbers of files; it's got
too many files on it that you don't want. It's better to create small too many files on it that you don't want. It's better to create small
backups of individual segments that you know you're going to restore backups of individual segments that you know you're going to restore
in their entirety. I'll list a bunch of examples later. in their entirety. I'll list a bunch of examples later.
</para>
<para>
Why then should you start with a full backup? Two basic reasons: Why then should you start with a full backup? Two basic reasons:
first, in the event of a catastrophic failure installing the new first, in the event of a catastrophic failure installing the new
system, you'll have a way to get back to the starting point with system, you'll have a way to get back to the starting point with
@ -172,15 +237,18 @@ installation, there is a very large chance that one or two important
files will be overlooked. In that case the clumsiness of restoring files will be overlooked. In that case the clumsiness of restoring
those one or two files from the full backup set will be preferable to those one or two files from the full backup set will be preferable to
the inconvenience of doing without them. the inconvenience of doing without them.
</para>
<para>
To save time and space, if you've still got the distribution medium To save time and space, if you've still got the distribution medium
for your old linux version, you might want to back up only those files for your old linux version, you might want to back up only those files
the mtime or ctime of which is more recent than the date of the the mtime or ctime of which is more recent than the date of the
original installation. original installation.
</para>
<sect>Back up /etc and its subdirectories on one or more floppies. </sect1>
<sect1>
<p> <title>Back up /etc and its subdirectories on one or more floppies.
</title>
<para>
This is the other extreme: you won't be restoring these files (for the This is the other extreme: you won't be restoring these files (for the
most part, anyway); you'll be comparing them with the new ones that most part, anyway); you'll be comparing them with the new ones that
get created during installation. Why? Because the new ones may have get created during installation. Why? Because the new ones may have
@ -191,141 +259,181 @@ formats of the configuration files and startup scripts that the /etc
tree contains, and you'll very likely have to edit your old data into tree contains, and you'll very likely have to edit your old data into
these files so as to preserve the new formats and take advantage of these files so as to preserve the new formats and take advantage of
the improvements. the improvements.
</para>
<sect>Make separate backups of each group of files you want to preserve. </sect1>
<sect1>
<p> <title>Make separate backups of each group of files you want to preserve.
</title>
<para>
This is the most variable part of the job, and all I can really do to This is the most variable part of the job, and all I can really do to
help is to describe what I did in my system, in the hope that it will help is to describe what I did in my system, in the hope that it will
serve as a rough guide. Basically, you want to look at every serve as a rough guide. Basically, you want to look at every
directory that contains any directory that contains any
</para>
<itemize> <para>
<item> files that aren't part of your standard linux installation, or <itemizedlist>
<item> files that are actually newer than the ones you'll <listitem>
install when you do your new linux installation <para>
</itemize> files that aren't part of your standard linux installation, or
</para>
</listitem>
<listitem>
<para>
files that are actually newer than the ones you'll install when you do
your new linux installation.
</para>
</listitem>
</itemizedlist>
</para>
<para>
and separate out only those files that you want to carry over. and separate out only those files that you want to carry over.
</para>
<para>
(Another possible strategy is to back up all files with mtime or (Another possible strategy is to back up all files with mtime or
ctime more recent than the day of the previous linux installation, ctime more recent than the day of the previous linux installation,
as mentioned above, and then restore from that. If you do that, as mentioned above, and then restore from that. If you do that,
you have to take into account that the new linux distribution may you have to take into account that the new linux distribution may
contain versions of some files that are newer still than the ones contain versions of some files that are newer still than the ones
you saved.) you saved.)
</para>
<para>
In my case, I ended up making a .tgz file on the backup medium for In my case, I ended up making a .tgz file on the backup medium for
each of each of
</para>
<itemize> <para>
<item> /usr/lib/rn <itemizedlist>
<item> /usr/lib/smail <listitem><para>/usr/lib/rn</para></listitem>
<item> /usr/lib/trn (the rest of /usr/lib would be reinstalled) <listitem><para>/usr/lib/smail</para></listitem>
<item> /usr/local/src <listitem><para>/usr/lib/trn (the rest of /usr/lib would be
<item> /usr/local/bin reinstalled)</para></listitem
<item> /usr/local/lib <listitem><para>/usr/local/src</para></listitem>
<item> /usr/local/lpfont <listitem><para>/usr/local/bin</para></listitem>
<item> /usr/local/man <listitem><para>/usr/local/lib</para></listitem>
<item> /usr/local/sbin <listitem><para>/usr/local/lpfont</para></listitem>
<item> /usr/local/thot (there were other /usr/local files I didn't need) <listitem><para>/usr/local/man</para></listitem>
<item> /usr/openwin <listitem><para>/usr/local/sbin</para></listitem>
<item> /usr/src/lilo-17 (because my new Slackware still had version 16) <listitem><para>/usr/local/thot (there were other /usr/local files
<item> /usr/src/linux-1.2.13 (because I'd done some customizing) I didn't need)</para></listitem>
<item> /usr/X11R6/lib/X11/app-defaults <listitem><para>/usr/openwin</para></listitem>
<item> /usr/X11R6/lib/X11/initrc (the rest of Xfree86 was to be reinstalled) <listitem><para>/usr/src/lilo-17 (because my new Slackware still
<item> /var/named had version 16)</para></listitem>
<item> /var/openwin <listitem><para>/usr/src/linux-1.2.13 (because I'd done some
<item> /var/texfonts customizing)</para></listitem>
</itemize> <listitem><para>/usr/X11R6/lib/X11/app-defaults</para></listitem>
<listitem><para>/usr/X11R6/lib/X11/initrc (the rest of Xfree86 was
to be reinstalled)</para></listitem>
<listitem><para>/var/named</para></listitem>
<listitem><para>/var/openwin</para></listitem>
<listitem><para>/var/texfonts</para></listitem>
</itemizedlist>
</para>
<para>
My machine was relatively easy in that there were no spool files to My machine was relatively easy in that there were no spool files to
worry about. I don't run a news spool on this box, and since there worry about. I don't run a news spool on this box, and since there
are only two users, it was easiest just to get all the mail read are only two users, it was easiest just to get all the mail read
before shutting down. Otherwise, /var/spool directories would have before shutting down. Otherwise, /var/spool directories would have
had to be backed up at the last minute. (And, of course, the news had to be backed up at the last minute. (And, of course, the news
library and site directories!) library and site directories!)
</para>
<sect>Prepare root and boot floppies for the new installation. </sect1>
<sect1>
<p> <title>Prepare root and boot floppies for the new
Details of how to do this will be found in the installation guide for installation.</title>
your new distribution. <para>
If you're lucky, your new package will include a bootable CD and this
<sect>Format floppies for the temporary kernel and the final build. step won't be needed. If you haven't got a CDROM drive, or can't boot
from it, details of how to make the floppies will be found in the
<p> installation guide for your new distribution.
</para>
</sect1>
<sect1>
<title>Format floppies for the temporary kernel and the final
build.</title>
<para>
You'll need two, one floppy for each. You'll need two, one floppy for each.
</para>
<para>
After all that's done, you're ready for the Big Moment. The next After all that's done, you're ready for the Big Moment. The next
step removes the system from production. step removes the system from production.
</para>
<sect>Inhibit logins and back up the /root and /home trees. </sect1>
<sect1>
<p> <title>Inhibit logins and back up the /root and /home trees.</title>
<para>
This is the last thing to be done on the old system before you destroy This is the last thing to be done on the old system before you destroy
it, so as to carry forward the most current user and root information. it, so as to carry forward the most current user and root information.
To inhibit logins, just echo "getting ready for upgrade" >/etc/nologin
<sect>Boot from the new installation's boot and root floppies. (as root, of course).
</para>
<p> </sect1>
<sect>Delete the linux partitions with fdisk and recreate them. <sect1>
<title>Boot from the new installation's boot and root
<p> floppies.</title>
<para>
Or, if you have that capability, boot the installation CD itself.
</para>
</sect1>
<sect1>
<title>Delete the linux partitions with fdisk and recreate
them.</title>
<para>
The installation guide will explain how to set about doing this, which The installation guide will explain how to set about doing this, which
will destroy the old system. From now on you're dependent on the will destroy the old system. From now on you're dependent on the
quality of the backups you made in the earlier steps! You have been quality of the backups you made in the earlier steps! You have been
warned! warned!
</para>
<sect>Run the new linux installation. </sect1>
<sect1>
<p> <title>Run the new linux installation.</title>
<para>
There are already several good documents describing how to do this, so There are already several good documents describing how to do this, so
I'm not going into any detail. Continue from here when the new system I'm not going into any detail. Continue from here when the new system
can boot from its hard disk. can boot from its hard disk.
</para>
<para>
Along the way, be sure to make a floppy that you can boot as well, Along the way, be sure to make a floppy that you can boot as well,
since the kernel that the linux setup installs has to be replaced and since the kernel that the linux setup installs has to be replaced and
accidents can happen during that process. Be sure to install the accidents can happen during that process. Be sure to install the
development packages and the kernel source. development packages and the kernel source.
</para>
<sect>With the new linux system booted from the hard disk, edit /etc/fstab </sect1>
<sect1>
<p> <title>Restore configuration data to the /etc directory and
and add your swap partition. Then run the command "swapon -a". subdirectories.</title>
I don't know why, but Slackware setup doesn't offer to do this for you <para>
if your swap partition exists already. Then, when you boot your new
system and the rc.S script tries to turn swapping on, it can't find
the partition in the fstab file and swapping doesn't get enabled.
This step fixes it.
<sect>Restore configuration data to the /etc directory and subdirectories.
<p>
As described above, you can't just copy all of the old files back into As described above, you can't just copy all of the old files back into
/etc and expect things to work properly afterward. Some files you can /etc and expect things to work properly afterward. Some files you can
do that with; for example, /etc/XF86Config (as long as you're using do that with; for example, /etc/XF86Config (as long as you're using
the same version of Xfree86 -- and the same video hardware -- in the the same version of XFree86 -- and the same video hardware -- in the
new installation as you did in the old). For the most part, though, new installation as you did in the old). For the most part, though,
it's best to use diff to compare the old and new files before doing it's best to use diff to compare the old and new files before doing
any copying. Watch out especially for significant changes in the any copying. Watch out especially for significant changes in the
files in /etc/rc.d, which may require you to reestablish your old files in /etc/rc.d and friends, which may require you to reestablish
configuration by hand editing, instead of by copying the old rc your old configuration by hand editing, instead of by copying the old
scripts from your backup. Once it's all done, reboot. rc scripts from your backup. Once it's all done, reboot.
</para>
<sect>Configure and rebuild the linux kernel. </sect1>
<sect1>
<p> <title>Configure and rebuild the linux kernel.</title>
<para>
Even if you don't absolutely have to do this in order to get a kernel Even if you don't absolutely have to do this in order to get a kernel
that supports your hardware, it's worth doing it in order to get a that supports your hardware, it's worth doing it in order to get a
kernel that doesn't contain masses of drivers for stuff your machine kernel that doesn't contain masses of drivers for stuff your machine
doesn't have. For details, see the Kernel HOWTO. Install the rebuilt doesn't have -- and even more so, in order to get a good understanding
kernel on a floppy at first; once that boots ok, install on the hard of how your kernel configuration options affect the behaviour of your
disk, run lilo if you're using it, and reboot. system! As linux grows, the ability of the distribution vendors to
configure a one-size-fits-all kernel has become very limited. For
<sect>Restore the stuff from the backups you made earlier. details on how it's done, see the Kernel HOWTO; it looks complicated at
first, but it's not rocket science; just take it a step at a time.
<p> </para>
<para>
Install the rebuilt kernel on a floppy at first; once that boots ok,
install on the hard disk, run lilo if you're using it, and reboot.
</para>
</sect1>
<sect1>
<title>Restore the stuff from the backups you made earlier.</title>
<para>
Some of the binaries may need to be reinstalled from the source Some of the binaries may need to be reinstalled from the source
directories; I had to do that with lilo, for example, since my version directories; I had to do that with lilo, for example, since my version
was newer than the one on the Slackware installation and I hadn't was newer than the one on the Slackware installation and I hadn't
@ -334,35 +442,57 @@ your restored programs and confirm the existence and correctness of
configuration files, libraries and so on. In some cases, you may have configuration files, libraries and so on. In some cases, you may have
to restore things in a specific order; you did make notes during to restore things in a specific order; you did make notes during
backup, didn't you? ;-) backup, didn't you? ;-)
</para>
<sect>Review security. </sect1>
<sect1>
<p> <title>Review security.</title>
<para>
(Sigh...) When I wrote this, this step was important but not crucial;
the Internet was a friendlier place even in 1996 than it is today.
Now, if your machine has Internet access, this step is utterly vital,
and there are whole books devoted to getting it right; I can do nothing
more here than offer a few very basic pointers:
</para>
<para>
Check file permissions and directory permissions to be sure that Check file permissions and directory permissions to be sure that
access is neither too restricted nor too easy. I find that Slackware access is neither too restricted nor too easy. I find that Slackware
tends to lean toward a more open environment than I like, so I go tends to lean toward a more open environment than I like, so I go
around changing 755's to 711's for binaries in the .../bin directories around changing 755's to 711's for binaries in the .../bin directories
and stuff like that. Or even 700's in the .../sbin ones. Especial and stuff like that. Or even 700's in the .../sbin ones. Especial
care is needed if you've carried over an ftp server; but then, if you care is needed if you've carried over ftp, telnet or web servers; but
were running an ftp server, you probably thought of that already. :) then, if you were running those, you probably thought of that already. :)
</para>
<sect>Enable logins. <para>
Look at /etc/inetd.conf or /etc/xinetd.conf and make sure you're not
<p> running any Internet services you don't need to. Also go through the
boot scripts in /etc/rc.d and friends for the same purpose. Check your
firewall rules if your box is an Internet gateway or has Internet
access.
</para>
</sect1>
<sect1>
<title>Enable logins.</title>
<para>
You're up and running. Over the next little while, there'll probably You're up and running. Over the next little while, there'll probably
be details to clean up; but the bulk of the work is done. Enjoy! be details to clean up; but the bulk of the work is done. Enjoy!
</para>
<sect>Sorry, but once again: </sect1>
<sect1>
<p> <title>Sorry, but once again:
<bf>USE THIS INFORMATION AT YOUR OWN RISK!</bf> <emphasis>USE THIS INFORMATION AT YOUR OWN RISK!</emphasis>
</title>
<para>
(See the disclaimer at the start of this document.) (See the disclaimer at the start of this document.)
</para>
<sect>Acknowledgements </sect1>
<sect1>
<p> <title>Acknowledgements</title>
<para>
Thanks for contributing to the content of this mini-HOWTO are Thanks for contributing to the content of this mini-HOWTO are
gratefully tendered to Zoltán Hidvégi. gratefully tendered to Zoltán Hidvégi; and for motivating me to bring
it a bit closer to modern practice, to Steve Sanfratello, author of the
rpmupgrade-HOWTO.
</para>
</sect1>
</article> </article>