mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
parent
e1e83610dc
commit
deb6912f53
|
@ -6,7 +6,7 @@
|
|||
|
||||
<title>Chroot-BIND HOWTO
|
||||
<author>Scott Wunsch, <tt>scott at wunsch.org</>
|
||||
<date>v1.1, 24 June 2000
|
||||
<date>v1.2, 16 September 2000
|
||||
<abstract>
|
||||
This document describes installing the BIND 8 nameserver to run in a chroot
|
||||
jail and as a non-root user, to provide added security and minimise the
|
||||
|
@ -73,7 +73,10 @@ url="http://www.losurs.org/docs/howto/Chroot-BIND.html">.
|
|||
|
||||
BIND is available from <url url="http://www.isc.org/" name="the Internet
|
||||
Software Consortium"> at <url url="http://www.isc.org/bind.html">. As of this
|
||||
writing, the current version of BIND is 8.2.2_P5.
|
||||
writing, the current version of BIND8 is 8.2.2_P5. BIND 9.0.0 has just been
|
||||
released, but I haven't even looked at it yet, so I don't know how much of this
|
||||
document will be applicable. Unless you like living on the bleeding edge, you
|
||||
may be better off staying with BIND8 for now.
|
||||
|
||||
<sect1>How?
|
||||
|
||||
|
@ -111,7 +114,10 @@ aware.
|
|||
<p>
|
||||
As mentioned in the introduction, it's not a good idea to run BIND as root. So,
|
||||
before we begin, let's create a separate user for BIND. Note that you should
|
||||
never use an existing user like <tt>nobody</> for this purpose.
|
||||
never use an existing generic user like <tt>nobody</> for this purpose.
|
||||
However, some distributions, such as SuSE and Linux Mandrake have started
|
||||
providing a specific user (generally called <tt>named</>); you can simply adapt
|
||||
this user for our purposes, if you like.
|
||||
|
||||
This requires adding a line something like the following to <tt>/etc/passwd</>:
|
||||
<tscreen><verb>
|
||||
|
@ -191,7 +197,7 @@ will be sufficient to put the necessary libraries in place:
|
|||
</verb></tscreen>
|
||||
As an alternative, you could simply build statically-linked versions of the BIND
|
||||
binaries to put in your chroot jail. You should also copy <tt>ldconfig</> into
|
||||
the jail, and run it to create an <tt>etc/ld.so.conf</> for the jail environment.
|
||||
the jail, and run it to create an <tt>etc/ld.so.cache</> for the jail environment.
|
||||
The following commands could take care of this:
|
||||
<tscreen><verb>
|
||||
# cp /sbin/ldconfig /chroot/named/bin/
|
||||
|
@ -226,7 +232,7 @@ in the real <tt>/etc/group</> above.
|
|||
|
||||
<p>
|
||||
Unlike a conventional jailbird, BIND can't just scribble its log entries on the
|
||||
walls :-). Normally, BIND logs through <tt/syslogd/, the system logging daemon.
|
||||
walls :-). Normally, BIND logs through <tt>syslogd</>, the system logging daemon.
|
||||
However, this type of logging is performed by sending the log entries to the
|
||||
special socket <tt>/dev/log</>. Since this is outside the jail, BIND can't use
|
||||
it any more. Fortuantely, there are a couple options to work around this.
|
||||
|
@ -235,11 +241,11 @@ it any more. Fortuantely, there are a couple options to work around this.
|
|||
|
||||
<p>
|
||||
The ideal solution to this dilemma requires a reasonably recent version of
|
||||
<tt/syslogd/ which supports the <tt/-a/ switch introduced by OpenBSD. Check the
|
||||
manpage for your <tt/syslogd(8)/ to see if you have such a version.
|
||||
<tt>syslogd</> which supports the <tt>-a</> switch introduced by OpenBSD. Check the
|
||||
manpage for your <tt>syslogd(8)</> to see if you have such a version.
|
||||
|
||||
If you do, all you have to do is add the switch ``<tt>-a
|
||||
/chroot/named/dev/log</>'' to the command line when you launch <tt/syslogd/. On
|
||||
/chroot/named/dev/log</>'' to the command line when you launch <tt>syslogd</>. On
|
||||
systems which use a full SysV-init (which includes most Linux distributions),
|
||||
this is typically done in the file <tt>/etc/rc.d/init.d/syslog</>. For example,
|
||||
on my Red Hat Linux system, I changed the line
|
||||
|
@ -250,23 +256,34 @@ to
|
|||
<tscreen><verb>
|
||||
daemon syslogd -m 0 -a /chroot/named/dev/log
|
||||
</verb></tscreen>
|
||||
The simply restart <tt/syslogd/, either by killing it and launching it again, or
|
||||
by using the SysV-init script to do it for you:
|
||||
Then simply restart <tt>syslogd</>, either by killing it and launching it again,
|
||||
or by using the SysV-init script to do it for you:
|
||||
<tscreen><verb>
|
||||
# /etc/rc.d/init.d/syslog stop
|
||||
# /etc/rc.d/init.d/syslog start
|
||||
</verb></tscreen>
|
||||
|
||||
I'm told that on SuSE systems, the best place to add this switch is in the
|
||||
<tt>/etc/rc.config</> file. Changing the line
|
||||
<tscreen><verb>
|
||||
SYSLOGD_PARAMS=""
|
||||
</verb></tscreen>
|
||||
to read
|
||||
<tscreen><verb>
|
||||
SYSLOGD_PARAMS="-a /chroot/named/dev/log"
|
||||
</verb></tscreen>
|
||||
should do the trick.
|
||||
|
||||
Once it's been restarted, you should see a ``file'' in <tt>/chroot/named/dev</>
|
||||
called <tt/log/, that looks something like this:
|
||||
called <tt>log</>, that looks something like this:
|
||||
|
||||
<verb>srw-rw-rw- 1 root root 0 Mar 13 20:58 log</verb>
|
||||
|
||||
<sect2>The Other Solutions
|
||||
|
||||
<p>
|
||||
If you have an older <tt/syslogd/, then you'll have to find another way to do
|
||||
your logging. There are a couple programs out there, such as <tt/holelogd/,
|
||||
If you have an older <tt>syslogd</>, then you'll have to find another way to do
|
||||
your logging. There are a couple programs out there, such as <tt>holelogd</>,
|
||||
which are designed to help by acting as a ``proxy'' and accepting log entries
|
||||
from the chrooted BIND and passing them out to the regular <tt>/dev/log</>
|
||||
socket.
|
||||
|
@ -454,16 +471,16 @@ exit 0
|
|||
<sect1>Configuration Changes
|
||||
|
||||
<p>
|
||||
You will also have to add or change a few options in your <tt/named.conf/ to
|
||||
You will also have to add or change a few options in your <tt>named.conf</> to
|
||||
keep the various directories straight. In particular, you should add (or
|
||||
change, if you already have them) the following directives in the <tt/options/
|
||||
change, if you already have them) the following directives in the <tt>options</>
|
||||
section:
|
||||
<tscreen><code>
|
||||
directory "/etc/namedb";
|
||||
pid-file "/var/run/named.pid";
|
||||
named-xfer "/bin/named-xfer";
|
||||
</code></tscreen>
|
||||
Since this file is being read by the <tt/named/ daemon, all the paths are of
|
||||
Since this file is being read by the <tt>named</> daemon, all the paths are of
|
||||
course relative to the chroot jail.
|
||||
|
||||
<sect>The End
|
||||
|
@ -483,13 +500,23 @@ If you take a look at your logs, you should find the initialisation messages
|
|||
that BIND spits out when it loads. (If not, there's a problem with your <ref
|
||||
id="logging" name="logging configuration"> that you need to fix.) Amongst those
|
||||
messages, BIND should tell you that it chrooted successfully, and that it is
|
||||
running as the user and group <tt/named/. If not, you have a problem.
|
||||
running as the user and group <tt>named</>. If not, you have a problem.
|
||||
|
||||
<sect1>That's It!
|
||||
|
||||
<p>
|
||||
You can go take a nap now ;-).
|
||||
|
||||
<sect>Appendix - Thanks<label id="thanks">
|
||||
|
||||
<p>
|
||||
I'd like to thank Lonny Selinger <tt><lonny at abyss.za.org></> for
|
||||
"testing" this HOWTO and making sure that I didn't miss any steps. I'd also
|
||||
like to thank Chirik <tt><chirik at CastleFur.COM></>, Dwayne Litzenberger
|
||||
<tt><dlitz at cheerful.com></>, Phil Bambridge <tt><phil.b at
|
||||
cableinet.co.uk></>, and others for pointing out errors, omissions, and other
|
||||
useful advice to make this HOWTO even better.
|
||||
|
||||
<sect>Appendix - Document Distribution Policy<label id="legal">
|
||||
|
||||
<p>
|
||||
|
@ -499,7 +526,7 @@ url="http://metalab.unc.edu/LDP/COPYRIGHT.html">.
|
|||
|
||||
This HOWTO is free documentation; you can redistribute it and/or modify it under
|
||||
the terms of the LDP licence. It is distributed in the hope that it will be
|
||||
useful, but <bf/without any warranty/; without even the impled warranty of
|
||||
useful, but <bf>without any warranty</>; without even the impled warranty of
|
||||
merchantability or fitness for a particular purpose. See the LDP licence for
|
||||
more details.
|
||||
|
||||
|
|
|
@ -6,13 +6,12 @@
|
|||
|
||||
<TITLE>From Power Up To Bash Prompt
|
||||
<AUTHOR>Greg O'Keefe, <tt>gcokeefe@postoffice.utas.edu.au</tt>
|
||||
<DATE>v0.7, April 2000
|
||||
<DATE>v0.8, September 2000
|
||||
|
||||
<ABSTRACT>
|
||||
This is a brief description of what happens in a Linux system, from the time
|
||||
that you turn on the power, to the time that you log in and get a bash prompt.
|
||||
It is organised by package to make it easier for people who want to build a
|
||||
system from source code. Understanding this will be helpful when you need to
|
||||
Understanding this will be helpful when you need to
|
||||
solve problems or configure your system.
|
||||
</ABSTRACT>
|
||||
|
||||
|
@ -45,7 +44,6 @@ I have included exercises in each section. If you actually do some of these,
|
|||
you will learn much more than you could by just reading.
|
||||
|
||||
<P>
|
||||
There are also links to source code downloads. The reason for this is that
|
||||
I hope some readers will undertake the best Linux learning exercise that I
|
||||
know of, which is building a system from source code.
|
||||
Giambattista Vico, an Italian philosopher (1668-1744) said
|
||||
|
@ -58,10 +56,14 @@ If you want to ``roll your own'', you should also see Gerard Beekmans'
|
|||
<URL URL="http://www.linuxfromscratch.org" NAME="Linux From Scratch HOWTO"> (LFS).
|
||||
LFS has detailed instructions on building a complete useable system from
|
||||
source code. On the LFS website, you will also find a mailing list for people
|
||||
building systems this way. What I have included in this document, is
|
||||
instructions
|
||||
(see <REF ID="building" NAME="Building a Minimal Linux System From Source">)
|
||||
for building a ``toy'' system, purely as a learning exercise.
|
||||
building systems this way.
|
||||
The instructions that used to be part of this document
|
||||
are now in a separate document ``Building a Minimal Linux System from Source Code'',
|
||||
and can be found at
|
||||
<URL URL="http://www.netspace.net.au/~gok/power2bash/"
|
||||
NAME="From PowerUp to Bash Prompt home page">.
|
||||
They explain how to
|
||||
``toy'' system, purely as a learning exercise.
|
||||
|
||||
<P>
|
||||
Packages are presented in the order in which they appear in the system
|
||||
|
@ -122,7 +124,7 @@ Ask around, someone might give you some of the parts you need.
|
|||
|
||||
<P>
|
||||
Check out, download compile and make a boot disk for
|
||||
<URL URL="http://learning.taslug.org.au/resources" NAME=Unios>.
|
||||
<URL URL="http://www.netspace.net.au/~gok/resources" NAME=Unios>.
|
||||
(They used to have a home page at <URL URL="http://www.unios.org">,
|
||||
but it disappeared)
|
||||
This is just a bootable ``Hello World!'' program, consisting of just over 100
|
||||
|
@ -143,7 +145,8 @@ Check out the source code for LILO's boot loader.
|
|||
<P>
|
||||
<ITEMIZE>
|
||||
<ITEM>
|
||||
<URL URL="http://www.linuxdoc.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO.html" NAME="The Unix and Internet Fundamentals HOWTO">
|
||||
<URL URL="http://www.linuxdoc.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO.html"
|
||||
NAME="The Unix and Internet Fundamentals HOWTO">
|
||||
by Eric S. Raymond,
|
||||
especially section 3, <EM>What happens when you switch on a computer?</EM>
|
||||
|
||||
|
@ -216,7 +219,8 @@ to make a five point loop. Fun!
|
|||
<LABEL ID="lilo-links">
|
||||
<ITEMIZE>
|
||||
<ITEM>The lilo man page.
|
||||
<ITEM>The Lilo package (see <REF ID="downloads" NAME="downloads">)
|
||||
<ITEM>The Lilo package
|
||||
(<URL URL="ftp://lrcftp.epfl.ch/pub/linux/local/lilo/" NAME="lilo">),
|
||||
contains the ``LILO User's Guide''
|
||||
<TT>lilo-u-21.ps.gz</TT> (or a later version).
|
||||
You may already have this document though.
|
||||
|
@ -326,7 +330,10 @@ Hack! See if you can make it spit out some extra messages or something.
|
|||
<TT>make menuconfig</TT> or <TT>make xconfig</TT>
|
||||
<ITEM> <URL URL="http://mirror.aarnet.edu.au/linux/LDP/LDP/"
|
||||
NAME="The Linux Kernel (and other LDP Guides)">
|
||||
<ITEM> Kernel source download see <REF ID="downloads" NAME="downloads">
|
||||
<ITEM> source code, see
|
||||
<URL URL="http://www.netspace.net.au/~gok/power2bash"
|
||||
NAME="Building a Minimal Linux System from Source Code">
|
||||
for urls
|
||||
</ITEMIZE>
|
||||
|
||||
|
||||
|
@ -400,7 +407,10 @@ a program that uses this library.
|
|||
<SECT1>More Information
|
||||
<P>
|
||||
<ITEMIZE>
|
||||
<ITEM>source code, see section <REF ID="downloads" NAME="downloads">
|
||||
<ITEM> source code, see
|
||||
<URL URL="http://www.netspace.net.au/~gok/power2bash"
|
||||
NAME="Building a Minimal Linux System from Source Code">
|
||||
for urls
|
||||
</ITEMIZE>
|
||||
|
||||
|
||||
|
@ -507,12 +517,15 @@ This is a good exercise in learning Bash shell scripting too, some of the script
|
|||
<SECT1>More Information
|
||||
<P>
|
||||
<ITEMIZE>
|
||||
<ITEM>see <REF ID="downloads" NAME="downloads"> for source code download url's
|
||||
<ITEM>There are man pages for the <TT>inittab</TT> and <TT>fstab</TT> files.
|
||||
Type (eg) <TT>man inittab</TT> into a shell to see it.
|
||||
<ITEM>The Linux System Administrators Guide has a good
|
||||
<URL URL="http://mirror.aarnet.edu.au/linux/LDP/LDP/"
|
||||
NAME="section"> on init.
|
||||
<ITEM> source code, see
|
||||
<URL URL="http://www.netspace.net.au/~gok/power2bash"
|
||||
NAME="Building a Minimal Linux System from Source Code">
|
||||
for urls
|
||||
</ITEMIZE>
|
||||
|
||||
|
||||
|
@ -594,7 +607,9 @@ Check out the ext2 filesystem code in the Kernel.
|
|||
<URL URL="http://mirror.aarnet.edu.au/linux/LDP/LDP/"
|
||||
NAME="mirror">
|
||||
<ITEM>The <TT>mount</TT> command is part of the util-linux package, there is a link
|
||||
to it in <REF ID="downloads" NAME="downloads">.
|
||||
to it in
|
||||
<URL URL="http://www.netspace.net.au/~gok/power2bash"
|
||||
NAME="Building a Minimal Linux System from Source Code">
|
||||
<ITEM>man pages for <TT>mount</TT>, <TT>fstab</TT>, <TT>fsck</TT> and <TT>mke2fs</TT>
|
||||
<ITEM>EXT2 File System Utilities
|
||||
<URL URL="http://web.mit.edu/tytso/www/linux/e2fsprogs.html"
|
||||
|
@ -858,11 +873,14 @@ Read shell scripts, look up stuff you don't understand.
|
|||
<SECT1>More Information
|
||||
<P>
|
||||
<ITEMIZE>
|
||||
<ITEM>source code download see <REF ID="downloads" NAME="downloads">
|
||||
<ITEM>There is a ``Bash Reference Manual'' with this, which is comprehensive, but heavy going.
|
||||
<ITEM>There is an O'Rielly book on Bash, not sure if it's good.
|
||||
<ITEM>I don't know of any good free up to date bash tutorials. If you do, please
|
||||
email me a url.
|
||||
<ITEM> source code, see
|
||||
<URL URL="http://www.netspace.net.au/~gok/power2bash"
|
||||
NAME="Building a Minimal Linux System from Source Code">
|
||||
for urls
|
||||
</ITEMIZE>
|
||||
|
||||
|
||||
|
@ -879,568 +897,6 @@ It has a full and up to date list of the packages that go into a Linux system
|
|||
as well as instructions on how to build them.
|
||||
|
||||
|
||||
<SECT>Building A Minimal Linux System From Source
|
||||
<LABEL ID="building">
|
||||
<P>
|
||||
So far I have focussed on what the packages do. Here I will offer what clues
|
||||
I can about making a minimal Linux system from source. This is a toy system
|
||||
we are making here. If you want to build a real system to be used for real
|
||||
work, see the
|
||||
<URL URL="http://www.linuxfromscratch.org" NAME="Linux From Scratch HOWTO">.
|
||||
|
||||
<P>
|
||||
It is possible to get a bash
|
||||
prompt without installing everything I mention here. What I describe is
|
||||
a base system, without nasty kludges, that can be built on easily.
|
||||
|
||||
|
||||
<SECT1>What You Will Need
|
||||
<P>
|
||||
We will install a Linux distribution like Red Hat in one partition,
|
||||
and use that to build a new Linux system in another partition.
|
||||
I will call the system we are building the ``target'' and the
|
||||
system we are using to build it with, the ``source'' (not to be
|
||||
confused with <EM>source code</EM> which we will also be using.)
|
||||
|
||||
<P>
|
||||
So you are going to need a machine with two spare partitions on it.
|
||||
If you can, use a machine with nothing important on it.
|
||||
You could use an existing Linux installation as the source system,
|
||||
but I wouldn't recommend that. If you leave a parameter out of one
|
||||
of the commands we will issue, you could accidentally install stuff to this
|
||||
system. This could lead to incompatibilites and strife.
|
||||
|
||||
<P>
|
||||
Older PC hardware, mostly 486's and earlier, have an annoying limitation
|
||||
in their bios. They can not read from a hard disk past the first 512M.
|
||||
This is not too much of a problem for Linux, because once it is up, it
|
||||
does its own disk io, bypassing the bios.
|
||||
But for Linux to get loaded by these old machines,
|
||||
the kernel has to reside somewhere below 512M. If you have one of these machines
|
||||
you will need to have a separate partition completely below the 512M
|
||||
mark, to mount as <TT>/boot</TT> for any partitions that are over that
|
||||
512M mark.
|
||||
|
||||
<P>
|
||||
Last time I did this, I used Red Hat 6.1 as a source system. I installed
|
||||
the base system plus
|
||||
|
||||
<ITEMIZE>
|
||||
<ITEM>cpp
|
||||
<ITEM>egcs
|
||||
<ITEM>egcs-c++
|
||||
<ITEM>patch
|
||||
<ITEM>make
|
||||
<ITEM>dev86
|
||||
<ITEM>ncurses-devel
|
||||
<ITEM>glibc-devel
|
||||
<ITEM>kernel-headers
|
||||
</ITEMIZE>
|
||||
|
||||
I also had X-window and Mozilla so I could read documentation easily,
|
||||
but that's not really necessary. By the time I had finished working,
|
||||
it had used about 350M of disk space. (Seems a bit high, I wonder why?)
|
||||
|
||||
<P>
|
||||
The finished target system took 650M, but that includes all the source code and
|
||||
intermediate build files. If space is tight, you should do a <TT>make clean</TT>
|
||||
after each package is built. Still, this mind boggling bloat is a bit of a worry.
|
||||
|
||||
<P>
|
||||
Finally, you are going to need the source code for the system we are going to
|
||||
build. These are the ``packages'' that I have discussed in this document. These
|
||||
can be obtained from a source cd, or from the internet. I'll give URL's for
|
||||
the USA sites and for Australian mirrors.
|
||||
|
||||
<P>
|
||||
<LABEL ID="downloads">
|
||||
<ITEMIZE>
|
||||
<ITEM>MAKEDEV
|
||||
<URL URL="ftp://tsx-11.mit.edu/pub/linux/sources/sbin" NAME="USA">
|
||||
Another
|
||||
<URL URL="ftp://sunsite.unc.edu/pub/Linux/system/admin" NAME="USA">
|
||||
site
|
||||
<ITEM>Lilo
|
||||
<URL URL="ftp://lrcftp.epfl.ch/pub/linux/local/lilo/" NAME="USA">,
|
||||
<URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/boot/lilo/"
|
||||
NAME="Australia">.
|
||||
<ITEM>Linux Kernel
|
||||
Use one of the mirrors listed at
|
||||
<URL URL="http://www.kernel.org" NAME="home page">
|
||||
rather than
|
||||
<URL URL="ftp://ftp.kernel.org/pub/linux/kernel" NAME="USA">
|
||||
because they are always overloaded.
|
||||
<URL URL="ftp://kernel.mirror.aarnet.edu.au/pub/linux/kernel/"
|
||||
NAME="Australia">
|
||||
<ITEM>GNU libc
|
||||
itself, and the linuxthreads addon are at
|
||||
<URL URL="ftp://ftp.gnu.org/pub/gnu/glibc" NAME="USA">
|
||||
<URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/glibc" NAME="Australia">
|
||||
<ITEM>GNU libc addons
|
||||
You will also need the linuxthreads and libcrypt addons.
|
||||
If libcrypt is not there it is because of some US export laws.
|
||||
You can get it at
|
||||
<URL URL="ftp://ftp.gwdg.de/pub/linux/glibc" NAME="libcrypt">
|
||||
The linuxthreads addon is in the same places as libc itself
|
||||
<ITEM>GNU ncurses
|
||||
<URL URL="ftp://ftp.gnu.org/gnu/ncurses" NAME="USA">
|
||||
<URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/ncurses" NAME="Australia">
|
||||
<ITEM>SysVinit
|
||||
<URL URL="ftp://sunsite.unc.edu/pub/Linux/system/daemons/init"
|
||||
NAME="USA">
|
||||
<URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/daemons/init"
|
||||
NAME="Australia">
|
||||
<ITEM>GNU Bash
|
||||
<URL URL="ftp://ftp.gnu.org/gnu/bash" NAME="USA">
|
||||
<URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/bash" NAME="Australia">
|
||||
<ITEM>GNU sh-utils
|
||||
<URL URL="ftp://ftp.gnu.org/gnu/sh-utils" NAME="USA">
|
||||
<URL URL="ftp://mirror.aarnet.edu.au/pub/gnu/sh-utils"
|
||||
NAME="Australia">
|
||||
<ITEM>util-linux
|
||||
<URL URL="ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/"
|
||||
NAME="Somewhere else">
|
||||
<URL URL="ftp://mirror.aarnet.edu.au/pub/linux/metalab/system/misc"
|
||||
NAME="Australia"> This package contains <TT>agetty</TT> and
|
||||
<TT>login</TT>.
|
||||
|
||||
</ITEMIZE>
|
||||
|
||||
<P>
|
||||
To sum up then, you will need:
|
||||
<ITEMIZE>
|
||||
<ITEM>A machine with two spare partitions of about 400M and 700M respectively
|
||||
though you could probably get away with less
|
||||
<ITEM>A Linux distribution (eg. a Red Hat cd) and a way of installing it
|
||||
(eg. a cdrom drive)
|
||||
<ITEM>The source code tarballs listed above
|
||||
</ITEMIZE>
|
||||
|
||||
<P>
|
||||
I'm assuming that you can install the source system yourself, without any
|
||||
help from me. From here on, I'll assume that its done.
|
||||
|
||||
<P>
|
||||
The first milestone in this little project is getting the kernel to boot up
|
||||
and panic because it can't find an <TT>init</TT>. This means we are going to have
|
||||
to install a kernel, and install lilo. To install lilo nicely though, we
|
||||
will need the device files in the target <TT>/dev</TT> directory. Lilo
|
||||
needs them to do the low level disk access necessary to write the boot
|
||||
sector. MAKEDEV is the script that creates these device files.
|
||||
(You can just copy them from the source system of course, but that's cheating!)
|
||||
But first of all, we need a filesystem to put all of this into.
|
||||
|
||||
|
||||
<SECT1>The Filesystem
|
||||
|
||||
<P>
|
||||
Our new system is going to live in a file system. So first, we have to make
|
||||
that file system using <TT>mke2fs</TT>. Then mount it somewhere. I'd suggest
|
||||
<TT>/mnt/target</TT>. In what follows, I'll assume that this is where it is.
|
||||
You could save yourself a bit of time by putting an
|
||||
entry in <TT>/etc/fstab</TT> so that it mounts there automatically when the
|
||||
source system comes up.
|
||||
|
||||
<P>
|
||||
When we boot up the target system, the stuff that's now in <TT>/mnt/target</TT>
|
||||
will be in <TT>/</TT>.
|
||||
|
||||
<P>
|
||||
We need a directory structure on target. Have a look at the
|
||||
File Heirarchy Standard (see section <REF ID="FHS" NAME="Filesystem">)
|
||||
to work out what this should be, or just <TT>cd</TT>
|
||||
to where the target is mounted and blindly do
|
||||
|
||||
<VERB>
|
||||
mkdir bin boot dev etc home lib mnt root sbin tmp usr var
|
||||
cd var; mkdir lock log run spool
|
||||
cd ../usr; mkdir bin include lib local sbin share src
|
||||
cd share/; mkdir man; cd man
|
||||
mkdir man1 man2 man3 ... man9
|
||||
</VERB>
|
||||
|
||||
Since the FHS and most packages disagree about where man pages should go,
|
||||
we need a symlink
|
||||
|
||||
<VERB>
|
||||
cd ..; ln -s share/man man
|
||||
</VERB>
|
||||
|
||||
<SECT1>MAKEDEV
|
||||
<P>
|
||||
We will put the source code in the target <TT>/usr/src</TT> directory.
|
||||
So for example, if your target file system is mounted on <TT>/mnt/target</TT>
|
||||
and your tarballs are in <TT>/root</TT>, you would do
|
||||
|
||||
<VERB>
|
||||
cd /mnt/target/usr/src
|
||||
tar -xzvf /root/MAKEDEV-2.5.tar.gz
|
||||
</VERB>
|
||||
|
||||
<P>
|
||||
Don't be completely lame and copy the tarball to the place where you are going
|
||||
to extract it ;->
|
||||
|
||||
<P>
|
||||
Normally when you install software, you are installing it onto the system
|
||||
that is running. We don't want to do that though, we want to install it
|
||||
as though <TT>/mnt/target</TT> is the root filesystem. Different packages
|
||||
have different ways of letting you do this. For MAKEDEV you do
|
||||
|
||||
<VERB>
|
||||
ROOT=/mnt/target make install
|
||||
</VERB>
|
||||
|
||||
<P>
|
||||
You need to look out for these options in the README and INSTALL files
|
||||
or by doing a <TT>./configure --help</TT>.
|
||||
|
||||
<P>
|
||||
Have a look in MAKEDEV's <TT>Makefile</TT> to see what it does with the
|
||||
<TT>ROOT</TT> varible that we set in that command. Then have a look
|
||||
in the man page by doing <TT>man ./MAKEDEV.man</TT> to see how it
|
||||
works. You'll find that the way to make our device files is to
|
||||
<TT>cd /mnt/target/dev</TT> and do <TT>./MAKEDEV generic</TT>.
|
||||
Do an <TT>ls</TT> to see all the wonderful device files it has made
|
||||
for you.
|
||||
|
||||
<SECT1>Kernel
|
||||
<P>
|
||||
Next we make a kernel. I presume you've done this before, so I'll be brief.
|
||||
It is easier to install lilo if the kernel
|
||||
it is meant to boot is already there. Go back to the target <TT>usr/src</TT>
|
||||
directory, and unpack the linux kernel source there. Enter the linux
|
||||
source tree (<TT>cd linux</TT>) and configure the kernel
|
||||
using your favourite method, for example <TT>make menuconfig</TT>.
|
||||
You can make life slightly easier for yourself by configuring
|
||||
a kernel without modules. If you configure any modules, then you
|
||||
will have to edit the <TT>Makefile</TT>, find <TT>INSTALL_MOD_PATH</TT>
|
||||
and set it to <TT>/mnt/target</TT>.
|
||||
|
||||
<P>
|
||||
Now you can <TT>make dep</TT>, <TT>make bzImage</TT>, and if you configured
|
||||
modules: <TT>make modules</TT>, <TT>make modules_install</TT>. Copy
|
||||
the kernel <TT>arch/i386/boot/bzImage</TT> and the system map <TT>System.map</TT>
|
||||
to the target boot directory <TT>/mnt/target/boot</TT>, and we are ready
|
||||
to install lilo.
|
||||
|
||||
<SECT1>Lilo
|
||||
<P>
|
||||
Lilo comes with a neat script called <TT>QuickInst</TT>. Unpack the lilo
|
||||
source into the target source directory, run this script with the command
|
||||
<TT>ROOT=/mnt/target ./QuickInst</TT>. It will ask you questions about
|
||||
how you want lilo installed.
|
||||
|
||||
<P>
|
||||
Remember, since we have set <TT>ROOT</TT>,
|
||||
to the target partition, you tell it file names relative to that. So
|
||||
when it asks what kernel you want to boot by default, answer
|
||||
<TT>/boot/bzImage</TT> <EM>not</EM> <TT>/mnt/target/boot/bzImage</TT>.
|
||||
I found a little bug in the script, so it said
|
||||
|
||||
<VERB>
|
||||
|
||||
./QuickInst: /boot/bzImage: no such file
|
||||
</VERB>
|
||||
|
||||
But if you just ignore it, it's ok.
|
||||
|
||||
<P>
|
||||
Where should we get <TT>QuickInst</TT> to put the boot sector?
|
||||
When we reboot we want to have the choice of booting into the source system
|
||||
or the target system, or any other systems that are on this box.
|
||||
And we want the instance of lilo that we are building now to load
|
||||
the kernel of our new system. How are we going achieve both of these
|
||||
things? Let's digress a little and look at how lilo boots DOS on a
|
||||
dual boot Linux system. The <TT>lilo.conf</TT> file on such a system
|
||||
probably looks something like this:
|
||||
|
||||
<P>
|
||||
<VERB>
|
||||
prompt
|
||||
timeout = 50
|
||||
default = linux
|
||||
|
||||
image = /boot/bzImage
|
||||
label = linux
|
||||
root = /dev/hda1
|
||||
read-only
|
||||
|
||||
other = /dev/hda2
|
||||
label = dos
|
||||
</VERB>
|
||||
|
||||
|
||||
<P>
|
||||
If the machine is set up this way, then the master boot record gets read and
|
||||
loaded by the bios, and it loads the lilo bootloader, which gives a prompt.
|
||||
If you type in <TT>dos</TT> at the prompt, lilo loads the boot sector from
|
||||
hda2, and it loads DOS.
|
||||
|
||||
<P>
|
||||
What we are going to do is just the same, except that the boot sector in
|
||||
hda2 is going to be another lilo boot sector - the one that <TT>QuickInst</TT>
|
||||
is going to install. So the lilo from the Linux distribution will load the
|
||||
lilo that we have built, and that will load the kernel that we have built.
|
||||
You will see two lilo prompts when you reboot.
|
||||
|
||||
<P>
|
||||
To cut a long story short, when <TT>QuickInst</TT> asks you where to put the
|
||||
boot sector, tell it the device where your target filesystem is,
|
||||
eg. <TT>/dev/hda2</TT>.
|
||||
|
||||
<P>
|
||||
Now modify the <TT>lilo.conf</TT> on your source system, so it has
|
||||
a line like
|
||||
|
||||
<VERB>
|
||||
other = /dev/hda2
|
||||
label = target
|
||||
</VERB>
|
||||
|
||||
run lilo, and we should be able to do our first boot into the target system.
|
||||
|
||||
<SECT1>Glibc
|
||||
<P>
|
||||
Next we want to install <TT>init</TT>, but like almost every program that
|
||||
runs under Linux, <TT>init</TT> uses library functions provided by the
|
||||
GNU C library, glibc. So we will install that first.
|
||||
|
||||
<P>
|
||||
Glibc is a very large and complicated package. It took 90 hours to build
|
||||
on my old 386sx/16 with 8M RAM. But it only took 33 minutes on my Celeron
|
||||
433 with 64M. I think memory is the main issue here. If you only have 8M
|
||||
of RAM (or, shudder, less!) be prepared for a long build.
|
||||
|
||||
<P>
|
||||
The glibc install documentation recommends building in a separate directory.
|
||||
This enables you to start again easily, by just blowing that directory away.
|
||||
You might also want to do that to save yourself about 265M of disk space!
|
||||
|
||||
<P>
|
||||
Unpack the <TT>glibc-2.1.3.tar.gz</TT> (or whatever version) tarball into
|
||||
<TT>/mnt/target/usr/src</TT>
|
||||
as usual. Now, we need to unpack the ``add-ons'' into glibc's directory. So
|
||||
<TT>cd glibc-2.1.3</TT>, and then unpack the <TT>glibc-crypt-2.1.3.tar.gz</TT>
|
||||
and <TT>glibc-linuxthreads-2.1.3.tar.gz</TT> tarballs there.
|
||||
|
||||
<P>
|
||||
Now we can create the build directory, configure, make and install glibc.
|
||||
These are the commands I used, but read the documentation yourself and
|
||||
make sure you do what is best for your circumstances.
|
||||
Before you do though, you might want to do a <TT>df</TT> command to see
|
||||
how much free space you have. You can do another after you've built and
|
||||
installed glibc, to see what a space-hog it is.
|
||||
|
||||
<P><VERB>
|
||||
cd ..
|
||||
mkdir glibc-build
|
||||
../glibc-2.1.3/configure --enable-add-ons --prefix=/usr
|
||||
make
|
||||
make install_root=/mnt/target install
|
||||
</VERB>
|
||||
|
||||
<P>
|
||||
Notice that we have yet another way of telling a package where to install.
|
||||
|
||||
<SECT1>SysVinit
|
||||
<P>
|
||||
Making and installing the SysVinit binaries is pretty straight forward.
|
||||
I'll just be lazy and give you the commands, assuming that you have
|
||||
unpacked and entered the SysVinit source code directory:
|
||||
|
||||
<P><VERB>
|
||||
cd src
|
||||
make
|
||||
ROOT=/mnt/target make install
|
||||
</VERB>
|
||||
|
||||
<P>
|
||||
There are also a lot of scripts associated with <TT>init</TT>.
|
||||
There are example scripts with the SysVinit package, which work fine.
|
||||
But you have to install them manually. They are set up in a heirarchy
|
||||
under <TT>debian/etc</TT> in the SysVinit source code tree. You can
|
||||
just copy them straight across into the target <TT>etc</TT> directory,
|
||||
with something like <TT>cd ../debian/etc; cp -r * /mnt/target/etc</TT>.
|
||||
Obviously you will want to have a look before you copy them across!
|
||||
|
||||
<P>
|
||||
Everything is in place now for the target kernel to load up <TT>init</TT>
|
||||
when we reboot. The problem this time should be that the scripts won't
|
||||
run, becasue <TT>bash</TT> isn't there to interpret them. Also, <TT>init</TT>
|
||||
will try to run <TT>getty</TT>'s, but there is no <TT>getty</TT> for it to run.
|
||||
Reboot now and make sure there is nothing else wrong.
|
||||
|
||||
<SECT1>Ncurses
|
||||
<P>
|
||||
The next thing we need is Bash, but bash needs ncurses, so we'll install
|
||||
it first. Ncurses replaces termcap as the way of handling text screens,
|
||||
but it can also provide backwards compatibility by supporting the termcap
|
||||
calls. In the interests of having a clean simple modern system,
|
||||
I think its best to
|
||||
disable the old termcap method. You might strike trouble later on if
|
||||
you are compiling an older application that uses termcap.
|
||||
But at least you will know what is using what. If you need to you can recompile
|
||||
ncurses with termcap support.
|
||||
|
||||
<P>
|
||||
The commands I used are
|
||||
|
||||
<P><VERB>
|
||||
./configure --prefix=/usr --with-install-prefix=/mnt/target --with-shared --disable-termcap
|
||||
make
|
||||
make install
|
||||
</VERB>
|
||||
|
||||
<SECT1>Bash
|
||||
<P>
|
||||
It me took quite a lot of reading and thinking and trial and error
|
||||
to get Bash to install itself where I thought it should go. The
|
||||
configuration options I used are
|
||||
|
||||
<P><VERB>
|
||||
./configure --prefix=/mnt/target/usr/local --exec-prefix=/mnt/target --with-curses
|
||||
</VERB>
|
||||
|
||||
<P>
|
||||
Once you have made and installed Bash, you need to make a symlink like this
|
||||
<TT>cd /mnt/target/bin; ln -s bash sh</TT>. This is because scripts usually
|
||||
have a first line like this
|
||||
|
||||
<P><VERB>
|
||||
#!/bin/sh
|
||||
</VERB>
|
||||
|
||||
<P>
|
||||
If you don't have the symlink, your scripts won't be able to run, because
|
||||
they will be looking for <TT>/bin/sh</TT> not <TT>/bin/bash</TT>.
|
||||
|
||||
<P>
|
||||
You could reboot again at this point if you like. You should notice that
|
||||
the scripts actually run this time, though you still can't login, because
|
||||
there are no <TT>getty</TT> or <TT>login</TT> programs.
|
||||
|
||||
<SECT1>Util-linux (getty and login)
|
||||
<P>
|
||||
The util-linux package contains <TT>agetty</TT> and <TT>login</TT>. We need
|
||||
both of these to be able to log in and get a bash prompt. After it is
|
||||
instlalled, make a symlink from <TT>agetty</TT> to <TT>getty</TT> in the
|
||||
target <TT>/sbin</TT> directory. <TT>getty</TT> is one of the programs
|
||||
that is supposed to be there on all Unix-like systems, so the link
|
||||
is a better idea than hacking <TT>inittab</TT> to run <TT>agetty</TT>.
|
||||
|
||||
<P>
|
||||
I have one remaining problem with the compilation of util-linux. The
|
||||
package also contains the program <TT>more</TT>, and I have not been
|
||||
able to persuade the <TT>make</TT> process to have <TT>more</TT>
|
||||
link against the ncurses 5 library on the target system rather than
|
||||
the ncurses 4 on the source system. I'll be having a closer look at
|
||||
that.
|
||||
|
||||
<P>
|
||||
You will also need a <TT>/etc/passwd</TT> file on the target system.
|
||||
This is where the <TT>login</TT> program will check to find out if
|
||||
you are allowed in. Since this is only a toy system at this stage,
|
||||
we can do outrageous things like setting up only the root user,
|
||||
and not requiring any password!! Just put this in the target
|
||||
<TT>/etc/passwd</TT>
|
||||
|
||||
|
||||
<P><VERB>
|
||||
root::0:0:root:/root:/bin/bash
|
||||
</VERB>
|
||||
|
||||
<P>
|
||||
The fields are separated by colons, and from left to right they are
|
||||
user id, password (encrypted), user number, group number, user's name,
|
||||
home directory and default shell.
|
||||
|
||||
<SECT1>Sh-utils
|
||||
<P>
|
||||
The last package we need is GNU sh-utils. The only program we need from
|
||||
here at this stage is <TT>stty</TT>, which is used in <TT>/etc/init.d/rc</TT>
|
||||
which is used to change runlevels, and to enter the initial runlevel.
|
||||
I actually have, and used a package that contains only <TT>stty</TT>,
|
||||
but I can't remember where it came from. Its a better idea to use the
|
||||
GNU package, because there is other stuff in there that you will need
|
||||
if you add to the system to make it useable.
|
||||
|
||||
<P>
|
||||
Well that's it. You should now have a system that will boot up and prompt
|
||||
you for a login. Type in ``root'', and you should get a shell. You won't
|
||||
be able to do much with it. There isn't even an <TT>ls</TT> command here
|
||||
for you to see your handiwork. Press tab twice so you can see the
|
||||
available commands. This was about the most satisfying thing I found to do
|
||||
with it.
|
||||
|
||||
<SECT1>Towards Useability
|
||||
<P>
|
||||
It might look like we have made a pretty useless system here. But really,
|
||||
there isn't that far to go before it can do some work. One of the first
|
||||
things you would have to do is have the root filesystem mount read-write.
|
||||
There is a script from the SysVinit package, in <TT>/etc/init.d/mountall.sh</TT>
|
||||
which does this, and
|
||||
issues a <TT>mount -a</TT> so that everything gets mounted the way you
|
||||
specify in <TT>/etc/fstab</TT>. Put a symlink called something like
|
||||
<TT>S05mountall</TT> to it in the target's <TT>etc/rc2.d</TT>.
|
||||
|
||||
<P>
|
||||
You may find that this script will use commands that you haven't
|
||||
installed yet. If so, find the package that contains the commands
|
||||
and install it. See section <REF ID="finding" NAME="Random Tips"> for
|
||||
clues on how to find packages.
|
||||
|
||||
<P>
|
||||
Look at the other scripts in <TT>/etc/init.d</TT>. Most of them will
|
||||
need to be included in any serious system. Add them in one at a time,
|
||||
make sure everthing is running smoothly before adding more.
|
||||
|
||||
<P>
|
||||
Check the File Heirarchy Standard (see section <REF ID="FHS" NAME="Filesystem">).
|
||||
It has lists of the commands that should be in <TT>/bin</TT> and
|
||||
<TT>/sbin</TT>. Make sure that you have all these commands installed.
|
||||
Even better, find the Posix documentation that specifies this stuff.
|
||||
|
||||
<P>
|
||||
>From there, it's really just a matter of throwing in more and more packages
|
||||
until everything you want it there. The sooner you can put the build tools
|
||||
such as <TT>gcc</TT> and <TT>make</TT> in the better. Once that is done,
|
||||
you can use the target system to build itself, which is much less complicated.
|
||||
|
||||
<SECT1>Random Tips
|
||||
<LABEL ID="finding">
|
||||
<P>
|
||||
If you have a command called <TT>thingy</TT> on a Linux system with RPM, and
|
||||
want a clue about where to get the source from, you can use the command:
|
||||
|
||||
<VERB>
|
||||
rpm -qif `which thingy`
|
||||
</VERB>
|
||||
|
||||
And if you have a Red Hat source CD, you can install the source code using
|
||||
|
||||
<VERB>
|
||||
rpm -i /mnt/cdrom/SRPMS/what.it.just.said-1.2.srpm
|
||||
</VERB>
|
||||
|
||||
<P>
|
||||
This will put the tarball, and any Red Hat patches into
|
||||
<TT>/usr/src/redhat/SOURCES</TT>.
|
||||
|
||||
<SECT1>More Information
|
||||
<P>
|
||||
<ITEMIZE>
|
||||
<ITEM> There is a mini-howto on building software from source, the
|
||||
<URL URL="http://www.linuxdoc.org/HOWTO/Software-Building.html"
|
||||
NAME="Software Building mini-HOWTO">.
|
||||
<ITEM> There is also a HOWTO on building a Linux system from scratch.
|
||||
It focuses much more on getting the system built so it can be used,
|
||||
rather than just doing it as a learning exercise.
|
||||
<URL URL="http://www.linuxfromscratch.org"
|
||||
NAME="The Linux From Scratch HOWTO">
|
||||
</ITEMIZE>
|
||||
|
||||
<SECT>Conclusion
|
||||
<P>
|
||||
One of the best things about Linux, in my humble opinion, is that you can get
|
||||
inside it and really find out how it all works. I hope that you enjoy this as
|
||||
|
@ -1458,8 +914,15 @@ Please acknowledge me if you use all or part of this in another document.
|
|||
<SECT1>Homepage
|
||||
<P>
|
||||
The lastest version of this document lives at
|
||||
<URL URL="http://learning.taslug.org.au/power2bash"
|
||||
<URL URL="http://www.netspace.net.au/~gok/power2bash"
|
||||
NAME="From Powerup To Bash Prompt">
|
||||
as does its companion ``Building a Minimal Linux System from Source Code''.
|
||||
|
||||
<P>
|
||||
There is a French translation at
|
||||
<URL URL="http://www.freenix.fr/unix/linux/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html"
|
||||
NAME="From Powerup To Bash Prompt"> thanks to Dominique van den Broeck.
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -1481,15 +944,6 @@ There are some people I want to say thanks to, for helping to make this happen.
|
|||
|
||||
<P>
|
||||
<DESCRIP>
|
||||
<TAG>Everyone on the learning@TasLUG mailing list</TAG>
|
||||
Thanks for reading all my mails and asking interesting questions.
|
||||
You can join this list by sending a message to
|
||||
<URL URL="mailto:majordomo@taslug.org.au" NAME="majordomo"> with
|
||||
<VERB>
|
||||
subscribe learning
|
||||
</VERB>
|
||||
in the message body.
|
||||
|
||||
|
||||
<TAG>Michael Emery</TAG>
|
||||
For reminding me about Unios.
|
||||
|
@ -1508,10 +962,25 @@ For correcting my hexidecimal arithmetic.
|
|||
For pointing out some typos.
|
||||
<TAG>David Leadbeater</TAG>
|
||||
For contributing some ``ramblings'' about the kernel deamons.
|
||||
<TAG> Dominique van den Broeck </TAG>
|
||||
For translating this doc into French.
|
||||
</DESCRIP>
|
||||
|
||||
<SECT1>Change History
|
||||
|
||||
<SECT2>0.7 -> 0.8
|
||||
<P>
|
||||
<ITEMIZE>
|
||||
<ITEM> Removed instructions on how to build a system, placing them in a
|
||||
separate document. Adjusted a few links accordingly.
|
||||
<ITEM> Changed homepage from <URL URL="http://learning.taslug.org.au/power2bash"
|
||||
NAME="learning@TasLUG">
|
||||
to <URL URL="http://www.netspace.net.au/~gok/power2bash"
|
||||
NAME="my own webspace">.
|
||||
<ITEM> Completely failed to incorporate a lot of good material
|
||||
contributed by various people. Maybe next time :(
|
||||
</ITEMIZE>
|
||||
|
||||
<SECT2>0.6 -> 0.7
|
||||
<P>
|
||||
<ITEMIZE>
|
||||
|
@ -1544,6 +1013,7 @@ For contributing some ``ramblings'' about the kernel deamons.
|
|||
<ITEM>add more exercises, perhaps a whole section on larger exercises,
|
||||
like creating a minimal system file by file from a distro
|
||||
install.
|
||||
<ITEM>add makefile hack to bash build instructions - see easter notes.
|
||||
</ITEMIZE>
|
||||
|
||||
</ARTICLE>
|
||||
|
|
Loading…
Reference in New Issue