diff options
Diffstat (limited to 'docs/docbook/projdoc/Integrating-with-Windows.xml')
| -rw-r--r-- | docs/docbook/projdoc/Integrating-with-Windows.xml | 712 |
1 files changed, 0 insertions, 712 deletions
diff --git a/docs/docbook/projdoc/Integrating-with-Windows.xml b/docs/docbook/projdoc/Integrating-with-Windows.xml deleted file mode 100644 index ae78e20276..0000000000 --- a/docs/docbook/projdoc/Integrating-with-Windows.xml +++ /dev/null @@ -1,712 +0,0 @@ -<chapter id="integrate-ms-networks"> - -<chapterinfo> - &author.jht; - <pubdate> (Jan 01 2001) </pubdate> -</chapterinfo> - -<title>Integrating MS Windows Networks with Samba</title> - -<para> -<indexterm><primary>NetBIOS</primary></indexterm> -This section deals with NetBIOS over TCP/IP name to IP address resolution. If -your MS Windows clients are not configured to use NetBIOS over TCP/IP, then this -section does not apply to your installation. If your installation -involves the use of -NetBIOS over TCP/IP then this section may help you to resolve networking problems. -</para> - -<note> -<para> -NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS -over Logical Link Control (LLC). On modern networks it is highly advised -to not run NetBEUI at all. Note also there is no such thing as -NetBEUI over TCP/IP &smbmdash; the existence of such a protocol is a complete -and utter misapprehension. -</para> -</note> - -<sect1> -<title>Features and Benefits</title> - -<para> -Many MS Windows network administrators have never been exposed to basic TCP/IP -networking as it is implemented in a UNIX/Linux operating system. Likewise, many UNIX and -Linux administrators have not been exposed to the intricacies of MS Windows TCP/IP-based -networking (and may have no desire to be either). -</para> - -<para> -This chapter gives a short introduction to the basics of how a name can be resolved to -its IP address for each operating system environment. -</para> - -</sect1> - -<sect1> -<title>Background Information</title> - -<para> -Since the introduction of MS Windows 2000, it is possible to run MS Windows networking -without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS -name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over -TCP/IP is disabled on MS Windows 2000 and later clients, then only the TCP port 445 will be -used and the UDP port 137 and TCP port 139 will not. -</para> - -<note> -<para> -When using Windows 2000 or later clients, if NetBIOS over TCP/IP is not disabled, then -the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet -Name Service or WINS), TCP port 139 and TCP port 445 (for actual file and print traffic). -</para> -</note> - -<para> -When NetBIOS over TCP/IP is disabled, the use of DNS is essential. Most installations that -disable NetBIOS over TCP/IP today use MS Active Directory Service (ADS). ADS requires -<indexterm><primary>DNS</primary><secondary>Dynamic</secondary></indexterm> -Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR). -<indexterm><primary>DHCP</primary></indexterm> -Use of DHCP with ADS is recommended as a further means of maintaining central control -over the client workstation network configuration. -</para> - -</sect1> - -<sect1> -<title>Name Resolution in a Pure UNIX/Linux World</title> - -<para> -The key configuration files covered in this section are: -</para> - -<itemizedlist> - <listitem><para><filename>/etc/hosts</filename></para></listitem> - <listitem><para><filename>/etc/resolv.conf</filename></para></listitem> - <listitem><para><filename>/etc/host.conf</filename></para></listitem> - <listitem><para><filename>/etc/nsswitch.conf</filename></para></listitem> -</itemizedlist> - -<sect2> -<title><filename>/etc/hosts</filename></title> - -<para> -This file contains a static list of IP addresses and names. -</para> -<para><programlisting> -127.0.0.1 localhost localhost.localdomain -192.168.1.1 bigbox.quenya.org bigbox alias4box -</programlisting></para> - -<para> -The purpose of <filename>/etc/hosts</filename> is to provide a -name resolution mechanism so uses do not need to remember -IP addresses. -</para> - -<para> -Network packets that are sent over the physical network transport -layer communicate not via IP addresses but rather using the Media -Access Control address, or MAC address. IP addresses are currently -32 bits in length and are typically presented as four (4) decimal -numbers that are separated by a dot (or period). For example, 168.192.1.1. -</para> - -<para> -<indexterm><primary>MAC Addresses</primary></indexterm> -MAC Addresses use 48 bits (or 6 bytes) and are typically represented -as two-digit hexadecimal numbers separated by colons: 40:8e:0a:12:34:56. -</para> - -<para> -Every network interface must have a MAC address. Associated with -a MAC address may be one or more IP addresses. There is no -relationship between an IP address and a MAC address; all such assignments -are arbitrary or discretionary in nature. At the most basic level, all -network communications take place using MAC addressing. Since MAC -addresses must be globally unique and generally remain fixed for -any particular interface, the assignment of an IP address makes sense -from a network management perspective. More than one IP address can -be assigned per MAC address. One address must be the primary IP -address &smbmdash; -this is the address that will be returned in the ARP reply. -</para> - -<para> -When a user or a process wants to communicate with another machine, -the protocol implementation ensures that the <quote>machine name</quote> or <quote>host -name</quote> is resolved to an IP address in a manner that is controlled -by the TCP/IP configuration control files. The file -<filename>/etc/hosts</filename> is one such file. -</para> - -<para> -When the IP address of the destination interface has been -determined, a protocol called ARP/RARP is used to identify -the MAC address of the target interface. ARP stands for Address -Resolution Protocol and is a broadcast-oriented method that -uses User Datagram Protocol (UDP) to send a request to all -interfaces on the local network segment using the all 1s MAC -address. Network interfaces are programmed to respond to two -MAC addresses only; their own unique address and the address -ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will -contain the MAC address and the primary IP address for each -interface. -</para> - -<para> -<indexterm><primary>/etc/hosts</primary></indexterm> -The <filename>/etc/hosts</filename> file is foundational to all -UNIX/Linux TCP/IP installations and as a minimum will contain -the localhost and local network interface IP addresses and the -primary names by which they are known within the local machine. -This file helps to prime the pump so a basic level of name -resolution can exist before any other method of name resolution -becomes available. -</para> - -</sect2> - - -<sect2> -<title><filename>/etc/resolv.conf</filename></title> - -<para> -This file tells the name resolution libraries: -</para> - -<itemizedlist> - <listitem><para>The name of the domain to which the machine - belongs. - </para></listitem> - - <listitem><para>The name(s) of any domains that should be - automatically searched when trying to resolve unqualified - host names to their IP address. - </para></listitem> - - <listitem><para>The name or IP address of available Domain - Name Servers that may be asked to perform name-to-address - translation lookups. - </para></listitem> -</itemizedlist> - -</sect2> - - -<sect2> -<title><filename>/etc/host.conf</filename></title> - - -<para> -<indexterm><primary>/etc/host.conf</primary></indexterm> -<filename>/etc/host.conf</filename> is the primary means by -which the setting in <filename>/etc/resolv.conf</filename> may be effected. It is a -critical configuration file. This file controls the order by -which name resolution may proceed. The typical structure is: -</para> - -<para><programlisting> -order hosts,bind -multi on -</programlisting></para> - -<para> -then both addresses should be returned. Please refer to the -man page for <filename>host.conf</filename> for further details. -</para> - - -</sect2> - - - -<sect2> -<title><filename>/etc/nsswitch.conf</filename></title> - - -<para> -<indexterm><primary>/etc/nsswitch.conf</primary></indexterm> -This file controls the actual name resolution targets. The -file typically has resolver object specifications as follows: -</para> - - -<para><programlisting> -# /etc/nsswitch.conf -# -# Name Service Switch configuration file. -# - -passwd: compat -# Alternative entries for password authentication are: -# passwd: compat files nis ldap winbind -shadow: compat -group: compat - -hosts: files nis dns -# Alternative entries for host name resolution are: -# hosts: files dns nis nis+ hesiod db compat ldap wins -networks: nis files dns - -ethers: nis files -protocols: nis files -rpc: nis files -services: nis files -</programlisting></para> - -<para> -Of course, each of these mechanisms requires that the appropriate -facilities and/or services are correctly configured. -</para> - -<para> -It should be noted that unless a network request/message must be -sent, TCP/IP networks are silent. All TCP/IP communications assume a -principal of speaking only when necessary. -</para> - - -<para> -<indexterm><primary>libnss_wins.so</primary></indexterm> -Starting with version 2.2.0, Samba has Linux support for extensions to -the name service switch infrastructure so Linux clients will -be able to obtain resolution of MS Windows NetBIOS names to IP -Addresses. To gain this functionality, Samba needs to be compiled -with appropriate arguments to the make command (i.e., <userinput>make -nsswitch/libnss_wins.so</userinput>). The resulting library should -then be installed in the <filename>/lib</filename> directory and -the <parameter>wins</parameter> parameter needs to be added to the <quote>hosts:</quote> line in -the <filename>/etc/nsswitch.conf</filename> file. At this point, it -will be possible to ping any MS Windows machine by its NetBIOS -machine name, as long as that machine is within the workgroup to -which both the Samba machine and the MS Windows machine belong. -</para> - -</sect2> -</sect1> - - -<sect1> -<title>Name Resolution as Used within MS Windows Networking</title> - -<para> -MS Windows networking is predicated about the name each machine -is given. This name is known variously (and inconsistently) as -the <quote>computer name,</quote> <quote>machine name,</quote> <quote>networking name,</quote> <quote>netbios name,</quote> -or <quote>SMB name.</quote> All terms mean the same thing with the exception of -<quote>netbios name</quote> that can also apply to the name of the workgroup or the -domain name. The terms <quote>workgroup</quote> and <quote>domain</quote> are really just a -simple name with which the machine is associated. All NetBIOS names -are exactly 16 characters in length. The 16<superscript>th</superscript> character is reserved. -It is used to store a one-byte value that indicates service level -information for the NetBIOS name that is registered. A NetBIOS machine -name is, therefore, registered for each service type that is provided by -the client/server. -</para> - -<para> -<link linkend="uniqnetbiosnames"/> and <link linkend="netbiosnamesgrp"/> list typical NetBIOS name/service type registrations. -</para> - -<table frame="all" id="uniqnetbiosnames"> -<title>Unique NetBIOS Names</title> -<tgroup cols="2"> -<colspec align="left"/> -<colspec align="justify"/> -<tbody> -<row><entry>MACHINENAME<00></entry><entry>Server Service is running on MACHINENAME</entry></row> -<row><entry>MACHINENAME<03></entry><entry>Generic Machine Name (NetBIOS name)</entry></row> -<row><entry>MACHINENAME<20></entry><entry>LanMan Server service is running on MACHINENAME</entry></row> -<row><entry>WORKGROUP<1b></entry><entry>Domain Master Browser</entry></row> -</tbody> -</tgroup> -</table> - -<table frame="all" id="netbiosnamesgrp"> -<title>Group Names</title> -<tgroup cols="2"> -<colspec align="left"/> -<colspec align="justify"/> -<tbody> -<row><entry>WORKGROUP<03></entry><entry>Generic Name registered by all members of WORKGROUP</entry></row> -<row><entry>WORKGROUP<1c></entry><entry>Domain Controllers / Netlogon Servers</entry></row> -<row><entry>WORKGROUP<1d></entry><entry>Local Master Browsers</entry></row> -<row><entry>WORKGROUP<1e></entry><entry>Internet Name Resolvers</entry></row> -</tbody> -</tgroup> -</table> - -<para> -<indexterm><primary>NetBIOS</primary></indexterm> -It should be noted that all NetBIOS machines register their own -names as per the above. This is in vast contrast to TCP/IP -installations where traditionally the system administrator will -determine in the <filename>/etc/hosts</filename> or in the DNS database what names -are associated with each IP address. -</para> - -<para> -<indexterm><primary>NetBIOS</primary></indexterm> -One further point of clarification should be noted. The <filename>/etc/hosts</filename> -file and the DNS records do not provide the NetBIOS name type information -that MS Windows clients depend on to locate the type of service that may -be needed. An example of this is what happens when an MS Windows client -wants to locate a domain logon server. It finds this service and the IP -address of a server that provides it by performing a lookup (via a -NetBIOS broadcast) for enumeration of all machines that have -registered the name type *<1c>. A logon request is then sent to each -IP address that is returned in the enumerated list of IP addresses. -Whichever machine first replies, it then ends up providing the logon services. -</para> - -<para> -The name <quote>workgroup</quote> or <quote>domain</quote> really can be confusing since these -have the added significance of indicating what is the security -architecture of the MS Windows network. The term <quote>workgroup</quote> indicates -that the primary nature of the network environment is that of a -peer-to-peer design. In a WORKGROUP, all machines are responsible for -their own security, and generally such security is limited to the use of -just a password (known as Share Level security). In most situations -with peer-to-peer networking, the users who control their own machines -will simply opt to have no security at all. It is possible to have -User Level Security in a WORKGROUP environment, thus requiring the use -of a user name and a matching password. -</para> - -<para> -MS Windows networking is thus predetermined to use machine names -for all local and remote machine message passing. The protocol used is -called Server Message Block (SMB) and this is implemented using -the NetBIOS protocol (Network Basic Input Output System). NetBIOS can -be encapsulated using LLC (Logical Link Control) protocol &smbmdash; in which case -the resulting protocol is called NetBEUI (Network Basic Extended User -Interface). NetBIOS can also be run over IPX (Internetworking Packet -Exchange) protocol as used by Novell NetWare, and it can be run -over TCP/IP protocols &smbmdash; in which case the resulting protocol is called -NBT or NetBT, the NetBIOS over TCP/IP. -</para> - -<para> -MS Windows machines use a complex array of name resolution mechanisms. -Since we are primarily concerned with TCP/IP, this demonstration is -limited to this area. -</para> - -<sect2> -<title>The NetBIOS Name Cache</title> - -<para> -All MS Windows machines employ an in-memory buffer in which is -stored the NetBIOS names and IP addresses for all external -machines that machine has communicated with over the -past 10-15 minutes. It is more efficient to obtain an IP address -for a machine from the local cache than it is to go through all the -configured name resolution mechanisms. -</para> - -<para> -If a machine whose name is in the local name cache has been shut -down before the name had been expired and flushed from the cache, then -an attempt to exchange a message with that machine will be subject -to time-out delays. Its name is in the cache, so a name resolution -lookup will succeed, but the machine cannot respond. This can be -frustrating for users but is a characteristic of the protocol. -</para> - -<para> -<indexterm><primary>nbtstat</primary></indexterm> -<indexterm><primary>nmblookup</primary></indexterm> -The MS Windows utility that allows examination of the NetBIOS -name cache is called <quote>nbtstat</quote>. The Samba equivalent of this -is called <command>nmblookup</command>. -</para> - -</sect2> - -<sect2> -<title>The LMHOSTS File</title> - -<para> -<indexterm><primary>LMHOSTS</primary></indexterm> -This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in the directory -<filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains the IP Address -and the machine name in matched pairs. The <filename>LMHOSTS</filename> file -performs NetBIOS name to IP address mapping. -</para> - -<para> -It typically looks like this: -</para> - -<para><programlisting> -# Copyright (c) 1998 Microsoft Corp. -# -# This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS -# over TCP/IP) stack for Windows98 -# -# This file contains the mappings of IP addresses to NT computernames -# (NetBIOS) names. Each entry should be kept on an individual line. -# The IP address should be placed in the first column followed by the -# corresponding computername. The address and the computername -# should be separated by at least one space or tab. The "#" character -# is generally used to denote the start of a comment (see the exceptions -# below). -# -# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts -# files and offers the following extensions: -# -# #PRE -# #DOM:<domain> -# #INCLUDE <filename> -# #BEGIN_ALTERNATE -# #END_ALTERNATE -# \0xnn (non-printing character support) -# -# Following any entry in the file with the characters "#PRE" will cause -# the entry to be preloaded into the name cache. By default, entries are -# not preloaded, but are parsed only after dynamic name resolution fails. -# -# Following an entry with the "#DOM:<domain>" tag will associate the -# entry with the domain specified by <domain>. This effects how the -# browser and logon services behave in TCP/IP environments. To preload -# the host name associated with #DOM entry, it is necessary to also add a -# #PRE to the line. The <domain> is always preloaded although it will not -# be shown when the name cache is viewed. -# -# Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT) -# software to seek the specified <filename> and parse it as if it were -# local. <filename> is generally a UNC-based name, allowing a -# centralized lmhosts file to be maintained on a server. -# It is ALWAYS necessary to provide a mapping for the IP address of the -# server prior to the #INCLUDE. This mapping must use the #PRE directive. -# In addition the share "public" in the example below must be in the -# LanManServer list of "NullSessionShares" in order for client machines to -# be able to read the lmhosts file successfully. This key is under -# \machine\system\currentcontrolset\services\lanmanserver\ -# parameters\nullsessionshares -# in the registry. Simply add "public" to the list found there. -# -# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE -# statements to be grouped together. Any single successful include -# will cause the group to succeed. -# -# Finally, non-printing characters can be embedded in mappings by -# first surrounding the NetBIOS name in quotations, then using the -# \0xnn notation to specify a hex value for a non-printing character. -# -# The following example illustrates all of these extensions: -# -# 102.54.94.97 rhino #PRE #DOM:networking #net group's DC -# 102.54.94.102 "appname \0x14" #special app server -# 102.54.94.123 popular #PRE #source server -# 102.54.94.117 localsrv #PRE #needed for the include -# -# #BEGIN_ALTERNATE -# #INCLUDE \\localsrv\public\lmhosts -# #INCLUDE \\rhino\public\lmhosts -# #END_ALTERNATE -# -# In the above example, the "appname" server contains a special -# character in its name, the "popular" and "localsrv" server names are -# preloaded, and the "rhino" server name is specified so it can be used -# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv" -# system is unavailable. -# -# Note that the whole file is parsed including comments on each lookup, -# so keeping the number of comments to a minimum will improve performance. -# Therefore it is not advisable to simply add lmhosts file entries onto the -# end of this file. -</programlisting></para> - -</sect2> - -<sect2> -<title>HOSTS File</title> - -<para> -This file is usually located in MS Windows NT 4.0 or Windows 200x/XP in -the directory <filename>C:\WINNT\SYSTEM32\DRIVERS\ETC</filename> and contains -the IP Address and the IP hostname in matched pairs. It can be -used by the name resolution infrastructure in MS Windows, depending -on how the TCP/IP environment is configured. This file is in -every way the equivalent of the UNIX/Linux <filename>/etc/hosts</filename> file. -</para> -</sect2> - - -<sect2> -<title>DNS Lookup</title> - - -<para> -<indexterm><primary>DNS</primary></indexterm> -This capability is configured in the TCP/IP setup area in the network -configuration facility. If enabled, an elaborate name resolution sequence -is followed, the precise nature of which is dependant on how the NetBIOS -Node Type parameter is configured. A Node Type of 0 means that -NetBIOS broadcast (over UDP broadcast) is used if the name -that is the subject of a name lookup is not found in the NetBIOS name -cache. If that fails then DNS, HOSTS and LMHOSTS are checked. If set to -Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the -WINS Server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast -lookup is used. -</para> - -</sect2> - -<sect2> -<title>WINS Lookup</title> - - -<para> -<indexterm><primary>WINS</primary></indexterm> -A WINS (Windows Internet Name Server) service is the equivalent of the -rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores -the names and IP addresses that are registered by a Windows client -if the TCP/IP setup has been given at least one WINS Server IP Address. -</para> - -<para> -To configure Samba to be a WINS server, the following parameter needs -to be added to the &smb.conf; file: -</para> - -<para><smbconfblock> -<smbconfoption><name>wins support</name><value>Yes</value></smbconfoption> -</smbconfblock></para> - -<para> -To configure Samba to use a WINS server, the following parameters are -needed in the &smb.conf; file: -</para> - -<para><smbconfblock> -<smbconfoption><name>wins support</name><value>No</value></smbconfoption> -<smbconfoption><name>wins server</name><value>xxx.xxx.xxx.xxx</value></smbconfoption> -</smbconfblock></para> - -<para> -where <replaceable>xxx.xxx.xxx.xxx</replaceable> is the IP address -of the WINS server. -</para> - -<para>For information about setting up Samba as a WINS server, read -<link linkend="NetworkBrowsing"/>.</para> - -</sect2> -</sect1> - -<sect1> -<title>Common Errors</title> - -<para> -TCP/IP network configuration problems find every network administrator sooner or later. -The cause can be anything from keyboard mishaps, forgetfulness, simple mistakes, and -carelessness. Of course, no one is ever deliberately careless! -</para> - - <sect2> - <title>Pinging Works Only in One Way</title> - - <para> - <quote>I can ping my Samba server from Windows, but I cannot ping my Windows - machine from the Samba server.</quote> - </para> - - <para> - <emphasis>Answer:</emphasis> The Windows machine was at IP Address 192.168.1.2 with netmask 255.255.255.0, the - Samba server (Linux) was at IP Address 192.168.1.130 with netmask 255.255.255.128. - The machines were on a local network with no external connections. - </para> - - <para> - Due to inconsistent netmasks, the Windows machine was on network 192.168.1.0/24, while - the Samba server was on network 192.168.1.128/25 &smbmdash; logically a different network. - </para> - - </sect2> - - <sect2> - <title>Very Slow Network Connections</title> - - <para> - A common cause of slow network response includes: - </para> - - <itemizedlist> - <listitem><para>Client is configured to use DNS and the DNS server is down.</para></listitem> - <listitem><para>Client is configured to use remote DNS server, but the - remote connection is down.</para></listitem> - <listitem><para>Client is configured to use a WINS server, but there is no WINS server.</para></listitem> - <listitem><para>Client is not configured to use a WINS server, but there is a WINS server.</para></listitem> - <listitem><para>Firewall is filtering our DNS or WINS traffic.</para></listitem> - </itemizedlist> - - </sect2> - - <sect2> - <title>Samba Server Name Change Problem</title> - - <para> - <quote>The name of the Samba server was changed, Samba was restarted, Samba server cannot be - pinged by new name from MS Windows NT4 Workstation, but it does still respond to ping using - the old name. Why?</quote> - </para> - - <para> - From this description, three things are obvious: - </para> - - <itemizedlist> - <listitem><para>WINS is not in use, only broadcast-based name resolution is used.</para></listitem> - <listitem><para>The Samba server was renamed and restarted within the last 10-15 minutes.</para></listitem> - <listitem><para>The old Samba server name is still in the NetBIOS name cache on the MS Windows NT4 Workstation.</para></listitem> - </itemizedlist> - - <para> - To find what names are present in the NetBIOS name cache on the MS Windows NT4 machine, - open a <command>cmd</command> shell and then: - </para> - - <para> -<screen> -&dosprompt;<userinput>nbtstat -n</userinput> - - NetBIOS Local Name Table - - Name Type Status ------------------------------------------------- -&example.workstation.windows; <03> UNIQUE Registered -ADMINSTRATOR <03> UNIQUE Registered -&example.workstation.windows; <00> UNIQUE Registered -SARDON <00> GROUP Registered -&example.workstation.windows; <20> UNIQUE Registered -&example.workstation.windows; <1F> UNIQUE Registered - - -&dosprompt;nbtstat -c - - NetBIOS Remote Cache Name Table - - Name Type Host Address Life [sec] --------------------------------------------------------------- -&example.server.samba; <20> UNIQUE 192.168.1.1 240 - -&dosprompt; -</screen> - </para> - - <para> - In the above example, &example.server.samba; is the Samba server and &example.workstation.windows; is the MS Windows NT4 Workstation. - The first listing shows the contents of the Local Name Table (i.e., Identity information on - the MS Windows workstation) and the second shows the NetBIOS name in the NetBIOS name cache. - The name cache contains the remote machines known to this workstation. - </para> - - </sect2> - -</sect1> - -</chapter> |