Kap5.html

With "HELIOSDIR/bin/pcsmsg" a UNIX user can send a display message to an SMB client, or to all connected PCShare clients if logged-in as "root", Fig. 55. Type
pcsmsg -? for detailed parameter information.

If neither -p is specified nor -u, and you are "super user", the message reaches all users logged-on to the respective PCShare server.

Note: If your PCShare clients use Windows 95/98/Me the WinPopup program must be installed and running in order to display messages on screen.

The following table compares the behavior of the different operating systems when it comes to the case of file names.

Fig. 56: Operating systems and the case-sensitivity of file names
	Case preserve	Case ignore
Mac OS	YES	YES
UNIX	YES	-
MS-DOS	-	YES
W9x/Me/NT/XP/2000	YES	YES

As Fig. 56 shows, there is no case preserving under
MS-DOS, i.e. file names entered in lowercase will appear uppercase in the directory listing. In contrast to UNIX, the Windows (as well as Macintosh) operating system is not case-sensitive when it looks for files or creates or opens them - if your application looks for "Dave", it will also find "dave", and you cannot create a file "Dave" and a file "dave" in the same folder on a local volume. Due to its UNIX heritage, this is unfortunately not true for HELIOS volumes.

This distinction is normally not a problem - if an application has created a file called "Editor Prefs", for example, and needs to open the file again, it usually tries to open it using the same name and not under the name "EDITOR PREFS". If an application cannot find a file which it has created, and the file is visible under UNIX and in the Finder, it is likely that case-sensitivity is to blame. If you are able to determine the name of the file which the application is trying to open, you can often provide a workaround by using a Macintosh/Windows link (alias) or by renaming the file (NOT folder!).

The UNIX program "pcfilter", which was designed to be used by the PCShare print server, can be used to carry out print job filtering and character set translation operations which are commonly required for different types of ASCII-printers.

E.g., to automatically add a "form feed" character to the last page of each print job, the -f option must be specified as shown in the following example:

"pcfilter" can also be called with the name of an exported printer. It references an option list for the particular printer in the "Preferences" file. In the following example a "form feed" flag for the printer "ljet" is set:

Appropriate entries in the "Preferences" file are made automatically when you export printers with PCShare Admin and choose print job filtering or character set translation. This is much easier than doing it manually (compare to 6.1.4 ""pcfilter" preferences").

The Epson and EBCDIC tables are provided as examples only. The Epson table is compatible with the FX10-50 and FX80-50 printers and the EBCDIC table only maps the valid EBCDIC codes.

Note: If your print job contains character codes which are not specified (i.e. missing) in the chosen input table, these codes are ignored and an error message is written each time to the system message file (see
7.2.2 ""generic" error messages" for the location of this file). A maximum of 10 such messages are written per print job.
If your print job contains character codes which are not specified in the chosen output table, these codes are ignored and not passed to the printer.

The tables are specially compiled binary mapping files which can only be edited using PCShare Admin or "prefvalue" (see also the description of the "prefvalue" utility in the HELIOS Base manual for related information).

You can also specify "pcfilter" for a local Windows printer which is configured to receive print jobs from a UNIX spool queue. An example entry from a "Preferences" dump:

[][Printers][epson-1][pcfilter][formfeed]
flags=0
type=Boolean
value=TRUE
[][Printers][epson-1][pcfilter][ctrld]
flags=0
type=Boolean
value=FALSE
[][Printers][epson-1][pcfilter][postscript]
flags=0
type=Boolean
value=FALSE
[][Printers][epson-1][pcfilter][exit]
flags=0
type=String
value=[4]
\007
[][Printers][epson-1][pcfilter][input]
flags=0
type=String
value=[4]
iso8
[][Printers][epson-1][pcfilter][output]
flags=0
type=String
value=[2]
pc

Appropriate entries in the "Preferences" file are made automatically when you create and export local printers with PCShare Admin.

"pcfilter" can also be used to correct several PC-specific problems which can occur when printing to a PostScript printer which has a network connection to the host.

Particularly when printing PostScript from Microsoft Windows, a "Ctrl-D" character is often included with the print job data to indicate end-of-job to the printer.

If you are using a PostScript printer with a network connection, it is necessary to filter out the "Ctrl-D" since it will cause a printer error. This is because it is the responsibility of the print server and not of the application program to signal end-of-job in a way appropriate to the chosen hardware interface (RS-232, Ethernet, etc.).

Furthermore, some PostScript printers expect the character string "%!PS" at the very beginning of each PostScript print job. If this string is missing it is assumed that the file is plain text, which is then automatically converted to PostScript before printing, resulting in the printout of a PostScript program listing rather than the print job itself.

If you are using a PostScript printer connected to the host, you can filter out "Ctrl-D" characters and add "%!PS" to the start of each print job, by specifying PCShare's "pcfilter" utility in the UNIX print command. For example, you should specify the print command in the "Preferences" file with a command similar to the following:

An appropriate print command is created automatically when you configure printers with PCShare Admin and choose a PostScript character mapping table (see also the Changing printer parameters section in 3.8 "Exporting Printers" for detailed information). See also the description of the magic parameter in the HELIOS Base manual for related information.

Note: When printing to an "lpr" printer queue, make sure that you switch off the Send CTRL+D before job and Send CTRL+D after job checkbox in Windows' Printers > Properties > PostScript > Advanced menu. Network printers do not understand "Ctrl-D" characters.

In a network of several UNIX hosts, the UNIX NIS (Network Information Service) system allows user names, group names, and passwords as well as other configuration details to be stored centrally on the "NIS Master" host. This considerably simplifies setting up new users, particularly if they each need access to more than one host. Please note that the user configuration data maintained under NIS is only stored on the Master host. Thus, changes in the user/group configuration on the Master host take effect on all NIS-client hosts.

PCShare Admin can administer NIS wide user and group information on the NIS master only. If PCShare is running on a NIS slave or client, only local user and group data can be administered.

PCShare Admin automatically recognizes "passwd" and "group" as long as it is located in "/var/yp/" (default!). Otherwise, the path to the files must be specified manually in "HELIOSDIR/var/conf/Preferences". For example, if the desired directory is "/var/nis/" the statement must be:

If PCShare is running on the NIS master, the password list ("HELIOSDIR/var/conf/passwd") can also be used with NIS by setting up a PCShare password file on the NIS Master host containing the names of all users of the NIS Master and its interconnected clients. In that case, the file name used must be "afppasswd", e.g. "/var/yp/afppasswd".

If a "/var/yp/passwd" is available on the NIS Master, the "HELIOSDIR/var/conf/passwd" file should only contain the "root" and system logins, terminated by "+:" in the last line.

Note: You should be familiar with editing such files in order to provide proper operation of NIS administration.

The "HELIOSDIR/var/conf/passwd" file of each host on the NIS slaves and clients must also include a line containing only "+:" at the position where the NIS user map should be included. This usually follows entries for the "root" and the system logins only, to make sure that it is still possible to log on to the host in case the network connection to the Master fails:

Name resolution through WINS (Windows Internet Name Server) or broadcasts deliver the matching IP address to a given NetBIOS name, like a telephone directory inquiry returns the telephone number to a given name.

Each host sends in regular intervals so called "Host Announcements" all over the network. These are received from all computers on the subnet, but ignored by all except for the LMB (Local Master Browser). From the received "Host Announcements" the LMB generates the browse list, which contains all the names known to the LMB. The browse list becomes visible e.g. in the Windows Network Neighborhood list.

One or several BB (Backup Browser) are subordinate to the LMB for load balancing purposes. Each BB requests the browse list from its LMB in regular intervals.

Each client, which would like to receive the browse list, e.g. because a user opens the Windows Network Neighborhood list, requests it arbitrarily (load balancing) from any LMB or BB.

On each subnet of a domain there is an LMB and a certain number of BB and clients. Domain in this context refers to the Windows NT Domain, not to mistake with an Internet Domain.

The development of the browsing hierarchy is a dynamic process and cannot be configured. Each host which would like to become LMB, and each host which would like to obtain a browse list but - for any reasons - does not obtain one, can enforce an election. However, unlike a political "election" here every node votes for itself and does not give its vote to another. An election consists of several heats. Each host votes for itself until it recognizes that another host has casted a more important vote.

The importance of a vote depends, among other things, on the operating system version and the uptime. A host running Windows NT Server "wins" before Windows NT Workstation, and NT Workstation wins before Windows 98, etc. In case of a "tie" the larger uptime and further criteria are decisive.

After max. 4 heats the "winner" of the election is found and appoints itself LMB, appoints further hosts BB, or divests existing BBs of their powers with the target of an optimal load balancing.

A browse list is complete several minutes after the election. Therefore, frequent elections have a detrimental effect and therefore should be avoided.

The LMB administers the browse list of its subnets. In order to make the hosts of other subnets visible, all other LMB browse lists must come to each LMBs knowledge. For that purpose each LMB connects with the DMB (Domain Master Browser) and synchronizes its browse list in regular intervals with the DMB. Thus, the local browse lists are assembled to a global browse list which covers the entire domain. This process can take up to 1 hour.

The DMB is the only arrangement within the browser hierarchy which must be configured. LMBs result from elections on a subnet by broadcasts. BBs are appointed by the respective LMB. The DMB must always also be LMB on its subnets. If the DMB loses the election another host becomes LMB. This usually leads to malfunctions.

In each domain there is a PDC (Primary Domain Controller) which, among other things, administers passwords. A PDC on the network can be found by use of the Primary Domain Controller Location Protocol, a sequence of special browsing packets and name resolution.

Microsoft determined that PDC and DMB have to be the same host. Since a LMB cannot find the DMB on the network it looks for the PDC and, in doing so, relies on having found the DMB also.

Thus, a Windows NT Server DMB is always also PDC. PDC functionality is not yet implemented in PCShare - the DMB functionality however is. If PCShare is to function as DMB, it must register itself with the WINS as PDC, pretending PDC functionality, in order to be considered DMB from other LMBs.

Important: If there is actually another PDC on the network, the PCShare server should under no circumstances be configured as DMB or PDC!

A NetBIOS name can be a group name, e.g. a Workgroup or a domain, or a unique name, e.g. a computer, a service or a user. A NetBIOS name may consist of uppercase characters as well as some special characters and is restricted to max. 15 characters. If it is shorter than 15 characters it is appropriately filled with blanks. The 16th Byte is a type byte, from which one can detect whether it concerns e.g. the name of a computer, of a user, or of a service. Thus, each NetBIOS name is exactly 16 bytes long.

In order to make a computer, service, etc. on the network recognizable, it must register itself first. If another computer wants to access this name, it must perform name resolution. For this, the IP address of the WINS must be known. Under PCShare the WINS server address can be automatically delivered via DHCP, when configured via PCShare Admin.

A computer registers itself with the WINS by sending it a Name Registration Request (unicast UDP). This datagram contains among other things the NetBIOS name and an IP address. The WINS answers with a positive Name Registration Response. This process is repeated in regular intervals (Name Refresh). If Name Refresh is not executed in the determined time interval, the WINS considers this client to have crashed or switched off, and removes its entry from the data base.

Similarly a client, which is switched off, should log out with a Name Release Request from its WINS so that its name is immediately removed from the WINS data base and not only after a time-out. This however does not happen very frequently.

The WINS will reject a registration (negative Name Registration Response), e.g. if a client wants to register a name which another client has already registered successfully before. This leads then to an (possibly quite strange) error message at the unsuccessful PC.

A client, which needs to get a name resolved, sends a Name Query Request (unicast UDP) to the WINS. The WINS answers with a positive Name Query Response, which contains the IP address of the looked-up NetBIOS name, or with a negative response, i.e. the looked up name is not known to the WINS (anymore).

If name resolution with WINS fails the client still tries it with some Name Query Requests which are sent as broadcasts. If the looked-up NetBIOS name is located on the same subnet its carrier will answer with a unicast Name Query Response.

In a larger network several WINS may share the tasks,
e.g. for reasons of reliability or for load balancing purposes. These WINS do replicate in regular intervals their data bases among themselves, in order to always share the same level of knowledge.

Note: A replication from WINS is not implemented within PCShare at the moment because Microsoft keeps the required "WINS Replication Protocol" secret. PCShare can be employed as exclusive WINS only.

If the WINS is not known to PCs which are located on a subnet they can only use broadcasts for name resolution. In this case a WINS Proxy can be used as a link.

The IP address of the WINS must be known to the WINS Proxy. It listens on its subnet for broadcasts and forwards these to the WINS. It incorporates a local cache in order to hold network traffic within limits. Thus, the nodes on the broadcast subnet can also resolve names of computers or services which are on other subnets. This does not work vice versa, i.e. bi-directionally.

The WINS Proxy should only be used for a transition period, until all nodes on the subnet are correctly configured and communicate directly with the WINS.

The communication with the WINS Proxy puts unnecessary workload on the network and can also cause additional problems. If a node gets more than one response after a broadcast it regards this as an error, even if the responses are correct and consistent, and rejects the received responses.

Nodes which do not communicate with the WINS broadcast their existence in regular intervals on their subnet. The WINS Proxy then can forward these broadcasts to the WINS. However, this does not lead to a registration of the broadcast node with the WINS. It is merely checked whether a broadcast node carries a name which a WINS client had already registered. If necessary, the WINS Proxy refuses the broadcast node registration.

With PCShare Admin adjustments can be made which influence the behavior of PCShare. Here we discuss issues which affect name resolution and browsing.

Of course, each PC can be manually configured and assigned an IP address, the IP address of its WINS, etc. However, this is very labor intensive for system administrators.

To some extent PCShare can do this. Each PC must only be "told" that it receives its configuration from the DHCP (Dynamic Host Configuration Protocol ). Thereupon it transmits a DHCP Request during the boot process which can be answered by PCShare with a DHCP Response. This response contains among other things the IP address which the PC is to receive, the IP address of the WINS, the Router, the DNS server, etc.

Macintosh computers can also be configured by means of DHCP. However, for Macs the address of the WINS is not of interest and is ignored since they do not use NetBIOS name resolution.

For safety reasons it can be necessary to forbid computers with certain IP addresses the access to the PCShare server. However, this option should only be used with caution because the structure of the Browser hierarchy is a dynamic process, and therefore it is often not predictable which host will take which position in this hierarchy.

If any host requests a browse list but is prevented by the IP access list from doing so, this may lead to a new election. For this, it is irrelevant whether a user opened the Network Neighborhood list, it came by periodic testing of the browse list, or the rejected host is located on the same or another subnet.

Note: An inappropriately selected entry in the IP access list leads to constant new elections. In this case you will be unable to get a stable and reliable browser hierarchy.

PCShare needs a NetBIOS host name as well as a NetBIOS domain name. As long as not configured in a different way, the host name is the PCShare server name and for the domain the name "workgroup" is employed:

Microsoft did not define a mechanism which allows to find the DMB on the network. Instead, there is a mechanism (Primary Domain Controller Location Protocol) to find the PDC on the network. Hence PCs rely on the fact that they will thereby also find the DMB. On that score PCShare must pretend PDC behavior (i.e respond to this PDC Location Protocol).

Of course, PCShare - if it is not the WINS itself - must know where to register itself and which arrangement is responsible for name resolution, e.g.:

In case of doubt, WINS Proxy should be switched off; WINS should only be switched on if PCShare is the only WINS on the network.

The Scope Identifier is a means to divide the flat NetBIOS name space into sections, when NetBios over TCP/IP is used. A hierarchy as in the DNS name space is however not realized. It defines a group of computers that recognize a registered NetBIOS name. Computers with the same Scope ID will be able to recognize each other's NetBIOS traffic or messages.

With telnet <ipaddress or hostname> 2003 a connection to the master PCShare process can be established and "Name Binding Service" configuration & status can be queried. The following short abstract shows how certain information can be listed.

Note: In a complex network you may have to wait several minutes after starting PCShare before a stable browsing hierarchy has been reached.

The master PCShare server will respond with a status line which lists the PCShare version incl. update level, UNIX host name, PCShare server name and UNIX operating system as well as date and uptime of the PCShare master process.

With di (display interfaces) the configured TCP/IP interfaces are listed with TCP, broadcast and Mac address. If the interface is registered for PCShare the column "reg" lists "+", otherwise "-".

With dw (display WINS) information about WINS will be listed as stored in "HELIOSDIR/var/run/wins.db", for example name and addresses, expiration date as well as type and state. In case the PCShare server is not WINS itself, this will return "No WINS entries".

With dp (display proxy) information about WINS proxy will be listed, see dw. In case the PCShare server itself is not WINS, or there is no WINS proxy information, this will return "No Proxy WINS entries".

With cnfg (configuration) configuration information about the PCShare server is listed. Apart from host name, domain name and comment which are always listed, any changes to the default parameter settings are listed also. For example, if the PCShare server is not WINS.

This feature requires a DNS server with bind version 8 or newer and on the PCShare server a bind 8 compatible DNS client installation, and the "nsupdate" (or similar) application available.

Most OS vendors provide a bind of version 8 or newer with their current OS implementation, apart from HP-UX 11 and IRIX 6.5. Check with your hardware/operating system vendor for OS requirements and availability of bind 8.

With the above requirements met, PCShare then supports dynamic DNS update according to RFC 2136 and also secure DNS according to RFC 2137.

Note: Bind 8 prior to 8.2 includes support for Dynamic DNS as specified in RFC 2136 but it does not currently include the authentication mechanism described in RFC 2137. As a result, any update requests received from allowed hosts will be accepted.

When PCShare has a DHCP TCP/IP address range specified (via PCShare Admin > Setup > DHCP TCP/IP, Bootserver State: set to Primary, and then Current Ranges:, see Fig. 57), the DHCP clients will receive this TCP/IP configuration including IP address, subnet mask, router, WINS and DNS server address. This enables the client to be a fully configured TCP/IP citizen, and to connect to the server and to use other TCP/IP services like web browser, etc.

A standard ping to the DHCP client (e.g. ping 192.168.1.8) shows that the DHCP client is alive. A reverse lookup e.g.: (ping mac-mike.helios.com) will only work if the client TCP/IP address is configured in the DNS server configuration. PCShare can automatically update the DNS server with the host names of DHCP clients. The benefit of this is that the DNS configuration gets dynamically updated every time PCShare provides a DHCP configuration to a client (e.g. Macintosh or Windows clients).

Fig. 57: DHCP range with dynamic DNS update

It is required to specify the DNS domain in which the DHCP name should be configured (e.g. "helios.com"). The DHCP client name will be used for the DNS configuration. A sample DNS reverse lookup would be e.g.:

Note: To avoid that a simple DHCP client can overwrite your DNS configuration by setting the client workstation name e.g. to "ftp", which means it will update the DNS setting of "ftp.helios.com" to the client IP address, we recommend to specify a unique domain for dynamic DNS clients. In our example we configure the PCShare dynamic DNS update name to "dyn.helios.com" which would register the client as "mac-mike.dyn.helios.com".

The DNS server can run on the same machine as PCShare or on a different server in the network. By default the DNS server will deny all remote DNS updates for security reasons. It is required to allow the DNS server to accept remote updates which are initiated by the PCShare DHCP server.

Using a UNIX based DNS server the "/etc/named.conf" configuration file needs an entry like the following to allow the PCShare server to update DNS entries. For example if our PCShare DHCP server has the IP address:

On Windows and Macintosh clients the DHCP request contains the workstation name, which is used to register the DNS workstation name, (e.g. "mac-mike" which will be "mac-mike.dyn.helios.com"). On Mac OS 9 the workstation name can be configured in the File Sharing control panel (Fig. 58) in the Computer Name field. On Windows computers it can be configured in the Network control panel Identification (Fig. 59).

Fig. 58: Workstation name in File Sharing control panel

Fig. 59: Network control panel Identification

Note: The Windows Computer name allows up to 15 characters. The Macintosh Computer Name allows up to 31 characters.

Please note: If two DHCP clients are using the same name only the last DNS entry will be valid. There is no warning or error message for duplicate names. To allow successful dynamic DNS update the workstation name should only contain digits 0-9 and ASCII characters. Special characters like umlauts, spaces, underlines, etc. may not work correctly.

The PCShare DHCP configuration file
"HELIOSDIR/var/conf/ethers.pcs" will contain a list of the assigned macaddress and TCP/IP address including the workstation names, e.g.:

When using a primary and secondary PCShare bootserver, make sure that the bind requirements, which have been described before in 5.6.1 "PCShare DHCP with dynamic DNS update", for dynamic DNS are also available on the secondary bootserver. Otherwise it will not be able to update dynamic DNS.

HELIOS PCShare 3.1 User manual