Networking for Home: Difference between revisions

From OS2World.Com Wiki
Jump to navigation Jump to search
(Created page with "By Nicholas McGuigan So! You have just bought your second PC and you have given your old one to the kids (or you're the kids!). You need to transfer files between the old...")
 
Line 352: Line 352:


The next few sections deal with how use this base to share resources and to transfer files and data about the place.
The next few sections deal with how use this base to share resources and to transfer files and data about the place.
==Resource Sharing Concepts==
[[Image:NetShareConcepts01.gif]]
This section covers the sharing of resources on your newly created home LAN. The typical resources you might share are:
'''Printers'''
 
This is an obvious choice. Mum or Dad buys a new beaut but tres expensive printer for their essential business needs (yeah, right!) leaving little Johnnie and Joannie to face the most important years of their lives (school and such) struggling with a dot matrix printer that Noah abandoned when he took to the Ark. Now, thanks to the wonder and convenience of a home LAN, the new printer can be shared amongst all the needy users in the house. The shared printer looks like just any other printer on your desktop.
'''Directories'''
   
Sharing disk directories enables you to share disk space amongst the home LAN users. As in the printer case, this enables the latest large disk purchase to be used by all the family. However, there are some additional benefits as well. These include being able to share what is in the shared directory, for example files and programs, and being able to use shared disk to make copies of files from the client workstations for backup and archive purposes. Shared printers look like additional disk drives to the using (client) workstation.
'''Disks'''
   
Like directories, whole disks can be shared. This is most useful for sharing changeable media devices such a Compact Disk drives or diskette drives.
'''COM Ports'''
   
Communications ports can also be shared which leads, in some circumstances, to the sharing of modems and so on. I say in some circumstances because although the shared port on the using (client) workstation appears as a new COM port, there is no physical port present of course. Thus the application that uses the shared port on the client workstation must use it entirely through the virtual redirected port and not try to directly access the hardware.
Generally, the shared resource appears on the client workstation as a local resource. For example, shared printers appear as local printers and shared directories appear as local disks. When shared resources appear on the client workstation like this they are called network or redirected devices.
I have subdivided this section into the following parts:
* Tools
* Basic Mechanics
* Controlling Access
* Sharing Resources
* Using Resources
===Tools===
Before we go any further, a quick word about the tools is in order. The basic mechanism for sharing on our home LAN is the OS/2 Peer that comes with OS/2 Warp Connect. This provides us with the ability to setup and use a network of peer workstations with some sharing resources and some using them.
The nice thing about a peer network is that anyone can share his or her local resources. Nothing special is required, for example special server code. That is already included in the peer code. Of course, for regularly shared resources a bit of planning and organisation will tend to put these on designated servers but that is just a matter of configuration not software installation.
There are several tools that enable use to work with the peer environment:
'''Commands'''
The peer environment provides us with a set of commands to enable us to set up resources, share them, control access to them, use them and so on. These commands have the general format:
    NET function parameters...
Except for a couple of examples, we will generally not be talking much about commands. Their real strength is imbedded in REXX command files used to automate some of the LAN administration tasks. For more details, see the online reference in the OS/2 Peer folder.
'''Sharing and Connecting'''
   
This application is found in the OS/2 Peer folder. It is a Workplace Shell program that enables you to define various profiles for sharing your local resources, connecting to remote resources to use them and for controlling access to the resources you have shared.
'''LAN Resource Browser'''
This tool is part of the Network Aware Shell, a series of extensions to the Workplace Shell to facilitate a level of integration between the Workplace Shell capabilities and the resources located on the LAN. The browser may be found in the Network folder along with a shadow to the OS/2 Peer folder. The full name of the browser is LAN Server and OS/2 Peer Resources.
The browser may be used to login to the LAN environment. Just click on it with mouse button 2 to get the context menu and then select the Login... menu item. To logoff again, just select the same menu item, now called Logout....
However, the major function of the browser is to browse the resources available to you on the network. Open the browser to see all the workstations you can access from your workstation. The workstations shown will be all those in your own peer domain, that is with the same domain name.
Opening any of the workstations shown will display the resources you can access on that workstation. You can use these resources directly, for example drag files to and from network directories, or you can shadow them onto your desktop and assign drive letters or printer devices to them as appropriate.
'''Workplace Shell'''
The peer environment is fully integrated into the Workplace Shell to present a seamless environment. For example, each resource that can be shared, disks, directories, printers and so on, has a Share... menu item added to its context menu. This can be used to perform the following actions:
* Start sharing
* Stop sharing
* Configure sharing
* Control access
* Apply access permissions
We will find out more about these operations below. In addition, the following extra pages are added to the settings notebooks of all shareable resources:
* Shares
* Access controls
Apart from these peer specific operations, the Workplace Shell makes no distinction between network resources and local resources when you use them which makes for an integrated single system image environment.
'''User Profile Management '''
This tool is used to define users and groups of users to whom resource access may be granted on a particular workstation. In order to be able to access a resource on a particular workstation, users must be defined on that workstation using UPM. The User Account Management application in the UPM Services folder is used to define these users. This folder also provides a Logon and Logoff icon however I recommend the use of the LAN Resource Browser for this task. Refer to the OS/2 Peer documentation for more details on UPM.
===Basic Mechanics===
The first thing to consider when setting up an environment to share resources is to decide what resources you want to share and which workstation should own them. In other words, which workstation should be a server.
Purely from a software point of view, any of the workstations can be a server. It is usage and capacity that determines the best server candidates.
Any workstation that isn't on the network 100% of the time makes a poor server. Also any machine that gets rebooted a lot or has dual boot installed and is sometimes booted as a DOS or Windows 95 system is also a poor choice. These are the usage factors you must consider.
Capacity is largely dictated by what you want to do. You don't need an enormous amount of power to serve a disk to two or three LAN users. I comfortably accomplish this using an old 50MHz 486 with not new IDE disks.
What you do need to share a resource is enough of the resource to share. Thus sharing a disk with only 20MB of free space is essentially a waste of time. Estimate how much disk space will be required by your users, double it and add 20% for safety, add what the local system will consume and you will have a reasonable estimate for your disk requirements.
To set up the server, you must have IBM Peer for OS/2 Warp installed and started. In particular, you must have the Peer component started which is the installation default. To perform any sharing or using, you must also be logged on to the workstation at which you are performing the work. Controlling Access has a complete overview of the security mechanism.
The act of sharing a resource is essentially the act of creating a special name, called a Network Name, which is understood by the server software and is used by the client software to access the resource. Network Names, generally called NetNames, can be created in various ways. For example, to share a directory called C:\Public\GeneralArtwork you could issue the following command on an OS/2 command line:
NET SHARE GENART=C:\Public\GeneralArtwork
This would create a netname, GENART, that refers to the directory resource, C:\Public\GeneralArtwork. Client workstations can then access this shared resource using the netname in the following command:
NET USE X: \\SERVER1\GENART
Where SERVER1 is the name assigned to the server workstation when you installed OS/2 Warp Peer. Don't get confused with TCP/IP host names which are different. In fact, as a tip I recommend you make these the same so you have less to remember but otherwise there is no connection. The X: is a drive letter of your choice which should not be used anywhere else on your workstation. When the command is executed, the shared directory will look like drive X: on the client workstation.
Commands are useful to show us the raw mechanics behind the sharing mechanism. However, we have a number of visual tools to protect us from the nasty brutish world of the command line:
* Sharing and Connecting Application
* Network Aware (Workplace) Shell
* LAN Resource Browser
These are the tools we shall be working with for the most part. For full details on the command set, see the Commands and Utilities online manual in the Books folder inside the OS/2 Peer folder.
===Controlling Access===
Before we go too much further, we need to check out the security system that forms part of OS/2 Warp Connect. Like any resource you share across a network, disks, directories, printers and so on all need to be protected from unauthorised access. The OS/2 Warp Connect security system, User Profile Management (UPM) performs this function.
There are two parts to the security system. The first defines authorised users and allocates user identities (userid) and passwords to them. The user can then identify themselves by logging into the system supplying the userid and password. The second part concerns determining what resources the user can have access to and granting that access when requested.
The first part is performed entirely within the UPM system. Within the UPM Services folder on the desktop after OS/2 Warp Connect has been installed is a tool called User Account Management. This is used to define each user you want to have access to your workstation. Larger organisations can gather defined users into Groups for easier management.
During the installation of OS/2 Warp Connect, you are prompted for an initial system administrator userid and password. This should be set up for the workstation's user who should also be configured as the workstation's system administrator. You must login using this userid and passowrd to use the facilities of UPM account management.
You could login using the Logon/Logoff icons in the same UPM folder. Alternatively, you could login using the login menu item of the LAN Server and OS/2 Peer Resources icon in the Network folder. I prefer this latter method as it links in with the Network Aware (Workplace) Shell we will be discussing later.
Access to shared resources on a server workstation is controlled by an access control profile called an Access Control List (ACL). These are special profiles maintained by the Peer software containing a list of userids or group names granted access to the resource and the level of access granted.
All shared resources must have an ACL associated with it even if it just grants full read/write access to PUBLIC. We will cover the detail of creating access control profiles when we discuss setting up shared resources as that is generally the time we would create the profile for the resource being shared.
[[Image:NetShareConcepts03.gif]]
In a peer network such as the one we are contemplating, to use a shared resource a user must logon on their own workstation with their allocated UPM userid and password. This means the userid and password must be defined on both their own workstation and the server workstation they wish to access. Whenever they connect to a shared resource, the userid and password they are logged on locally with are passed to the server for validation there. Again, this means the userid and password must also be defined on the server workstation.
The environment has two provisions to help reduce the work of maintaining all these userids and passwords. Firstly, you can set up resources as publicly accessible and that therefore require no userid and password to use. Secondly, when you set up connections, you can specify that you want to be prompted for a new password if the server password differs from the local one.
For more information about access control, UPM and logging in and out, see the relevant sections in the Commands and Utilities and User's Guide online books in the OS/2 Peer folder.
===Sharing Resources===
Sharing resources can be accomplished in one of three ways, commands (NET), the Sharing and Connecting application and the network aware extensions to the Workplace Shell. We won't be looking at the NET commands much. There usefulness lies in the fact that they can be included in REXX command files which enables you to automate a lot of routine tasks.
[[Image:NetShareConcepts02.gif]]
Sharing and Connecting is started using the icon shown which is found in the OS/2 Peer folder. This shows a window containing a notebook with three tabs:
* Connections
* Shares
* Access Control
The Connections page is used to view what resources your workstation is using on other workstations. We will look at this page when we discuss using resources in the Using Resources section below.
Of the other two tabs, the Shares page is used to create, alter and delete profiles describing resources owned by our workstation and which are to be shared and describing when they are to be shared. The Access Control page is used to create, alter and delete access control profiles.
Sharing a resource requires three steps:
# Describing the resource in a share profile
# Authorising access in an access control profile
# Initiating the share using the share profile
The first step, describing the resource, can be done using the Shares page of the Sharing and Connecting application or using the resource's Workplace Shell context menu.
Using the Sharing and Connecting application, switch to the Shares page, pull down the Share menu and select the Create... menu item. Select the resource type from the resulting dialog and press the Ok pushbutton.
On the resulting panel, fill in the resource details including a description and so on. The share name is the public netname used to access the resource when it is shared. You can also limit the number of users that can access a particular resource at any one time. This is useful to enforce licensing requirements for programs you put in shared directories.
The ''Start Sharing...'' checkbox enables you to specify this resource is to be shared when the peer service is started, normally when the workstation is booted. If you don't specify this option, you must manually share the resource when it is required.
The ''Grant access...'' pushbutton provides a tie in to the access control management environment available from the Access Control page. This enables you set up an access control profile for the specific resource you are creating a share profile for now and this would probably be the normal way you create such profiles.
Pressing the Grant access... pushbutton displays the Grant Access dialog. This dialog has two sets of contents depending on whether you choose to grant Basic access or Customized access. Basic sets a simple access level that is applicable for all users no matter what their userid, password or group is. Customized enables you to specify the Groups and/or Users that can access this resource and what access permissions they are granted.
An access permission is a level of access, for example read only, read/write and so on. An additional checkbox at the bottom of the dialog sets auditing on for this resource. When set on, all accesses to the resource are logged in the Audit Log.
When all setting have be made to your satisfaction, pressing the Ok pushbuttons on each dialog returns you to the main page and the share and access control profiles are created. If an access control profile needs to be explicitly created, turn to the Access Control page and use the Create... menu item on the Access pulldown menu.
You should note that you can create access control profiles independent of any particular shared resource. For example, you might have a shared directory to which we grant read/write access. We could create an access control profile for one of its subdirectories restricting access to read only although the subdirectory is not explicitly named in a share profile. When your delete a share profile, you are given the option of deleting the access profiles or leaving them in place. Access control profiles may be created for individual resources without an associated share profile using the Access Controls page.
Another thing to note is the Apply access permissions... menu item on the Access pulldown menu. This copies the access control profile, creating a new one for each subdirectory within a shared directory. Normally, a new access control profile is automatically created when a new subdirectory is created within a shareable resource. However, when you first create the share profile, you must do this manually using this menu item. Note that if you already have access control profiles on some or all of the subdirectories, these will be overwritten.
As we mentioned before, we can bypass the Sharing and Connecting application and use the Workplace Shell directly. To create a share profile and access control profile for a resource, click on it with mouse button 2 to popup the context menu. At or near the bottom, you will see a Share menu item with a cascade arrow. If you don't see the arrow, Peer is not started. Start it, logon and try again.
Click the Share menu item and select the Configure sharing menu item. This will lead you to the same Configure Sharing dialog you reached from the application. The process of creating a share profile and associated access control profile is the same. The details of the profiles can be found in the Shares and Access controls pages of the resource's settings notebook.
If you just want to create an access control profile for the resource, use the Control access menu item from the cascade menu. The Apply access permissions menu item can be used to replicate the profile to all subdirectories if required.
Once the share profile and access control profile have been created for the resource, the last step is to share the resource. This is done automatically for your when you create the share profile. However, if you want the share to be automatically done each time you start the Peer service, you must click the Start Sharing... checkbox when creating the share profile.
If you have not set up automatic sharing for a resource, you must manually share it. This can be done using the functions of the Sharing and Connecting application or the Workplace Shell as before.
With the application, start it, go to the Shares page, select the share profile of the resource to be shared and then select the Start menu item from the Share pulldown menu. Alternatively, you can click the share profile with mouse button 2 to get a popup menu with the same options. The Stop option on either menu is used to manually stop sharing the resource.
Using the Workplace Shell, click on the resource to be shared with mouse button 2 to get its context menu. Select the Share option at the bottom and select Start sharing from the cascade menu to start the share or Stop sharing to stop it again.
Once again, for more information about sharing resources, check out the online documentation that comes in the OS/2 Peer folder. The Sharing and Connecting application help is also useful reading.
===Using Resources===
Once a workstation has shared resources, other workstations can use them by connecting to them using either the same Sharing and Connecting application or the Workplace Shell. In the application, the Connections page is used to set up connection profiles which record the details of the resources you wish to connect to. Connection resources may be currently connected or disconnected. Inactive connections have a small icon in the shape of a broken red lightning zap on them.
Creating a new connection profile is just a matter of pulling down the Connection menu and selecting the Create... menu item. You will be walked through the process of establishing a connection profile for a resource on a server.
In summary, you need to specify the name of the server workstation owning the resource and the netname the resource was shared with. Pulling down the list from the share/alias combo box will show you a list of candidate workstation names to select from. You will then specify the name, for example drive letter, by which that shared resource will be known on your workstation.
Setting on the Connect to resource at logon checkbox specifies that you will automatically connect to this resource whenever you fire up your workstation starting the peer service. Setting on the Prompt for password checkbox indicates you would like to be prompted for a password should your local one not match any on the server workstation.
Creating the profile will also initiate the connection. To automatically, connect on subsequent starts of your workstation, click the Connect to resource at logon checkbox. If this box is not clicked, you must select the connection profile and use the Start menu item on the Connection pull down menu. Alternatively, click on the profile using mouse button 2 to get a popup menu and select the Start menu item. The connection can be terminated anytime using the Stop menu item for either menu.
As with sharing, the Workplace Shell can also be used to connect to shared resources on the LAN. The main tool for connecting to resources is the LAN Server and OS/2 Peer Resources folder which is normally found in the Network folder on your desktop. This is also used to login and out using the appropriate option on its context menu. I will refer to it from here on as the LAN Resources Browser.
Open the LAN Resources Browser. Inside, you should find an icon for your own workstation and other workstations on the LAN with resources to share. If you can't see the workstation you are after, click on any of them with mouse button 2 to get the context menu then select Access another.... Ignore the first field and type the name of the workstation into the second field, Server, and press the OK pushbutton.
You could try the pulldown option on the Server field but if the workstation isn't in the main folder it probably won't be in drop down list. If the workstation can be found, it will be added to those in the folder. A shadow of the workstation icon also appears on the desktop. This can be shredded if not required.
Having located the workstation owning the resources you are after, you must open it (double click) to see the resources it has to offer. These will shown as icons inside the open workstation folder. You can now access any of the displayed icons directly with no further work. For example, you can drop files onto printers and folders and drag files out of folders and so on. To go further, you can assign a local device name, for example a drive letter or printer device, to the resource by clicking on it with mouse button 2 to get its context menu and selecting the Assign... menu item.
Unlike the Sharing and Connecting application, using the Workplace Shell does not set up a permanent connection profile that can be used again and again. It just sets up a one time connection to the resource. Next time you start up your workstation, you will have to re-establish the connection manually. You can streamline this process by dragging shadows out of the LAN Resources folder and placing them where they are more accessible.

Revision as of 21:25, 6 June 2013

By Nicholas McGuigan

So! You have just bought your second PC and you have given your old one to the kids (or you're the kids!). You need to transfer files between the old and new systems. The kids want more disk space and access to the fancy printer you bought with the new system.

Yes, you are discovering the delights of a multi-system household that in this day and age can include laptops from work, spouse desktops and kids games/school machines. Businesses have been tackling this type of environment for a long time now with a tool called a Local Area Network or LAN for short. Why shouldn't you do the same?

No reason at all! Today, LAN hardware is cheap, reliable and readily available. With OS/2 Warp Connect, so is the software needed to drive it. With a LAN using these components, you can share disks and printers with other systems connected on the LAN using Peer for OS/2, you can transfer files directly between them using TCP/IP for OS/2, share clipboards and DDE sessions and do personal conferencing with Person to Person. All this and more can be accomplished with just OS/2 Warp Connect and nothing more to pay.

This article looks at how you would go about implementing a LAN in your home using the capabilities of OS/2 Warp Connect. I will mostly be concentrating on stuff you can do without having to buy anything extra. However, occasionally I will show how you can build on the base infrastructure with additional components.

Concepts and Terminology

If you are knowledgeable about Local Area Networks and the like, you can probably skip this section. It is mostly designed to level set readers who haven't had much to do with them by introducing them to various basic concepts and terminology.

Firstly, the "home network" we are talking about is a Local Area Network (LAN). So what is a LAN? Very simply, a LAN is a communications network in the form of a piece of wire that runs around the area connecting up all the PCs that need to talk to each other.

It is called a Local Area Network as it generally connects up small areas such as the rooms in your dwelling, small offices, corporate departments and so on. Connecting up dispersed locations, for example an office in Melbourne to one in Detroit, requires a different type of network called a Wide Area Network (WAN).

The shape the LAN wire takes is called its topology and the way the signals that flow across it are formatted is called its communications protocol. There are two common protocols:

Ethernet

The Ethernet communications protocol uses a straight section of wire called a bus with special terminators at each end. Multiple buses can be connected together to form larger networks. Newer forms of Ethernet, 10BaseT for example, are implemented using a central hub and look like star wired networks. However, inside they resolve down to a bus like the other forms.

Connected into the bus are the PCs that need to communicate using the LAN. These compete for use of the LAN by trying to transmit and then listening to see if they were successful. For more details, see Ethernet LANs.

Token Ring

The Token Ring communications protocol uses a ring topology with the wire in the form of a loop. The loop is actually implemented in a central hub called an MSAU or MAU or, more lately, CAU with LAMs. The PCs are connected via wires that plug into the hub giving it a star wired appearance.

Access to the LAN is controlled by a token that is passed from PC to PC. The way this is done ensures that each PC gets a fair share of the LAN and enables high LAN utilisations are achieved. For more details, see Token Ring LANs.

To be part of a LAN, each PC must have a LAN Adapter card installed and this must be attached to the LAN, usually by a piece of cable.

It must be emphasized that a LAN is not owned by any of the applications that run over it. There is no such thing as a Novell NetWare LAN or a Windows LAN. Each and every LAN enabled application can run side by side and independently of every other LAN enabled application. Thus you can have NetBIOS, IEEE802.2, IPX, SNA LU6.2, TCP/IP and other conversations all taking place simultaneously. The one thing that does characterise a LAN is its topology and fundamental LAN communications protocol, that is whether it is Ethernet or Token Ring.

The next piece of the puzzle is the PCs that attach to the LAN. I will often refer to these as Personal Workstations or just Workstations. Such a workstation can operate in either of two roles, a client which uses the resources that other workstations own and share and a server workstation which does the owning and sharing.

In the LANs created in corporations, these roles are usually quite distinct with special workstations being setup in groups as servers and with all other workstations operating as clients. The clients generally have human operators whereas the servers are locked away somewhere and operate unattended.

In general, the set of workstations operating together on a LAN may be quite heterogeneous. For example, we could quite easily encounter Windows, OS/2 and Apple clients all operating together. This can also be the case at home. For example, I am very happy with OS/2 and have designed my LAN around its use. However, my children are attending schools that insist on Apples.

You may expect a future article on how I dealt with this problem but for the rest of this one, I will assume for simplicity we are talking OS/2 Warp Connect workstations. As Warp Connect shares a common protocol, namely Server Message Block (SMB), with Windows for Workgroups, Windows NT, IBM LAN Server and some others, most of the stuff we talk about can be very simply extended to Windows family clients.

The LAN with its LAN communications protocols, Ethernet and Token Ring, provides the basic connectivity between the individual workstations. If you like, it is the road network connecting the various sites. However for it to be useful, it must be used for something. In other words, someone must drive trucks and cars across it. Those someones, or somethings in this case, are applications and the trucks and cars are the higher level communications protocols such as NetBIOS and TCP/IP.

NetBIOS is a relatively simple protocol that enables two LAN-attached workstations to communicate by passing messages. The workstations must be attached to the LAN as NetBIOS doesn't operate over a WAN. NetBIOS is used as a base for a lot of LAN traffic such as Disk and Printer Servers and so on.

TCP/IP is a communications protocol that can be used to connect workstations in both a LAN and WAN environment. It has a higher overhead than NetBIOS but has more general purpose functionality defined for it including additional protocols such as File Transfer Protocol (FTP), Telnet and the mechanism you are probably using to view this document now, Hypertext Transfer Protocol (HTTP).

When setting up our home network, we will configure both NetBIOS and TCP/IP for our use. However, there are a number of other protocols that are commonly found in a LAN environment. These are:

IEEE802.2

This was supposed to supersede the defacto standard NetBIOS as a standard protocol to connect Ethernet or Token Ring attached workstations over a LAN. In practice, it is used for some 3270 Emulators and not much else that I can see.

APPN/LU 6.2

This is an efficient and highly reliable communications protocol used much in the "big iron" shops where these characteristics are valued. Like TCP/IP, is can be used to connect workstations across LAN and WAN environments.

IPX

This protocol is used by Novell NetWare clients and servers and not much else. In pure NetWare only environments, it is an asset. In the more common mixed environments, it is a problem to be solved.

We briefly discussed the concepts of client workstations and server workstations above. A server workstation is one which owns resources that it subsequently makes available to or shares with client workstations who are the users or consumers of those shared resources. There are numerous different types of servers that can be set up including:

  • Disk
  • Print
  • Application
  • Web
  • Communications
  • Database
  • Security
  • Directory
  • Systems Management
  • Lotus Notes

And lots more. In the course of this article, we will be discussing Disk and Print servers in depth and Communications and Web servers in passing.

Servers are usually implemented by a piece of code (program) that manages the shared resource and provides access to it via the selected communications mechanisms. Client workstations usually have a corresponding piece of partner code, often called the client or requester, which is used to access the resources managed by the server.

We discussed earlier how it was common practice to have a set of workstations performing the role of server and the remainder performing the role of client. In a lot of corporate environments, these roles are fixed. However, there is an alternative type of networking, called peer networking, where each workstation can take on the role of pure server or pure client or both at the same time. OS/2 Warp Connect provides a function called IBM Peer for OS/2 Warp which enables this type of networking and this is what we will be using to set up our home network.

Normally, when setting up your own home LAN, there is quite a bit of software to assemble to do it all. Add to this that if you want to do it in a Microsoft Windows environment, you will have to be an expert in DOS memory management and other esoteric concerns. However, with OS/2 Warp Connect, all the pieces of the puzzle are in one package. You get the wherewithal to access the LAN using NetBIOS, TCP/IP, IEEE802.2 and IPX, to set up disk, printer and communications (COM port) servers, transfer files about (FTP), use each other's workstations (Telnet), perform remote management (Telnet, FTP), conference (P2P) and much more without shelling out a brass razzoo extra and without having to worry about Upper Memory Blocks (UMB) and the like. To fill you in on the details, the next section will do a review of what's in OS/2 Warp Connect.

Warp Connect Overview

For those of you that haven't met OS/2 Warp Connect, this section will briefly review what is in it and how it relates to its siblings, IBM OS/2 Warp for Windows (a.k.a. Warp Red Spine/Box) and IBM OS/2 Warp with WINOS2 (a.k.a. Warp Blue Spine/Box).

In essence, OS/2 Warp Connect is the same OS/2 Warp we know and love together with an additional set of client connectivity options for use in a networked environment. As with original Warp packages, there are two versions, one for a native Windows environment and one with WINOS2 and, yes, I believe they have red and blue spines although I haven't personally laid eyes on the former. The BonusPak remains unchanged.

So what are the connection options provided and how do these position Warp Connect in the market? The following options are provided as part of the Warp Connect package:

  • Multiprotocol Transport Services (MPTS)
  • TCP/IP for OS/2
  • LAN Server Requester or Peer for OS/2
  • Netware Client for OS/2
  • LAN Distance Remote
  • Lotus Notes Express

These are described in more detail in the next sections along with the following topics:

  • Installation
  • BonusPak Contributions


Multiprotocol Transport Services (MPTS)

Multiprotocol Transport Services (MPTS) is an implementation of the Multiprotocol Transport Network (MPTN) architecture. It provides support for protocols such as NetBIOS, TCP/IP and IEEE 802.2 over a variety of media such as Ethernet and Token Ring local area networks (LAN).

In addition, MPTS implements a software layer called Common Transport Semantics (CTS). This is a framework that supports a mix-and-match approach to protocols and the application programming interfaces (API) used to drive them. For example, using the MPTS supplied with Warp Connect you can run NetBIOS over TCP/IP and can add additional products to run Sockets over SNA and LU6.2 over TCP/IP.

If you didn't quite get all of that, don't worry. It has very little to do with home networking. From our home LAN perspective, MPTS and the various protocol and MAC drivers that are part of it are just the software glue that attaches our workstation to the LAN.

TCP/IP for OS/2

Warp Connect has a full version of TCP/IP which supports both SLIP and PPP dial up connections and LAN connections and can do so simultaneously.

You may be familiar with the BonusPak IBM Internet Access Kit (IAK). This was implemented on IBM TCP/IP for OS/2 (Version 2) which had been stripped down to restrict it to dial (SLIP, PPP) connections only. The new kit not only removes the restrictions but is a new version as well.

You should note that the original IAK is available still on the BonusPak as before. If you install the full TCP/IP implementation as part of the Warp Connect install, you should not install the BonusPak IAK. All the familiar IAK tools are installed as part of the full product anyway.

LAN Server Requester or Peer for OS/2

Both of these products are provided but you can only install one. For home networking in particular and for most business applications, I recommend the OS/2 Peer product.

So what are these things. Both provide a client requester function, sometimes called a redirector, to servers that communicate using a protocol called Server Message Block (SMB) over NetBIOS and, more lately, TCP/IP. Servers of this type include IBM LAN Server and Microsoft NT Advanced Server.

Using the requester function, we can make drives, directories and printers accessible on our own system. For example, one of the servers shares a directory and we can make it look like a drive, called a network drive, on our system and then use it like we would any other drive. There are a number or trifling details like security and access permissions that interfere with this vision of paradise but I will deal with them later.

In addition to the requester function, both products provide a peer function and it is here we can differentiate the two. The peer function enables the normally client code to function as a server, albeit in a more limited sense. In other words, I can decide to share directories and printers with authorised users without having to install a full function server package. Clipboard and DDE sharing is also supported.

The LAN Server Requester product is quite limited in its implementation of peer services. It can only support one user of a shared resources and its user interface for sharing is quite limited. Peer for OS/2 is more more of a proposition. It really implements a mini-server with a simple and attractive user interface and features complete integration with the Workplace Shell. Multiple remote users are simultaneously supported.

Netware Client for OS/2

This is much the same sort of deal as the LAN Server Requester but for Novell NetWare servers instead. This is good news if you have a Novell server but they are a bit rich for home use so I will dwell no more upon it.

LAN Distance Remote

The good news is LAN Distance provides you with a way of extending your LAN across the telephone network. Thus if you have a mobile system, you can dial your LAN and effectively become part of it remotely, using all the same stuff you use when connected locally.

The bad news is that LAN Distance Remote is the client piece that can connect your workstation to the LAN. You need the server piece, LAN Distance Connection Server, to catch the Remote call and make you part of the network.

For the most part,I want to stick to talking about stuff that you can do right out of the Warp Connect box. However for this category, I will talk about the whole LAN Distance setup in Remote Access because of the powerful additional dimensions it opens for us.

Lotus Notes Express

With some copies of OS/2 Warp Connect, a "Lite" version of the Lotus Notes client, called Lotus Notes Express is included as a promotion.

Although a Notes setup can greatly increase the function available in a home LAN, it does require additional software to implement a Notes Server and a level of skill and planning beyond what is required for the rest of functions described in this article. Highly recommended if you have the skill, finances and energy but we won't be covering it here. Installation

On top of all the features and functions we have described above, Warp Connect has a very nice installation process which takes the hassle (some would say fun) out of installing all this stuff.

The familiar plain OS/2 Warp install is present as before. The install proceeds through the initial character based phase to the Presentation Manager phase. At the end of the standard install dialogs during the Presentation Manager phase, a new set of dialogs prompt for details of the desired communications environment. It is here you select which functions you want and how you want them to be configured. After that, just watch the blinking lights until the install is complete and your workstation has rebooted itself.

BonusPak Contributions

The BonusPak supplied with OS/2 Warp Connect is identical to that supplied with the other Warp siblings. The only major change is under Warp Connect you would not normally install the Internet Access Kit as this function, much expanded, is provided by the TCP/IP Version 3.0 installed as part of the base.

As you would know if you have used OS/2 Warp before, the BonusPak is stuffed full of nice to have goodies. However, there is one feature included that can significantly add value to our home LAN, IBM Person to Person, the IBM personal conferencing system.

Person to Person (P2P) provides a number of functions that enable a group of up to eight (8) users to share information in the following ways:

  • Exchange messages
  • Share and annotate information
  • Share clipboards
  • Video conference

NetBIOS and TCP/IP connections are supported as well as POTS phone links, ISDN, SNA and so on. Personal conferencing and its implementation on your home LAN is covered in Personal Conferencing in this article.

Getting Wired

In this section, we will look briefly, very briefly, at the physical wiring required to implement our home LAN. Essentially, this boils down to a choice of two LAN types, Token Ring and Ethernet. We will look at what these are and what the implications are when wiring up a home LAN in the following sections:

  • Token Ring LANs
  • Ethernet LANs
  • Making a Choice

Token Ring LANs

Although sometimes the actual wiring doesn't appear like one, this is a loop of wire to which the participating workstations are connected. Use of the wire is very orderly, being controlled by a token which is passed from system to system.

The token is a short empty message. When it arrives at your workstation and is free, you may attach a message to be sent to another workstation on the LAN. The token is now no longer free and each participating workstation just passes the message on until it reaches the target workstation.

The target reads the message and then passes it on again but with a received flag set on. Again the token is passed around until it reaches the original sender who now generates a free token which is passed on to the next workstation in the ring. Using the token ring protocol, which is defined in IEEE 802.5, every workstation gets a chance in turn to use the LAN leading to predictable performance and high utilisation (up to 80%).

To implement a token ring LAN, each machine must have a token ring LAN adapter. The actual token ring is implemented in a hub. There are various types of hub ranging from the simple unpowered IBM 8228 Multistation Access Unit (MSAU) to some very fancy powered stuff with network management and a price tag to match.

The workstation adapters are connected to the hubs by wire of varying types, for example Unshielded Twisted Pair (UTP) or Shielded Twisted Pair (STP), depending on the type of hub used. Hubs may be strung together to make a big single ring and multiple rings may be bridged together to make larger structures.

Ethernet LANs

An Ethernet LAN is actually a type of shared bus although again the physical wiring can hide this. The protocol by which the participating workstations gain access to this bus is called Carrier Sense Multiple Access/Collision Detect (CSMA/CD).

CSMA/CD is quite different from the orderly sharing scheme of token ring LANs. The workstations compete for access by first listening to see if anyone is transmitting. If the LAN is occupied, they wait a bit and try again. When the LAN is free, the workstation transmits its message which it simultaneously reads back again. By checking the received message with the transmitted message, the workstation can tell if someone transmitted at the same time, called a collision, and corrupted the message. If a collision occurs, each collider backs off a random amount of time and then tries again.

CSMA/CD is quite easy to implement and is very effective at low utilisations. However, over about 30% utilisation, a considerable proportion of the available bandwidth is tied up in collisions and retries which has a major impact on throughput.

As with token ring, each participating machine must have an Ethernet LAN adapter in it. Unlike token ring, a hub is not necessarily required. The simplest form of Ethernet LAN is a straight piece of wire terminated at both ends. The wire runs through connectors in the back of the LAN adapters. Other Ethernet types, for example 10baseT, utilise hubs.

Making a Choice

So what does all that mean. For the home user, virtually nothing. It is unlikely that load and throughput considerations will drive the LAN type decision in the home so other factors, mainly price, will be much more important.

In the price department Ethernet is considerably cheaper than token ring. Adapters are generally very cheap. For example, $75 Australian should get you something quite serviceable and there are cheaper ones out there. The straight wire version of Ethernet using thin Ethernet wiring is the scheme I would recommend for the same price reasons. Hubs are expensive and should be avoided in home implementations unless you have a large extended family with lots of machines and a pressing need for improved system management.

That said, the question remains as to why you might choose token ring. I must confess I have a token ring setup. My decision was driven by the fact that my company uses token ring in the office and so the mobile I use, an IBM Thinkpad 755CE, comes with a PCMCIA token ring card. My choice was to go Ethernet and have to obtain a PCMCIA Ethernet card or to stay token ring and buy a ISA bus token ring card for my designated server and a hub.

I chose the latter course as I was able to obtain a good deal on a hub and and a LAN adapter. Together these came in as less dollars than a PCMCIA Ethernet adapter which is a bit more pricey than the cheapies I mentioned above. It also saved me the hassle of swapping from token ring to Ethernet every time I moved from office to home and vice versa.

In summary, my recommendation is to go for the Ethernet option avoiding hubs. Make sure you choose a set of Ethernet adapters supported by OS/2. Warp's support is fairly comprehensive but it doesn't hurt to check. Get some advice about wiring and stuff unless you're a wiz on that topic. Then wire up your home to the level that suits you. This can range from a wire along the back of your workbench up to a fancy set of wall mounted faceplates in each room holding a participating machine. My hub is balanced on top of a pile of bricks and the connecting wires trail along the back of the desk. It works for me!

Whatever decision you make, OS/2 Warp Connect will support either transparently to the applications that use the network. How this happens and what you need to do to set it up is covered in the next section.

Basic Setup

This section deals with the basic requirements for implementing the home LAN installation using Warp Connect. It covers what to install from the OS/2 Warp Connect package and configuring the basic communications components, the LAN connection using MPTS and the TCP/IP environment. It finishes with a summary of what you should have when these steps have been completed.

  • What to Install
  • Configuring the LAN Connection
  • Configuring TCP/IP
  • Configuring Peer for OS/2
  • Installation Summary

What to Install

We have had a general look at the contents of the OS/2 Warp Connect package in the Warp Connect Overview section. However, as we pointed out in that section, not all the features are suitable for use in a home LAN. These are the features I recommend you install for this environment:

IBM Peer for OS/2

This provides the mechanism for sharing and using shared resources such as disks and printers across the LAN.

IBM TCP/IP

This provides the communications support from transferring data between workstations and terminal access to the server if required.

IBM Person to Person

From the BonusPak, this provides the basis for personal conferencing around the LAN using either NetBIOS or TCP/IP.

IBM LAN Distance Remote (Optional)

Together with the additional IBM LAN Distance Connection Server, this provides the capability for remote dial in access to the home LAN. You should only install it if you plan on obtaining the connection server. See the Remote Access topic for more details.

Installation of all these except IBM Person to Person (P2P) is done during the main system installation procedure. P2P must be installed from the BonusPak CD in the normal way. The Multiprotocol Transport Services (MPTS) is installed automatically if you select any communications options.

During installation, you have the opportunity to specify what configuration details you require. The configuration information for the base communications products, MPTS, TCP/IP and Peer for OS/2 are covered in the next sections.

Configuring the LAN Connection

For our purposes, MPTS implements an NDIS compliant environment to support your LAN adapter and to provide simultaneous access to it from a variety of protocols. MPTS provides the environment, supporting software and the protocol stacks (drivers) for NetBIOS, IEEE802.2 and NetWare. The TCP/IP product provides an additional stack for TCP/IP.

You must provide a LAN card. If the card is known to Warp Connect, the installation process will select the appropriate driver. If not, you must supply an OS/2 NDIS compliant MAC driver for the card. You will be prompted for this during the install procedure.

Whether you use a known adapter or supply your own, you will be prompted to supply configuration information for the adapter. This information is fairly straightforward, for example interrupt level to be used, default ringspeed for token ring and so on.

Once the main installation is complete, you should have a working system. However, if you need to change it or just have an insatiable curiosity, you need to use the MPTS program. Two icons for this program can be found on the desktop with one of them being shadowed into the Network folder. Start it up, select Configure and then LAN Adapters and Protocols and you see a screen like the one shown here.

The top two boxes enable you to select an adapter (left) and then assign protocols to be used with it (right). The result is shown in the bottom box as an adapter entry with a series of assigned protocols indented underneath. Multiple adapters can be defined in this way with the same or different sets of supported protocols. Double clicking on any line, adapter or protocol, or selecting them and pressing the Edit pushbutton enables you to specify or modify various settings.

Once complete, pressing the Ok pushbutton rebuilds a file called PROTOCOL.INI which is used to initialise the LAN setup at boot time. If you change anything, you must reboot to effect the changes.

Now the OS/2 Warp Connect installation does a pretty good job at setting up the LAN environment so what are you likely to end up changing in the setup? Generally, the only thing I find it necessary to tune up a bit is the NetBIOS Sessions, Commands and Names. These can be changed by double clicking on the NetBIOS protocol entry for the adapter.

The file LANTRAN.LOG is created during the boot and contains a message saying how many sessions, commands and names are available after the Peer for OS/2 has taken its allocation (see Configuring Peer for OS/2 for more details) so use this to juggle the figures if you are having NetBIOS connection failures due to insufficient resources.

Configuring TCP/IP

The main details of the TCP/IP configuration are dealt with during the system installation. You will be asked to supply the following information:

  • IP Address
  • Subnet Mask
  • Host Name
  • Domain Name

To be a TCP/IP host, you must have an IP address. Most of the other paraphernalia of an IP network, Routers and Domain Name Servers, aren't applicable to the home environment and should be left blank on the prompt dialogs.

What IP address should you use? Generally, your home system will be separate from any other network so you can pretty well make your own IP address up. If you are connected to another network, you will need a router and an allocated IP address. In this case, contact the administrators of the other network and ask their advice.

Without belabouring the details, an IP address is a set of four numbers separated by dots. Each of the numbers can range from 0 to 255, that is the range of an 8 bit number. For example, 9.185.106.25 is my IP address allocated to me by my company. For your private home scheme, I recommend you take a scheme like 100.100.100.xxx and vary the xxx piece from 1 to 255 with each of your home systems getting a unique number.

Another piece of arcana you will be required to specify is the Subnet Mask. If you use the scheme suggested above, a Subnet Mask of 255.255.255.0 should be used. If you use a scheme of your own, you know enough to decide on your own subnet mask.

The host name is a plain text name by which your machine is known throughout the TCP/IP network. (Note: a TCP/IP network is called an internet. The Internet is just a network of internets that is publicly accessible.) For example, the system I am writing this on has a host name of nicholas.

A domain name is a sequence of plain text names separated by dots. Each plain text name represents a domain under the control of a specific administering authority. For example, au.ibm.com is the domain name of the system being used to write this. Strictly speaking you don't need much of a domain name for the home environment but a scheme such as familyname.home is suggested.

If you move a mobile between work and the home, you may want to have the home environment's setup look like the work environment. Thus you could have the same IP number, subnet mask, host name and domain name. This would enable to avoid fiddling with the configuration each time you move the mobile.

Moving mobiles is a bit of a pain in IP networks as your IP address is tied to routers which don't move. One solution to this problem is a protocol that enables machines to be allocated an IP address dynamically. IBM OS/2 Warp Server has such a capability built in for example. However, these are a bit beyond the scope of our home LANs.

The main system install is complete as far as the definitions required for the local system. However, you will need to modify the configuration to add the names of your other systems. In a larger environment, for example at work, this would be taken care of by a Domain Name Server (DNS). This is a piece of code that takes a host and domain name and returns the corresponding IP address for that host. In the case of our home LAN where there is no DNS capability, we must specify the names of each host in the network together with its IP address.

Specifying these additional pieces of information is done using the TCP/IP Configuration program found in the TCP/IP folder on the desktop. You can do all the configuration by fiddling with text files in the %ETC% directory, usually C:\MPTN\ETC. However, the configuration utility is easier to get going with.

Start the utility by opening the icon (double click). A notebook will be displayed. Click on the various tabs to display the different configuration dialogs and make any changes you need to. Once the changes have been made, close the notebook (double click system menu) and reboot the system. The key tabs (right hand side of the notebook) are:

  • Network
  • Hostnames
  • Autostart
  • Security

Network

If you picked right during the main install you probably won't need to mess about with this page. This is where the IP address and subnet mask for the host are specified.

If you add a second LAN adapter, you will need to make changes here as well. IP addresses are actually assigned by host and LAN adapter pair. Each adapter represents a different network as far as the host is concerned and must have a separate IP address. To set the new adapter details, click on the next adapter name, for example LAN interface 1, in the list box on the left and fill in the IP address and subnet mask on the right. Don't forget to enable the interface using the check box at the top.

Hostnames

There are two pages on this tab, the first contains the workstation's hostname and the local domain name. If the main install went ok, you probably don't need to change them but this is where you do if you need to. You can ignore the list boxes underneath in our simple home LAN environment.

The second page is where we specify the other hosts in our home LAN. To reach it, click the forward button at the bottom left of the first page. Using the Add, Change and Delete pushbuttons below the listbox, enter a list of IP addresses and host names for the machines on your home LAN. When finished, click on the checkbox just under list box. This will ensure this list is used to resolve host names.

Autostart

This page is where you specify what TCP/IP services are to be automatically started when TCP/IP is initialised. What you specify here will be different depending on the role you have selected for the machine being installed. For a designated server, I would configure ftpd and telnetd to autostart. For other systems, you must decide how you want to work with these services. On my own system for example I have ftpd configured to autostart but not telnetd.

If you are going to autostart services, I recommend you use the inetd super server daemon. This starts the other services within the same OS/2 session and only when there is an incoming request for them. To configure, click on the inetd entry in the Services to autostart listbox and then check the Autostart service check box on the right.

If you are going to autostart telnetd, you should then click on the Foreground session radiobutton and check the Minimized checkbox. This is because the Telnet daemon runs as an OS/2 fullscreen session and the inet daemon cannot start such processes if it is running detached. If Telnet is not being autostarted, click the Detached radiobutton.

For both ftpd and telnetd, click the name in the Services to autostart listbox and then check the Autostart checkbox and the Inetd super server daemon radiobutton. If there any other services you would like to start, configure them in the same way.

Security

This is where you specify a password for incoming Telnet users and userids and passwords for FTP users. For Telnet, just enter a suitable password. This ends up being added to the CONFIG.SYS as a SET statement as follows:

SET TELNET.PASSWORD.ID=password

The upshot of this is if someone gets physical access to your system, they find out your Telnet password. Don't give anyone FTP access to your CONFIG.SYS or to your %ETC% directory.

To add FTP users, click on the FTP access protection listbox and use the Add pushbutton. We will talk more about the requirements here in the section Transferring Data.

Configuring Peer for OS/2

Peer for OS/2 is a NetBIOS application and draws resources from the pool of NetBIOS resources configured using MPTS as described above. It should not be necessary to modify the NetBIOS resources Peer requires or any of the other possible settings but if you need to, they are all found in the IBMLAN.INI file in the C:\IBMLAN directory.

The number of sessions, commands and names that Peer will use from the NetBIOS resource pool is specified in the NETx statements that are found near the top of the file in the section called [networks]. There is one for each LAN adapter so for our home LAN, NET1 is likely to be the only one present. The following figure shows what the values specified represent:

There is quite a lot of stuff specified in the IBMLAN.INI but the good news is it doesn't need to be changed for our environment. However, have a browse through it to get your bearings. Some of the comments make interesting reading. If you do decide to fiddle, make a copy of the original so you can get back to it easily.

The only thing that might need some attention occasionally is the Computername and Domain values. Computername is the NetBIOS name assigned to your machine on the network. Domain is the name of the Peer domain. Essentially, it is a name chosen to identify the group of machines that work together. Various commands use this name to identify other machines owning resources you may want to use. For our home LAN, I suggest a simple domain name such as HOME for your domain.

Both of these names are specified during the main install and, if you are happy with them, you don't need to change them. However, if you do, they are in the IBMLAN.INI at the bottom of the section marked [requester]. Changing the Domain name is relatively simple but if you change your machine name and others use resources on you machine, you should notify them to update their definitions as well.

Installation Summary

If all has gone well and you performed all the installation and configuration steps described in this section, you should have the following environment:

  • OS/2 Warp Operating System to give you your basic operating system environment.
  • Multiprotocol Transport Services to give you access to the LAN via your installed LAN adapter and which is configured to provide a set of NetBIOS resources and support the use of NetBIOS and IEEE802.5 across the LAN.
  • TCP/IP to provide a TCP/IP protocol stack to MPTS which supports the use of TCP/IP across the LAN. This also provides a familiar set of TCP/IP services such as FTP, Telnet, Talk, Finger, Ping and so on. As a by-product, the Internet Access Kit including the WebExplorer, Gopher, Newsreader/2 and Ultimail/2 Lite are all installed for use over the LAN and dial up connections. As usual, a dialer is provided.
  • Peer for OS/2 to provide the infrastructure for sharing files and printers on your machine with other users and for using files and printers shared by other users.

You may have chosen to install the LAN Distance Remote product as well. If so, review the section Remote Access for information about configuring and using this product.

The next few sections deal with how use this base to share resources and to transfer files and data about the place.

Resource Sharing Concepts

This section covers the sharing of resources on your newly created home LAN. The typical resources you might share are:

Printers

This is an obvious choice. Mum or Dad buys a new beaut but tres expensive printer for their essential business needs (yeah, right!) leaving little Johnnie and Joannie to face the most important years of their lives (school and such) struggling with a dot matrix printer that Noah abandoned when he took to the Ark. Now, thanks to the wonder and convenience of a home LAN, the new printer can be shared amongst all the needy users in the house. The shared printer looks like just any other printer on your desktop.

Directories

Sharing disk directories enables you to share disk space amongst the home LAN users. As in the printer case, this enables the latest large disk purchase to be used by all the family. However, there are some additional benefits as well. These include being able to share what is in the shared directory, for example files and programs, and being able to use shared disk to make copies of files from the client workstations for backup and archive purposes. Shared printers look like additional disk drives to the using (client) workstation.

Disks

Like directories, whole disks can be shared. This is most useful for sharing changeable media devices such a Compact Disk drives or diskette drives.

COM Ports

Communications ports can also be shared which leads, in some circumstances, to the sharing of modems and so on. I say in some circumstances because although the shared port on the using (client) workstation appears as a new COM port, there is no physical port present of course. Thus the application that uses the shared port on the client workstation must use it entirely through the virtual redirected port and not try to directly access the hardware.

Generally, the shared resource appears on the client workstation as a local resource. For example, shared printers appear as local printers and shared directories appear as local disks. When shared resources appear on the client workstation like this they are called network or redirected devices.

I have subdivided this section into the following parts:

  • Tools
  • Basic Mechanics
  • Controlling Access
  • Sharing Resources
  • Using Resources

Tools

Before we go any further, a quick word about the tools is in order. The basic mechanism for sharing on our home LAN is the OS/2 Peer that comes with OS/2 Warp Connect. This provides us with the ability to setup and use a network of peer workstations with some sharing resources and some using them.

The nice thing about a peer network is that anyone can share his or her local resources. Nothing special is required, for example special server code. That is already included in the peer code. Of course, for regularly shared resources a bit of planning and organisation will tend to put these on designated servers but that is just a matter of configuration not software installation.

There are several tools that enable use to work with the peer environment:

Commands

The peer environment provides us with a set of commands to enable us to set up resources, share them, control access to them, use them and so on. These commands have the general format:

   NET function parameters...

Except for a couple of examples, we will generally not be talking much about commands. Their real strength is imbedded in REXX command files used to automate some of the LAN administration tasks. For more details, see the online reference in the OS/2 Peer folder.

Sharing and Connecting

This application is found in the OS/2 Peer folder. It is a Workplace Shell program that enables you to define various profiles for sharing your local resources, connecting to remote resources to use them and for controlling access to the resources you have shared.

LAN Resource Browser

This tool is part of the Network Aware Shell, a series of extensions to the Workplace Shell to facilitate a level of integration between the Workplace Shell capabilities and the resources located on the LAN. The browser may be found in the Network folder along with a shadow to the OS/2 Peer folder. The full name of the browser is LAN Server and OS/2 Peer Resources.

The browser may be used to login to the LAN environment. Just click on it with mouse button 2 to get the context menu and then select the Login... menu item. To logoff again, just select the same menu item, now called Logout....

However, the major function of the browser is to browse the resources available to you on the network. Open the browser to see all the workstations you can access from your workstation. The workstations shown will be all those in your own peer domain, that is with the same domain name.

Opening any of the workstations shown will display the resources you can access on that workstation. You can use these resources directly, for example drag files to and from network directories, or you can shadow them onto your desktop and assign drive letters or printer devices to them as appropriate.

Workplace Shell

The peer environment is fully integrated into the Workplace Shell to present a seamless environment. For example, each resource that can be shared, disks, directories, printers and so on, has a Share... menu item added to its context menu. This can be used to perform the following actions:

  • Start sharing
  • Stop sharing
  • Configure sharing
  • Control access
  • Apply access permissions

We will find out more about these operations below. In addition, the following extra pages are added to the settings notebooks of all shareable resources:

  • Shares
  • Access controls

Apart from these peer specific operations, the Workplace Shell makes no distinction between network resources and local resources when you use them which makes for an integrated single system image environment.

User Profile Management

This tool is used to define users and groups of users to whom resource access may be granted on a particular workstation. In order to be able to access a resource on a particular workstation, users must be defined on that workstation using UPM. The User Account Management application in the UPM Services folder is used to define these users. This folder also provides a Logon and Logoff icon however I recommend the use of the LAN Resource Browser for this task. Refer to the OS/2 Peer documentation for more details on UPM.

Basic Mechanics

The first thing to consider when setting up an environment to share resources is to decide what resources you want to share and which workstation should own them. In other words, which workstation should be a server.

Purely from a software point of view, any of the workstations can be a server. It is usage and capacity that determines the best server candidates.

Any workstation that isn't on the network 100% of the time makes a poor server. Also any machine that gets rebooted a lot or has dual boot installed and is sometimes booted as a DOS or Windows 95 system is also a poor choice. These are the usage factors you must consider.

Capacity is largely dictated by what you want to do. You don't need an enormous amount of power to serve a disk to two or three LAN users. I comfortably accomplish this using an old 50MHz 486 with not new IDE disks.

What you do need to share a resource is enough of the resource to share. Thus sharing a disk with only 20MB of free space is essentially a waste of time. Estimate how much disk space will be required by your users, double it and add 20% for safety, add what the local system will consume and you will have a reasonable estimate for your disk requirements.

To set up the server, you must have IBM Peer for OS/2 Warp installed and started. In particular, you must have the Peer component started which is the installation default. To perform any sharing or using, you must also be logged on to the workstation at which you are performing the work. Controlling Access has a complete overview of the security mechanism.

The act of sharing a resource is essentially the act of creating a special name, called a Network Name, which is understood by the server software and is used by the client software to access the resource. Network Names, generally called NetNames, can be created in various ways. For example, to share a directory called C:\Public\GeneralArtwork you could issue the following command on an OS/2 command line:

NET SHARE GENART=C:\Public\GeneralArtwork

This would create a netname, GENART, that refers to the directory resource, C:\Public\GeneralArtwork. Client workstations can then access this shared resource using the netname in the following command:

NET USE X: \\SERVER1\GENART

Where SERVER1 is the name assigned to the server workstation when you installed OS/2 Warp Peer. Don't get confused with TCP/IP host names which are different. In fact, as a tip I recommend you make these the same so you have less to remember but otherwise there is no connection. The X: is a drive letter of your choice which should not be used anywhere else on your workstation. When the command is executed, the shared directory will look like drive X: on the client workstation.

Commands are useful to show us the raw mechanics behind the sharing mechanism. However, we have a number of visual tools to protect us from the nasty brutish world of the command line:

  • Sharing and Connecting Application
  • Network Aware (Workplace) Shell
  • LAN Resource Browser

These are the tools we shall be working with for the most part. For full details on the command set, see the Commands and Utilities online manual in the Books folder inside the OS/2 Peer folder.

Controlling Access

Before we go too much further, we need to check out the security system that forms part of OS/2 Warp Connect. Like any resource you share across a network, disks, directories, printers and so on all need to be protected from unauthorised access. The OS/2 Warp Connect security system, User Profile Management (UPM) performs this function.

There are two parts to the security system. The first defines authorised users and allocates user identities (userid) and passwords to them. The user can then identify themselves by logging into the system supplying the userid and password. The second part concerns determining what resources the user can have access to and granting that access when requested.

The first part is performed entirely within the UPM system. Within the UPM Services folder on the desktop after OS/2 Warp Connect has been installed is a tool called User Account Management. This is used to define each user you want to have access to your workstation. Larger organisations can gather defined users into Groups for easier management.

During the installation of OS/2 Warp Connect, you are prompted for an initial system administrator userid and password. This should be set up for the workstation's user who should also be configured as the workstation's system administrator. You must login using this userid and passowrd to use the facilities of UPM account management.

You could login using the Logon/Logoff icons in the same UPM folder. Alternatively, you could login using the login menu item of the LAN Server and OS/2 Peer Resources icon in the Network folder. I prefer this latter method as it links in with the Network Aware (Workplace) Shell we will be discussing later.

Access to shared resources on a server workstation is controlled by an access control profile called an Access Control List (ACL). These are special profiles maintained by the Peer software containing a list of userids or group names granted access to the resource and the level of access granted.

All shared resources must have an ACL associated with it even if it just grants full read/write access to PUBLIC. We will cover the detail of creating access control profiles when we discuss setting up shared resources as that is generally the time we would create the profile for the resource being shared.

In a peer network such as the one we are contemplating, to use a shared resource a user must logon on their own workstation with their allocated UPM userid and password. This means the userid and password must be defined on both their own workstation and the server workstation they wish to access. Whenever they connect to a shared resource, the userid and password they are logged on locally with are passed to the server for validation there. Again, this means the userid and password must also be defined on the server workstation.

The environment has two provisions to help reduce the work of maintaining all these userids and passwords. Firstly, you can set up resources as publicly accessible and that therefore require no userid and password to use. Secondly, when you set up connections, you can specify that you want to be prompted for a new password if the server password differs from the local one.

For more information about access control, UPM and logging in and out, see the relevant sections in the Commands and Utilities and User's Guide online books in the OS/2 Peer folder.

Sharing Resources

Sharing resources can be accomplished in one of three ways, commands (NET), the Sharing and Connecting application and the network aware extensions to the Workplace Shell. We won't be looking at the NET commands much. There usefulness lies in the fact that they can be included in REXX command files which enables you to automate a lot of routine tasks.

Sharing and Connecting is started using the icon shown which is found in the OS/2 Peer folder. This shows a window containing a notebook with three tabs:

  • Connections
  • Shares
  • Access Control

The Connections page is used to view what resources your workstation is using on other workstations. We will look at this page when we discuss using resources in the Using Resources section below.

Of the other two tabs, the Shares page is used to create, alter and delete profiles describing resources owned by our workstation and which are to be shared and describing when they are to be shared. The Access Control page is used to create, alter and delete access control profiles.

Sharing a resource requires three steps:

  1. Describing the resource in a share profile
  2. Authorising access in an access control profile
  3. Initiating the share using the share profile

The first step, describing the resource, can be done using the Shares page of the Sharing and Connecting application or using the resource's Workplace Shell context menu.

Using the Sharing and Connecting application, switch to the Shares page, pull down the Share menu and select the Create... menu item. Select the resource type from the resulting dialog and press the Ok pushbutton.

On the resulting panel, fill in the resource details including a description and so on. The share name is the public netname used to access the resource when it is shared. You can also limit the number of users that can access a particular resource at any one time. This is useful to enforce licensing requirements for programs you put in shared directories.

The Start Sharing... checkbox enables you to specify this resource is to be shared when the peer service is started, normally when the workstation is booted. If you don't specify this option, you must manually share the resource when it is required.

The Grant access... pushbutton provides a tie in to the access control management environment available from the Access Control page. This enables you set up an access control profile for the specific resource you are creating a share profile for now and this would probably be the normal way you create such profiles.

Pressing the Grant access... pushbutton displays the Grant Access dialog. This dialog has two sets of contents depending on whether you choose to grant Basic access or Customized access. Basic sets a simple access level that is applicable for all users no matter what their userid, password or group is. Customized enables you to specify the Groups and/or Users that can access this resource and what access permissions they are granted.

An access permission is a level of access, for example read only, read/write and so on. An additional checkbox at the bottom of the dialog sets auditing on for this resource. When set on, all accesses to the resource are logged in the Audit Log.

When all setting have be made to your satisfaction, pressing the Ok pushbuttons on each dialog returns you to the main page and the share and access control profiles are created. If an access control profile needs to be explicitly created, turn to the Access Control page and use the Create... menu item on the Access pulldown menu.

You should note that you can create access control profiles independent of any particular shared resource. For example, you might have a shared directory to which we grant read/write access. We could create an access control profile for one of its subdirectories restricting access to read only although the subdirectory is not explicitly named in a share profile. When your delete a share profile, you are given the option of deleting the access profiles or leaving them in place. Access control profiles may be created for individual resources without an associated share profile using the Access Controls page.

Another thing to note is the Apply access permissions... menu item on the Access pulldown menu. This copies the access control profile, creating a new one for each subdirectory within a shared directory. Normally, a new access control profile is automatically created when a new subdirectory is created within a shareable resource. However, when you first create the share profile, you must do this manually using this menu item. Note that if you already have access control profiles on some or all of the subdirectories, these will be overwritten.

As we mentioned before, we can bypass the Sharing and Connecting application and use the Workplace Shell directly. To create a share profile and access control profile for a resource, click on it with mouse button 2 to popup the context menu. At or near the bottom, you will see a Share menu item with a cascade arrow. If you don't see the arrow, Peer is not started. Start it, logon and try again.

Click the Share menu item and select the Configure sharing menu item. This will lead you to the same Configure Sharing dialog you reached from the application. The process of creating a share profile and associated access control profile is the same. The details of the profiles can be found in the Shares and Access controls pages of the resource's settings notebook.

If you just want to create an access control profile for the resource, use the Control access menu item from the cascade menu. The Apply access permissions menu item can be used to replicate the profile to all subdirectories if required.

Once the share profile and access control profile have been created for the resource, the last step is to share the resource. This is done automatically for your when you create the share profile. However, if you want the share to be automatically done each time you start the Peer service, you must click the Start Sharing... checkbox when creating the share profile.

If you have not set up automatic sharing for a resource, you must manually share it. This can be done using the functions of the Sharing and Connecting application or the Workplace Shell as before.

With the application, start it, go to the Shares page, select the share profile of the resource to be shared and then select the Start menu item from the Share pulldown menu. Alternatively, you can click the share profile with mouse button 2 to get a popup menu with the same options. The Stop option on either menu is used to manually stop sharing the resource.

Using the Workplace Shell, click on the resource to be shared with mouse button 2 to get its context menu. Select the Share option at the bottom and select Start sharing from the cascade menu to start the share or Stop sharing to stop it again.

Once again, for more information about sharing resources, check out the online documentation that comes in the OS/2 Peer folder. The Sharing and Connecting application help is also useful reading.

Using Resources

Once a workstation has shared resources, other workstations can use them by connecting to them using either the same Sharing and Connecting application or the Workplace Shell. In the application, the Connections page is used to set up connection profiles which record the details of the resources you wish to connect to. Connection resources may be currently connected or disconnected. Inactive connections have a small icon in the shape of a broken red lightning zap on them.

Creating a new connection profile is just a matter of pulling down the Connection menu and selecting the Create... menu item. You will be walked through the process of establishing a connection profile for a resource on a server.

In summary, you need to specify the name of the server workstation owning the resource and the netname the resource was shared with. Pulling down the list from the share/alias combo box will show you a list of candidate workstation names to select from. You will then specify the name, for example drive letter, by which that shared resource will be known on your workstation.

Setting on the Connect to resource at logon checkbox specifies that you will automatically connect to this resource whenever you fire up your workstation starting the peer service. Setting on the Prompt for password checkbox indicates you would like to be prompted for a password should your local one not match any on the server workstation.

Creating the profile will also initiate the connection. To automatically, connect on subsequent starts of your workstation, click the Connect to resource at logon checkbox. If this box is not clicked, you must select the connection profile and use the Start menu item on the Connection pull down menu. Alternatively, click on the profile using mouse button 2 to get a popup menu and select the Start menu item. The connection can be terminated anytime using the Stop menu item for either menu.

As with sharing, the Workplace Shell can also be used to connect to shared resources on the LAN. The main tool for connecting to resources is the LAN Server and OS/2 Peer Resources folder which is normally found in the Network folder on your desktop. This is also used to login and out using the appropriate option on its context menu. I will refer to it from here on as the LAN Resources Browser.

Open the LAN Resources Browser. Inside, you should find an icon for your own workstation and other workstations on the LAN with resources to share. If you can't see the workstation you are after, click on any of them with mouse button 2 to get the context menu then select Access another.... Ignore the first field and type the name of the workstation into the second field, Server, and press the OK pushbutton.

You could try the pulldown option on the Server field but if the workstation isn't in the main folder it probably won't be in drop down list. If the workstation can be found, it will be added to those in the folder. A shadow of the workstation icon also appears on the desktop. This can be shredded if not required.

Having located the workstation owning the resources you are after, you must open it (double click) to see the resources it has to offer. These will shown as icons inside the open workstation folder. You can now access any of the displayed icons directly with no further work. For example, you can drop files onto printers and folders and drag files out of folders and so on. To go further, you can assign a local device name, for example a drive letter or printer device, to the resource by clicking on it with mouse button 2 to get its context menu and selecting the Assign... menu item.

Unlike the Sharing and Connecting application, using the Workplace Shell does not set up a permanent connection profile that can be used again and again. It just sets up a one time connection to the resource. Next time you start up your workstation, you will have to re-establish the connection manually. You can streamline this process by dragging shadows out of the LAN Resources folder and placing them where they are more accessible.