Kap7.html

With "$PCDIR/etc/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. 75. 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 "swho" command can be used to list all currently active PCShare and EtherShare child server processes, together with the process ID (PID), the network address (EtherShare: AppleTalk/IP address or name; PCShare: internet address or client name), user name and process starting time:

In this example you can see three logins via AppleTalk (one "AFPServer" and two "UNIXTerminal" connections) and two logins via "PCShare", one of them from a PC client as a guest user ("nobody"), and the other from another PC with the user name "anyuser".

A separate PCShare process is started for each user login (including guest logins - user "nobody"), although a single process can support multiple drive and/or printer connections, even if they are all mounted at the same time.

The name of the PCs ("tecra" and "Office" in the above example) is only shown if the PC has been specified with name and IP address in "/etc/hosts" or in the equivalent host database such as NIS. If the name is not specified, the internet address is shown instead of the computer name:

Use the -c switch to include an optional comment field, which shows more information on the session. PCShare servers show the name of the corresponding mounted UNIX directory or print command, EtherShare file servers ("AFPServer") show the names of the currently mounted Macintosh volumes:

"swho" gets its information from the file "stmp", which is updated by both PCShare and EtherShare servers. If you have only installed PCShare on your host, "stmp" is located in the "$PCDIR" directory. If EtherShare was already installed and running when you installed PCShare, the PCShare installer will create a "symbolic link" in the "$PCDIR" directory to "$ESDIR/stmp" instead, to allow both servers to share the same login overview file.

The PCShare and EtherShare environment variables "$PCDIR" and "$ESDIR" need to be set to the path of the installation directory for the "swho" command to work. If not, set them to the desired path, or use the -f switch to specify an alternative input file for the swho command. The default file is either "/usr/local/pcshare/stmp" or
"/usr/local/es/stmp".

Use the -n switch to suppress DNS (Domain Name Service) functionality. If this option is set, the network address appears as IP number instead of the name.

Note: If "swho" delivers quicker results with the -n switch set you probably have a DNS configuration problem.

The -p option is used to clear the "$ESDIR/stmp" file from entries which are orphans, i.e. cannot be allocated to current processes anymore.

Related information is available from the hosts process list. In the following example, we have used "grep" to limit the otherwise extensive list to PCShare servers only:

PCShare file and print server functionality is all implemented in a single "pcshare" master process, which spawns a child process each time a user mounts volumes or print queues. The child processes are also called "pcshare".

The UNIX program pcfilter, which is 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.

It replaces the dfilter program provided with earlier PCShare versions, and has a much wider range of features.

pcfilter is called from UNIX with command line options prefixed by "-". You can also call it with the name of an exported printer. In the latter case, which is the preferred method, pcfilter references an option list for the exported printer in the PCShare configuration file
"$PCDIR/conf/Preferences".

For example, to automatically add a "form feed" character to the last page of each print job, specify pcfilter with the
-f flag in the corresponding printer entry in PCShare's configuration file "$PCDIR/conf/exports.pcs" as follows:

Alternatively, specify pcfilter with the printers name instead, which causes pcfilter to refer to
"$PCDIR/conf/Preferences" for its configuration:

"ljet4050" is a printer queue which has been allocated to the physical printer "ljet". Use the "@" character to replace spaces in the name of the exported printer, e.g. if the name of the exported printer is "Text Printer":

Appropriate entries in "exports.pcs" and "Preferences" are made automatically when you export printers with the PCShare Admin and choose print job filtering or character set translation. This is much easier than doing it manually.

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
8.4.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 the PCShare Admin or "prefvalue" (see prefvalue in 7.8 "Server preferences").

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:

[][PCShare][Printers][epson-1][host]
flags=0
type=String
value=[17]
\\helix\epson
[][PCShare][Printers][epson-1][port]
flags=0
type=String
value=[4]
COM1
[][PCShare][Printers][epson-1][user]
flags=0
type=String
value=[6]
pcuser
[][PCShare][Printers][epson-1][printerpw]
flags=0
type=String
value=[72]
gdfcpoocfanmfdcfhiidhanlpehhnjafipjjgjoohkokahjbojmpnfeabdfgfoankpninbog

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

localptr is a printer queue which has been allocated to the physical printer "epson-1" attached to Windows PC "helix".

This configures the spooler to print to port COM1 on a Windows PC with host name "helix", adds a "form feed" at the end of the last page in each print job, converts the characters in the print job from the "iso8" set (Sun) to the "PC" set and rings the printer's bell (ASCII 7) when each print job is finished.

Note: The given example is for the shipping PCShare "lpr" which is based on the BSD printing system.

Appropriate entries in "exports.pcs" and "Preferences" are made automatically when you create and export local printers with the 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 PCShares pcfilter utility in the UNIX print command. For example, you should specify the print command in the "exports.pcs" file with a command similar to the following:

An appropriate print command is created automatically when you configure printers with the PCShare Admin and choose a PostScript character mapping table (see also the Changing printer parameters section in 5.8 "Exporting Printers" for detailed 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.

pcfilter replaces the dfilter program provided with earlier PCShare versions, and has a much wider range of features.

A symbolic link from dfilter to pcfilter is provided in the "$PCDIR" directory to ensure compatibility when upgrading existing installations. If pcfilter is started through the dfilter link without specifying any parameters, it behaves just like dfilter so the above example of printing to an EtherShare spool queue can also be specified as:

In a network of several UNIX hosts, the UNIX NIS 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.

PCAdmin 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.

The PCShare Admin automatically recognizes "passwd" and "group" as long as it is located in "/var/yp/" (default!). Else, the path to the files must be specified manually in "$PCDIR/conf/Preferences" with the "prefvalue" program. For example, if the desired directory is "/var/nis/" the state-ment in "prefvalue" must be:

If PCShare is running on the NIS master, the user list ("$PCDIR/conf/pcpasswd") 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/afppasswd" is available on the NIS Master, the "$PCDIR/conf/pcpasswd" 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 "$PCDIR/conf/pcpasswd" file of each host in 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:

All PCShare access to the UNIX host is logged in the UNIX text file "server.acct", together with a usage profile. Furthermore, currently active sessions are detailed in the binary file "stmp". Both of these accounting files, which are created as empty files during installation, are only maintained if they exist. You can delete the "server.acct" file if you do not want server accounting.

All print jobs sent by PCShare to local PC printers or to EtherShare printer queues are logged in "printer.acct". Jobs sent by PCShare to standard UNIX spool queues are not logged.

If PCShare is installed on the same UNIX computer as EtherShare (another HELIOS networking product, see EtherShare in A 7 "Glossary") they can share the same printer and server accounting files by using symbolic links. This is recognized automatically by the PCShare server installer script, which automatically creates the appropriate links for this purpose if EtherShare was already installed and running when you installed PCShare.

If PCShare and EtherShare are sharing "printer.acct", "server.acct" and "stmp" they are located in the "$ESDIR" directory instead.

If the accounting files are being shared the PCShare Admin will also show printer jobs and server access from EtherShare users, and vice versa for the EtherShare Admin.

Name resolution through WINS 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 Local Master Browser (LMB). 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 Backup Browser(s) (BB) 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 Domain Master Browser (DMB) 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 Primary Domain Controller (PDC) 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 3 - 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. This can raise further problems.

Important: Under no circumstances the PCShare server must be configured as DMB or PDC, if there is actually another PDC on the network.

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 (Windows Internet Name Server) must be known. Under PCShare this is configured with DHCP 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 application of the WINS Proxy puts unnecessarily 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 Dynamic Host Configuration Protocol (DHCP). 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 this in 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. Then a stable browser hierarchy with a complete browse list may also fail.

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:

PCShare will force - shortly after booting up - an election and try to become LMB. This behavior can also be turned off. At the same time the tendency to win an election which was forced by another host is reduced.

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 not 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 | 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. For technical background information on these topics, see your Microsoft documentation.

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 "$PCDIR/conf/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 lead to "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 lead to "No Proxy WINS entries".

With dc (display clients) current connection information about WINS will be listed, e.g. NetBIOS name, type and flags.

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 "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, the DHCP clients will receive his 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.13) 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).

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 DNS that "ftp.helios.com" to the client IP address, we recommend to specify an own 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 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. 77) in the Computer Name field. On Windows computers it can be configured in the Network control panel Identification (Fig. 78).

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. will not work correctly.

The PCShare DHCP configuration file
"$PCDIR/conf/ethers.pcs" will contain a list of the assigned macaddress and TCP/IP address including the workstation names.

When using a primary and secondary PCShare bootserver, make sure that the above described bind requirements for dynamic DNS are also available on the secondary bootserver. Otherwise it will not be able to update dynamic DNS.

The configuration files "/etc/hosts", "/etc/ethers",
"/etc/bootptab", "$PCDIR/conf/hosts.pcs" and
"$PCDIR/conf/ethers.pcs" contain information on the Ethernet and IP addresses, and hosts names.

The UNIX binary file "$PCDIR/conf/Preferences" is the main configuration file for the PCShare UNIX software. It can contain sections for the UNIX programs "pcshare" and "pcadmin" and also for the printer spooler. All of these programs look for relevant parameters in "Preferences" when starting. Default values are used for parameters which do not appear in the "Preferences" file.

Each of the server configuration files described below can contain comments by starting the line with the "#" character. This can be used to add additional information, e.g. explanatory remarks.

The UNIX text file "$PCDIR/conf/exports.pcs", which is required on each PCShare server, specifies the services (such as network volumes and printers) which should be made available by the host to the PCShare clients. The structure is as follows:

#type name spec flags
disk "My Disk" /usr/local/data
printer "My Printer" "lpr -Plp"
disk '~%u' - hidedotfiles

The first column (type) describes the type of entry, either disk or printer. The second column (name) is the name under which the service is known to the PCs ("~%u" in this example stands for "user home directory"). The third column specifies either a UNIX directory (if type=disk) or a UNIX print command (if type=printer).

The 4th column is optional and used for flags, which are comma-separated (the 5th column is also optional and used for group names). The following volume flags are available:

[no]mandatory
This switch specifies how the server handles record locking between multiple PCShare clients.

Note that if you want to run multi-user PC programs which were specially written for PCNFS: PCNFS normally uses advisory record locking whereas most other Windows or DOS network programs (such as Novell) use mandatory record locking, as specified by Microsoft. The latter is the default method used by PCShare.

The advisory method, the default method for UNIX applications, asssumes that multi-user applications explicitly attempt to lock the record or file before writing, whereas the mandatory method used by DOS applications automatically checks and sets the required lock region before every read or write without requiring explicit code in the program. The mandatory method requires less program code and assures consistent access.

nomandatory is only necessary if you are using multi-user PC programs that do not or only partially implement the Microsoft specifications on file access. For example, some PCNFS applications have been specially designed to operate with advisory record locking only.

Note: Only specify nomandatory if it is required by your applications, and if you fully understand the potential dangers. If possible, use unixlocks instead.

[no]compatdeny
This flag specifies how the server reacts if a PC opens a file for reading or writing without indicating how (and whether) the file can be simultaneously opened by other programs.

Normally, if a file is opened for reading, other users can only open the file for reading ("deny other write"). Furthermore if a file is opened for reading and writing, other users cannot open the file at all ("deny other all").

Using programs which need to access files which are already opened for reading and writing, specify nocompatdeny to allow others to read and write to the file.

nocompatdeny is only necessary if you are using multi-user PC programs that do not or only partially implement the Microsoft specifications on file access. For example, some PCNFS applications do not properly check the access modes, and require the nocompatdeny setting.

Note: Only specify nocompatdeny if it is required by your applications, and if you fully understand the potential dangers.

charset=PC850 or SJIS
If utf8 is active the charset flag is used to translate and encode file names to the "PC850" or "SJIS" character set.

[no]hidedotfiles
This option has been added to the PCShare server in order to hide files starting with a dot ("."). Then, such files are only visible if Windows is configured that way.

[no]readonly
This flag must be set when the underlying physical media is write protected (e.g. CD-ROM). Then, there is - for all users - only read access to the specific volume.

[no]close
The switch close is used to specify how the file server reacts to a file close command from the PC. Specify close to disable file descriptor caching if you want files to be closed immediately as soon as the file close command is received. If you specify the noclose option, files are kept open until either PCShare is terminated, an explicit command is received by "pcshare" to close all files ("pcsignal -flush") or the memory used by the file descriptors is required for other files.

The noclose mode accelerates PC file processing, particularly if the same files are often being closed and reopened. This occurs often with Microsoft Windows applications.

However, if files are often being shared between PC and non-PC applications, specify close in order to be able to recognize changes in the files more quickly.

The close option can be specified globally, or for individual volumes, in the Export Volumes window in the PCShare Admin or in the "$PCDIR/conf/exports.pcs" file. For performance reasons, the specification for individual volumes is preferred.

Note: The UNIX operating system may have limits on the maximum number of files which can be open simultaneously.

[no]closedirs
The closedirs switch is used to specify how the file server reacts to a directory close command from the PC. Specify closedirs to disable directory descriptor caching if you want directories to be closed instantly as soon as the directory close command is received. Specifying noclosedirs directories are kept open until either PCShare is terminated, an explicit command is received by "pcshare" to close all directories ("pcsignal -flush") or the memory used by the directory descriptors is required for other files.

The noclosedir mode accelerates PC file processing, particularly if the same directories are often being closed and reopened. This occurs often with Microsoft Windows applications.

Instead, if directories are often being shared between UNIX and PC applications, specify closedirs in order to be able to recognize changes in the directories more quickly. Compare to the close flag above.

Note: The UNIX operating system may have limits on the maximum number of directories which can be open simultaneously.

[no] unixlocks
This option specifies how the server handles record locking between PCShare clients and UNIX applications.

PCShare clients do not normally lock against UNIX applications. Specify unixlocks if you want to use UNIX record locking in addition to the standard mandatory record locking used between PCShare clients, to allow file and record locking between Windows applications and UNIX applications. UNIX locking may be necessary if UNIX and PC applications are sharing the same files, but you need to check whether your UNIX application supports locking at all (ask the supplier).

UNIX locking can also be specified for individual volumes only, in the Export Volumes window in the PCShare Admin or in the "$PCDIR/conf/exports.pcs" file. This way is preferable to specifying global UNIX locking parameters with "prefvalue" in "$PCDIR/conf/Preferences" since UNIX locking slows down record and file locking considerably.

[no]utf8
If this flag is specified, the Unicode character set is used on the volume (see also charset above).

A dash "-" is used as a placeholder, e.g. if you have not defined any volume flags but you have defined volume groups.

Note: Most of these volume flags can be configured when you export a volume using the PCShare Admin. This is generally more convenient than editing "exports.pcs" manually.

If necessary, entries in the "exports.pcs" file can be surrounded by single or double quotation marks to allow you to specify spaces in the commands or names.

#type name spec flags
printer "Public Printer" "lpr -Plp" public
disk "PCShare" /usr2/pcshare public
disk "WordPerfect" /usr2/wp/bin
disk "osiris root" /root

Remember to use unique names in the "exports.pcs" file, otherwise only the first of the duplicates will be used.

On the respective PCShare server which is displayed in Windows Network Neighborhood list, the volumes will appear to all users as "PCShare", "WordPerfect" and "osiris root", respectively. "PCShare" is a public drive, available to guest logins, too. The printer will appear as "Public Printer".

The UNIX text file "$PCDIR/conf/ethers.pcs", which is updated automatically by the "pcshare" server, documents the relationship between ethernet address and IP address for PCShare clients whose IP address has been automatically allocated, together with the date of last change for each entry. It is also used to specify the range of IP addresses which have been set aside for dynamic allocation.

Primary: 192.9.201.33-192.9.201.39
Primary: 192.9.201.41-192.9.201.44
#
#ethernet addr. internet addr. last change date
#
2:60:8c:2:ad:6c 192.9.200.60 Sat Feb 19 18:20:51
00:00:6b:81:39:12 192.9.200.11 Fri Nov 12 15:00:33
09:00:07:ff:ff:ff 193.9.201.11 Fri Nov 12 15:00:33

The following is an example of "$PCDIR/conf/ethers.pcs" for a secondary bootserver (see also Primary and secondary bootservers in 6.2 "Configuring IP address and host name for PCShare clients"):

Secondary: 192.9.201.32 lux (name of primary bootserver)
Disabled: 192.9.201.50
#
#ethernet addr. internet addr. last change date
#
2:60:8c:2:ad:6c 192.9.200.60 Sat Feb 19 18:20:51
00:00:6b:81:39:12 192.9.200.11 Fri Nov 12 15:00:33
09:00:07:ff:ff:ff 193.9.201.11 Fri Nov 12 15:00:33

The UNIX text file "PCDIR/conf/pcshare.lic" is automatically created during PCShare installation. It specifies information on the extent of your software license and contains the software activation key (checksum), see License information in "Welcome to PCShare 3", without which PCShare cannot be started. Modifications of the entries can only be done with the "$PCDIR/install" script.

PCShare Admin preferences are stored on the PCShare server in each users home directory in the "~/.pcadmin" file. This allows the PCShare Admin to be configured individually for each user.

The following example of the preferences file shows all of the defaults. Normally, the ".pcadmin" file only contains values for parameters which are not set to the default value:

# Profile for pcadmin
#

[pcadmin]

LANGUAGE=en_US
START_PROGRAM=/usr/bin/sh
HOMEDIR=/usr/home/dave
SPOOLDIR=/usr/spool
PRIMARY_GROUP=helios
SHOW_USER_ID=ON
PING_INTERVAL=30000
INPUTTABLENAME=iso8
OUTPUTTABLENAME=epson

START_PROGRAM is the users starting program or shell and HOMEDIR is the home directory (e.g. "/usr/home/<username>" or "/home/<username>").

SPOOLDIR is the default base directory for printer spooling directories. PRIMARY_GROUP is the default primary group.

The SHOW_USER_ID and SHOW_GROUP_ID switches specify whether to display the User ID and Group ID fields in the Configure Users and Configure Groups windows, respectively. These fields allow you to specify the required user or group ID manually. Otherwise, when creating new users and groups, the next free ID (above 500) will be chosen automatically.

To avoid unnecessary network traffic, the Client Activities for <client> window in the PCShare Admin is updated once per second for about 20 seconds, and thereafter at progressively longer intervals. PING_INTERVAL specifies the longest update interval (default 30000 ms, i.e. every 30 s).

INPUTTABLENAME and OUTPUTTABLENAME are the names of the input and output character mapping tables which you last edited with the PCShare Admin.

The PCShare server preferences are stored in a binary file. In the following, the preferences are listed by name, type, and default value. The default value is used by the PCShare server unless another value is specified, e.g. in the PCShare Admin or the "exports.pcs" file.

The programs "prefrestore", "prefdump", and "prefvalue" can be used to create and update the PC Share preferences file "$PCDIR/conf/Preferences".

Setting and retrieving single entries of the preference database can be done using the program "prefvalue" found in "$PCDIR/etc".

PreferenceFile is the binary preference database file to use. If omitted, the default file "$PCDIR/conf/Preferences" will be taken.

Valuefile is a pathname of a file to print a preference value to or read a preference value from. If omitted, "stdout" or "stdin" respectively will be used.

Keys is a single string conatining the key strings for the preference delimited by "/" characters. To set a system wide PCShare preference, the first key element is "PCShare".

Type is one of the following and may only be used when setting a preference:


Type	Value is
bool	TRUE or FALSE
int	a signed (32 bit) integer value
uint	an unsigned (32 bit) integer value
int64	a signed (64 bit) integer value
uint64	an unsigned (64 bit) integer value
double	a floating point number
ulist	a list of unsigned integers separated by comma
str	a string
strlist	a list of strings separated by comma
data	The value cannot be taken from the command line and therefore requires a valuefile specified

"prefvalue" is the command, -k the preference key (here
PCShare/Programs/pcshare/leasetime), -t the value type (here int for integer), and the last argument is the value to set (57600).

"PreferencesFile" is the binary preference database file which exports the preferences. If omitted, the default file "$PCDIR/conf/Preferences" will be taken.

If "ASCIIPreferenceExport" is specified the preference database will be exported to that file. If omitted, the preference database will be printed to "stdout".

Restoring preferences which have been dumped into a readable text file (e,g. with "prefdump") back into the binary "Preferences" file can be done using "prefrestore".

"PreferencesFile" is the binary preference database file which imports the preferences from "ASCIIPreferenceExport". Any old preferences are deleted then.

All of the following preferences are not set by default, meaning they are not listed in "prefdump" output, and PCShare will use the given default values. When a different value is set by means of "prefvalue", this will take precedence. To revert back to the default value of PCShare, use "prefvalue -k '<key>' -d" to delete the preference entry.

This switch specifies how the file server reacts to a file close command from the PC. close disables the file descriptor caching, so files are closed immediately as soon as the file close command is received.

This switch specifies how the file server reacts to a directory close command from the PC. closedirs disables the directory descriptor caching, so directories are closed immediately as soon as the directory close command is received.

This preference specifies the maximum number of files that can be opened by the file server simultaneously. The achievable maximum cannot exceed the maximum number of open files per process currently allowed by the host. It is normally set by "pcshare" for itself automatically. To conserve system resources, do not set this value higher than necessary.

The default is the maximum number of open files per process currently allowed by the host or 256, whichever is less.

Specifies the user name which is automatically allocated to guest users. The name is invisible to the guest users themselves, it is solely used to assign an entry for guests in the user list.

The default for guest is "nobody". The specified guest user must exist on your host. The PCShare installation automatically creates the user "nobody" if it does not already exist.

The default for this parameter is 10*sessions, where "sessions" is equal to the number of units (clients) for which you bought your license.

Do not set this preference to an unnecessary high value because this increases PCShare's requirement for UNIX system resources.

This preference specifies how the server handles record locking between PCShare clients and UNIX applications.

If set, admin is the name of a user with administrative rights whose password entitles to log in as any other user. In this way, e.g. a helpdesk can be set up in order to log in as user "xyz" and investigate problems with access rights.

The default is built from the PCShare server version and the machine architecture, e.g.
"PCShare 3.0.0u0226 lux SunOS 2.8 Generic 10".

This preference specifies the name of the file which contains the IP-access list for home directory access, and makes the home directory visible to the respective user.

Lets "PCShare" append a record to the system messages file if, due to the IP-access list, access from one or more clients has been denied.

Specifies the time interval in seconds after which the UNIX user and group database is checked for changes.

Normally, only the system administrator is allowed to make any changes. Non-privileged users can inspect the configuration and the print job queue, but cannot change anything except delete their own print jobs.

However, members of the special "printer administrators" group can also use "PCShare Admin" for print job scheduling (e.g. deleting print jobs) only. prnadmgroup specifies the name of the special "printer administrators" group.
Compare sysadmgroup and queadmgroup.

"PCShare Admin" allows users with sufficient permis-sions to configure the PCShare system from any PC on the network in a convenient and secure way. For example it can be used to set up users, groups, volumes and printers, and inspect print jobs. Normally, only the system administrator is allowed to make any changes. Non-privileged users can inspect the configuration and the print job queue, but cannot change anything except delete their own print jobs.

However, members of the special "system administrators" group can also use "PCShare Admin" to make any changes they like, including printer configuration, but they are not allowed to modify any information on users with an ID less than 100 (note: root has a user ID of 0). sysadmgroup specifies the name of the special "system administrators" group. Compare prnadmgroup and queadmgroup.

Name of group which is allowed to configure and administer PCShare queues (compare prnadmgroup and sysadmgroup).

PCShare clients can be optionally configured for dynamic IP address allocation, rather than manually configuring the address on each PC. In this case, "$PCDIR/conf/ethers.pcs" is used to store a list of client IP addresses which have been automatically allocated. Dynamically allocated IP addresses will be reused by the server for other clients if they are not used by the original client for dynage days.

The default for dynage is 62 (days). If dynage=0, the server never reuses IP addresses which have been dynamically allocated.

PCShare clients can be optionally configured for dynamic IP address allocation, rather than manually configuring the address on each PC. This preference specifies the name(s) and/or IP address(es) of one or more IP routers on the network (if any).

PCShare clients configured for dynamic IP address allocation are then allocated to the gateway in this list which is appropriate to their IP address. The gateways list has the same function as the "gateway" entry in the local HOSTS file, which is not present if the client is configured for dynamic IP address allocation.

Specifies in bytes the size of the IP data packets to be used by the PCShare server. The TCP/IP specification is flexible in this respect. For optimum data throughput, the size of the IP data packets should be the maximum packet size that can be processed by the physical network protocol (Ethernet, Token-Ring etc.) which underlies the internet protocol, i.e. such that each IP packet just fits in one physical protocol packet. PCShare does not support datagram fragmentation.

Specifies the time interval in which a Secondary Boot Server synchronizes the data with the Primary Boot Server. At each client boot request this synchronization is intended to be carried out if at least primaryage time has passed after the last synchronization.

Specifies if via DHCP static "Ethernet-to-IP address" mappings, which are defined in "/etc/bootptab" or "/etc/ethers",
are used too.

Specifies if an error message is written to the "syslog" file when the "Ethernet-to-IP address" mapping is missing at BOOTP protocol requests.

Forms the list of one or more IP addresses of the servers which can be used. It is transferred to the client via DHCP. The default is the server's local "/etc/resolv.conf" file.

Stops the "nsupdate" program if it has been idling for the specified amount of time (in seconds). If necessary, it is started again.

Program which is used for dynamic DNS updates. This is part of the UNIX-named DNS bind daemon packets. The program is called in a pipe and controled by the dnsadd and dnsdel templates.

If specified, broadcasting nodes can see WINS clients on other subnets but may get confused due to the increased name resolution network traffic.

Can only be used in conjunction with the enableproxy preference. It helps to avoid duplicate computer names. Duplicate computer names in one network will not work reliably.

This preference is normally not set. If the Windows PC is configured to use a scope identifier it needs to be identical to the Windows client configuration.

HELIOS PCShare 3.0 User manual