JRFS

Man Page Index

jRFS Quick Start
Remote File Pointers
Remote File Service
jConnect Library
Client Connections
Configuration Files
Advanced jRFS Configuration (Unix/Linux only)

REMOTE FILE POINTERS

Remote file pointers is one mechanism by which a client application can access files located on a remote system.

A Q pointer is created in the MD file and set to point to a SYSTEM file entry as normal for Q pointers. e.g.

QPTR
001 Q
002 AccountName
003 FileName

The Qpointer is resolved in the normal way to the SYSTEM file entry. However the SYSTEM file entry is an Rpointer, usually of the following form.

AccountName
001 R
002
003
004 HostName

The full format of an R pointer SYSTEM entry is as follows:

AccountName
001 R
002 {RemoteAccountName} {ServerName}
003
004 {HostName}

Where
RemoteAccountName - Optional Remote Host SYSTEM file reference.
ServerName - Optional network service name.
HostName - Remote HostName or IP Address.

If the optional RemoteAccountName is specified then searching for remote relative filenames will start in the directory path specified by the SYSTEM entry on the remote host. If the specified RemoteAccountName is not a valid accountname entry in the remote SYSTEM file then the open request will fail with file not found If left blank then searching for remote relative filenames will begin in the home directory of the network userid.

The optional ServerName is used to specify an alternative network service required by locating a matching entry in the services file. If left blank the server name will default to jRFS, which is then used to reference the services file and find the required network service. Note that a dash, "-", should be used as a place holder to signify a blank RemoteAccountName when only an alternate ServerName is specified.

The HostName is optional and if specified is used to determine the network address of the target system by locating a matching entry in the hosts file. If left blank the target system name will default to the local host node name or on some systems localhost, which is then used to reference the hosts file and find the network address of the local system. The HostName may also be entered as a dotted IP address.

In order to gain access to the remote system via the jRFS, the client must provide a remoteusername. This remoteusername will either be the same as the client user name or a mapped alternative, see later. The supplied remoteusername must be a valid user name on the remote system or the connection will be denied. The remoteusername is also used to determine file access permissions.

The combination of the second attribute from the remote Dpointer, or the remote home directory of the remoteusername, and the third attribute from the Qpointer produces the filepath for the file referenced by the Qpointer. However if the third attribute from the Qpointer is an absolute path then this reference will be used on the remote system.

Alternatively, to eliminate the need for the SYSTEM and MD entries (or if you do not maintain SYSTEM and/or MD files), you can create a remote file stub in a directory that is visible from the JEDIFILEPATH environment variable. For example,

[ Note the two underscore characters between 'JBC' and 'SOB'. ]

REMOTE FILE SERVICE

The jRFS process must be running on the target system before access via Rpointers can be achieved. The jRFS process, once initiated on the target system, waits passively for a client request from another system. When a client request is detected, the server then spawns another process to handle the request. The spawned process performs a security check of the connecting client and if successful then becomes a remote user process as determined by the remoteusername. The remote user process then attempts to open the specified file via the standard jEDI interface. The result of the file open is returned to the client process. The remote user process will continue to handle all further remote file operations for the client process. The remote user process continues to be active until all opened remote files are closed and the client issues a disconnect or an error/shutdown signal is received, in which case all files still open are closed using the jEDI interface.

Before the jRFS process can being to accept client requests the services file must be updated to include an entry for the server. This entry describes the connection type and an arbitrary connecting port. A port should be chosen which does not clash with any existing services on both the server and client systems.

e.g. jRFS 5001/tcp

Unix
The jRFS can be initiated at boot time or manually as root by installing the script, jRFS.init.d, located in the "src" subdirectory of the jBASE release directory.

NT
The jRFS process can be installed as a service by the jRFSInstall.exe and removed from the services by the jRFSRemove.exe. Once installed and configured the jRFS can be started by the services applet in the control panel. To install and start the jRFS the user must have administrator privileges.

Once started the jRFS process attempts to read the jRFS configuration file, jrfs_config, This configuration file contains flags which can be asserted to "flag" the jRFS and client request modules to produce trace information for remote file operations. The trace facility can be useful for determining successful Rpointer resolution or confirmation that a remote file operation has been successfully constructed, sent and received. The jRFS process passes control to the jConnect library, which reads the jConnect configuration file, jnet_config. This configuration file contains flags which can be utilized to specify the security mechanism for client requests and also "flag" the jConnect library to provide trace information. The jConnect trace information can be used to ascertain why a client connect request has been denied.

WARNING: The trace features can severely degrade performance and also generate large trace files. The trace features should only be enabled when required and care taken to allow sufficient space in the log file partition.

jCONNECT LIBRARY

Unix
The jConnect library provides for two mutually exclusive security mechanisms. The default mechanism is the standard UNIX ruserok mechanism usually utilized by ftp, rcp, etc. This mechanism first checks the /etc/hosts.equiv file and then the target users .rhosts file to determine whether further processing is allowed An alternative method, which can be configured in the jnet_config configuration file, is to use the jnetok mechanism. The jnetok mechanism requires that certain components included in the client connect request match an entry in the /etc/jnet_access file. For security purposes this file should only be readable by root. If required, the location of the jnet_access file can be defined by the environment variable JBCNETACCESS.

NT
The jConnect library provides user security on NT by the jnet_access file. This file should be placed in a NTFS directory set with administrator read only privileges. The directory location should then be configured into a system environment variable JBCNETACCESS.

NOTE Both security mechanisms utilize the connecting hostname as listed in the hosts file, the remoteusername and the client username as supplied by the client connect request. The jnetok mechanism also requires the correct servername before permission is granted to continue the client connection. The jConnect library will deny access to clients whose remoteusername resolves to a user id of less than one hundred.

Once the security check has completed successfully the jConnect library then proceeds to set the groupid, userid and home directory along with certain other required environment variables. The jConnect library then attempts to match the client connect request components with an entry in the jnet_env file. If successful then any related environment entries are setup before returning control back to the jBASE Remote File Service modules.

CLIENT CONNECTIONS

Client connections can be configured to map client connect request components to alternative values by using the client mapping feature of the jConnect library. The client mapping feature requires that certain components from the client connect request match an entry in the jnet_map file. If a valid entry is found then some of the components can be mapped to alternatives before executing the connect request proper. The components that can be mapped are the hostname, the servername and the remoteusername. This feature enables administrators to configure an alternative remoteusername for specific clients or rename a remote system without having to change all the references in the local SYSTEM file.

NOTE Client mapping is invoked before the resolution of the network address and service, therefore the mapped names will be used in place of original to obtain the connection parameters.

CONFIGURATION FILES

Templates for all jRFS configuration files can be found in the "config" subdirectory of the jBASE release directory. It is recommended that the template file are copied to a read only directory and accessed using the JBCNETDIR environment variable. The following files are used for configuration:

DEMONS