mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
gferg
parent
ebe9f33cc6
commit
7bd5093006
|
|
@ -1,9 +1,9 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://docbook.org/xml/4.1.2/docbookx.dtd">
|
||||
|
||||
|
||||
|
||||
<article>
|
||||
|
||||
|
||||
<articleinfo>
|
||||
|
||||
<title>Apache based WebDAV Server with LDAP and SSL </title>
|
||||
|
|
@ -23,6 +23,15 @@
|
|||
|
||||
<revhistory>
|
||||
|
||||
<revision>
|
||||
<revnumber>v4.1.0</revnumber>
|
||||
<date>2003-09-02</date>
|
||||
<authorinitials>sa</authorinitials>
|
||||
<revremark>
|
||||
Updated the SSL section based on the feedback received from readers.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>v4.0.2</revnumber>
|
||||
<date>2003-08-01</date>
|
||||
|
|
@ -605,7 +614,6 @@ section's compilation process will have Apache to listen to both port 80 (normal
|
|||
to use this server for DAV, then I will highly suggest that you close port 80. In this section of the HOWTO I will provide some
|
||||
information regarding SSL and maintaining SSL on a Apache HTTP server.
|
||||
</para>
|
||||
|
||||
<sect2><title>Introduction to SSL</title>
|
||||
<para>
|
||||
SSL (Secure Socket Layer) is a protocol layer that exists between the Network Layer and Application layer. As the name suggest
|
||||
|
|
@ -638,16 +646,16 @@ The following is a over-simplified structure of the layers involved in SSL.
|
|||
<para>The client request content from the Web Server using HTTPS.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The web server responds with a Certificate which includes the server's public key.</para>
|
||||
<para>The web server responds with a Digital Certificate which includes the server's public key.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The client check to see if the certificate has expired.</para>
|
||||
<para>The client checks to see if the certificate has expired.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Then the client checks if the Certificate Authority that signed the certificate, is a trusted authority listed in the browser. This explains why we need to get a certificate from a a trusted CA.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The client then checks to see if the Domain Name of the web server matches the Comman Name (CN) on the certificate?</para>
|
||||
<para>The client then checks to see if the Fully Qualified Domain Name (FQDN) of the web server matches the Comman Name (CN) on the certificate?</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>If everything is successful the SSL connection is initiated.</para>
|
||||
|
|
@ -656,7 +664,7 @@ The following is a over-simplified structure of the layers involved in SSL.
|
|||
<note><title>Note:</title><para>Anything encrypted with Private Key can only be decrypted by using the Public Key. Similarly anything encrypted using the Public Key can only be decrypted using the Private Key. There is a common mis-conception that only the Public Key is used for encryption and Private Key is used for decryption. This is not case. Any key can be used for encryption/decryption. However if one key is used for encryption then the other key must be used for decryption. e.g. A message can not encrypted and then decrypted using only the Public Key.</para>
|
||||
<para><emphasis>Using Private Key to encrypt and a Public Key to decrypt ensures the integrity of the sender (owner of the Private Key) to the recipients. Using Public Key to encrypt and a Private Key to decrypt ensures that only the inteded recipient (owner of the Private Key) will have access to the data.</emphasis>(i.e. only the person who holds the Private Key will be able to decipher the message).</para></note>
|
||||
<para>
|
||||
<emphasis role="strong">Symmetric Cryptography - Actual transmission of data</emphasis>: After the SSL connection has been established, Symmetric cryptography is used for encryption data as it uses CPU cycles. In symmetric cryptography the data can be encrypted and decrypted using the same key. The Key for symmetric cryptography is exchanged during the initiation process, using Public Private Key Cryptography. </para>
|
||||
<emphasis role="strong">Symmetric Cryptography - Actual transmission of data</emphasis>: After the SSL connection has been established, Symmetric cryptography is used for encrypting data as it uses less CPU cycles. In symmetric cryptography the data can be encrypted and decrypted using the same key. The Key for symmetric cryptography is exchanged during the initiation process, using Public Key Cryptography. </para>
|
||||
|
||||
<para><emphasis role="strong">Message Digest</emphasis> The server uses message digest algoritm such as HMAC, SHA, MD5 to verify the integrity of the transferred data.</para>
|
||||
</sect3>
|
||||
|
|
@ -685,9 +693,7 @@ Similarly the test certificates will also cause a warning message to appear on t
|
|||
<sect2><title>How to generate a CSR</title>
|
||||
<para>
|
||||
CSR or Certificate Signing Request must be sent to the trusted CA for signing. This section discusses howto create a CSR,
|
||||
and send it to the CA of your choice.
|
||||
|
||||
|
||||
and send it to the CA of your choice. <command># openssl req</command> command can be used to a CSR as follows:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
|
|
@ -730,7 +736,7 @@ An optional company name []:
|
|||
At this point you will be asked several questions about your server to generate the Certificate Singning Request</para>
|
||||
|
||||
<para>
|
||||
Note: You Common Name (CN) is the DNS name of your webserver e.g. dav.server.com . If you put in anything else, it will NOT work. Remember the passwd that you use, for future reference.
|
||||
Note: Your Common Name (CN) is the Fully Qualified DNS (FQDN) name of your webserver e.g. dav.server.com . If you put in anything else, it will NOT work. Remember the password that you use, for future reference.
|
||||
</para>
|
||||
|
||||
<para>Once the process is complete, you will have <filename>private.key</filename> and a <filename>public.csr</filename> . You will need to submit the <filename>public.csr</filename> to the Certification Authority. At this pointe the public.key is not encrypted. To encrypt:
|
||||
|
|
@ -744,7 +750,62 @@ Note: You Common Name (CN) is the DNS name of your webserver e.g. dav.server.com
|
|||
|
||||
</sect2>
|
||||
<sect2><title>Installing Server Private Key, and Server Certificate</title>
|
||||
<para>Once the Certification Authority processes your request, they will send an encoded certificate back to you. You will need to place this certificate on the server, and tell Apache where to find it.</para>
|
||||
<para>Once the Certification Authority processes your request, they will send an encoded certificate (Digital Certificate) back to you. The Digital Certificate is in the format defined by X.509 v3. The following shows the structure of a typical X509 v3 Digital Certificate</para>
|
||||
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem>Certificate
|
||||
<itemizedlist mark='opencircle'><listitem>Version</listitem><listitem>Serial Number</listitem><listitem>Algorithm ID</listitem><listitem>Issuer</listitem>></itemizedlist>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem>Validity</listitem>
|
||||
<listitem><itemizedlist mark='opencircle'><listitem>Not Before</listitem><listitem>Not After</listitem></itemizedlist></listitem>
|
||||
</itemizedlist>
|
||||
<itemizedlist mark='opencircle'><listitem>Subject</listitem></itemizedlist>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem>Subject Public Key Info</listitem>
|
||||
<listitem><itemizedlist mark='opencircle'><listitem>Public Key Algorithm</listitem><listitem>RSA Public Key</listitem></itemizedlist></listitem>
|
||||
</itemizedlist>
|
||||
<itemizedlist mark='opencircle'><listitem>Extensions</listitem></itemizedlist>
|
||||
</listitem>
|
||||
<listitem>Certificate Signature Algorithm</listitem>
|
||||
<listitem>Certificate Signature</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
<sect3><title>Verifying a Digital Certificate</title>
|
||||
<para>To verify a X.509 Certificate use the following command</para>
|
||||
<screen><command># openssl verify <filename>server.crt</filename></command>
|
||||
server.crt: OK </screen>
|
||||
<para>Where <filename>server.crt</filename> is the name of the file that contains the Digital Certificate</para>
|
||||
|
||||
</sect3>
|
||||
<sect3><title>Viewing the contents of a Digital Certificate</title>
|
||||
<para>The contents of a Digital Certificate can be viewed by using the <command># openssl x509</command> command as follows:</para>
|
||||
<screen><command># openssl x509 -text -in <filename>server.crt</filename></command>
|
||||
Certificate:
|
||||
Data:
|
||||
Version: 3 (0x2)
|
||||
Serial Number: 312312312 (0x0)
|
||||
Signature Algorithm: md5WithRSAEncryption
|
||||
Issuer: C=US, O=GTE Corporation, CN=GTE CyberTrust Root
|
||||
Validity
|
||||
Not Before: Feb 8 03:25:50 2000 GMT
|
||||
Not After : Feb 8 03:25:50 2001 GMT
|
||||
Subject: C=US, ST=New York, L=Pelham, O=xml-dev, OU=web, CN=www.xml-dev.com/Email=saqib@xml-dev.com
|
||||
Subject Public Key Info:
|
||||
Public Key Algorithm: rsaEncryption
|
||||
RSA Public Key: (1024 bit)
|
||||
Modulus (1024 bit):
|
||||
............
|
||||
............
|
||||
Exponent: 65537 (0x10001)
|
||||
Signature Algorithm: md5WithRSAEncryption
|
||||
............
|
||||
............
|
||||
|
||||
</screen>
|
||||
|
||||
|
||||
</sect3>
|
||||
<para> You will need to place this certificate on the server, and tell Apache where to find it.</para>
|
||||
<para>For this example, the Private Key is placed in the <filename type="directory">/usr/local/apache2/conf/ssl.key/</filename> directory, and the Sever Certificate is placed in the <filename type="directory">/usr/local/apache2/conf/ssl.crt/</filename>.</para>
|
||||
<para>Copy the file received from the Certification to a file called <filename>server.crt</filename> in the <filename type="directory">/usr/local/apache2/conf/ssl.crt/</filename>.</para>
|
||||
<para>And place the private.key generated in the previous step in the <filename type="directory">/usr/local/apache2/conf/ssl.key/</filename></para>
|
||||
|
|
@ -833,7 +894,114 @@ One way to secure the decrypted Private Key is to make readable only by the root
|
|||
|
||||
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2><title>Glossary of PKI Terms</title>
|
||||
<glossary><title>Glossary of PKI Terms</title>
|
||||
|
||||
<glossdiv><title>A</title>
|
||||
|
||||
<glossentry id="asymmetric_crypt"><glossterm>Asymmetric Cryptography</glossterm>
|
||||
<glossdef>
|
||||
<para>In this Cryptography a Key Pair - Private and Public Key is used. Private Key is kept secret and the Public Key is Widely distrbuted.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossdiv>
|
||||
|
||||
|
||||
<glossdiv><title>C</title>
|
||||
|
||||
<glossentry id="ca"><glossterm>Certificate Authority (CA)</glossterm>
|
||||
<acronym>CA</acronym>
|
||||
<glossdef>
|
||||
<para>Issuer of the Digital Certificate. Also validates the Identity of the End-Entity that posseses the Digital Certificate.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id="csr"><glossterm>Certificate Signing Request (CSR)</glossterm>
|
||||
<acronym>CSR</acronym>
|
||||
<glossdef>
|
||||
<para>Certificate Signing Request (CSR) is what you send to a Certifiate Authority (CA) to get enrolled. A CSR contains the Public Key of the End-Entity that is a requesting the Digital Certificate.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id="cn"><glossterm>Common Name (CN)</glossterm>
|
||||
<acronym>CN</acronym>
|
||||
<glossdef>
|
||||
<para>Common Name is the name of the End-Entity e.g. Saqib Ali. If the End-Entity is a WebServer the CN is the Fully Qualified Domain Name (FQDN) of the WebServer</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
|
||||
</glossdiv>
|
||||
|
||||
<glossdiv><title>D</title>
|
||||
|
||||
<glossentry id="dig_cert"><glossterm>Digital Certificate</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>Public Key of the End-Entity + the identifying information of the End-Entity (owner of the Public Key). It certifies the Identity of the owner (End-Entity). It is signed by Issuing CA.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id="dig_sign"><glossterm>Digital Signature</glossterm>
|
||||
<glossdef>
|
||||
<para>A Digital Signature is created by signing the Message Digest using the Private Key. It ensures the Identity of the Sender, and the Integrity of the Data.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossdiv>
|
||||
|
||||
<glossdiv><title>E</title>
|
||||
<glossentry id="end_entity"><glossterm>End-Entity</glossterm>
|
||||
<glossdef>
|
||||
<para>An entity that participates in the PKI. Usually a Server, Service, Router, or a Person. A CA is not a End-Entity. An RA is an End-Entity to the CA</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossdiv>
|
||||
|
||||
|
||||
<glossdiv><title>P</title>
|
||||
|
||||
<glossentry id="private_key"><glossterm>Private Key</glossterm>
|
||||
<glossdef>
|
||||
<para>Private Key is the Key in Asymmetric Cryptography that is kept secret by the owner (End-Entity). Can be used for encryption or decryption</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id="public_key"><glossterm>Public Key</glossterm>
|
||||
<glossdef>
|
||||
<para>Public Key is the Key in Asymmetric Cryptography that is widely distributed. Can be used for encryption or decryption</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
<glossentry id="end_entity"><glossterm>Public Key Infrastructure (PKI)</glossterm>
|
||||
<acronym>PKI</acronym>
|
||||
<glossdef>
|
||||
<para>Public Key Infrastructure</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossdiv>
|
||||
|
||||
|
||||
<glossdiv><title>S</title>
|
||||
<glossentry id="end_entity"><glossterm>Secure Socket Layer (SSL)</glossterm>
|
||||
<acronym>SSL</acronym>
|
||||
<glossdef>
|
||||
<para>Secure Socket Layer (SSL) is a security protocol that provides authentication (Digital Certificate), confidentiality (encryption), and data integrity (Message Digest - MD5, SHA etc).</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
<glossentry id="symmetric_crypt"><glossterm>Symmetric Cryptography</glossterm>
|
||||
<glossdef>
|
||||
<para>In this cryptography the message the encrypted and decrypted by the same key. (((n^2-n))/2) keys are required for n users who want to participate in this system of cryptography. </para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
</glossdiv>
|
||||
|
||||
|
||||
</glossary>
|
||||
|
||||
|
||||
</sect2>
|
||||
|
||||
|
||||
</sect1>
|
||||
</article>
|
||||
|
|
|
|||
|
|
@ -898,7 +898,7 @@ M$Frontpage Server Extensions. </Para>
|
|||
Apache-WebDAV-LDAP-HOWTO</ULink>,
|
||||
<CiteTitle>Apache based WebDAV Server with LDAP and SSL HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: August 2003</CiteTitle>.
|
||||
<CiteTitle>Updated: September 2003</CiteTitle>.
|
||||
A HOWTO on implementing WebDAV services using Apache - with LDAP for
|
||||
authentication and SSL for ensuring security of the DAV stores. </Para>
|
||||
</ListItem>
|
||||
|
|
|
|||
|
|
@ -262,7 +262,7 @@ MS Frontpage Server Extensions. </Para>
|
|||
Apache-WebDAV-LDAP-HOWTO</ULink>,
|
||||
<CiteTitle>Apache based WebDAV Server with LDAP and SSL HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: August 2003</CiteTitle>.
|
||||
<CiteTitle>Updated: September 2003</CiteTitle>.
|
||||
A HOWTO on implementing WebDAV services using Apache - with LDAP for
|
||||
authentication and SSL for ensuring security of the DAV stores. </Para>
|
||||
</ListItem>
|
||||
|
|
@ -2834,7 +2834,7 @@ Access Server). </Para>
|
|||
Module-HOWTO</ULink>,
|
||||
<CiteTitle>Linux Loadable Kernel Module HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: July 2003</CiteTitle>.
|
||||
<CiteTitle>Updated: September 2003</CiteTitle>.
|
||||
Explains what Linux loadable kernel modules (LKMs) are,
|
||||
and how to use and create them. </Para>
|
||||
</ListItem>
|
||||
|
|
|
|||
|
|
@ -532,7 +532,7 @@ Crash Dump) package. </Para>
|
|||
Module-HOWTO</ULink>,
|
||||
<CiteTitle>Linux Loadable Kernel Module HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: July 2003</CiteTitle>.
|
||||
<CiteTitle>Updated: September 2003</CiteTitle>.
|
||||
Explains what Linux loadable kernel modules (LKMs) are,
|
||||
and how to use and create them. </Para>
|
||||
</ListItem>
|
||||
|
|
|
|||
|
|
@ -347,7 +347,7 @@ point for more information. </Para>
|
|||
Module-HOWTO</ULink>,
|
||||
<CiteTitle>Linux Loadable Kernel Module HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: July 2003</CiteTitle>.
|
||||
<CiteTitle>Updated: September 2003</CiteTitle>.
|
||||
Explains what Linux loadable kernel modules (LKMs) are,
|
||||
and how to use and create them. </Para>
|
||||
</ListItem>
|
||||
|
|
|
|||
|
|
@ -17,9 +17,18 @@
|
|||
|
||||
</author>
|
||||
|
||||
<pubdate>3 July 2003</pubdate>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>v1.04</revnumber>
|
||||
<date>2003-09-03</date>
|
||||
<authorinitials>bjh</authorinitials>
|
||||
<revremark>
|
||||
Fix typo: AHA154x should be AHA152x
|
||||
Add information on what module names the kernel module loader
|
||||
calls for. Add information on what an LKM does when you first
|
||||
load it.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>v1.03</revnumber>
|
||||
<date>2003-07-03</date>
|
||||
|
|
@ -633,6 +642,62 @@ didn't find it is that the file isn't an LKM. See
|
|||
</sect2>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>What Happens When An LKM Loads</title>
|
||||
<para>
|
||||
So you've successfully loaded an LKM, and verified that via
|
||||
<filename>/proc/modules</filename>. But how do you know it's working?
|
||||
That's up to the LKM, and varies according to what kind of LKM it is,
|
||||
but here are some of the more common actions of an LKM upon being loaded.
|
||||
</para>
|
||||
<para>
|
||||
The first thing a device driver LKM does after loading (which is what
|
||||
the module would do at boot time if it were bound into the base
|
||||
kernel) is usually to search the system for a device it knows how to
|
||||
drive. Just how it does this search varies from one driver to the
|
||||
next, and can usually be controlled by module parameters. But in any
|
||||
case, if the driver doesn't find any device it is capable of driving,
|
||||
it causes the load to fail. Otherwise, the driver registers itself
|
||||
as the driver for a particular major number and you can start using
|
||||
the device it found via a device special file that specifies that
|
||||
major number. It may also register itself as the handler for the
|
||||
interrupt level that the device uses. It may also send setup commands
|
||||
to the device, so you may see lights blink or something like that.
|
||||
</para>
|
||||
<para>
|
||||
You can see that a device driver has registered itself in the file
|
||||
<filename>/proc/devices</filename>. You can see that the device
|
||||
driver is handling the device's interrupts in
|
||||
<filename>/proc/interrupts</filename>.
|
||||
</para>
|
||||
<para>
|
||||
A nice device driver issues kernel messages telling what devices it
|
||||
found and is prepared to drive. (Kernel messages in most systems end
|
||||
up on the console and in the file
|
||||
<filename>/var/log/messages</filename>). Some drivers, however, are
|
||||
silent. A nice device driver also gives you (in kernel messages) some
|
||||
details of its search when it fails to find a device, but many just
|
||||
fail the load without explanation, and what you get is a list of
|
||||
guesses from <command>insmod</command> as to what the problem might
|
||||
have been.
|
||||
</para>
|
||||
<para>
|
||||
A network device (interface) driver works similarly, except that the
|
||||
LKM registers a device name of its choosing
|
||||
(e.g. <literal>eth0</literal>) rather than a major number. You can
|
||||
see the currently registered network device names in
|
||||
<filename>/proc/net/dev</filename>
|
||||
</para>
|
||||
<para>
|
||||
A filesystem driver, upon loading, registers itself as the driver for
|
||||
a filesystem type of a certain name. For example, the
|
||||
<literal>msdos</literal> driver registers itself as the driver for the
|
||||
filesystem type named <literal>msdos</literal>. (LKM authors typically
|
||||
name the LKM the same as the filesystem type it will drive).
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2 id="intelligent">
|
||||
<title>
|
||||
Intelligent Loading Of LKMs - Modprobe
|
||||
|
|
@ -667,12 +732,24 @@ have to have <filename>fat.o</filename> loaded before you can load
|
|||
The other major thing <command>modprobe</command> does for you is to
|
||||
find the object module containing the LKM given just the name of the
|
||||
LKM. For example, <command>modprobe msdos</command> might load
|
||||
<filename>/lib/2.4.2-2/fs/msdos.o</filename>. Check out the man pages
|
||||
<filename>/lib/2.4.2-2/fs/msdos.o</filename>.
|
||||
In fact, <command>modprobe</command>'s argument may be a totally
|
||||
symbolic name that you have associated with some actual module. For
|
||||
example, <command>modprobe eth0</command> loads the appropriate network
|
||||
device driver to create and drive your <literal>eth0</literal> device,
|
||||
assuming you set that up properly in <filename>modules.conf</filename>.
|
||||
Check out the man pages
|
||||
for <command>modprobe</command> and the configuration file
|
||||
<filename>modules.conf</filename> (usually
|
||||
<filename>/etc/modules.conf</filename>) for details on the search
|
||||
rules <command>modprobe</command> uses.
|
||||
</para>
|
||||
<para><command>modprobe</command> is especially important because it
|
||||
is by default the program that the kernel module loader uses to load
|
||||
an LKM on demand. So if you use automatic module loading, you will
|
||||
need to set up <filename>modules.conf</filename> properly or
|
||||
things will not work. See <xref linkend=autoload>.
|
||||
</para>
|
||||
<para>
|
||||
<command>depmod</command> scans your LKM object files (typically all
|
||||
the <filename>.o</filename> files in the appropriate <filename
|
||||
|
|
@ -713,9 +790,9 @@ Automatic Loading
|
|||
</title>
|
||||
<para>
|
||||
You can cause an LKM to be loaded automatically when the kernel first
|
||||
needs it. You do this with either a <literal>kerneld</literal> daemon
|
||||
or with the more recent invention, the kernel module loader, which is
|
||||
part of Linux.
|
||||
needs it. You do this with either the kernel module loader, which is
|
||||
part of the Linux kernel, or the
|
||||
older version of it, a <literal>kerneld</literal> daemon.
|
||||
</para>
|
||||
<para>
|
||||
As an example, let's say you run a program that executes an open
|
||||
|
|
@ -731,32 +808,22 @@ and uses it to cause the LKM to be loaded. The kernel then proceeds
|
|||
with the open.
|
||||
</para>
|
||||
<para>
|
||||
Both <literal>kerneld</literal> and the kernel module loader use
|
||||
Automatic kernel module loading is really not worth the complexity in most
|
||||
modern systems. It may make sense in a very small memory system, because
|
||||
you can keep parts of the kernel in memory only when you need them. But
|
||||
the amount of memory these modules uses is so cheap today that you will
|
||||
normally be a lot better off just loading all the modules you might need
|
||||
via startup scripts and leaving them loaded.
|
||||
</para>
|
||||
<para>
|
||||
Red Hat Linux uses automatic module loading via the kernel module loader.
|
||||
</para>
|
||||
<para>
|
||||
Both the kernel module loader and <literal>kerneld</literal> use
|
||||
<command>modprobe</command>, ergo <command>insmod</command>, to insert
|
||||
LKMs.
|
||||
LKMs. See <xref linkend=intelligent>.
|
||||
</para>
|
||||
|
||||
<sect4>
|
||||
<title>
|
||||
Kerneld
|
||||
</title>
|
||||
<para>
|
||||
<literal>kerneld</literal> is explained at length in the Kerneld
|
||||
mini-HOWTO, available from the <ulink URL="http://www.linuxdoc.org">Linux
|
||||
Documentation Project</ulink>.
|
||||
</para>
|
||||
<para>
|
||||
<literal>kerneld</literal> is a user process, which runs the
|
||||
<application>kerneld</application> program from the
|
||||
<application>modutils</application> package. <literal>kerneld</literal>
|
||||
sets up an IPC message channel with the kernel. When the kernel needs
|
||||
an LKM, it sends a message on that channel to <literal>kerneld</literal>
|
||||
and <literal>kerneld</literal> runs <command>modprobe</command>
|
||||
to load the LKM, then sends a message back to the kernel to say that it
|
||||
is done.
|
||||
</para>
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>
|
||||
Kernel Module Loader
|
||||
|
|
@ -786,7 +853,7 @@ $ echo "sbin/mymodprobe" >/proc/sys/kernel/modprobe
|
|||
</screen>
|
||||
</para>
|
||||
<para>
|
||||
The kernel module loader passes the following arguments to
|
||||
The kernel module loader passes the following arguments to the
|
||||
<command>modprobe</command>: Argument Zero is the full file name of
|
||||
<command>modprobe</command>. The regular arguments are
|
||||
<literal>-s</literal>, <literal>-k</literal>, and the name of the LKM
|
||||
|
|
@ -796,6 +863,62 @@ cryptic way to say <literal>--autoclean</literal>. I.e. messages
|
|||
from <command>modprobe</command> will go to syslog and the loaded
|
||||
LKM will have the "autoclean" flag set.
|
||||
</para>
|
||||
<para>
|
||||
The most important part of the <command>modprobe</command> invocation
|
||||
is, of course, the module name. Note that the "module name"
|
||||
argument to <command>modprobe</command> is not necessarily a real
|
||||
module name. It is often a symbolic name representing the role that
|
||||
module plays and you use an <literal>alias</literal> statement in
|
||||
<filename>modules.conf</filename> to tell what LKM gets loaded.
|
||||
For example, if your Ethernet adapter requires the <literal>3c59x</literal>
|
||||
LKM, you would have probably need the line
|
||||
<screen>
|
||||
alias eth0 3c59x
|
||||
</screen>
|
||||
in <filename>/etc/modules.conf</filename>.
|
||||
Here
|
||||
is what the kernel module loader uses for a module name in some of the
|
||||
more popular cases (there are about 20 cases in which the kernel calls
|
||||
on the kernel module loader to load a module):
|
||||
<itemizedlist>
|
||||
<listitem><para>When you try access a device and no device driver has
|
||||
registered to serve that device's major number, the kernel requests
|
||||
the module by the name
|
||||
<filename>block-major-</filename><varname>N</varname> or
|
||||
<filename>char-major-</filename><varname>N</varname> where
|
||||
<varname>N</varname> is the major number in decimal without leading
|
||||
zeroes. </para></listitem>
|
||||
|
||||
<listitem><para>When you try to access a network interface (maybe by running
|
||||
<command>ifconfig</command> against it) and no network device driver
|
||||
has registered to serve an interface by that name, the kernel requests
|
||||
the module named the same as the interface name
|
||||
(e.g. <literal>eth0</literal>). This applies to drivers for non-physical
|
||||
interfaces such as <literal>ppp0</literal> as well.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>When you try to access a socket in a protocol family which no
|
||||
protocol driver has registered to drive, the kernel requests the
|
||||
module named <filename>net-pf-</filename><varname>N</varname>, where
|
||||
<varname>N</varname> is the protocol family number (in decimal without
|
||||
leading zeroes).
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>When you try to NFS export a directory or otherwise
|
||||
access the NFS server via the NFS system call, the kernel requests the
|
||||
module named <filename>nfsd</filename>. </para></listitem>
|
||||
|
||||
<listitem><para>The ATA device driver (named <filename>ide</filename>)
|
||||
loads the relevant drivers for classes of ATA devices by the names:
|
||||
<filename>ide-disk</filename>, <filename>ide-cd</filename>,
|
||||
<filename>ide-floppy</filename>, <filename>ide-tape</filename>, and
|
||||
<filename>ide-scsi</filename>. </para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
The kernel module loader runs <command>modprobe</command> with the
|
||||
following environment variables (only): HOME=<literal>/</literal>;
|
||||
|
|
@ -822,6 +945,28 @@ hardcoded. You may prefer to use <literal>kerneld</literal> instead,
|
|||
or not bother with automatic loading of LKMs at all.
|
||||
</para>
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>
|
||||
Kerneld
|
||||
</title>
|
||||
<para>
|
||||
<literal>kerneld</literal> is explained at length in the Kerneld
|
||||
mini-HOWTO, available from the <ulink URL="http://www.linuxdoc.org">Linux
|
||||
Documentation Project</ulink>.
|
||||
</para>
|
||||
<para>
|
||||
<literal>kerneld</literal> is a user process, which runs the
|
||||
<application>kerneld</application> program from the
|
||||
<application>modutils</application> package. <literal>kerneld</literal>
|
||||
sets up an IPC message channel with the kernel. When the kernel needs
|
||||
an LKM, it sends a message on that channel to <literal>kerneld</literal>
|
||||
and <literal>kerneld</literal> runs <command>modprobe</command>
|
||||
to load the LKM, then sends a message back to the kernel to say that it
|
||||
is done.
|
||||
</para>
|
||||
</sect4>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -2743,12 +2888,12 @@ This driver atoprobes the card and requires installed BIOS.
|
|||
|
||||
<sect3>
|
||||
<title>
|
||||
aha154x: SCSI low-level driver for Adaptec AHA152X/2825
|
||||
aha152x: SCSI low-level driver for Adaptec AHA152X/2825
|
||||
</title>
|
||||
<para>
|
||||
Example:
|
||||
<screen>
|
||||
modprobe aha154x
|
||||
modprobe aha152x
|
||||
</screen>
|
||||
</para>
|
||||
<para>
|
||||
|
|
|
|||
Loading…
Reference in New Issue