mars-nwe/examples/nw.ini

#
# This is the configuration-file for "mars_nwe", a free netware-emulator
# for Linux.
#
# last change: 17-Jul-96

# This file specifies which Linux-resources (printers, users, directories)
# should be accessible to the DOS-clients via "mars_nwe". Furthermore
# some general parameters are configured here.
# Some options of "mars_nwe" can only be altered by editing the the file
# `config.h' and re-compiling "mars_nwe", please see there for more
# information.


# Syntax of this config-file:
#       - everything after a "#" is treated as a comment (particularly
#         it does never belong to the values themselves)
#       - entries _must_ begin with a number, indicating the section
#         they belong to
#       - hexadecimal values are prepended by "0x"
#
# All examples are verbatim.
#
# The term "DOS-client" does not refer to the special operating-system
# "DOS" in _this_ file. "DOS-client" is only a synomym for all possible
# ipx-clients (it's choosen for the people who are confused by the
# meaning of "client" and "server").
# The "Linux-side" of the game is always the "mars_nwe"-server.


# =========================================================================
# Section 1: volumes (required)
#
# In this section you list all Linux-directories accessible via "mars_nwe".
#
# To be more precise: a mapping from Linux-directories to mars_nwe-volumes
# is done. (Volumes are the beasts you can map to drive letters under DOS
# using "map.exe").
#
# Linux-directory               mars_nwe-volume    map.exe      DOS-Drive
# /var/local/nwe/SYS  ------->  SYS             ------------->  W:
#
# More than one entry is allowed in this section.
# The maximum number of volumes is a compile-time option that must be
# specified in `config.h' before compiling mars_nwe.
#
# Please note that at least the volume "SYS" must be defined and it must
# contain the following sub-directories: LOGIN, PUBLIC, SYSTEM, MAIL.
# See the installation-instructions in the doc-directory for more infos.
#
#
# -------------------------------------------------------------------------
# Syntax:
#       1       VOLUMENAME      DIRECTORY               OPTIONS
#
# VOLUMENAME:   the name of the mars_nwe-volume (max. 8 characters)
# DIRECTORY:    the directory on your Linux-system associated with that
#               volume; use the special name "~" to refer to the users
#               individual home-directory
#
# OPTIONS:      none or some of the following characters (without a seperator)
#
#               Next two options control DOS and OS/2 namespace.
#       i       ignore case, handle mixing upper/lowercase filenames (slow)
#       k       use lowercase-filenames (if you don't set this,
#               and you don't set 'i' all files _must_ be upper-case)
#
#       m       removable volume (e.g. cd-roms)
#       r       volume is read-only and always reports "0 byte free"
#               (this is intended for copies of CD-ROMs on harddisks)
#       o       volume has only one filesystem/device/namespace
#               this is for filesystems with high inode > 0xFFFFFFF.
#               because for namespace services mars_nwe normally use the
#               first 4 bit of 32 bit inode for distinguish
#               between several devices/namespaces for one volume.
#       p       "PIPE"-filesystem. All files are pipe commands.
#               See `doc/PIPE-FS'.
#
#               additional Namespaces
#       O       + OS/2 namespace.
#       N       + NFS  namespace.
# -------------------------------------------------------------------------
#
# Examples:
#       1       SYS             /var/local/nwe/SYS      k
#       1       CDROM           /cdrom                  kmr
#       1       HOME            ~                       k

        1       SYS             /u3/SYS/                k


# =========================================================================
# Section 2: servername (optional)
#
# The servername is the name under which this server will show up when
# using tools like "slist" (server-list).
#
# If you don't supply an entry for this section, the hostname of your
# Linux-machine will be converted to all-uppercase and used as the servername.
#
# -------------------------------------------------------------------------
# Syntax:
#       2       SERVERNAME
#
# SERVERNAME:   a name for this nw-server
# -------------------------------------------------------------------------
#
# Example:
#       2       MARS    # name of the server would be "MARS"


# =========================================================================
# Section 3: Number of the internal network (required)
#
# If have dealt with the TCP/IP-configuration of your Linux-Box, the term
# "ip-address" may be familiar to you. It's a numer that uniquely
# identifies your machine in the internet.
# As you might already expect, even the IPX-people use a unique number to
# identify each other. Addresses in the IPX-world always consist of a
# 4-byte "network-number" plus a 6-byte "node-number" (remember the
# ip-addresses also use 4-bytes).
#
# The numbering-rule for ipx-clients is easy: their "address" is the
# external-network of the server they are connected to plus the
# hardware-address of their own ethernet-card (6 byte). As a result of this
# rule, the clients can determine their address automatically (by listening
# to the server and looking at their own ethernet-hardware) and no
# configuration-files on the clients-side have to be maintained. (It would
# really be a nasty thing if you think of very many DOS-clients [remember:
# DOS is an OS where ordinary users can screw up the configuration files].)
#
# For internal routing purposes, a netware-server has an "internal network"
#
# As there is no organisation which regulates the use of network-numbers
# in the IPX-world, you have to run "slist" (under DOS or Linux) to
# determine a number that isn't already used by another server on your
# net. You better double-check and ask the other network administrators
# before using a random value because not all servers might be on-line when
# you "listen" to the net.
#
# A reasonable choice for the internal net-number of your mars_nwe-server
# could be the ip-address of your Linux-Box. It is reasonable because
# ip-addresse are unique and if every nw-administrator uses only this uniqe
# value, potential conflicts will be minimized. Of course this choice is
# no guarantee.
#
# Please note that you have to specify the address of your "internal
# ipx-network" in hexadecimal format (the leading "0x" indicates it).
#
#
# -------------------------------------------------------------------------
# Syntax:
#       3       INTERNAL_NET    [NODE]
#
# INTERNAL_NET: the hexadecimal value of your "internal ipx-network". Use
#               "0x0" or "auto" to refer to your ip-addresse (it's a kind of
#               automagically setup)
# NODE:         use "1" if you don't know what this entry is for (optional)
# -------------------------------------------------------------------------
#
# Example:
#       3       auto     1       # automatic setup

        3       auto


# =========================================================================
# Section 4: IPX-devices (strongly recommended)
#
# This section contains information for the ipx-router built into mars_nwe
# and/or the external program "nwrouted".
# Both processes exchange the ipx-packets between your machine and the rest
# of the world (in other words: their functionallity is essential). Of
# course, to use one of both is already sufficient.
#
# Note for people with other IPX/NCP servers on the net:
#       - choose the same frame-type as the other servers use
#       - make sure your network-number is not already in use by another
#         server (see the output of "slist" under Linux or DOS)
#
# Under Linux, it is possible to let the kernel detect all values
# automatically for you. This is only possible (and only makes sense then)
# if there are other IXP/NCP servers on the same net which are setup
# correctly.
#
#
# -------------------------------------------------------------------------
# Syntax:
#       4       NET_NUMBER      DEVICE  FRAME   TICKS
#
# NET_NUMBER:   this number is determined by the router of the physical
#               network you're attached to. Use "0x0" to let the
#               linux-kernel determine your network number by listening
#               on the local network
# DEVICE:       the network-interface associated with the NET_NUMBER. Use
#               a "*" (star) to automatically setup all devices at once.
# FRAME:        the frame-type of the data-packets on your local network.
#               Possible values are:
#                       ethernet_ii
#                       802.2
#                       802.3   (default)
#                       snap
#                       token
#                       auto    automatic detection of the frame-type used
#                               in your ipx-environment
# TICKS:        the time data-packets need to get delivered over a
#               certain interface. If your connection goes through several
#               routers, the shortest path can be determined by summing up
#               all ticks for every route and compare the results.
#               (1 tick = 1/18th second)
# -------------------------------------------------------------------------
#
# Examples:
#       4       0x0     *       AUTO    1       # automatic setup
#       4       0x10    eth0    802.3   1       # manual setup

        4       0x10    eth0    802.3   1
        4       0x0     *       AUTO    1


# =========================================================================
# Section 5: Saving of ipx-routes (required)
#
# This entry controls if the information regarding the ipx-routes should be
# saved beyond the lifetime of the server.
#
# -------------------------------------------------------------------------
# Syntax:
#       5       SAVE_FLAG
#
# SAVE_FLAG:
#       0       don't save routes (default)
#       1       do save routes
# -------------------------------------------------------------------------
#

5       0


# =========================================================================
# Section 6: version-"spoofing"
#
# Some clients work better if the server tells that it is a 3.11 Server,
# although many calls (namespace services) of a real 3.11 Server are
# missing yet.
# To test the namespace calls, this entry must be set to > 0 and `config.h'
# must be altered before compiling "mars_nwe".
#
# -------------------------------------------------------------------------
# Syntax:
#       6       SERVER_VERSION
#
# SERVER_VERSION: the version-number reported to DOS-clients
#       0       Version 2.15 (default)
#       1       Version 3.11
#       2       Version 3.12 (not implemented yet)
# -------------------------------------------------------------------------
#

6       0


# =========================================================================
# Section 7: password handling of DOS-clients (required)
#
# When changing your "mars_nwe"-password from a DOS-client, this client
# (think of "LOGIN.EXE", "SYSCON.EXE" or "SETPASS.EXE") can encrypt your
# password before sending it to the "mars_nwe"-server (this improves
# security a little bit).
# In this section you can enforce encryption of user-passwords or allow
# not-encrypted sending of passwords over the net.
#
#
# On the Linux-side, passwords will only be stored in encrypted format.
#
#
# -------------------------------------------------------------------------
# Syntax:
#       7       FLAG
#
# FLAG:
#       0       enforce encryption of _all_ passwords by the DOS-client
#               (default)
#       1       as "0", but allow the non-encrypted version of the
#               "change password"-routine.
#       7       allow all non-encrypted stuff but no empty nwe passwords.
#       8       allow all non-encrypted stuff and also allow empty
#               nwe-passwords.
#       9       use all non-encryted calls + "get crypt key" will allways fail
#               so the login program will use the old unencryted calls.
#               this will *not* work with all clients !! (OS2/client)
# -------------------------------------------------------------------------

7       0


# Section 8: currently not used
# Section 9: currently not used

# Section 10: UID and GID with minimal rights
# =========================================================================
#
# When loading the netware-drivers in the "autoexec.bat" of your
# DOS-client, you automatically "attach" to a netware-server.
# As a result, a new drive-letter is accessible under DOS, usally
# containing the programs "login.exe" and "slist.exe".
# Because you haven't logged in, nothing else of the netware-server
# will be visible to you. All actions requested from the DOS-client
# will be done with the following UID and GID on the Linux-side in this
# case.
# To achieve some level of security, the user/group asscociated with
# the UID and GID should only have _read_ rights on the files visible,
# _nothing_ else.
#
# On most Linux-systems, there is a user and group "nobody" defined in
# `/etc/passwd' and `/etc/group'. Use the number of that user/group
# for the following entries.
#
# -------------------------------------------------------------------------
# Syntax:
#       10      GID
#       11      UID
#
# GID   numeric number of the group
# UID   numeric number of the user
# -------------------------------------------------------------------------
#
# Example:
#       10      65534
#       11      65534

        10      65534
        11      65534


# =========================================================================
# Section 12: supervisor-login (required)
#
# The "supervisor" of a nw-server is much like "root" on the Linux-side.
#
# Specify a Linux-user that should be mapped to the supervisor of this
# mars_nwe-server.
# To improve security, don't use "root" for this purpose but create a
# seperate administrative account (under Linux) called "nw-adm" or similar.
#
# The nw-user defined in this section will have the mars_nwe internal UID
# "1" (remember even under Linux "root" must have the special UID "0"), so
# it is not possible to define a supervisor in section 13 (the users
# defined there will get random UIDs).
# You _can_ define a user with name "SUPERVISOR" in section 13, but he
# won't really be the "local god" on the "mars_nwe"-server.
# And of course you _can_ define a supervisor with name "GOD" or "ROOT"
# in _this_ section, which would only break the traditional naming-scheme
# of the netware-world.
#
#
# -------------------------------------------------------------------------
# Syntax:
#       12      NW_LOGIN        LINUX_LOGIN     [PASSWORD]
#
# NW_LOGIN:     the login-name for the "mars_nwe"-server (traditionally,
#               this is "SUPERVISOR")
# LINUX_LOGIN:  the account on the Linux-side associated with the NW_LOGIN
# PASSWORD:     the password for the NW_LOGIN. It must be clear-text but
#               will be encrypted and permanent stored in the
#               bindery-files, so it (the password or the whole section, at
#               your option) can be deleted after the first start of
                "nwserv".
#
#               Make sure this file is not world-readable as long
#               as the password stands here.
#
#               If you leave this field blank when starting "mars_nwe" the
#               first time, the supervisor-login will be completely
#               disabled. In other words: there is no way to supply the
#               supervisor with no password ("null-password").
# -------------------------------------------------------------------------
#
# Example:
#       12      SUPERVISOR      nw-adm          top-secret

12  SUPERVISOR   root


# =========================================================================
# Section 13: user-logins (optional)
#
# You can provide mappings from the regular login-names of your Linux-Box
# to "mars_nwe"-logins here.
# Every "mars_nwe"-user _must_ have a login-name on the Linux side (even
# if he can't log in into the account associated with the login-name,
# because you locked it with a "*") in order to "own" files.
# If you specify a Linux-login that doesn't exist (one could think of a
# typo), the user will only have the minimal rights defined in
# sections 10/11.
#
# See section 12 for a description of the syntax.
#
# Unlike in section 12, you can define users with no password.
#
# Example:
#       13      MARTIN          martin


# Section 14: currently not used

# =========================================================================
# Section 15: automatic mapping of logins (decision required)
#
# If you have a large number of accounts on your Linux-machine, you may
# want to map all Linux-logins automatically to "mars_nwe"-logins.
#
# At this stage this section is only a quick hack to make life a bit
# easier for the administrator.
#
# WARNING: as there is no algorithm to convert the encrypted
# "Linux-passwords" into the encrypted format used by the DOS-clients (and
# therefore "mars_nwe"), you have to supply a common password for all
# automatically mapped users. This is a big security concern and you
# should never make this common password public (and, of course you
# should choose a sufficient "secure" (read: difficult) password).
# Type the common password to grant access to the users login and the
# command "setpass" instead of telling the password to the user.
#
# Only those Linux-logins will handled automatically that don't have a
# "x" or "*" as their encrypted password.
#
#
# -------------------------------------------------------------------------
# Syntax:
#       15      FLAG    DEFAULT_PASSWORD
#
# FLAG:
#       0       DON'T map the Linux-logins automatically to
#               "mars_nwe"-logins (default)
#       1       YES, DO the automatic mapping and provide every login
#               created this way with the common password given with
#               "DEFAULT_PASSWORD"
#       99      re-read the logins from /etc/passwd and overwrite even the
#               already existing logins from the bindery (this will also
#               reset all the passwords to "DEFAULT_PASSWORD")
#
# DEFAULT_PASSWORD: the common password for all automatically created
#               logins (only needed if FLAG is not "0"); everything about
#               password in section 12 applies to this.
# -------------------------------------------------------------------------

15   0     top-secret



# =========================================================================
# Section 16: Tests on startup
#
# If you want some sanity checks at startup, set this flag to 1.
# "mars_nwe" will try to create missing directories (with the "right"
# permissions, of course) if you enable this.
#

16      1


# Section 17-20: currently not used


# =========================================================================
# Section 21: print queues (optional)
#
# Which of the printers connected to your Linux-box should be accessible
# from the DOS-clients?
# Multiple entries are allowed.
#
# -------------------------------------------------------------------------
# Syntax:
#       21      QUEUE_NAME      QUEUE_DIR       PRINT_COMMAND
#
# QUEUE_NAME:   the name of the print queue on client-side (to make it
#               perfectly clear: _not_ the Linux-queue)
# QUEUE_DIR:    spooling directory for the print-jobs; this directory must
#               exist before printing (_not_ the spooling-directories of
#               the Linux-lpd)
# PRINT_COMMAND: command used for serving the print-jobs under Linux
#               (see "man lpr" and "man magicfilter" for details)
#
# Examples:
#       21      LASER           SYS:/PRINT/L    lpr -Plaser
#       21      OCTOPUSS        SYS:/PRINT/O    lpr -Php_deskjet
# -------------------------------------------------------------------------



# --------------------------------------------------------
# You usally don't want to change anything below this line
# --------------------------------------------------------


# Sections 100-106: amount of debug-information
#
# FLAG:
#       0       no debug messages
#       1       errors and notes are reported
#       99      maximum debug levels

100     0               # debug IPX KERNEL (0 | 1)
101     1               # debug NWSERV
102     0               # debug NCPSERV
103     0               # debug NWCONN
104     0               # debug (start) NWCLIENT
105     0               # debug NWBIND
106     1               # debug NWROUTED

# Sections 200-202: logging of "nwserv"
#
200     1               # 0 = no logfile and dont daemonize nwserv/nwrouted
                        # 1 = daemonize nwserv/nwrouted and use logfile
201     /tmp/nw.log     # filename of logfile
202     1               # 1=creat new logfile, 0=append to logfile


# Sections 210,211: timing

210     10              # 1 .. 600  (default 10) seconds after server
                        # really goes down after a down command
211     60              # 10 .. 600 (default 60) broadcasts every x seconds


# Sections 300-302: loging of routing-information

300     1               # > 0 print routing info to file every x broadcasts.
                        # ( normally minutes )
301     /tmp/nw.routes  # filename of logfile
302     1               # 1 = creat new routing info file
                        # 0 = append to this file


# Section 310: watchdogs

310     7               # send wdog's only to device net < x ticks.
                        # 0 = allways send wdogs. < 0 = never send wdogs

# Section 400:
# station file for special handling of stations.

400  /etc/nwserv.stations  # for syntax see file in the examples directory.


# Section 401: nearest server
#
# for special handling of the 'get nearest server request'.
401     0       # 0 = ignore entry 400, get nearest response ever enabled.
                # 1 = 400 are excludes, get nearest response normally enabled.
                # 2 = 400 are includes, get nearest response normally disabled.