Integrating Windows 95 and UNIX on One Network
Given the ubiquity of Windows on PCs and the capabilities
as a server, environments that integrate these two operating
are becoming increasingly common. The issues involved
can be problematic, and once resolved for Windows 3.x,
they are not
necessarily resolved for Windows 95. Based on our site's
with the final Beta version of Windows 95, this article
clarify some of the integration issues, and to provide
tips that will
help you avoid some of the pitfalls awaiting the unwary.
Our site has an existing network of desktop PCs which
are used for
day-to-day production work (the invoice system, word
The PCs are connected through LAN, and a Novell NetWare
also connected to this "administrative" network.
all corporate files, the applications which are available
network, and other material that must be generally available
The desktop systems run a version of Microsoft Windows
as their operating
system. Windows allows the users to have more than one
at the same time and to switch between these tasks on
These users, however, have also expressed a desire to
to the Internet.
We also have a UNIX machine, which is used mainly by
are working on a number of (UNIX-based) products. The
terminals to connect to the UNIX machine, and they store
all of their
sources and programs here. They also use the machine
as a spooler
for their print jobs.
The UNIX machine has a fully functional Internet connection
for sending email, reading USEnet news, and downloading
the net. This machine is not connected to the LAN, so
the users on
the corporate LAN and the developers cannot exchange
This situation will change in the near future. The developers
also be connected to the corporate LAN and thus will
have a desktop
PC and the accompanying software. They will lose their
will have to work from their desktop PCs. However, they
do need access
to their UNIX files and would like to use the UNIX printer
sources and other technical information. The Internet
be made available to everyone.
To prepare for the release of Windows 95, we developed
a pilot to
see if all these demands could be met, and what it would
take to achieve
the whole package.
Preparing for the Pilot Project
The pilot project used the final Beta version of Windows
called the Preview Version. This version contains a
number of online
documents describing the migration from an existing
Windows 3.1 network
environment to a Windows 95 environment. Since the installation
Windows 95 is covered in a number of sources, this article
that the software has already been installed in its
basic form, that
is, the software has been loaded, but the network part
has not yet
A Linux machine served as the UNIX host. This software
runs on a standard
PC and was readily available for testing. Using Linux
advantage in the fact that the source for most of the
kernel is available on-line. So if the need arose, it
would be relatively
easy to make changes.
Also used in the pilot projet was SAMBA, a software
package that allows
a UNIX host to act as a file and printer server for
(See the sidebar "About SAMBA" for more information.)
Before building the pilot, we ensured that both the
UNIX host and
the desktop PC were functioning correctly. Using some
programs (under DOS and not Windows 95!), we verified
that each could
"see" the other on the network.
The first actual step in developing the pilot was to
set the hardware
parameters for the network card on the desktop machine.
From the Windows
Control Panel, we chose the system icon, which brings
up a window
in which we can select the Device Manager. This window
the devices configured on the system, including the
Figure 1 shows this window, with the settings we used
for our network
With the network parameters correctly set, we could
begin to configure
the TCP/IP protocol, which would be used to communicate
desktop system and UNIX host.
The network icon on the same Windows Control Panel brings
up the window
in which the different items for the TCP/IP stack are
The information you see after selecting the network
icon depends on
the setup of the system before installing Windows 95.
If you've been
using NetWare and other protocols before, the Windows
procedure will recognize this and automatically configure
still a good idea to check the settings -- to avoid
In our case the TCP/IP prorocol was not yet configured,
so we had
to add it. To add a protocol, you simply click on the
Add button and
select from the displayed items. From the list of available
we choose Microsoft's TCP/IP. By clicking on the OK
button, we added
the TCP/IP protocol to the list of installed protocols.
It was then
necessary to configure it so that it would work with
our UNIX host.
Figure 2 shows the main configuration window for the
I will explain in detail each of the items you must
Obtaining an IP Address
The first thing to determine is how the desktop PC will
IP address. The easiest way is to hard-code it into
window shown in Figure 2, and this is how we specified
it in our pilot.
In a large-scale production environment, this might
not be the best
thing to do, since it would create extra work and maintenance.
such an environment, the better choice is the DHCP (Distributed
Configuration Protocol) option. This option is comparable
in that it allows a client to obtain its IP address
by querying a
special server on the net. (See the sidebar "About
The UNIX host would be a good candidate to become a
DHCP server for
the entire network. However, for utmost reliability,
you would need
such a server on each segment of the network. This would
system from breaking down completely if a router failed
separate segments. A simple server would do the job
-- its only
task would be to serve DHCP requests and maintain the
pool of allocated
Finding IP Addresses for Other Systems
The second thing to be configured for the TCP/IP stack
is how the
desktop system can obtain the IP addresses of other
systems it wants
to communicate with. There are two alternatives available:
Windows NT Internet Naming Service, or the more familiar
Name Service. Because of our connection to the UNIX
host, we choose
to use DNS. The configuration of DNS allows us to specify
a list of
name servers, including their search order. Furthermore,
we can specify
a search order for the different domain suffixes (if
We selected the UNIX host as our primary nameserver.
It knows all
the IP addresses of the local UNIX group PCs. However,
the UNIX server
is not allowed to propagate DNS requests for outside
hosts on the
Internet. Because of our firewall setup, all outside
leap frog over our gateway through a proxy mechanism.
We also did
not need to specify a search order for different domain
as all the machines live in the same domain.
The above are the most important settings for a local,
For a more complex network, connected by routers and
you can use the Gateway option. This option allows you
a list of gateways which should be searched for the
best route to
the destination. The first gateway in this list is designated
default gateway. If this one cannot help you, the list
in the order you specified while entering.
The last option worth mentioning is the Advanced option.
option you can make TCP/IP the default protocol on your
means that all network traffic is directed over TCP/IP
network is forced to use another protocol.
Activating the New Settings
Having entered the appropriate settings, we return to
the window with
the list of active protocols. At this point, the TCP/IP
been added to the list. All that remains is to click
on the OK button,
and the new software will be installed on our the desktop
Along with a wealth of drivers and libraries come a
few familiar programs.
These are well known from UNIX and can be used on Windows
95 as well.
These include telnet, ftp, ping, route,
netstat, and ifconfig, all of which come in a command
line variety. They can be called from the DOS command
line to test
whether the network is functioning properly. (It's note
all of these programs are necessary in a normal production
-- most are simply used for testing the network.)
After all components are installed, the desktop systems
must be rebooted
to activate the software.
The basic configuration of the desktop environment is
The next step is to configure the UNIX machine so that
users can share
disks and printers.
The UNIX Side
The first step on the UNIX side is to configure the
new desktop machines
in the nameserver of the UNIX host, since this is where
all the machines
will obtain the addresses of the other machines. We
already had a
named running on the UNIX host, so we simply added the
and IP addresses to the local data files. At our site
are called named.reseau.data for the mapping of names
and named.rev.data for the mapping of addresses to names.
The lines we added to the forward mapping file look
test1 IN A 126.96.36.199
test2 IN A 188.8.131.52
The domain name will be appended by default in our setup
of the name server.
The lines we added to the reverse mapping file look
123 IN PTR test1.reseau.nl.
124 IN PTR test2.reseau.nl.
Once you've added the data, restart the named
or send it a HUP signal to make the information you
just entered active.
If you are not already running a name server on your
UNIX host, you
have two options. One is to define the names and IP
addresses of all
hosts in a special host file on each desktop machine,
but this creates
a lot of work and a lot of maintenance (imagine doing
it for 250 desktop
machines). The other option is to install and configure
a name server
on your UNIX host. How to do this is beyond the scope
of this atricle:
there are a number of good books on this subject that
can help you
get started very quickly.
The UNIX host next needs to be equipped with the software
allow it to be used as a file and printer server. A
number of packages
are available to achieve this, both commercial and public
For test purposes we chose SAMBA, a public domain package,
on the Internet. The reason for this choice was that
it comes with
the source, so we could adapt it to our own standards
if the need
arose. A Linux port is also available for this package,
so we could,
with a minimum of effort, install and configure it on
the UNIX host.
(For more information on this package, see the sidebar
SAMBA is configured through a number of files. Your
has to do with how SAMBA should be started. For this
there are two
options, as standalone daemons or via inetd.
To run the standalone version, you must modify your
files to include the startup commands. You will need
to start both
the SAMBA name daemon, nmbd, and the server daemon,
You can do this by adding these lines to your startup
shell assumed, samba installed in /usr/local/samba):
if [ -x /usr/local/samba/bin/nmbd -a -f /usr/local/samba/smb.conf ]
if [ -x /usr/local/samba/bin/smbd -a -f /usr/local/samba/smb.conf ]
We chose to start the daemons through inetd.
This lets us use the TCP-wrapper to control which hosts
to connect to the daemon and which hosts are not. It
operates on the
low level before the nmbd or smbd daemons come into
play. Describing the TCP-wrapper is beyond the scope
of this article,
but if you want more information, you can look at the
home site of
To start SAMBA through inetd, you must modify
two system files, /etc/services and /etc/inetd.conf.
The services file contains a mapping from a service
a port/protocol pair. The information you need to add
to this file
describes the service for both the nmbd and smbd daemons.
The exact lines are shown below:
netbios-ns 137/udp # netbios name service [JBP]
netbios-ssn 139/tcp # netbios session service
The netbios-ns service is used by the nmbd
name daemon; the other service is for the service daemon,
Using these service names, you can update the information
in the inetd.conf
file, adding two lines here as well:
netbios-ns dgram udp wait root /etc/inet/tcpd nmbd
netbios-ssn stream tcp nowait root /etc/inet/tcpd smbd
As you can see from these lines, the daemons are started
through /etc/inet/tcpd, the TCP-wrapper daemon. You
this new configuration active by sending the HUP signal
to the inetd.
From then on, the SAMBA daemons are active and PCs on
can use the services that are configured.
However, before making these changes to inetd.conf,
to configure SAMBA to define the services the users
will be able to
The SAMBA Configuration File
The services SAMBA offers are defined in a configuration
This file can be found in the lib- subdirectory of the
root of SAMBA. All the services that are offered are
defined in this
file, and it is the only file you need to edit if you
want to add,
delete, or change services.
There are two kind of services, public and private.
The public services
are available to everyone and are generally spool and
The private services belong to specific users and can
only be accessed
by these users. You can also define global settings
that are applicable
to all services of the server. A complete description
of the configuration
file is in the manual page smb.conf(5). This page describes
all the items you can configure, together with the different
you may enter. The following paragraphs present examples
from this configuration file.
The first section you will encounter is the [global]
This defines settings that are applicable to all services
in the file.
The entries we defined as being global were:
printing = bsd
printcap name = /etc/printcap
load printers = yes
guest account = nobody
log file = /usr/local/samba/log.%m
log level = 1
Because the version of Linux we use is based on BSD-style
printing, we defined printing as bsd. This is important
get right, as using a wrong printing style will make
the printer useless
from the desktop. Another important setting is the guest
This name is used whenever a public or anonymous service
This user account should not be able to do an interactive
should be as restricted as possible. When you have problems
you can set the log-level and the log file, so that
you can gather
information about the problems.
The second setting describes the printers The actual
on the printing style you selected. We used the BSD
comment = All Printers
browseable = no
printable = yes
public = yes
writable = yes
; create mode = 0700
; printer command = /usr/bin/lpr -P%p -lrh %s
; lpq command = /usr/bin/lpq
For our printing software, the default print commands
worked well. If you need to change these, you can enter
your own printing
and status commands using the printer command and lpq
command keywords. The browsable keyword determines whether
you can "see" this printer when you use a
on the client. There are a few problems related to browsing
SAMBA software itself cannot act as a "browse master"
server for a number of stations in the same workgroup).
You will have
to designate another machine as a browse master.
The last setting in the configuration file is related
to the home
directories of the users. These directories are known
under the service
named homes, and are mapped to the home directory of
the user who is requesting the service. So each user
will in effect
have her or his own home directory mapped to a local
comment = Home Directories
browseable = no
read only = no
create mode = 0750
These three services are general and are required. For
our purposes, we needed to add some specific services
for the different
directories on the UNIX host. We can define a service
as a directory
in the UNIX file system that will be made available
on the network.
comment = Project source tree
path = /usr/project/src
public = no
writable = no
write list = @engineering
printable = no
This service is available only for people in the engineering
group, and not for others. The people in engineering
can both read
and write to this service.
In this way you can define a large number of services
each service, who may use it.
We appear to have succeeded in establishing a good relationship
a UNIX machine and a Windows 95 desktop. The systems
and the UNIX host is capable of serving information
to the desktop
For our pilot we used a minimal set of resources, and
the public domain
software was of a great benefit to us. Using this kind
in a large scale environment can be problematic, however
so much because of the technical merits of the product,
of the maintanance and support of the product. This
is a decision
you will have to make for yourself.
We can only say that marrying UNIX and Windows 95 might
prove a good
combination in a number of different environments.
About the Author
Arthur Donkers graduated from the Delft University
with a degree in Electrical Engineering, with a major
Architecture. He has since worked for a number of major
in the Netherlands, specializing in projects relating
to data communications,
especially the integration of multi-vendor network systems.
four years he worked as an independent consultant for
his own company,
Le Reseau (The Network).