Integrating Windows 95 and UNIX on One Network
Arthur Donkers Given the ubiquity of Windows on PCs and the capabilities of UNIX as a server, environments that integrate these two operating systems are becoming increasingly common. The issues involved in integration can be problematic, and once resolved for Windows 3.x, they are not necessarily resolved for Windows 95. Based on our site's experience with the final Beta version of Windows 95, this article attempts to clarify some of the integration issues, and to provide tips that will help you avoid some of the pitfalls awaiting the unwary. Site Description Our site has an existing network of desktop PCs which are used for day-to-day production work (the invoice system, word processing, etc. The PCs are connected through LAN, and a Novell NetWare system is also connected to this "administrative" network. It holds all corporate files, the applications which are available across the network, and other material that must be generally available to the desktop users. The desktop systems run a version of Microsoft Windows as their operating system. Windows allows the users to have more than one program active at the same time and to switch between these tasks on the desktop. These users, however, have also expressed a desire to get connected to the Internet. We also have a UNIX machine, which is used mainly by developers who are working on a number of (UNIX-based) products. The developers use 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 used for sending email, reading USEnet news, and downloading software from the net. This machine is not connected to the LAN, so the users on the corporate LAN and the developers cannot exchange email. This situation will change in the near future. The developers will also be connected to the corporate LAN and thus will have a desktop PC and the accompanying software. They will lose their terminals and 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 to print sources and other technical information. The Internet connection will 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 95, also 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 of Windows 95 is covered in a number of sources, this article assumes 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 been configured. A Linux machine served as the UNIX host. This software runs on a standard PC and was readily available for testing. Using Linux has another advantage in the fact that the source for most of the programs and 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 desktop machines. (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 simple test 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 displays all the devices configured on the system, including the network card. Figure 1 shows this window, with the settings we used for our network card. With the network parameters correctly set, we could begin to configure the TCP/IP protocol, which would be used to communicate between the desktop system and UNIX host. Configuring TCP/IP The network icon on the same Windows Control Panel brings up the window in which the different items for the TCP/IP stack are configured. 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 95 installation procedure will recognize this and automatically configure them. (It's still a good idea to check the settings -- to avoid unhappy surprises.) 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 protocols 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 TCP/IP protocol. I will explain in detail each of the items you must specify here. Obtaining an IP Address The first thing to determine is how the desktop PC will obtain its IP address. The easiest way is to hard-code it into the configuration 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. In such an environment, the better choice is the DHCP (Distributed Host Configuration Protocol) option. This option is comparable to BOOTP in that it allows a client to obtain its IP address by querying a special server on the net. (See the sidebar "About DHCP" for more information.) 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 prevent the system from breaking down completely if a router failed between two separate segments. A simple server would do the job -- its only task would be to serve DHCP requests and maintain the pool of allocated IP addresses. 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: WINS, the Windows NT Internet Naming Service, or the more familiar DNS, Domain 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 need be). 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 connections must leap frog over our gateway through a proxy mechanism. We also did not need to specify a search order for different domain suffixes, as all the machines live in the same domain. Other Settings The above are the most important settings for a local, isolated network. For a more complex network, connected by routers and other mechanisms, you can use the Gateway option. This option allows you to specify a list of gateways which should be searched for the best route to the destination. The first gateway in this list is designated as the default gateway. If this one cannot help you, the list is searched in the order you specified while entering. The last option worth mentioning is the Advanced option. With this option you can make TCP/IP the default protocol on your machine. This means that all network traffic is directed over TCP/IP unless the 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 protocol has 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 system. 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 clear whether all of these programs are necessary in a normal production environment -- 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 now finished. 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 names and IP addresses to the local data files. At our site these files are called named.reseau.data for the mapping of names to addresses and named.rev.data for the mapping of addresses to names. The lines we added to the forward mapping file look like this:
named.reseau.data test1 IN A 193.23.45.123 test2 IN A 193.23.45.124 ...
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 like this:
named.rev.data 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. Configuring SAMBA The UNIX host next needs to be equipped with the software that will allow it to be used as a file and printer server. A number of packages are available to achieve this, both commercial and public domain. For test purposes we chose SAMBA, a public domain package, available 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 on "About SAMBA.") SAMBA is configured through a number of files. Your first decision 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 system startup files to include the startup commands. You will need to start both the SAMBA name daemon, nmbd, and the server daemon, smbd. You can do this by adding these lines to your startup file (Bourne shell assumed, samba installed in /usr/local/samba):
if [ -x /usr/local/samba/bin/nmbd -a -f /usr/local/samba/smb.conf ] then /usr/local/samba/bin/nmbd -D fi if [ -x /usr/local/samba/bin/smbd -a -f /usr/local/samba/smb.conf ] then /usr/local/samba/bin/smbd -D fi
We chose to start the daemons through inetd. This lets us use the TCP-wrapper to control which hosts are allowed 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 the software:
ftp://ftp.win.tue.nl/pub/security.
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 name to 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, smbd. 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 can make this new configuration active by sending the HUP signal to the inetd. From then on, the SAMBA daemons are active and PCs on the network can use the services that are configured. However, before making these changes to inetd.conf, it's necessary to configure SAMBA to define the services the users will be able to use. The SAMBA Configuration File The services SAMBA offers are defined in a configuration file, ~/lib/smb.conf. This file can be found in the lib- subdirectory of the installation 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 temporary services. 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 keywords you may enter. The following paragraphs present examples and items from this configuration file. The first section you will encounter is the [global] section. This defines settings that are applicable to all services in the file. The entries we defined as being global were:
[global] 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 to get right, as using a wrong printing style will make the printer useless from the desktop. Another important setting is the guest account. This name is used whenever a public or anonymous service is used. This user account should not be able to do an interactive login and should be as restricted as possible. When you have problems with SAMBA 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 settings depend on the printing style you selected. We used the BSD version:
[printers] 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 network browser on the client. There are a few problems related to browsing as the SAMBA software itself cannot act as a "browse master" (browse 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 disk.
[homes] 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. For example,
[sources] 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 and, for each service, who may use it. Conclusion We appear to have succeeded in establishing a good relationship between a UNIX machine and a Windows 95 desktop. The systems can communicate, and the UNIX host is capable of serving information to the desktop machines. 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 of software in a large scale environment can be problematic, however -- not so much because of the technical merits of the product, but because 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 of Technology with a degree in Electrical Engineering, with a major in Computer Architecture. He has since worked for a number of major software houses in the Netherlands, specializing in projects relating to data communications, especially the integration of multi-vendor network systems. The last four years he worked as an independent consultant for his own company, Le Reseau (The Network).
|