Configuring the Linux Server

Pervasive logo

Getting Started with Pervasive.SQL (Server edition)

Configuring the Linux Server

The following sections explain how to get Pervasive.SQL configured on your Linux server.

Security Configuration

The following sections discuss security issues that need to be addressed before using Pervasive.SQL V8.

ODBC/SQL Security

Please refer to Chapter 19, Connecting Clients to a Pervasive.SQL Databasefor specific information on setting up database security for ODBC/SQL applications.

ODBC applications running locally on the server must be run as a user belonging to the same group as that with which the engine was started (the default is pvsw). Please refer to the next section, Btrieve Security, for additional information.

Btrieve Security

Authentication

There are several ways to authenticate Btrieve users in this product. The UnixAuthenticate setting in bti.ini is used to set a preferred method. The default value is WORKGROUP. Just as with the Workgroup engine, all incoming connections are granted. If additional security is required, set UnixAuthenticate to BTPASSWD or PAM. This allows only authorized users to gain access.

While BTPASSWD uses a special user and password database stored in $PVSW_ROOT/etc/btpasswd, PAM (Pluggable Authentication Modules) employs robust and flexible Linux authentication which can utilize your custom authentication schemes. To modify BTPASSWD, use the btadmin utility as described in "Linux Supplementary Documentation" in Pervasive.SQL User's Guide. For PAM, consult your OS documentation about setting up PAM.

If you have a Samba server on the same machine as Pervasive.SQL, another method of authentication is available. See Samba Authentication .

File Access Authorization

Once authentication is complete, the engine will work with Btrieve databases on your behalf. The engine is started with the default user ID psql, group ID pvsw. This means the engine can only access files that are accessible to either this specific user and group or to everyone. This remains true regardless of the authentication method used to connect to the engine or whether the access is remote or local. It is possible to run engines with other user IDs but is not recommended as it can cause a security breach.

Note
It is strongly advised that you not start the engine as root. A warning message will display if you try to do so.

Administrative Right

When working with remote monitor or configuration such as with the Distributed Tuning Interface or Win 32 client utilities, the MKDE checks users and passwords against the $PVSW_ROOT/etc/btpasswd file when UnixAuthenticate is set to WORKGROUP or BTPASSWD. A special admin flag should be set for users that are allowed to access the Distributed Tuning Interface remotely (see "btadmin" in the "Linux Supplementary Documentation" section of Pervasive.SQL User's Guide). When UnixAuthenticate is set to PAM, only members of pvsw-adm group are allowed access.

Using Utilities

See Chapter 14, Application Configuration on Linux for information on this topic.

Supported Path Formats

From Win32 clients, the order of actual parsing is as follows:

\\server\share\relative\path

share denotes a valid Samba share, made accessible to a Windows client.

server reads smb.conf (its location is specified by the SmbConf setting in bti.ini) to determine the absolute path to the shared directory, then combines it with the relative path to get a full UNIX path. The location of smb.conf is essential for valid resolution of the file path supplied in this format on the client. If the relative path is not correct, status 12 is returned.

Drive:\path

drive must be a Samba drive mapped on the client. It is the client responsibility to convert it into the latter format and pass to a server, which never knows a drive mapping on the client.

Note
Client users must be advised that share names on a Linux server are case sensitive. When mapping drives to a Linux server they must pay careful attention to the case of the share name if they want all their utilities to work properly.

If neither smb.conf nor the share name are found, the path defaults to \\server\absolute\path format. If the absolute path is not correct, status 12 is returned.

Server and Client Settings

While these settings can be changed at the server, you can also view and modify them from a Win32 client using the Configuration utility available in the Pervasive Control Center.

Server

Edit $PVSW_ROOT/etc/bti.ini to change settings, and do not forget to restart the engine (/etc/rc.d/init.d/psql restart).

SmbConf=<path>

This defines the path to the Samba configuration file (smb.conf), which is parsed on engine startup to determine mapping between share names and server directory locations.

Note
In order to make changes in smb.conf visible to the engine, you must restart the engine.

UnixAuthenticate={WORKGROUP | BTPASSWD | PAM}

This defines the primary method of authentication used by the server. If you want more security on the server and do not want to store RTSS passwords in the registry, Samba authentication should be used. See Samba Authentication for more information.

WORKGROUP

This is the default. The Workgroup engine is emulated in this mode. All requests for remote connections are granted. Samba authentication is not used in this case.

WORKGROUP should be used while running applications on a trusted network segment or if you must use pre-Service Pack 1 Pervasive.SQL 2000 for clients.

BTPASSWD

The btadmin utility is used to configure user names and passwords. File $PVSW_ROOT/etc/btpasswd stores them. User names and passwords should be specified from the client using the RTSS setting.

BTPASSWD should be used if stronger security is needed for the server and you want user names and passwords different from any user authentication scheme employed on the Linux server.

PAM

Standard Linux authentication is used with PAM. Members of pvsw-adm group can configure and monitor the engine remotely (in addition to root user). User names and passwords should be specified from the client using the pvnetpass utility.

PAM should be used if you want to use existing user names and passwords on the Linux server. PAM is also very flexible and there are many custom PAM modules, especially for Linux. Check the PAM home page http://www.us.kernel.org/pub/linux/libs/pam/ for more information on PAM capabilities.

If UnixAuthenticate is set to BTPASSWD or PAM, the engine requires a user name and password be supplied by the client
To add a user to the btpasswd file run the following command in the directory containing btadmin utility:
% btadmin <username>  
If this user will require administrator rights (to use remote engine configuration via the Pervasive Control Center), type
% btadmin a+ <username>  
If UnixAuthenticate is set to PAM, the engine requires that a user name be specified for the engine daemon using the pvnetpass utility.

pvnetpass -a linuxserver.domain -u psql -p psql

Note
When performing Btrieve operations, if the username or password are incorrect, the MKDE returns Status 94 every time you attempt to create or open database files.

Stored Client Credentials

If you are using BTPASSWD or PAM authentication on your Linux server, user names and passwords must be set up using the pvnetpass utility from clients connecting to this server. You can find information about the pvnetpass utility in the Pervasive.SQL User's Guide at: pvnetpass .

If the client computer is shared by multiple users or needs to have higher security, you may wish to consider Samba Authentication. For further information, see "Samba Authentication" on page 13-9.

Samba Authentication

If you are not emulating the Workgroup engine and the RTSS user name and password are not supplied to the client software, another client authentication method may be used. However, this is only true when there is a Samba server up and running on the computer with Pervasive.SQL V8. It is initiated by the client when other ways of authentication are not available.

How does it work?

The server creates a well-known FIFO share via Samba. FIFO is created in $PVSW_ROOT/etc/pipe/mkde.pip. $PVSW_ROOT/etc/pipe should be shared by Samba as PVPIPE$.

Note
The trailing $ means this share will be hidden. The Pervasive.SQL client components automatically take care of accessing this pipe as \\<server>\PVPIPE$\mkde.pip (case-insensitive); you do not need to perform any explicit actions or modify your application to access this pipe. The only exception to this is if you are troubleshooting your Samba or Pervasive.SQL configurations (see section on Troubleshooting below).

When a client connects to the remote engine and discovers the engine returns UNIX in the version block, it will first look in the registry (RTSS) setting) for authentication information. If the user name and password are not found there, the client connects to the above pipe and receives client authentication information from the server, which will be validated later.
To be authenticated, you must be able to connect to the share and read the pipe. This is one way of specifying who can use the engine and who cannot. The easiest way to do this is to utilize the Samba "valid users" setting in smb.conf (Samba configuration file). If the client is unable to get authentication, status 3106 (The Pervasive Network Services layer encountered a connection failure) will be returned.

How to set up PVPIPE$ for Samba share

While this should be done by the installation procedure (if Samba is installed on the server), an example of setting up the Pervasive pipe is shown below:
 
##################################################### 
[PVPIPE$] 
comment = Pervasive pipes 
 
path = /usr/local/psql/etc/pipe
 
force group = pvsw 
# force group pvsw when accessing pipe - will be 
# useful if primary group for this user is not pvsw 
 
valid users = @pvsw 
# only members of group pvsw will have access 
 
oplocks = False 
# Absolutely necessary - prevents caching on the client 
##################################################### 
To configure access to files shared through Samba, read the Samba documentation.

Note
By allowing a client read access to PVPIPE$, that client is authorized to access the engine remotely.

Troubleshooting

A simple way to ensure the client gets proper authentication is to enter \\<yourserver>\pvpipe$\mkde.pip at the command prompt. You should see a lot of question marks (unprintable symbols), occasional printables and beeps. If you do not, check your Samba configuration to be sure you have rights to read this pipe. If you do but still get error 94, use the Configuration utility to validate your RTSS setting.

Prev
Default Settings

Contents
Up
Check for Revisions

Next
Configuring the Linux Client