mirror of https://github.com/tLDP/LDP
1928 lines
78 KiB
Plaintext
1928 lines
78 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<!-- This is the Linux IPX-HOWTO, please forward any comments or suggestions
|
|
to the author: kevin@pricetrak.com
|
|
-->
|
|
|
|
<article>
|
|
|
|
<!-- Title information -->
|
|
|
|
<title>Linux IPX-HOWTO
|
|
<author>Kevin Thorpe, <tt/kevin@pricetrak.com/
|
|
<date>v2.3, 06 May 1998
|
|
|
|
<abstract>
|
|
This document aims to describe how to obtain, install and configure various
|
|
tools available for the Linux Operating System that use the Linux Kernel
|
|
IPX protocol support.
|
|
</abstract>
|
|
|
|
<!-- Table of contents -->
|
|
<toc>
|
|
|
|
<!-- Begin the document -->
|
|
|
|
<sect><heading>Introduction.
|
|
<p>
|
|
This is the Linux IPX-HOWTO. You should read the Linux NET-3-HOWTO in
|
|
conjunction with this document.
|
|
|
|
<sect1><heading>Changes from the previous release.
|
|
<p>
|
|
|
|
<verb>
|
|
Change of author:
|
|
Many thanks to Terry Dawson for passing on this document and
|
|
congratulations on becoming a father :-).
|
|
|
|
Additions:
|
|
Addition of a brief explanation of IPX. This is in response to
|
|
many baffled queries on the discussion lists.
|
|
|
|
Corrections/Updates:
|
|
New version of ncpfs which now supports NDS logins. This is early
|
|
beta test and may be prohibited in your country due to the use of
|
|
patented technology.
|
|
|
|
Addition of support for trustee rights in mars_nwe. This is still
|
|
in beta test.
|
|
</verb>
|
|
|
|
<sect1><heading>Introduction.
|
|
<p>
|
|
The Linux Kernel has a completely new network implementation as compared
|
|
to other Unix like operating systems. The ability to take a fresh approach
|
|
to developing the kernel networking software has led to the Linux kernel
|
|
having support for a range of non tcp/ip protocols being built. The IPX
|
|
protocol is one of those that have been included.
|
|
|
|
The Linux kernel supports the IPX protocol only. It does not yet support
|
|
protocols such as IPX/RIP, SAP or NCP, these are supported by other software
|
|
such as that documented elsewhere in this document.
|
|
|
|
The IPX support was originally developed by Alan Cox
|
|
<tt/<alan@lxorguk.ukuu.org.uk>/ and has been significantly enhanced by
|
|
Greg Page <tt/<greg@caldera.com>/.
|
|
|
|
<sect><heading>Disclaimer.
|
|
<p>
|
|
I do not and cannot know everything there is to know about the Linux network
|
|
software. Please accept and be warned that this document probably does contain
|
|
errors. Please read any README files that are included with any of the various
|
|
pieces of software described in this document for more detailed and accurate
|
|
information. I will attempt to keep this document as error-free and up-to-date
|
|
as possible. Versions of software are current as at time of writing.
|
|
<p>
|
|
In no way do I or the authors of the software in this document offer protection
|
|
against your own actions. If you configure this software, even as described in
|
|
this document and it causes problems on your network then you alone must
|
|
carry the responsibility. I include this warning because IPX network design
|
|
and configuration is not always a simple matter and sometimes undesirable
|
|
interaction with other routers and fileservers can result if you do not design
|
|
or configure your network carefully. I also include this warning because I
|
|
was asked to by someone unfortunate enough to have discovered this lesson the
|
|
hard way.
|
|
|
|
<sect><heading>Related Documentation.
|
|
<p>
|
|
This document presumes you understand how to build a Linux kernel with
|
|
the appropriate networking options selected and that you understand how
|
|
to use the basic network tools such as <em>ifconfig</em> and <em>route</em>.
|
|
If you do not, then you should read the
|
|
<url url="NET-3-HOWTO.html" name="NET-3-HOWTO">
|
|
in conjunction with this document as it describes these.
|
|
<p>
|
|
Other Linux HOWTO documents that might be useful are:
|
|
<p>
|
|
The
|
|
<url url="Ethernet-HOWTO.html" name="Ethernet-HOWTO">,
|
|
which describes the details of configuring an Ethernet device for Linux.
|
|
|
|
The <url url="PPP-HOWTO.html" name="PPP-HOWTO">
|
|
as IPX support is available for version 2.2.0d and later of the Linux PPP
|
|
implementation.
|
|
|
|
<sect1><heading>New versions of this document.
|
|
<p>
|
|
If your copy of this document is more than two months old then I strongly
|
|
recommend you obtain a newer version. The networking support for Linux is
|
|
changing very rapidly with new enhancements and features, so this document
|
|
also changes fairly frequently. The latest released version of this document
|
|
can always be retrieved by anonymous ftp from:
|
|
|
|
<tt/ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/IPX-HOWTO>/
|
|
or:
|
|
<tt/ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/other-formats/IPX-HOWTO{-html.tar,ps,dvi}.gz>/
|
|
via the World Wide Web from the
|
|
<url url="http://sunsite.unc.edu/LDP/linux.html"
|
|
name="Linux Documentation Project Web Server">, at page:
|
|
<url url="http://sunsite.unc.edu/LDP/HOWTO/IPX-HOWTO.html" name="IPX-HOWTO">
|
|
or directly from me, <tt/<kevin@pricetrak.com>/. It may
|
|
also be posted to the newsgroups: <tt/comp.os.linux.networking/,
|
|
<tt/comp.os.linux.answers/ and <tt/news.answers/ from time to time.
|
|
|
|
<sect1><heading>Feedback.
|
|
<p>
|
|
Please send any comments, updates, or suggestions to me,
|
|
<tt/<kevin@pricetrak.com>/. The sooner I get feedback, the
|
|
sooner I can update and correct this document. If you find any problems
|
|
with it, please mail me directly as I can miss info posted to the newsgroups.
|
|
|
|
<sect1><heading>Mailing list support.
|
|
<p>
|
|
There is a mailing list established for discussion of the various Linux
|
|
IPX software packages described in this document. You can subscribe to it
|
|
by sending a mail message to <tt/`listserv@sh.cvut.cz'/ with
|
|
<tt/`add linware'/ in the body of the message. To post to the list your
|
|
send your mail to <tt/`linware@sh.cvut.cz'/. I regularly watch this list.
|
|
<p>
|
|
The mailing list is archived at
|
|
<url url="http://www.kin.vslib.cz/hypermail/linware/" name="www.kin.vslib.cz">.
|
|
|
|
<sect><heading>Some of the terms used in this document.
|
|
<p>
|
|
You will often see the terms <tt/client/ and <tt/server/ used in this
|
|
document. They are normally fairly specific terms but in this document I have
|
|
generalized their definitions a little so that they mean the following:
|
|
<descrip>
|
|
<tag>client</tag>The machine or program that initiates an action or a
|
|
connection for the purpose of gaining use of some service or data.
|
|
<tag>server</tag>The machine or program that accepts incoming connections from
|
|
multiple remote machines and provides a service or data to those.
|
|
</descrip>
|
|
|
|
These definitions are not very reliable either, but they provide a means of
|
|
distinguishing the ends of peer to peer systems such as <em>SLIP</em> or
|
|
<em>PPP</em> which truly do not actually have clients and servers.
|
|
<p>
|
|
Other terms you will see are:
|
|
<descrip>
|
|
<tag/Bindery/The <em/bindery/ is a specialised database storing network
|
|
configuration information on a Novell fileserver. Netware clients may query
|
|
the <em/bindery/ to obtain information on available services, routing and
|
|
user information.
|
|
<tag/Frame Type/is a term used to describe that actual protocol used to carry
|
|
the IPX (and IP) datagrams across your ethernet style network segments. There
|
|
are four common ones. They are:
|
|
<descrip>
|
|
<tag>Ethernet_II</tag>This is a refined version of the original DIX ethernet
|
|
standard. Novell has been allocated a formal protocol id and this means that
|
|
both IPX and IP can coexist happily in an Ethernet_II environment quite
|
|
happily. This is commonly used in Novell environments and is a good choice.
|
|
<tag>802.3</tag>This is an I.E.E.E. protocol defining a Carrier Sense
|
|
Multiple Access with Collision Detection (CSMA/CD) mechanism. It was based
|
|
on the original DIX Ethernet standard, with an important modification, the
|
|
type (protocol id) field was converted into a length field instead. It is
|
|
for this reason that IPX really shouldn't be run here. IEEE 802.3 was designed
|
|
to carry IEEE 802.2 frames <bf>only</bf> but there are implementations that use
|
|
it to carry IPX frames directly and remarkably it does work. Avoid it unless
|
|
you are trying to interwork with a network already configured to use it.
|
|
<tag>802.2</tag>This is an I.E.E.E. protocol that defines a set of Logical Link
|
|
Control procedures. It provides a simplistic way of allowing different
|
|
protocols to coexist, but is quite limited in this respect. Novell uses an
|
|
unofficial Service Address Point (like a protocol id) but since everyone else
|
|
uses it as well, that hasn't yet presented too much of a problem.
|
|
<tag>SNAP</tag>SNAP is the Sub Network Access Protocol. This protocol is
|
|
designed ride on top of 802.3 and 802.2. It expands the multiprotocol
|
|
capability of 802.2 and provides some measure of compatability with existing
|
|
Ethernet and Ethernet_II frame types.
|
|
</descrip>
|
|
|
|
<tag/IPX/Internet Packet eXchange is a protocol used by the Novell
|
|
corporation to provide internetworking support for their NetWare(tm) product.
|
|
IPX is similar in functionality to the IP protocol used by the tcp/ip
|
|
community.
|
|
<tag/IPX network address/This is a number which uniquely identifies a
|
|
particular IPX network. The usual notation for this address is in hexadecimal.
|
|
An example might look like: <tt/0x23a91002/.
|
|
<tag/IPX Internal network/This is a virtual IPX network. It is virtual
|
|
because it does not correspond to a physical network. This is used to provide
|
|
a means of uniquely identifying and addressing a particular IPX host. This
|
|
is generally only useful to IPX hosts that exist on more than one physical
|
|
IPX network such as fileservers. The address is coded in the same form as
|
|
for a physical IPX network.
|
|
<tag/RIP/Routing Information Protocol is a protocol used to automatically
|
|
propagate network routes in an IPX network. It is functionally similar to the
|
|
RIP used within the tcp/ip community.
|
|
<tag/NCP/NetWare Core Protocol is a networked filesystem protocol designed
|
|
by the Novell Corporation for their NetWare(tm) product. NCP is functionally
|
|
similar to the NFS used in the tcp/ip community.
|
|
<tag/SAP/Service Advertisement Protocol is a protocol designed by the
|
|
Novell Corporation that is used to advertise network services in a NetWare(tm)
|
|
environment.
|
|
<tag/Hardware address/This is a number that uniquely identifies a host in a
|
|
physical network at the media access layer. Examples of this are
|
|
<em/Ethernet Addresses/. An Ethernet address is generally coded as six
|
|
hexadecimal values separated by colon characters eg. <tt/00:60:8C:C3:3C:0F/
|
|
<tag/route/The <em/route/ is the path that your packets take through the
|
|
network to reach their destination.
|
|
</descrip>
|
|
|
|
<sect><heading>A brief discussion of IPX network topology
|
|
<p>
|
|
This is a much simplified explanation for people new to IPX. Large networks
|
|
will probably break lots of the rules explained here. In complex IPX networks
|
|
the administrator should always be consulted.
|
|
<p>
|
|
IPX networking revolves around a scheme of numbered <em/networks/ unlike
|
|
IP which places more emphasis on the <em/interface/ addresses. A network
|
|
is a collection of equipment connected to the same LAN segment and
|
|
<em/using the same frame type/. Different frame types on the same LAN segment
|
|
are treated as seperate networks.
|
|
<p>
|
|
Each network must be allocated a number which is unique across the entire
|
|
internetwork. This is usually performed by a NetWare(tm) server, but can
|
|
easily be performed by Linux. IPX clients are given this number by the
|
|
server when starting, they only require to know the correct frame type.
|
|
<p>
|
|
Routing between networks is usually performed by putting two network cards
|
|
in a server. This server then runs the RIP protocol which holds a routing
|
|
table for the internetwork. Periodic broadcasts of this routing table are
|
|
exchanged between servers. Within a short time each server 'discovers' the
|
|
topology of the internetwork.
|
|
<p>
|
|
If you only wish to use the services of an existing NetWare server, you
|
|
can use <tt/ipx_configure/ (section 7.1) to automatically define the
|
|
IPX interfaces by using broadcast queries to look for a server. If this
|
|
fails, or you wish to provide IPX services, you will need to define the
|
|
interfaces manually using <tt/ipx_interface/ or <tt/mars_nwe/.
|
|
|
|
<sect><heading>The IPX related files in the <tt>/proc</tt> filesystem.
|
|
<p>
|
|
There are a number of files related to the Linux IPX support that are located
|
|
within the <tt>/proc</tt> filesystem. They are:
|
|
|
|
<descrip>
|
|
<tag>/proc/net/ipx_interface</tag>This file contains information
|
|
about the IPX interfaces configured on your machine. These may have been
|
|
configured manually by command or automatically detected and configured.
|
|
<tag>/proc/net/ipx_route</tag>This file contains a list of the
|
|
routes that exist in the IPX routing table. These routes may have been added
|
|
manually by command or automatically by an IPX routing daemon.
|
|
<tag>/proc/net/ipx</tag>This file is a list of the IPX sockets
|
|
that are currently open for use on the machine.
|
|
</descrip>
|
|
|
|
<sect><heading>Greg Pages IPX tools.
|
|
<p>
|
|
Greg Page <tt/<greg@caldera.com/ of Caldera Incorporated has written
|
|
a suite of IPX configuration tools and enhanced the Linux IPX kernel support.
|
|
<p>
|
|
The kernel enhancements allow linux to be configured as a fully featured
|
|
IPX bridge or router. The enhanced IPX support has already been fed back into
|
|
the mainstream kernel distribution so you will probably already have it.
|
|
<p>
|
|
The network configuration tools provide you with the capability to configure
|
|
your network devices to support IPX and allow you to configure IPX routing
|
|
and other facilities under Linux. The Linux IPX network tools are available
|
|
from:
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/filesystems/ncpfs/ipx.tgz"
|
|
name="sunsite.unc.edu">.
|
|
|
|
<sect1><heading>The IPX tools in more detail.
|
|
<p>
|
|
<descrip>
|
|
<tag>ipx_interface</tag>This command is used to manually add, delete or check
|
|
ipx capability to an existing network device. Normally the network device
|
|
would be an Ethernet device such at <tt/eth0/. At least one IPX interface
|
|
must be designated the <em>primary</em> interface and the <em/-p/ flag
|
|
to this command does this. For example to enable Ethernet device <tt/eth0/
|
|
for IPX capability as the primary IPX interface using the IEEE 802.2 frame type
|
|
and IPX network address <tt/39ab0222/ you would use:
|
|
<tscreen><verb>
|
|
# ipx_interface add -p eth0 802.2 0x39ab0222
|
|
</verb></tscreen>
|
|
<p>
|
|
If the frame type differs from NetWare(tm) servers on this network, they will
|
|
studiously ignore you. If the frame type is correct but the network number
|
|
differs, they will still ignore you but complain frequently on the NetWare
|
|
server console. The latter is guaranteed to gain you flames from your
|
|
NetWare administrator and may disrupt existing NetWare clients.
|
|
<p>
|
|
If you get an error while running this program and you happen to not
|
|
have already configured tcp/ip, then you will find that you need to manually
|
|
start the <tt/eth0/ interface using the command:
|
|
<tscreen><verb>
|
|
# ifconfig eth0 up
|
|
</verb></tscreen>
|
|
|
|
<tag>ipx_configure</tag>This command enables or disables the automatic setting
|
|
of the interface configuration and primary interface settings.
|
|
<descrip>
|
|
<tag><tt/--auto_interface/</tag>allows you to select whether new network
|
|
devices should be automatically configured as IPX devices or not.
|
|
<tag><tt/--auto_primary/</tag>allows you to select whether the IPX software
|
|
should automatically select a primary interface or not. Problems have been
|
|
noted using this with Windows 95 clients on the network.
|
|
</descrip>
|
|
A typical example would be to enable both automatic interface configuration
|
|
and automatic primary interface setting with the following command:
|
|
<tscreen><verb>
|
|
# ipx_configure --auto_interface=on --auto_primary=on
|
|
</verb></tscreen>
|
|
|
|
<tag>ipx_internal_net</tag>This command allows you to configure or deconfigure
|
|
an internal network address. An internal network address is optional, but when
|
|
it is configured it will always be the primary interface. To configure an
|
|
IPX network address of <tt/ab000000/ on IPX node <tt/1/
|
|
you would use:
|
|
<tscreen><verb>
|
|
# ipx_internal_net add 0xab000000 1
|
|
</verb></tscreen>
|
|
|
|
<tag>ipx_route</tag>The command allows you to manually modify the IPX routing
|
|
table. For example to add a route to IPX network <tt/39ab0222/ via
|
|
a router with node number <tt/00608CC33C0F/ on IPX network
|
|
<tt/39ab0108/:
|
|
<tscreen><verb>
|
|
# ipx_route add 0x39ab0222 0x39ab0108 0x00608CC33C0F
|
|
</verb></tscreen>
|
|
</descrip>
|
|
|
|
<sect><heading>Configuring your Linux machine as an IPX router.
|
|
<p>
|
|
If you have a number of IPX segments that you wish to internetwork you
|
|
need the services of a router. In the Novell environment there are two
|
|
pieces of information which are necessary to be propagated around the network.
|
|
They are the network routing information propagated using Novell RIP, and
|
|
the service advertisement information propagated using Novell SAP. Any
|
|
router must support both of these protocols to be useful in most situations.
|
|
<p>
|
|
Linux has support for both of these protocols and can be fairly easily
|
|
made to function as a fully Novell compliant router.
|
|
<p>
|
|
The Linux kernel IPX support actually manages the IPX packet forwarding
|
|
across interfaces, but it does this according to the rules coded into the
|
|
IPX routing table. Linux needs a program to implement the Novell RIP and SAP
|
|
to ensure that the IPX routing table is built correctly and updated periodically
|
|
to reflect changes in the network status.
|
|
<p>
|
|
Volker Lendecke <tt/<lendecke@namu01.gwdg.de>/ has developed a routing
|
|
daemon <em/ipxripd/ that will do this for you. The <em/mars_nwe/ package
|
|
mentioned later includes an alternative routing daemon.
|
|
<p>
|
|
You can find <em/ipxripd/ at:
|
|
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/filesystems/ncpfs/ipxripd-0.7.tgz"
|
|
name="sunsite.unc.edu">
|
|
|
|
or at Volkers home site at:
|
|
|
|
<url url="ftp://ftp.gwdg.de/pub/linux/misc/ncpfs/ipxripd-0.7.tgz"
|
|
name="ftp.gwdg.de">
|
|
<p>
|
|
Configuring your Linux machine to act as a router is very straightforward.
|
|
The steps you must take are:
|
|
<enum>
|
|
<item>Build your kernel with IPX, Ethernet and <tt>/proc</tt> support.
|
|
<item>Obtain, compile and install the <em/ipxd/ daemon program.
|
|
<item>Boot the new kernel and ensure that each of the Ethernet cards has
|
|
been properly detected and there are no hardware conflicts.
|
|
<item>Enable the IPX protocol on each of the interfaces using the
|
|
<em/ipx_interface/ command described above.
|
|
<item>Start the <em/ipxd/ daemon program.
|
|
</enum>
|
|
<p>
|
|
Consider the following simple network:
|
|
|
|
<verb>
|
|
IPX Addr: 0x01000000 802.2
|
|
|--------------------------|
|
|
|
|
|
\_________________________
|
|
\ Linux Router
|
|
IPX Addr: 0x02000000 802.2 \
|
|
|--------------------------| \ eth0/-----------\
|
|
| \--====| |
|
|
\_________________________ | IPX route |
|
|
\ eth1| Table |
|
|
IPX Addr: 0x03000000 etherII \----====| ^ |
|
|
|--------------------------| | | |
|
|
| eth2| IPXd |
|
|
\______________________________/====| |
|
|
| SAPd |
|
|
IPX Addr: 0x04000000 etherII eth3| |
|
|
|--------------------------| /====| |
|
|
| | \___________/
|
|
\______________________________/
|
|
</verb>
|
|
<p>
|
|
The configuration for the above network would look like:
|
|
<tscreen><verb>
|
|
# ipx_interface add eth0 802.2 0x0100000000
|
|
# ipx_interface add eth1 802.2 0x0200000000
|
|
# ipx_interface add eth2 etherii 0x0300000000
|
|
# ipx_interface add eth3 etherii 0x0400000000
|
|
# ipxd
|
|
</verb></tscreen>
|
|
<p>
|
|
You should then wait a moment or two and check your
|
|
<tt>/proc/net/ipx_route</tt> file and you should see it populated with
|
|
the IPX routes relevant to your configuration and any learned from any other
|
|
routers in the network.
|
|
|
|
<sect1><heading>Do I need to configure an internal network ?
|
|
<p>
|
|
Novell has a feature called an internal network, which it uses to simplify
|
|
routing in situations where a host has more than one network device connected.
|
|
This is useful in the case of a fileserver connected to multiple networks
|
|
as it means that only one route needs to be advertised to reach the server
|
|
regardless of which network you are attempting from.
|
|
<p>
|
|
In the case of a configuration where you are not running a fileserver and
|
|
your machine acting only as an IPX router the question is not as simple to
|
|
answer. It has been reported that configuring for IPX/PPP works `better' if
|
|
you also configure an internal network.
|
|
<p>
|
|
In any case it is easy to do, but may require a rebuild of your kernel.
|
|
When you are working through the kernel <tt/make config/ you must answer
|
|
<tt/y/ when asked <tt/Full internal IPX network/ as illustrated:
|
|
|
|
<tscreen><verb>
|
|
...
|
|
...
|
|
Full internal IPX network (CONFIG_IPX_INTERN) [N/y/?] y
|
|
...
|
|
...
|
|
</verb></tscreen>
|
|
<p>
|
|
To configure the internal network interface, use the <em/ipx_internal_net/
|
|
command described earlier in the IPX tools section. The main precaution to
|
|
take is to ensure that they IPX network address you assign is unique on your
|
|
network and that no other machine or network is using it.
|
|
|
|
<sect><heading>Configuring your Linux machine as an NCP client.
|
|
<p>
|
|
If you are a user of a mixed technology network that comprises both IP and IPX
|
|
protocols it is likely that at some time or another you have wanted to have
|
|
your Linux machine access data stored on a Novell fileserver on your
|
|
network. Novell have long offered an NFS server package for their
|
|
fileservers that would allow this, but if you are a small site or have only
|
|
a small number of people interested in doing this it is difficult to justify
|
|
the cost of the commercial package.
|
|
<p>
|
|
Volker Lendecke <tt/<lendecke@namu01.gwdg.de>/ has written a Linux
|
|
filesystem kernel module that supports a subset of the Novell NCP
|
|
that will allow you to mount Novell volumes into your Linux filesystem
|
|
without requiring any additional products for your fileserver.
|
|
Volker has called the package <em/ncpfs/ and derived the necessary
|
|
information mainly from the book "Netzwerkprogrammierung in C" by
|
|
Manfred Hill and Ralf Zessin (further details of the book are contained within
|
|
the README file in the <em/ncpfs/ package).
|
|
<p>
|
|
The software causes Linux to emulate a normal Novell workstation for file
|
|
services. It also includes a small print utility that allows you to print to
|
|
Novell print queues (This is documented in the Print Client section later).
|
|
The <em/ncpfs/ package will work with Novell fileservers of version 3.x and
|
|
later, it will not work the Novell 2.x. The <em/ncpfs/ client will also work
|
|
with close Novell compatible products, but unfortunately some products that
|
|
claim to be compatible aren't compatible enough. To use <em/ncpfs/ with Novell
|
|
4.x fileservers, it is preferred to use the Novell server in <em/bindery/
|
|
emulation mode. The NDS support is a very recent early beta addition to
|
|
<em/ncpfs/ and additionally its use may be prohibited in your country due to
|
|
the inclusion of patented technology.
|
|
<p>
|
|
|
|
<sect1><heading>Obtaining <bf/<em/ncpfs//.
|
|
<p>
|
|
The latest <em/ncpfs/ package was designed to be built against the version
|
|
<tt/1.2.13/ kernel or kernels later than <tt/1.3.71/ (this includes 2.x.x).
|
|
If you not using a kernel in either of these categories then you will have
|
|
to upgrade your kernel. The
|
|
<url url="Kernel-HOWTO.html" name="Kernel-HOWTO"> describes how to do this in
|
|
detail.
|
|
<p>
|
|
You can obtain the <em/ncpfs/ package by anonymous ftp from
|
|
Volker's home site at:
|
|
<url url="ftp://ftp.gwdg.de/pub/linux/misc/ncpfs/" name="ftp.gwdg.de">
|
|
or
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/filesystems/ncpfs"
|
|
name="sunsite.unc.edu">
|
|
or mirror sites. The current version at the time of writing was:
|
|
|
|
<tt/ncpfs-2.0.11.tgz/ or <tt/ncpfs-2.2.0.tgz/ which adds the NDS support.
|
|
|
|
<sect1><heading>Building <bf/<em/ncpfs// for kernel 1.2.13.
|
|
<p>
|
|
<descrip>
|
|
<tag>Build a kernel with Ethernet and IPX support</tag>The first thing you
|
|
need to do is ensure that your kernel has been built with IPX support enabled.
|
|
In the <tt/1.2.13/ version kernel you need only ensure that you have
|
|
answered <tt/Y/ to the question: '<tt/The IPX protocol/' as
|
|
illustrated:
|
|
<verb>
|
|
...
|
|
...
|
|
Assume subnets are local (CONFIG_INET_SNARL) [y]
|
|
Disable NAGLE algorithm (normally enabled) (CONFIG_TCP_NAGLE_OFF) [n]
|
|
The IPX protocol (CONFIG_IPX) [n] y
|
|
*
|
|
* SCSI support
|
|
...
|
|
...
|
|
</verb>
|
|
You will also need to ensure that you include an appropriate driver for your
|
|
Ethernet card. If you do not know how to do this then you should read the
|
|
<url url="Ethernet-HOWTO.html" name="Ethernet-HOWTO">.
|
|
<p>
|
|
You can then proceed to build your kernel. Make sure you remember to run
|
|
<em/lilo/ to install it when you have finished.
|
|
|
|
<tag>Untar the <em/ncpfs/ software</tag>
|
|
<verb>
|
|
# cd /usr/src
|
|
# tar xvfz ncpfs-2.0.11.tgz
|
|
# cd ncpfs
|
|
</verb>
|
|
|
|
<tag>Check the Makefile</tag>If you intend to use <em/kerneld/ to
|
|
autoload the <em/ncpfs/ kernel module then you must uncomment the
|
|
line in the <tt/Makefile/ that refers to: <tt/KERNELD/. If you
|
|
are unsure what this means then you should read the
|
|
<url url="Kernel-HOWTO.html" name="Kernel-HOWTO"> to familiarise
|
|
yourself with kernel module configuration.
|
|
|
|
<tag>Make the <em/ncpfs/ software</tag>The software should compile cleanly
|
|
with no other configuration necessary:
|
|
<verb>
|
|
# make
|
|
</verb>
|
|
|
|
<tag>Copy the IPX tools somewhere useful if you don't already have them.
|
|
</tag>After the <em>make</em> has completed you should find all of the tools
|
|
you need in the <tt>ncpfs/bin</tt> directory. You can use:
|
|
|
|
<tscreen><verb>
|
|
# make install
|
|
</verb></tscreen>
|
|
|
|
to install the tools in Volkers choice of directories. If you are running
|
|
on an ELF based system then you will need to rerun <tt/`ldconfig -v'/ to
|
|
ensure that the shared library is able to be found.
|
|
|
|
<tag>Copy the <em>ncpfs.o</em> module somewhere useful if necessary.</tag>
|
|
If you are compiling for a <tt/1.2.*/ kernel then you will find a file
|
|
called <tt/ncpfs.o/ in the <tt>ncpfs/bin</tt> directory after the
|
|
<em>make</em> has completed. This is the <em>ncpfs</em> kernel module.
|
|
You should copy this somewhere useful. On my <em>debian</em> system I have
|
|
copied it to the <tt>/lib/modules/1.2.13/fs</tt> directory and added
|
|
<tt/ncpfs/ to the <tt>/etc/modules</tt> file so that it will be
|
|
automatically started at boot time. If you are using some other distribution
|
|
you should find where it keeps its modules and copy it there, or just copy it
|
|
to your <tt>/etc</tt> directory. To load the modules manually you need to use
|
|
the command:
|
|
<verb>
|
|
# insmod ncpfs.o
|
|
</verb>
|
|
|
|
</descrip>
|
|
|
|
<sect1><heading>Building <bf><em>ncpfs</em></bf> for kernels 1.3.71++/2.0.*.
|
|
<p>
|
|
For the latest version of <em/ncpfs/ you must use kernel <tt/1.3.71/
|
|
or newer, this includes the <tt/2.0.*/ kernels.
|
|
<p>
|
|
If you intend using a kernel that is version <tt/1.3.71/ or newer then the
|
|
<em>ncpfs</em> kernel code has been included in the standard kernel
|
|
distribution. You need only answer <tt/Y/ to:
|
|
<tscreen><verb>
|
|
Networking options --->
|
|
...
|
|
...
|
|
<*> The IPX protocol
|
|
...
|
|
Filesystems --->
|
|
...
|
|
...
|
|
<*> NCP filesystem support (to mount NetWare volumes)
|
|
...
|
|
</verb></tscreen>
|
|
<p>
|
|
You will still need to follow the instructions for building for kernels
|
|
<tt/1.2.*/ so that you can build the tools but there will not be a module
|
|
file for you to install.
|
|
|
|
<sect1><heading>Configuring and using <bf><em>ncpfs</em></bf>.
|
|
<p>
|
|
<descrip>
|
|
<tag>Configure the IPX network software</tag>There are two ways of configuring
|
|
the IPX network software. You can manually configure all of your IPX network
|
|
information or you can choose to let the software determine for itself some
|
|
reasonable settings using the command:
|
|
|
|
<tscreen><verb>
|
|
# ipx_configure --auto_interface=on --auto_primary=on
|
|
</verb></tscreen>
|
|
|
|
This should be reasonable in most circumstances, but if it doesn't work for
|
|
you then read the 'IPX tools' section above to configure your software
|
|
manually. Problems have been noted using this on networks containing
|
|
Windows '95 clients.
|
|
|
|
<tag>Test the configuration</tag>After your IPX network is configured you
|
|
should be able to use the <em>slist</em> command to see a list of all of
|
|
the Novell fileserver on your network:
|
|
<verb>
|
|
# slist
|
|
</verb>
|
|
If the slist command displays a message like:
|
|
<tt/ncp_connect: Invalid argument/ then your kernel probably does not
|
|
support IPX. Check that you have actually booted off the appropriate kernel.
|
|
When you boot you should see messages about '<tt/IPX/' and '<tt/ncpfs/' in
|
|
the system startup messages. If the <em>slist</em> command does not list all
|
|
of your fileservers then you may need to use the manual network configuration
|
|
method.
|
|
|
|
<tag>Mount a Novell(tm) server or volume.</tag>If your IPX network software
|
|
is working
|
|
ok you should now be able to mount a Novell fileserver or volume into your
|
|
Linux filesystem. The <em>ncpmount</em> command is used for this purpose
|
|
and requires that you specify at least the following information:
|
|
<enum>
|
|
<item>The fileserver name
|
|
<item>(optionally) The fileserver directory to mount
|
|
<item>The fileserver login id. If it has a password you will also need that.
|
|
<item>The mount point ie. where you want the mount to go. This will be an
|
|
existing directory on your machine.
|
|
</enum>
|
|
<p>
|
|
There is an equivalent <em/ncpumount/ command to unmount a mounted NCP
|
|
filesystem. The NCP filesystems will be unmounted cleanly if you shutdown
|
|
your machine normally, so you needn't worry about <em/ncpumount/ing your
|
|
filesystems manually before a <em/halt/ or <em/shutdown/.
|
|
<p>
|
|
An example command to mount fileserver <tt/ACCT_FS01/, with a login id of
|
|
<tt/guest/ with no password, under the <tt>/mnt/Accounts</tt> directory
|
|
might look like the following:
|
|
<verb>
|
|
# ncpmount -S ACCT_FS01 /mnt/Accounts -U guest -n
|
|
</verb>
|
|
Note the use of the <tt/-n/ option to indicate that no password is
|
|
required for the login. The same login specifying a password of <tt/secret/
|
|
would look like:
|
|
<verb>
|
|
# ncpmount -S ACCT_FS01 /mnt/Accounts -U guest -P secret
|
|
</verb>
|
|
If you don't specify either the <tt/-n/ or the <tt/-P/ options you
|
|
will be prompted for a password.
|
|
|
|
<tag>Check the mount</tag>If the mount is successful you will find all the
|
|
volumes accessible to the userid used for login listed as directories under
|
|
the mount point. You should then also be able to traverse the directory
|
|
structure to find other files. You may alternatively use the <tt/-V/ option
|
|
to mount a single volume.
|
|
|
|
NCP does not provide uid or gid ownership of files. All the files will have
|
|
the permission and ownership assigned to the mount point directory restricted
|
|
by trustee permissions on the Novell server. Bear this in mind when sharing
|
|
mounts between Linux users.
|
|
|
|
<tag>Configure mounts to be automatically performed.</tag>If you have some
|
|
need to permanently have an ncp mount then you will want to configure the
|
|
commands above into your <em>rc</em> files so that they occur automatically
|
|
at boot time. If your distribution doesn't already provide some way of
|
|
configuring IPX like debian then I recommend you place them in your
|
|
<tt>/etc/rc.local</tt> file if you have one. You might use something like:
|
|
<tscreen><verb>
|
|
#
|
|
# Start the ncp filesystem
|
|
|
|
/sbin/insmod /lib/modules/1.2.13/fs/ncpfs.o
|
|
|
|
# configure the IPX network
|
|
ipx_configure --auto_interface=on --auto_primary=on
|
|
|
|
# guest login to the Accounting fileserver
|
|
ncpmount -S ACCT_FS01 /mnt/Accounts -U guest -n
|
|
|
|
#
|
|
</verb></tscreen>
|
|
There is another means of configuring NCP mounts and that is by building
|
|
a <tt>$HOME/.nwclient</tt> file. This file contains details of temporary
|
|
or user specific NCP mounts that would be performed regularly. It allows
|
|
you to store the details of mounts so that you can recreate them without
|
|
having to specify all of the detail each time.
|
|
<p>
|
|
Its format is quite straightforward:
|
|
<tscreen><verb>
|
|
# The first entry is the 'preferred server' entry and is
|
|
# used whenever you do not specify a server explicitly.
|
|
#
|
|
# User TERRY login to DOCS_FS01 fileserver with password 'password'
|
|
DOCS_FS01/TERRY password
|
|
#
|
|
# Guest login to the ACCT_FS01 fileserver with no password.
|
|
ACCT_FS01/GUEST -
|
|
</verb></tscreen>
|
|
To activate these mounts you could use:
|
|
<tscreen><verb>
|
|
$ ncpmount /home/terry/docs
|
|
</verb></tscreen>
|
|
to mount: DOCS_FS01 with a login of TERRY under the /home/terry/docs
|
|
directory. Note that this entry was chosen because no fileserver was
|
|
specified in the mount command. If the following command were used:
|
|
<tscreen><verb>
|
|
$ ncpmount -S ACCT_FS01 /home/terry/docs
|
|
</verb></tscreen>
|
|
then a GUEST login to ACCT_FS01 would be mounted there instead.
|
|
<p>
|
|
<bf>Note:</bf> for this mechanism to work the permissions of the
|
|
<tt>$HOME/.nwclient</tt> file must be <tt/0600/ so you would
|
|
need to use the command:
|
|
<tscreen><verb>
|
|
$ chmod 0600 $HOME/.nwclient
|
|
</verb></tscreen>
|
|
If non-root users are to be allowed to use this mechanism then
|
|
the <em>ncpmount</em> command must be Set Userid Root, so you
|
|
would need to give it permissions:
|
|
<tscreen><verb>
|
|
# chmod 4755 ncpmount
|
|
</verb></tscreen>
|
|
|
|
<tag>Try out the <em>nsend</em> utility</tag>a utility to send messages
|
|
to Novell users is also included in the package, it is called <em>nsend</em>
|
|
and is used as follows:
|
|
<verb>
|
|
# nsend rod hello there
|
|
</verb>
|
|
would send the message "hello there" to a logged in user "rod" on your
|
|
"primary" fileserver (the first one appearing in your <tt/.nwclient/
|
|
file. You can specify another fileserver with the same syntax as for the
|
|
<em>ncpmount</em> command.
|
|
|
|
</descrip>
|
|
|
|
<sect><heading>Configuring your Linux machine as an NCP server.
|
|
<p>
|
|
There are two packages available that allow Linux to provide the functions of
|
|
a Novell Fileserver. They both allow you to share files on your linux
|
|
machine with users using Novell NetWare client software. Users can attach and
|
|
map filesystems to appear as local drives on their machines just as they would
|
|
to a real Novell fileserver. You may want to try both to see which best
|
|
serves your intended purpose.
|
|
|
|
<sect1><heading>The <bf><em>mars_nwe</em></bf> package.
|
|
<p>
|
|
Martin Stover <tt/<mstover@freeway.de>/ developed <em>mars_nwe</em>
|
|
to enable linux to provide both file and print services for NetWare clients.
|
|
<p>
|
|
In case you are wondering about the name: <em>mars_nwe</em> is Martin Stovers
|
|
Netware Emulator.
|
|
|
|
<sect2><heading>Capability of <bf><em>mars_nwe</em></bf>.
|
|
<p>
|
|
<em>mars_nwe</em> implements a subset of the full Novell NCP for file services,
|
|
disk based bindery and also print services. It is likely to contain bugs but
|
|
there are many people using it now and the number of bugs is steadily
|
|
decreasing as new versions are released.
|
|
|
|
<sect2><heading>Obtaining <bf><em>mars_nwe</em></bf>.
|
|
<p>
|
|
You can obtain <em>mars_nwe</em> from
|
|
<url url="ftp://ftp.gwdg.de/pub/linux/misc/ncpfs/" name="ftp.gwdg.de">
|
|
or from
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/filesystems/ncpfs/">.
|
|
<p>
|
|
The version current at the time of writing was: <tt/mars_nwe-0.99.pl10.tgz/.
|
|
|
|
<sect2><heading>Building the <em>mars_nwe</em> package.
|
|
<p>
|
|
<descrip>
|
|
<tag>Build a kernel with Ethernet and IPX Support</tag>In the <tt/1.2.13/
|
|
version kernel you need only ensure that you have answered <tt/Y/ to the
|
|
question: '<tt/The IPX protocol/' and <tt/N/ to the question:
|
|
`<tt/Full internal IPX network/' as illustrated:
|
|
<verb>
|
|
...
|
|
...
|
|
The IPX protocol (CONFIG_IPX) [n] y
|
|
...
|
|
...
|
|
Full internal IPX network (CONFIG_IPX_INTERN) [N/y/?] n
|
|
...
|
|
...
|
|
</verb>
|
|
In newer kernels a similar process is adopted but the actual text of the prompt
|
|
may have changed slightly.
|
|
<p>
|
|
You will also need to ensure that you include an appropriate driver for your
|
|
Ethernet card. If you do not know how to do this then you should read the
|
|
<url url="Ethernet-HOWTO.html" name="Ethernet-HOWTO">.
|
|
<p>
|
|
You can then proceed to build your kernel. Make sure you remember to run
|
|
<em>lilo</em> to install it when you have finished.
|
|
|
|
<tag>Untar the <em>mars_nwe</em> package.</tag>
|
|
<tscreen><verb>
|
|
# cd /usr/src
|
|
# tar xvfz mars_nwe-0.99.pl10.tgz
|
|
</verb></tscreen>
|
|
|
|
<tag>Make <em>mars_nwe</em>.</tag>To make the package is very simple.
|
|
The first step is to simply run <tt/make/, this will create a
|
|
<tt/config.h/ file for you. Next you should look at and edit the
|
|
<tt/config.h/ file if necessary. It allows you to configure items
|
|
such as the installation directories that will be used and the maximum
|
|
number of sessions and volumes that the server will support. The really
|
|
important entries to look at are:
|
|
<verb>
|
|
FILENAME_NW_INI the location of the initialisation file
|
|
PATHNAME_PROGS where the executable support programs will be found.
|
|
PATHNAME_BINDERY where the 'bindery' files will go.
|
|
PATHNAME_PIDFILES the directory for the 'pid' files to be written.
|
|
MAX_CONNECTIONS the maximum number of simultaneous connections allowed.
|
|
MAX_NW_VOLS the maximum number of volumes mars_nwe will support.
|
|
MAX_FILE_HANDLES_CONN the maximum number of open files per connection.
|
|
WITH_NAME_SPACE_CALLS if you want to support ncpfs clients.
|
|
INTERNAL_RIP_SAP whether you want mars_nwe to provide rip/sap routing.
|
|
SHADOW_PWD whether you use shadow passwords or not.
|
|
</verb>
|
|
<p>
|
|
The defaults will probably be ok but you should check anyway.
|
|
<p>
|
|
When this is done:
|
|
<tscreen><verb>
|
|
# make
|
|
# make install
|
|
</verb></tscreen>
|
|
|
|
will build the servers and install them in the appropriate directory. The
|
|
installation script also installs the configuration file
|
|
<tt>/etc/nwserv.conf</tt>.
|
|
|
|
<tag>Configure the server.</tag>Configuration is fairly simple. You need to
|
|
edit the <tt>/etc/nwserv.conf</tt> file. The format of this file may at first
|
|
look a little cryptic, but it is fairly straightforward. The file contains a
|
|
number of single line configuration items. Each line is whitespace delimited
|
|
and begins with a number that indicates the contents of the line. All
|
|
characters following a '<tt/#/' character are considered a comment and
|
|
ignored. Martin supplies an example configuration file in the package,
|
|
but I'll present what I consider to be a simplified example to offer an
|
|
alternative for you.
|
|
|
|
<tscreen><verb>
|
|
# VOLUMES (max. 5)
|
|
# Only the SYS volume is compulsory. The directory containing the SYS
|
|
# volume must contain the directories: LOGIN, PUBLIC, SYSTEM, MAIL.
|
|
# The 'i' option ignores case.
|
|
# The 'k' option converts all filenames in NCP requests to lowercase.
|
|
# The 'm' option marks the volume as removable (useful for cdroms etc.)
|
|
# The 'r' option set the volume to read-only.
|
|
# The 'o' option indicates the volume is a single mounted filesystem.
|
|
# The 'P' option allows commands to be used as files.
|
|
# The 'O' option allows use of the OS/2 namespace
|
|
# The 'N' option allows use of the NFS namespace
|
|
# The default is upper case.
|
|
# Syntax:
|
|
# 1 <Volumename> <Volumepath> <Options>
|
|
|
|
1 SYS /home/netware/SYS/ # SYS
|
|
1 DATA /home/netware/DATA/ k # DATA
|
|
1 CDROM /cdrom kmr # CDROM
|
|
|
|
# SERVER NAME
|
|
# If not set then the linux hostname will be converted to upper case
|
|
# and used. This is optional, the hostname will be used if this is not
|
|
# configured.
|
|
# Syntax:
|
|
# 2 <Servername>
|
|
|
|
2 LINUX_FS01
|
|
|
|
# INTERNAL NETWORK ADDRESS
|
|
# The Internal IPX Network Address is a feature that simplifies IPX routing
|
|
# for multihomed hosts (hosts that have ports on more than one IPX network).
|
|
# Syntax:
|
|
# 3 <Internal Network Address> [<Node Number>]
|
|
# or:
|
|
# 3 auto
|
|
#
|
|
# If you use 'auto' then your host IP address will be used. NOTE: this may
|
|
# be dangerous, please be sure you pick a number unique to your network.
|
|
# Addresses are 4byte hexadecimal (the leading 0x is required).
|
|
|
|
3 0x49a01010 1
|
|
|
|
|
|
# NETWORK DEVICE(S)
|
|
# This entry configures your IPX network. If you already have your
|
|
# IPX network configured then you do not need this. This is the same as
|
|
# using ipx_configure/ipx_interface before you start the server.
|
|
# Syntax:
|
|
# 4 <IPX Network Number> <device_name> <frametype> [<ticks>]
|
|
# Frame types: ethernet_ii, 802.2, 802.3, SNAP
|
|
|
|
4 0x39a01010 eth0 802.3 1
|
|
|
|
# SAVE IPX ROUTES AFTER SERVER IS DOWNED
|
|
# Syntax:
|
|
# 5 <flag>
|
|
# 0 = don't save routes, 1 = do save routes
|
|
|
|
5 0
|
|
|
|
# NETWARE VERSION
|
|
# Syntax:
|
|
# 6 <version>
|
|
# 0 = 2.15, 1 = 3.11
|
|
|
|
6 1
|
|
|
|
# PASSWORD HANDLING
|
|
# Real Novell DOS clients support a feature which encypts your
|
|
# password when changing it. You can select whether you want your
|
|
# mars server to support this feature or not.
|
|
# Syntax
|
|
# 7 <flag>
|
|
# <flag> is:
|
|
# 0 to force password encryption. (Clients can't change password)
|
|
# 1 force password encryption, allow unencrypted password change.
|
|
# 7 allow non-encrypted password but no empty passwords.
|
|
# 8 allow non-encrypted password including empty passwords.
|
|
# 9 completely unencrypted passwords (doesn't work with OS/2)
|
|
|
|
7 1
|
|
|
|
# MINIMAL GID UID rights
|
|
# permissions used for attachments with no login. These permissions
|
|
# will be used for the files in your primary server attachment.
|
|
# Syntax:
|
|
# 10 <gid>
|
|
# 11 <uid>
|
|
# <gid> <uid> are from /etc/passwd, /etc/groups
|
|
|
|
10 200
|
|
11 201
|
|
|
|
# SUPERVISOR password
|
|
# May be removed after the server is started once. The server will
|
|
# encrypt this information into the bindery file after it is run.
|
|
# You should avoid using the 'root' user and instead use another
|
|
# account to administer the mars fileserver.
|
|
#
|
|
# This entry is read and encrypted into the server bindery files, so
|
|
# it only needs to exist the first time you start the server to ensure
|
|
# that the password isn't stolen.
|
|
#
|
|
# Syntax:
|
|
# 12 <Supervisor-Login> <Unix username> [<password>]
|
|
|
|
12 SUPERVISOR terry secret
|
|
|
|
# USER ACCOUNTS
|
|
# This associates NetWare logins with unix accounts. Password are
|
|
# optional.
|
|
# Syntax:
|
|
13 <User Login> <Unix Username> [<password>]
|
|
|
|
13 MARTIN martin
|
|
13 TERRY terry
|
|
|
|
# LAZY SYSTEM ADMIN CONFIGURATION
|
|
# If you have a large numbers of users and could not be bothered using
|
|
# type 13 individual user mappings, you can automatically map mars_nwe
|
|
# logins to linux user names. BUT, there is currently no means of making
|
|
# use of the linux login password so all users configured this way are
|
|
# will use the single password supplied here. My recommendation is not
|
|
# to do this unless security is absolutely no concern to you.
|
|
# Syntax:
|
|
# 15 <flag> <common-password>
|
|
# <flag> is: 0 - don't automatically map users.
|
|
# 1 - do automatically map users not configured above.
|
|
# 99 - automatically map every user in this way.
|
|
|
|
15 0 duzzenmatta
|
|
|
|
# SANITY CHECKING
|
|
# mars_nwe will automatically ensure that certain directories exist if
|
|
# you set this flag.
|
|
# Syntax:
|
|
# 16 <flag>
|
|
# <flag> is 0 for no, don't, or 1 for yes, do.
|
|
|
|
16 0
|
|
|
|
# PRINT QUEUES
|
|
# This associates NetWare printers with unix printers. The queue
|
|
# directories must be created manually before printing is attempted.
|
|
# The queue directories are NOT lpd queues.
|
|
# Syntax:
|
|
# 21 <queue_name> <queue_directory> <unix_print_cmd>
|
|
|
|
21 EPSON SYS:/PRINT/EPSON lpr -h
|
|
21 LASER SYS:/PRINT/LASER lpr -Plaser
|
|
|
|
# DEBUG FLAGS
|
|
# These are not normally needed, but may be useful if are you debugging
|
|
# a problem.
|
|
# Syntax:
|
|
# <debug_item> <debug_flag>
|
|
#
|
|
# 100 = IPX KERNEL
|
|
# 101 = NWSERV
|
|
# 102 = NCPSERV
|
|
# 103 = NWCONN
|
|
# 104 = start NWCLIENT
|
|
# 105 = NWBIND
|
|
# 106 = NWROUTED
|
|
# 0 = disable debug, 1 = enable debug
|
|
|
|
100 0
|
|
101 0
|
|
102 0
|
|
103 0
|
|
104 0
|
|
105 0
|
|
106 0
|
|
|
|
# RUN NWSERV IN BACKGROUND AND USE LOGFILE
|
|
# Syntax:
|
|
# 200 <flag>
|
|
# 0 = run NWSERV in foreground and don't use logfile
|
|
# 1 = run NWSERV in background and use logfile
|
|
|
|
200 1
|
|
|
|
# LOGFILE NAME
|
|
# Syntax:
|
|
# 201 <logfile>
|
|
|
|
201 /tmp/nw.log
|
|
|
|
# APPEND LOG OR OVERWRITE
|
|
# Syntax:
|
|
# 202 <flag>
|
|
# 0 = append to existing logfile
|
|
# 1 = overwrite existing logfile
|
|
|
|
202 1
|
|
|
|
# SERVER DOWN TIME
|
|
# This item sets the time after a SERVER DOWN is issued that the
|
|
# server really goes down.
|
|
# Syntax:
|
|
# 210 <time>
|
|
# in seconds. (defaults 10)
|
|
|
|
210 10
|
|
|
|
# ROUTING BROADCAST INTERVAL
|
|
# The time is seconds between server broadcasts
|
|
# Syntax:
|
|
# 211 <time>
|
|
# in seconds. (defaults 60)
|
|
|
|
211 60
|
|
|
|
# ROUTING LOGGING INTERVAL
|
|
# Set how many broadcasts take place before logging of routing
|
|
# information occurs.
|
|
# Syntax:
|
|
# 300 <number>
|
|
|
|
300 5
|
|
|
|
# ROUTING LOGFILE
|
|
# Set the name of the routing logfile
|
|
# Syntax:
|
|
# 301 <filename>
|
|
|
|
301 /tmp/nw.routes
|
|
|
|
# ROUTING APPEND/OVERWRITE
|
|
# Set whether you want to append to an existing log file or
|
|
# overwrite it.
|
|
# Syntax:
|
|
# 302 <flag>
|
|
# <flag> is 0 for append, 1 for create/overwrite
|
|
|
|
302 1
|
|
|
|
# WATCHDOG TIMING
|
|
# Set the timing for watchdog messages that ensure the network is
|
|
# still alive.
|
|
# Syntax:
|
|
# 310 <value>
|
|
# <value> = 0 - always send watchdogs
|
|
# < 0 - (-ve) for disable watchdogs
|
|
# > 0 - send watchdogs when network traffic
|
|
# drops below 'n' ticks
|
|
|
|
310 7
|
|
|
|
# STATION FILE
|
|
# Set the filename for the stations file which determine which
|
|
# machines this fileserver will act as the primary fileserver for.
|
|
# The syntax of this file is described in the 'examples' directory
|
|
# of the source code.
|
|
# Syntax:
|
|
# 400 <filename>
|
|
|
|
400 /etc/nwserv.stations
|
|
|
|
# GET NEAREST FILESERVER HANDLING
|
|
# Set how SAP Get Nearest Fileserver Requests are handled.
|
|
# Syntax:
|
|
# 401 <flag>
|
|
# <flag> is: 0 - disable 'Get Nearest Fileserver' requests.
|
|
# 1 - The 'stations' file lists stations to be excluded.
|
|
# 2 - The 'stations' file lists stations to be included.
|
|
|
|
401 2
|
|
</verb></tscreen>
|
|
|
|
<tag>Start the server</tag>If you've configured the server to expect external
|
|
programs to configure your network and/or provide the routing function then
|
|
you should start those before starting the server. Presuming you have
|
|
configured the server so that it will configure your interfaces for you and
|
|
provide the routing services you need only issue the command:
|
|
<tscreen><verb>
|
|
# nwserv
|
|
</verb></tscreen>
|
|
|
|
<tag>Test the server</tag>To test the server you should first try to attach
|
|
and login from a NetWare client on your network. You then set a
|
|
<tt/CAPTURE/ from the client and attempt a print. If both of these are
|
|
successful then the server is working.
|
|
</descrip>
|
|
|
|
<sect1><heading>The <bf><em>lwared</em></bf> package.
|
|
<p>
|
|
Ales Dryak <tt/<A.Dryak@sh.cvut.cz>/ developed <em>lwared</em> to allow
|
|
Linux to function as an NCP based fileserver.
|
|
<p>
|
|
Ales has called the package <em>lwared</em>, an abbreviation for <em>LinWare
|
|
Daemon</em>.
|
|
|
|
<sect2><heading>Capability of <bf><em>lwared</em></bf>.
|
|
<p>
|
|
The <em>lwared</em> server is capable of providing a subset of the full
|
|
function of the Novell NCP. It incorporates messaging but it does not provide
|
|
any printing facilities at all. It does not currently work very well with
|
|
either Windows95 or Windows NT clients. The <em>lwared</em> server relies
|
|
on external programs to build and update the IPX routing and SAP tables.
|
|
Misbehaving clients can cause the server to crash. Importantly, filename
|
|
translation facilities have not been included.
|
|
<p>
|
|
The server does work for NETX and VLM NetWare shells.
|
|
|
|
<sect2><heading>Obtaining <bf><em>lwared</em></bf>
|
|
<p>
|
|
The <em>lwared</em> package can be built for any kernel newer than
|
|
<tt/1.2.0/, I recommend you use version <tt/1.2.13/ as no kernel
|
|
patches are required if you do. Some of the IPX functionality has changed
|
|
with the version <tt/1.3.*/ kernels and this means that patches are
|
|
now required to make it work properly. Appropriate patches are included for
|
|
the new kernels, so if you must use an alpha kernel you should still be able
|
|
to get <em>lwared</em> to work properly for you.
|
|
<p>
|
|
You can obtain the <em>lwared</em> package by anonymous ftp from:
|
|
<url url="ftp://klokan.sh.cvut.cz/pub/linux/linware/"
|
|
name="klokan.sh.cvut.cz">
|
|
|
|
or from:
|
|
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/network/daemons"
|
|
name="sunsite.unc.edu">
|
|
or mirror sites. The current version at the time of writing was:
|
|
<tt/lwared-0.95.tar.gz/
|
|
|
|
<sect2><heading>Building <bf><em>lwared</em></bf>
|
|
<p>
|
|
<descrip>
|
|
<tag>Untar the <em>lwared</em>package</tag>Something like:
|
|
<verb>
|
|
# cd /usr/src
|
|
# tar xvpfz lwared-0.95.tar.gz
|
|
</verb>
|
|
|
|
<tag>Build a kernel with Ethernet and IPX support</tag>
|
|
If you are using an alpha <tt/1.3.*/ kernel then you should try and use
|
|
kernel version <tt/1.3.17/ or newer because the supplied patches were built
|
|
against it. <tt/1.3.*/ kernels older than <tt/1.3.17/ will require
|
|
hand patching to install. (<em>some information on how to do this is included
|
|
in the <tt/INSTALL/ file in the package.</em>). To install the patches
|
|
against a <tt/1.3.17/ kernel or newer you should try:
|
|
<verb>
|
|
# make patch
|
|
</verb>
|
|
<p>
|
|
After applying the patches if necessary, the next thing you need to do is
|
|
ensure that your kernel has been built with IPX support enabled. In the
|
|
<tt/1.2.13/ version kernel you need only ensure that you have answered
|
|
<tt/Y/ to the question: '<tt/The IPX protocol/' as
|
|
illustrated:
|
|
<verb>
|
|
...
|
|
...
|
|
Assume subnets are local (CONFIG_INET_SNARL) [y]
|
|
Disable NAGLE algorithm (normally enabled) (CONFIG_TCP_NAGLE_OFF) [n]
|
|
The IPX protocol (CONFIG_IPX) [n] y
|
|
*
|
|
* SCSI support
|
|
...
|
|
...
|
|
</verb>
|
|
In newer kernels a similar process is adopted by the actual text of the prompt
|
|
may have changed slightly.
|
|
<p>
|
|
You will also need to ensure that you include an appropriate driver for your
|
|
Ethernet card. If you do not know how to do this then you should read the
|
|
<url url="Ethernet-HOWTO.html" name="Ethernet-HOWTO">.
|
|
<p>
|
|
You can then proceed to build your kernel. Make sure you remember to run
|
|
<em>lilo</em> to install it when you have finished.
|
|
|
|
<tag>Compile and install <em>lwared</em>.</tag>To compile <em>lwared</em> you
|
|
should first check, edit if necessary, the <tt>server/config.h</tt> file. This
|
|
file contains various settings that will govern the way your server will
|
|
behave when it is running. The defaults are reasonable, though you might want
|
|
to check that the directories specified for the log files and configuration
|
|
files suit your system.
|
|
<verb>
|
|
# make depend
|
|
# make
|
|
# make install
|
|
</verb>
|
|
I found that the '<tt/make depend/' complained about not finding the
|
|
<tt/float.h/ file on my system but appeared to work anyway.
|
|
I also found that when I tried compiling with gcc <tt/2.6.3/ I found
|
|
I had to change the line:
|
|
<verb>
|
|
#include <net/route.h>
|
|
</verb>
|
|
to
|
|
<verb>
|
|
#include <net/if_route.h>
|
|
</verb>
|
|
in <tt>lib/ipxkern.c</tt> as this file changed name sometime.
|
|
<p>
|
|
The '<tt/make install/' will attempt to install the server and routing
|
|
daemon programs into your <tt>/usr/sbin</tt> directory, the <em>lwpasswd</em>
|
|
program into your <tt>/usr/bin</tt> directory, the IPX utility programs will
|
|
be installed into your <tt>/sbin</tt> directory and last but not least the
|
|
manual pages will go into the <tt>/usr/man</tt> directory structure. If any
|
|
of these locations are not suitable for your system then you should edit
|
|
the relevant <tt/Makefile/ and change the target directories to suit.
|
|
|
|
</descrip>
|
|
|
|
<sect2><heading>Configuring and using <bf><em>lwared</em></bf>
|
|
<p>
|
|
Now the fun bit!
|
|
|
|
<descrip>
|
|
<tag>Configuring the IPX network</tag>The first thing you must do is configure
|
|
your Ethernet interfaces to support the IPX networks your server will support.
|
|
To do this you will need to know the IPX network addresses for each of your
|
|
LAN segments, which Ethernet device (<tt/eth0/, <tt/eth1/ etc.) is
|
|
on which segment, what frame type (<tt/802.3/, <tt/EtherII/ etc.) each
|
|
LAN segment uses and what Internal Network address your server should use
|
|
(this is really needed if your server will service more than one LAN segment).
|
|
A configuration for a server that is on two dis-similar segments with IPX
|
|
network addresses <tt/23a91300/ and <tt/23a91301/ and internal network
|
|
address <tt/bdefaced/ might look like:
|
|
<verb>
|
|
# ipx_internal_net add BDEFACED 1
|
|
# ipx_interface add eth0 802.3 23a91300
|
|
# ipx_interface add eth1 etherii 23a91301
|
|
</verb>
|
|
|
|
<tag>Start the routing daemons</tag>The kernel software itself actually does
|
|
the IPX packet forwarding as it does for IP, but the kernel requires additional
|
|
programs to manage the routing table updates. In the case of IPX two daemons
|
|
are needed and both are supplied with <em>lwared</em>: <em>ipxripd</em> manages
|
|
the IPX routing information and <em>ipxsapd</em> manages the SAP information.
|
|
To start the daemons you need only specify the location of where they should
|
|
write their log messages:
|
|
<verb>
|
|
# ipxripd /var/adm/ipxrip
|
|
# ipxsapd /var/adm/ipxsap
|
|
</verb>
|
|
|
|
<tag>Configure the <em>lwared</em> server</tag>There are two files that you
|
|
must manually configure to allow user login to your <em>lwared</em> server.
|
|
They are:
|
|
|
|
<p>
|
|
<descrip>
|
|
<tag><tt>/etc/lwpasswd</tt></tag>This is where LinWare user account
|
|
information is kept. The <em>lwpasswd</em> program is to keep it up to date.
|
|
In its simplest form the <tt>/etc/lwpasswd</tt> file looks like:
|
|
<verb>
|
|
ales:
|
|
terryd:
|
|
guest:
|
|
</verb>
|
|
Its format is a simple list of login id followed by a ':' character and then
|
|
the encrypted version of the login passwd. A couple of important caveats here:
|
|
No encrypted password means no password, LinWare users must have Linux
|
|
accounts, that is any user you place in <tt>/etc/lwpasswd</tt> must also
|
|
appear in <tt>/etc/passwd</tt> and <tt/root/ is the only account that can
|
|
change the password of another LinWare user. If you are logged in as
|
|
<tt/root/ you can change the password of a LinWare user as this transcript
|
|
demonstrates:
|
|
<verb>
|
|
# lwpasswd rodg
|
|
Changing password for RODG
|
|
Enter new password:
|
|
Re-type new password:
|
|
Password changed.
|
|
</verb>
|
|
<tag><tt>/etc/lwvtab</tt></tag>This is the LinWare volume tables and it stores
|
|
information about what directories should be made available to LinWare users
|
|
(this file is similar in nature to the NFS <tt>/etc/exports</tt> file). A
|
|
simple example of its format is as follows:
|
|
<verb>
|
|
SYS /lwfs/sys
|
|
DATA /lwfs/data
|
|
HOME /home
|
|
</verb>
|
|
The format is simple: Volume name followed by whitespace followed by Linux
|
|
directory to export. You must have at <bf>least</bf> an entry for the
|
|
<tt/SYS/ volume for the server to start. If you intend your DOS based
|
|
users to be able use your LinWare server as their primary server then you must
|
|
install a standard <tt/SYS/ volume directory structure underneath the
|
|
directory you export as your <tt/SYS/ volume. Since these files are
|
|
proprietary and copyright to the Novell corporation you should have a license
|
|
for these. If you users will be using a Novell fileserver as their primary
|
|
server then this will not be necessary.
|
|
</descrip>
|
|
|
|
<tag>Start the <em>lwared</em> server.</tag>tada!
|
|
<verb>
|
|
# lwared
|
|
</verb>
|
|
It is almost an anticlimax isn't it ? Ok so you've got a question, right?
|
|
What is the fileserver name that is being advertised ? If you started the
|
|
server as shown then the LinWare server name being advertised will be
|
|
based on what is returned by the Linux <em>hostname</em>. If you'd like it
|
|
to be something else then you can give the server the name when you start
|
|
it, for example:
|
|
<verb>
|
|
# lwared -nlinux00
|
|
</verb>
|
|
would start the server with the name <tt/linux00/.
|
|
|
|
<tag>Test the <em>lwared</em> server.</tag>The very first thing to test is
|
|
that your LinWare server appears in an <em>slist</em> from a DOS client
|
|
on your network. The <em>slist</em> program is stored on the <tt/SYS/
|
|
volume of a Novell fileserver so you must do this from a machine that is
|
|
already logged in somewhere. If this is not successful then check that
|
|
<em>ipxsapd</em> and <em>lwared</em> are both running. If the <em>slist</em>
|
|
is successful then you should try attaching to the server and mapping
|
|
a volume:
|
|
<verb>
|
|
C:> attach linux00/ales
|
|
...
|
|
...
|
|
C:> map l:=linux00/data:
|
|
C:> l:
|
|
</verb>
|
|
You should then be able to treat the new map just like any other map. The
|
|
file permissions you will have will be based on those allowed to the
|
|
<em>linux</em> account that parallels your LinWare login.
|
|
|
|
</descrip>
|
|
|
|
<sect><heading>Configuring your Linux machine as a Novell Print Client.
|
|
<p>
|
|
The <em/ncpfs/ package includes two small programs that allow you to handle
|
|
printing from you Linux machine to a printer attached to a Novell print server.
|
|
The <em>nprint</em> command allows you to print to a file to a NetWare print
|
|
queue. The <em>pqlist</em> command allows you the list the available print
|
|
queues on a NetWare server.
|
|
<p>
|
|
To obtain and install these commands just follow the instructions relating to
|
|
the NCP client described earlier.
|
|
<p>
|
|
Both commands require that you supply username and
|
|
password so you might normally consider building some shell scripts to make
|
|
the task of printing easier.
|
|
<p>
|
|
An example might look like:
|
|
<tscreen><verb>
|
|
# pqlist -S ACCT_FS01 -U guest -n
|
|
# nprint -S ACCT_FS01 -q LASER -U guest -n filename.txt
|
|
</verb></tscreen>
|
|
The login syntax is similar to the <em>ncpmount</em> command. The examples
|
|
above assume that fileserver <tt/ACCT_FS01/ has a <tt/guest/ account
|
|
with no password, that a print queue called <tt/LASER/ exists and that
|
|
<tt/guest/ is allowed to print to it.
|
|
|
|
On my Linux boxen I have a short shell script for each Novell printer. This
|
|
can then be used as a print filter to allow printing using the standard
|
|
Linux spooler.
|
|
|
|
<sect><heading>Configuring your Linux machine as a Novell Print Server.
|
|
<p>
|
|
A program to allow your Linux machine to act as a print server on a Netware
|
|
network is included in the <em/ncpfs/ package. For instructions on how to
|
|
obtain and build, it follow the directions in the `Netware client' section
|
|
above. Alternatively, support is included in the <em/mars_nwe/ package.
|
|
<p>
|
|
|
|
<sect1><heading>Prerequisites
|
|
<p>
|
|
Configuration is quite straightforward but relies on you already having your
|
|
printer configuration completed and working under Linux. This is covered in
|
|
the <url url="Printing-HOWTO.html" name="Printing-HOWTO"> in some depth.
|
|
|
|
<sect1><heading>Configuration
|
|
<p>
|
|
When you have a working printer configuration, and you have built and
|
|
installed the <em/pserver/ utility then you need to add commands to start it
|
|
into your <tt/rc/ files.
|
|
<p>
|
|
Exactly what command will use will depend on depend on exactly how you want
|
|
it to operate, but in its simplest form something like the following will
|
|
work:
|
|
|
|
<tscreen><verb>
|
|
# pserver -S ACCT_01 -U LASER -P secret -q LASERJET
|
|
</verb></tscreen>
|
|
|
|
This example asks the <em/pserver/ utility to login in to the <tt/ACCT_01/
|
|
fileserver with username <tt/LASER/ and password <tt/secret/ and to take
|
|
jobs from the <tt/LASERJET/ print queue. When an incoming print job is received
|
|
it will use the default print command of <em/lpr/ to feed the print job to the
|
|
Linux print daemon. The print queue must already be defined on the fileserver
|
|
and the username must have server priveliges for the queue.
|
|
<p>
|
|
You could if you wished use any Linux command to accept and print the
|
|
print job. The <tt/-c/ argument allows you to specify the exact print command.
|
|
For example:
|
|
<tscreen><verb>
|
|
# pserver -S ACCT_01 -U LASER -P secret -q LASERJET -c "lpr -Plaserjet"
|
|
</verb></tscreen>
|
|
would do exactly the same as the previous example except it would send the
|
|
job to the <tt/laserjet/ <em/printcap/ configuration instead of the default
|
|
one.
|
|
|
|
<sect><heading>An overview of the <em/ncpfs/ user and adminstration commands
|
|
<p>
|
|
Recent versions of Volker's <em/ncpfs/ package include a range of user and
|
|
administration commands that you might want to use. The tools are built and
|
|
installed as part of the <em/ncpfs/ installation process, so if you haven't
|
|
already, follow the instructions supplied in the Novell Client section above
|
|
to build and install them.
|
|
<p>
|
|
Detailed information is available in the supplied <em/man/ pages but a brief
|
|
summary of the commands is as follows;
|
|
|
|
<sect1><heading>User commands.
|
|
<p>
|
|
<descrip>
|
|
<tag/ncopy/Network Copy - allows efficient file copies to be performed by
|
|
using a Netware function rather than a copy across the network.
|
|
<tag/nprint/Network Print - allows you to print a file to a Netware print
|
|
queue on a Netware server.
|
|
<tag/nsend/Network Send - allows you to send messages to other users on a
|
|
Netware server.
|
|
<tag/nwbols/List Bindery Objects - allows you to list the bindery
|
|
contents of a Netware server.
|
|
<tag/nwboprops/List Properties of a Bindery Object - allows you to the
|
|
properties of a Netware bindery object.
|
|
<tag/nwbpset/Set Bindery Property - allows you to set the properties of a
|
|
Netware bindery object.
|
|
<tag/nwbpvalues/Print Netware Bindery Objects Property Contents - allows you
|
|
to print the contents of a Netware bindery property.
|
|
<tag/nwfsinfo/Fileserver Information - prints some summary information about
|
|
a Netware server.
|
|
<tag/nwpasswd/Netware Password - allows you to change a Netware users password.
|
|
<tag/nwrights/Netware Rights - displays the rights associated with a particular
|
|
file or directory.
|
|
<tag/nwuserlist/Userlist - lists the users currently logged into a Netware
|
|
fileserver.
|
|
<tag/pqlist/Print Queue List - displays the contents of a Netware print queue.
|
|
<tag/slist/Server List - displays a list of know Netware fileserver.
|
|
</descrip>
|
|
|
|
<sect1><heading>Administration tools.
|
|
<p>
|
|
<descrip>
|
|
<tag/nwbocreate/Create a Bindery Object - allows you to create a Netware
|
|
bindery object.
|
|
<tag/nwborm/Remove Bindery Object - allows you to delete a Netware bindery
|
|
object.
|
|
<tag/nwbpadd/Add Bindery Property - allows you to set the value of an existing
|
|
property of a Netware bindery object.
|
|
<tag/nwbpcreate/Create Bindery Property - allows you to create a new property
|
|
for an existing Netware bindery object.
|
|
<tag/nwbprm/Remove Bindery Property - allows you to remove a property from
|
|
a Netware bindery object.
|
|
<tag/nwgrant/Grant Trustee Rights - allows you to assign trustee rights to a
|
|
directory on a Netware fileserver.
|
|
<tag/nwrevoke/Revoke Trustee Rights - allows you to remove trustee rights from
|
|
a directory on a Netware fileserver.
|
|
</descrip>
|
|
|
|
|
|
<sect><heading>Configuring PPP for IPX support.
|
|
<p>
|
|
New versions of the <em>pppd</em> PPP daemon for Linux have support that
|
|
allows you to carry IPX packets across a PPP serial link. You need at least
|
|
version <tt/ppp-2.2.0d/ of the daemon. See the
|
|
<url url="PPP-HOWTO.html" name="PPP-HOWTO">
|
|
for details on where to find it. When you compile <em>pppd</em> you must
|
|
ensure you enable the IPX support by adding the following two lines:
|
|
|
|
<tscreen><verb>
|
|
IPX_CHANGE = 1
|
|
USE_MS_DNS = 1
|
|
</verb></tscreen>
|
|
|
|
to: <tt>/usr/src/linux/pppd-2.2.0f/pppd/Makefile.linux</tt>.
|
|
<p>
|
|
The <tt/IPX_CHANGE/ is what configures the IPX support into PPP.
|
|
The <tt/USE_MS_DNS/ define allows Microsoft Windows95 machines to do
|
|
Name Lookups.
|
|
<p>
|
|
The real trick to getting it to work in knowing how to configure it.
|
|
<p>
|
|
There are many ways of doing this, but I'm only going to describe the two that
|
|
I've received any information on. I've tried neither yet, so consider this
|
|
section experimental, and if you get something to work, please let me know.
|
|
|
|
<sect1><heading>Configuring an IPX/PPP server.
|
|
<p>
|
|
The first thing you need to do is configure your Linux machine as an IP/PPP
|
|
server. Don't panic! This isn't difficult. Again, follow the instructions in
|
|
the <url url="PPP-HOWTO.html" name="PPP-HOWTO"> and you should be pretty
|
|
much ok. When you have this done there are a couple of simple modifications
|
|
you need to make to get IPX working over the same configuration.
|
|
|
|
<sect2><heading>First steps.
|
|
<p>
|
|
One of the first steps you must take is to configure your linux machine as an
|
|
IPX router as described in the appropriate section earlier in this document.
|
|
You won't need to use the <em/ipx_route/ command for the <tt/ppp/ interface
|
|
because <em/pppd/ will configure these for you as it does for IP. When you
|
|
have the <em/ipxd/ daemon running it will automatically detect any new IPX
|
|
interfaces and propogates routes for them. In this way your dialup hosts will
|
|
be seen by other machines automatically when they connect.
|
|
<p>
|
|
|
|
<sect2><heading>Design.
|
|
<p>
|
|
When you are running as a server it will normally be your responsibility
|
|
to assign network address to each of the PPP links when they are established.
|
|
This is an important point, each PPP link will be an IPX network and will have
|
|
a unique IPX network address. This means that you must decide how you will
|
|
allocate addresses and what they will be. A simple convention is to
|
|
allocate one IPX network address to each serial device that will support
|
|
IPX/PPP. You could allocate IPX network addresses based on the login id
|
|
of the connecting user, but I don't see any particularly good reason to do
|
|
so.
|
|
<p>
|
|
I will assume that this is what you have done, and that there are two serial
|
|
devices (modems) that we will use. The addresses I've assigned in this
|
|
contrived example are:
|
|
|
|
<tscreen><verb>
|
|
device IPX Network Address
|
|
------ -------------------
|
|
ttyS0 0xABCDEF00
|
|
ttyS1 0xABCDEF01
|
|
</verb></tscreen>
|
|
|
|
<sect2><heading>Configure <em>pppd</em>.
|
|
<p>
|
|
Configure your <tt>/etc/ppp/options.ttyS0</tt> file as follows:
|
|
|
|
<tscreen><verb>
|
|
ipx-network 0xABCDEF00
|
|
ipx-node 2:0
|
|
ipxcp-accept-remote
|
|
</verb></tscreen>
|
|
|
|
and your <tt>/etc/ppp/options.ttyS1</tt> file as:
|
|
|
|
<tscreen><verb>
|
|
ipx-network 0xABCDEF01
|
|
ipx-node 3:0
|
|
ipxcp-accept-remote
|
|
</verb></tscreen>
|
|
|
|
These will ask <em>pppd</em> to allocate the appropriate IPX network addresses
|
|
to the link when the link is established, set the local node number to
|
|
<tt/2/ or <tt/3/ and will let the remote node overwrite what the
|
|
remote node number with what it thinks it is. Note that each of the addresses
|
|
are hexadecimal numbers and that <tt/0x/ is required at the start of the
|
|
network address, but not required at the start of the node address.
|
|
<p>
|
|
There are other places this information could be configured. If you have only
|
|
one dialin modem then an entry could go into the <tt>/etc/ppp/options</tt>
|
|
file. Alternatively this information can be passed on the command line to
|
|
<em>pppd</em>.
|
|
|
|
<sect2><heading>Test the server configuration.
|
|
<p>
|
|
To test the configuration you will need to have a client configuration that
|
|
is known to work. When the caller dials in, logs in and <em>pppd</em> starts
|
|
it will assign the network address, advise the client of the servers node
|
|
number and negotiate the clients node number. When this has completed, and
|
|
after <em>ipxd</em> has detected the new interface the client should be able
|
|
to establish IPX connections to remote hosts.
|
|
|
|
<sect1><heading>Configuring an IPX/PPP client.
|
|
<p>
|
|
In a client configuration, whether or not you configure your Linux machine
|
|
as an IPX router depends on whether you have a local LAN that you wish to
|
|
act as an IPX router for. If you are a standalone machine connecting to an
|
|
IPX/PPP dialin server then you won't need to run <em>ipxd</em>, but if you
|
|
have a LAN and wish all of the machines on the LAN to make use of the
|
|
IPX/PPP route then you must configure and run <em>ipxd</em> as described.
|
|
This configuration is much simpler because you do not have multiple serial
|
|
devices to configure.
|
|
|
|
<sect2><heading>Configuring <em>pppd</em>
|
|
<p>
|
|
The simplest configuration is one that allows the server to supply all of
|
|
the IPX network configuration information. This configuration would be
|
|
compatible with the server configuration described above.
|
|
<p>
|
|
Again you need to add some options to your <tt>/etc/ppp/options</tt> file,
|
|
they are:
|
|
<tscreen><verb>
|
|
ipxcp-accept-network
|
|
ipxcp-accept-remote
|
|
ipxcp-accept-local
|
|
</verb></tscreen>
|
|
|
|
These options tell <em>pppd</em> to act completely passively and accept
|
|
all of the configuration details from the server. You could supply default
|
|
values here for servers that don't supply details by adding
|
|
<tt/ipx-network/ and <tt/ipx-node/ entries similar to the server
|
|
configuration.
|
|
|
|
<sect2><heading>Testing the IPX/PPP client.
|
|
<p>
|
|
To test the client you will need a known working server to dial into. After
|
|
you have dialled in and pppd has run you should see the IPX details configured
|
|
on your <tt/ppp0/ device when you run the <em>ifconfig</em> command and
|
|
you should be able to use <em>ncpmount</em>.
|
|
<p>
|
|
I'm not sure whether you will have to manually add IPX routes so that you
|
|
can reach distant fileserver or not. This seems likely. If anyone running
|
|
this configuration could tell me I'd be grateful.
|
|
|
|
<sect><heading>IPX tunnel over IP
|
|
<p>
|
|
Many of you will be in a situation where you have two Novell Local Area Netorks
|
|
with only an IP connection between them. How do you play multiplayer deathmatch
|
|
DOOM for DOS via this arrangement you might ask ? Andreas Godzina
|
|
<tt/<ag@agsc.han.de>/ has an answer for you in the form of
|
|
<em>ipxtunnel</em>.
|
|
<p>
|
|
<em>ipxtunnel</em> provides a bridge-like facility for IPX by allowing
|
|
IPX packets to be encapsulated with tcp/ip datagrams so that they can
|
|
be carried by a tcp/ip connection. It listens for IPX packets and when it
|
|
hears one it wraps it within a tcp/ip datagram and routes it to a remote
|
|
IP address that you specify. For this to work of course the machine that
|
|
you route the encapsulated IPX must also be running a copy of the same
|
|
version of <em>ipxtunnel</em> as you.
|
|
|
|
<sect1><heading>Obtaining <em>ipxtunnel</em>
|
|
<p>
|
|
You can obtain <em>ipxtunnel</em> from
|
|
<url url="ftp://sunsite.unc.edu/pub/Linux/system/network/daemons"
|
|
name="sunsite.unc.edu">
|
|
or mirror sites.
|
|
|
|
<sect1><heading>Building <em>ipxtunnel</em>
|
|
<p>
|
|
<em>ipxtunnel</em> built cleanly for me using the following commands:
|
|
<tscreen><verb>
|
|
# cd /usr/src
|
|
# tar xvfz .../ipxtunnel.tgz
|
|
# cd ipxtunnel
|
|
# make
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>Configuring <em>ipxtunnel</em>
|
|
<p>
|
|
Configuration for <em>ipxtunnel</em> is easy. Lets say that your friends
|
|
machine is <tt/gau.somewhere.com/ and your machine is called
|
|
<tt/gim.sw.edu/. <em>ipxtunnel</em> uses a configuration file called
|
|
<tt>/etc/ipxtunnel.conf</tt>. This file allows you to specify the default UDP
|
|
port to use for the tcp/ip connection, where to send the encapsulated data
|
|
and which of your local interfaces <em>ipxtunnel</em> should listen on
|
|
and deliver IPX packets to.
|
|
<p>
|
|
A simple configuration file would look like the following:
|
|
<tscreen><verb>
|
|
#
|
|
# /etc/ipxtunnel.conf for gim.sw.edu
|
|
#
|
|
# The UDP port to use: (default 7666)
|
|
port 7777
|
|
#
|
|
# The remote machine to send IPX packets to: (no default)
|
|
remote gau.somewhere.com
|
|
#
|
|
# The local interfaces to listen for IPX on: (default eth0)
|
|
interface eth0
|
|
interface eth1
|
|
</verb></tscreen>
|
|
Obviously the other machine would have a similar configuration file specifying
|
|
this machine as a <tt/remote/ host.
|
|
|
|
<sect1><heading>Testing and using <em>ipxtunnel</em>
|
|
<p>
|
|
<em>ipxtunnel</em> acts <bf>like</bf> an IPX bridge, so the IPX networks
|
|
at either end of the link should probably be the same. Andreas has never
|
|
tested the <em>ipxtunnel</em> in an environment that actually supports
|
|
Novell file servers so if you do try this in a real environment let Andreas
|
|
know if it works or not.
|
|
<p>
|
|
If the <em>ipxtunnel</em> is working you should be able to start your
|
|
DOOM machines up at each end of the link running IPX mode and they should
|
|
see each other.
|
|
<p>
|
|
Andreas has only used this code over good high speed lines and he makes no
|
|
claim as to its performance when your link is low speed. Again, let him
|
|
know what works for you and what doesn't.
|
|
|
|
|
|
<sect><heading>Commercial IPX support for Linux.
|
|
<p>
|
|
|
|
|
|
<sect1><heading>Caldera'a Network Desktop
|
|
<p>
|
|
Caldera Inc., produce a Linux distribution that features a range of
|
|
commercially supported enhancements including fully functional Novell NetWare
|
|
client support. The base distribution is the well respected Red Hat Linux
|
|
Distribution and Caldera have added their "Network Desktop" products to this.
|
|
The NetWare support provides a fully featured Novell NetWare client built on
|
|
technology licensed from Novell Corporation. The client provides full client
|
|
access to Novell 3.x and 4.x fileservers and includes features such as NetWare
|
|
Directory Service (NDS) and RSA encryption.
|
|
<p>
|
|
You can obtain much more information and ordering details from the:
|
|
<url url="http://www.caldera.com/" name="Caldera Inc Web Server">.
|
|
<p>
|
|
If you work within a Netware 4.x and/or NDS environment then the Caldera
|
|
Netware Client is the only solution available.
|
|
<p>
|
|
If you have a business critical application for Novell support for Linux
|
|
then the Caldera product should be something you take a close look at.
|
|
|
|
<sect><heading>Some Frequently Asked Questions
|
|
<p>
|
|
<descrip>
|
|
<tag>Where can I find commercially supported IPX software for Linux ?
|
|
</tag>The Caldera Corporation offers a fully licensed and fully supported
|
|
Netware 3.x and 4.x client. You can obtain information about it from the
|
|
<url url="http://www.caldera.com/" name="Caldera Inc Web Server">.
|
|
|
|
<tag>Does the IPX software work with Arcnet/Token Ring/etc. ?
|
|
</tag>The Linux IPX software does work with ArcNet and Token Ring interfaces.
|
|
I haven't heard of anyone trying it with AX.25 yet. Configuration is the same
|
|
as for configuring for ethernet except you will have to substitute appropriate
|
|
device names in place of 'eth0' and appopriate hardware addresses where
|
|
necessary.
|
|
|
|
<tag>How do I configure more than one IPX interface ?
|
|
</tag>If you have more than one interface in your machine you should use the
|
|
<em>ipx_interface</em> command to manually configure each one, you should not
|
|
use the `plug n play' configuration.
|
|
|
|
<tag>How do I choose IPX addresses ?
|
|
</tag>IPX networking is similar, but not identical to, IP networking. A major
|
|
difference is the way that addresses are used. IPX does not use the concept
|
|
of subnetworking and so the sort of associations that you have between network
|
|
addresses and networks is different. The rules are fairly simple:
|
|
<itemize>
|
|
<item>Every IPX network address must be unique on a wide area network. This
|
|
includes Internal Network Addresses. Many organisations using IPX over a wide
|
|
area network will have some sort of addressing standard that you should follow.
|
|
<item>Every Host address on an individual network must be unique. This means
|
|
that every host on each IPX network must have a uniquely assigned address. In
|
|
the case of ethernet network this isn't difficult as the cards each have a
|
|
unique address. In the case of IPX/PPP this means you must ensure that you
|
|
allocate unique addresses to all hosts on the network, irrespective of which
|
|
end of the link(s) they are connected. Host address do not need to be unique
|
|
across a wide area network as the network address is used in combination with
|
|
the host address to uniquely identify a host.
|
|
</itemize>
|
|
|
|
<tag>What are frame types, which should I use ?
|
|
</tag>There are a variety of frame types in use over which you can run IPX.
|
|
The most common of these are described in the 'common terms' section of this
|
|
document (under the `<tt/Frame Type/ entry').
|
|
<p>
|
|
If you are installing your machine on an existing network then you must use
|
|
whatever is already in use to allow you to interwork with the other hosts on
|
|
the network, but if the installation is a brand new network you can use any
|
|
of a range of protocols to carry your IPX traffic. My recommendation if you
|
|
are configuring a brand new network and you need to carry both IPX and IP
|
|
traffic is to use the <tt/Ethernet_II/ frame type.
|
|
|
|
<tag>My Windows95 machines mess up my frame type autodetection ?
|
|
</tag>Apparently they can, yeah. I could make nasty comments, but instead
|
|
I'll just suggest that you use the manual frame type configuration instead
|
|
of the automatic one. It is probably the better way anyway.
|
|
|
|
<tag>Why do I get the message `invalid argument' when I configure IPX ?
|
|
</tag>You are probably not running a kernel that supports IPX, either recompile
|
|
your kernel so it does, or double check that you have actually used lilo to
|
|
install and run the new kernel.
|
|
|
|
<tag>Why do I get the message `package not installed' when I configure IPX ?
|
|
</tag>You are probably not running a kernel that supports IPX, either recompile
|
|
your kernel so it does, or double check that you have actually used lilo to
|
|
install and run the new kernel.
|
|
|
|
<tag>Why do I get the message `IPX support not in kernel' from <em/pppd/ ?
|
|
</tag>You've probably compiled IPX as a module and not ensured that it was
|
|
loaded before started <em/pppd/.
|
|
|
|
<tag>How do I NFS export a mounted NCP filesystem ?
|
|
</tag>To use NFS to export an NCP filesystem you must mount it using the
|
|
<em>ncpmount</em> <tt/-V/ option. This option allows you to mount only
|
|
one volume of a fileserver instead of the usual mounting of all of them.
|
|
When you do this your NFS daemon will allow you to export that filesystem in
|
|
the usual way.
|
|
|
|
<tag>Why doesn't slist work when I have an internel network with mars_nwe ?
|
|
</tag>You must have the get nearest server enabled. That is, entry 401 in
|
|
/etc/nwserv.conf should be 0 unless you have a reason for not responding
|
|
to get nearest servers. If you just want slist to work and not respond to
|
|
every get nearest server request, include your internal network and node
|
|
number in /etc/nwserv.stations and set entry 401 in /etc/nwserv.conf to 2.
|
|
|
|
<tag>Does ncpfs package work with mars_nwe ?
|
|
</tag>Martin and Volker's code is slowly beginning to converge. Recent versions
|
|
of <em>mars_nwe</em> have an option to enable it to work with <em>ncpfs</em>.
|
|
You must enable the <tt/WITH_NAME_SPACE_CALLS/ in the <em>mars_nwe</em>
|
|
<tt/config.h/ file.
|
|
|
|
<tag>Is there any free DOS software to work with mars_nwe ?
|
|
</tag>A contrived question deserves a contrived answer. I'm glad you asked,
|
|
Martin has a package that he distributes alongside his <em>mars_nwe</em>
|
|
package that offers free DOS client support for the <em>mars_nwe</em> server.
|
|
You can find it at the same sites as the server, and it will be called
|
|
<tt/mars_dosutils-0.01.tgz/. It includes C source code for programs such
|
|
as <em>slist.exe</em>, <em>login.exe</em>, <em>map.exe</em> etc. The source
|
|
is compilable with Borland(tm) C.
|
|
|
|
</descrip>
|
|
|
|
<sect><heading>Copyright Message.
|
|
<p>
|
|
The IPX-HOWTO, a guide to software supporting the IPX protocol for Linux.
|
|
Copyright (c) 1995 Terry Dawson.
|
|
|
|
This program is free software; you can redistribute it and/or modify it under
|
|
the terms of the GNU General Public License as published by the Free Software
|
|
Foundation; either version 2 of the License, or (at your option) any later
|
|
version.
|
|
|
|
This program is distributed in the hope that it will be useful, but WITHOUT
|
|
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
|
|
FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License along with
|
|
this program; if not, write to the:
|
|
|
|
Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
<sect><heading>Miscellaneous and Acknowledgements.
|
|
<p>
|
|
Terry Dawson <tt/<terry@perf.no.itg.telstra.com.au>/ for the original
|
|
document
|
|
<p>
|
|
David E. Storey <tt/<dave@tamos.gmu.edu>/ and
|
|
Volker Lendecke <tt/<lendecke@namu01.gwdg.de>/
|
|
both assisted greatly by supplying me with information for this document.
|
|
Gilbert Callaghan <tt/<gilbert@pokey.inviso.com>/,
|
|
David Higgins <tt/<dave@infra.com>/ and
|
|
Chad Robinson <tt/<chadr@brtgate.brttech.com>/ each contributed
|
|
information on configuring IPX/PPP.
|
|
Bennie Venter <tt/<bjv@Gil-galad.paradigm-sa.com>/ contributed some useful
|
|
information relating to frame types.
|
|
Christopher Wall <tt/<vergil@idir.net/ contributed some useful suggestions
|
|
to improve the readability and layout of the document.
|
|
Axel Boldt <tt/<boldt@math.ucsb.edu>/ contributed some useful suggestions
|
|
and feedback.
|
|
Erik D. Olson <tt/<eriko@wrq.com>/ provided some useful feedback and
|
|
information on configuring PPP for IPX.
|
|
Brian King <tt/<root@brian.library.dal.ca>/ contributed a question for the
|
|
FAQ section.
|
|
<p>
|
|
"NetWare" is a registered trademark of the
|
|
<url url="http://www.novell.com/" name="Novell Corporation">.
|
|
"Caldera" is a registered trademark of the
|
|
<url url="http://www.caldera.com/" name="Caldera Corporation">.
|
|
|
|
|
|
<p>regards
|
|
<tt/Kevin Thorpe./
|
|
<p>
|
|
<tt/<kevin@pricetrak.com>/
|
|
|
|
</article>
|