Testing and Configuration of the HP Common Internet File System in the Environment Gash, Robert

NRC Publications Archive Archives des publications du CNRC

For the publisher’s version, please access the DOI link below./ Pour consulter la version de l’éditeur, utilisez le lien DOI ci-dessous.

Publisher’s version / Version de l'éditeur: https://doi.org/10.4224/17210708 Student Report; no. SR-2010-05, 2010-04-26

NRC Publications Archive Record / Notice des Archives des publications du CNRC : https://nrc-publications.canada.ca/eng/view/object/?id=3f6609de-394a-482b-846d-63b00888c747 https://publications-cnrc.canada.ca/fra/voir/objet/?id=3f6609de-394a-482b-846d-63b00888c747

Access and use of this website and the material on it are subject to the Terms and Conditions set forth at https://nrc-publications.canada.ca/eng/copyright READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THIS WEBSITE.

L’accès à ce site Web et l’utilisation de son contenu sont assujettis aux conditions présentées dans le site https://publications-cnrc.canada.ca/fra/droits LISEZ CES CONDITIONS ATTENTIVEMENT AVANT D’UTILISER CE SITE WEB.

Questions? Contact the NRC Publications Archive team at [email protected]. If you wish to email the authors directly, please see the first page of the publication for their contact information.

Vous avez des questions? Nous pouvons vous aider. Pour communiquer directement avec un auteur, consultez la première page de la revue dans laquelle son article a été publié afin de trouver ses coordonnées. Si vous n’arrivez pas à les repérer, communiquez avec nous à [email protected]. DOCUMENTATION PAGE

REPORT NUMBER NRC REPORT NUMBER DATE

SR-2010-05 April 2010 REPORT SECURITY CLASSIFICATION DISTRIBUTION

Unclassified Unlimited TITLE

TESTING AND CONFIGURATION OF THE HP COMMON INTERNET FILE SYSTEM IN THE IOT ENVIRONMENT AUTHOR (S)

Robert Gash CORPORATE AUTHOR (S)/PERFORMING AGENCY (S) National Research Council, Institute for Ocean Technology, St. John’s, NL PUBLICATION

SPONSORING AGENCY(S)

National Research Council, Institute for Ocean Technology, St. John’s, NL IOT PROJECT NUMBER NRC FILE NUMBER

KEY WORDS PAGES FIGS. TABLES 17, VMS systems, Compaq Advanced Server, Pathworks App. A 6 software SUMMARY

The National Research Council of Canada’s Institute for Ocean Technology employs the use of HP OpenVMS systems for the purposes of project data collection and storage. The Computer Systems group has chosen these VMS systems for their robust and secure nature. VMS systems are known for lengthy uptimes (sometimes several years) as well as their secure file system and networking model. The people of IOT need a method of conveniently accessing files through Windows file shares. The current method used for accessing these files has become problematic and so investigation into an alternative is required.

ADDRESS National Research Council Institute for Ocean Technology Arctic Avenue, P. O. Box 12093 St. John's, NL A1B 3T5 Tel.: (709) 772-5185, Fax: (709) 772-2462

National Research Council Conseil national de recherches Canada Canada

Institute for Ocean Institut des technologies Technology océaniques

TESTING AND CONFIGURATION OF THE HP COMMON INTERNET FILE SYSTEM IN THE IOT ENVIRONMENT

SR-2010-05

Robert Gash

April 2010 CONTENTS

LIST OF FIGURES ...... ii

1 INTRODUCTION...... 1

1.1 Usage of VMS Within the Institute for Ocean Technology...... 1

1.2 Current Usage of Pathworks on VMS...... 1

1.3 HP CIFS / Samba and its Advantages in the IOT Environment...... 2

2 INSTALLATION AND SETUP ...... 2

2.1 Requirements for Installation ...... 2

2.2 Hardware Used for Testing...... 3

2.3 Installation of HP CIFS 1.1 ...... 4

3 CONFIGURATION AND MANAGEMENT OF HP CIFS ...... 5

3.1 Configuring HP CIFS ...... 5 3.1.1 HP CIFS / Samba as a Domain Member Server ...... 6 3.1.2 Using Winbind to Map Users, Groups, and Permissions ...... 7

3.2 User, Group, and File Permission Management...... 11 3.2.1 Managing Local Users...... 11 3.2.2 Managing Groups...... 11 3.2.3 Directories and File Permission Management ...... 12

3.3 Miscellaneous Configuration Considerations...... 14

4 Conclusion ...... 15

5 Recommendations ...... 16

APPENDIX A ...... A-1

i LIST OF FIGURES

Figure 1 – Troll: Compaq DS20E...... 3

Figure 2 – Winbind Process Flow ...... 7

Figure 3 – Winbind User Mapping...... 9

Figure 4 - Winbind Group Mapping...... 10

Figure 5 – Performing DIR /SEC on Samba Share Directory...... 13

Figure 6 – Setting Samba Share Permissions from Windows...... 14

1 INTRODUCTION

1.1 Usage of VMS Within the Institute for Ocean Technology

1.2 Current Usage of Pathworks on VMS

IOT currently runs Compaq Advanced Server / Pathworks software on VMS cluster nodes as the primary method of creating and hosting Windows-based file shares. While this method is very useful, it is prone to regular incorrect translation of file and directory permissions. These incorrect translations result in a user’s inability to access files and directories. As well, diagnosing access issues as Pathworks problems can be difficult as errors seen by users are often incorrect or cryptic (such as “zero disk quota” errors).

1 1.3 HP CIFS / Samba and its Advantages in the IOT Environment

The HP Common Internet File System (CIFS) is an implementation of the open source Samba protocol. Samba is developed for Unix-based systems and is an open source version of Microsoft’s SMB protocol used for file and printer sharing.

HP CIFS is able to implement the functionality of Samba within VMS systems.

CIFS allows for a more complete implementation of Windows NT file sharing and permissions. It allows for better translation of permissions and user access between VMS and WinNT. HP CIFS is currently the only HP-supported alternative to Pathworks. Testing of CIFS is necessary in order to determine if a complete switch to CIFS from Pathworks is feasible.

2 INSTALLATION AND SETUP

2.1 Requirements for Installation

HP CIFS 1.1 requires HP OpenVMS 8.2 or higher in order to install and run. Prior to the investigation into whether or not CIFS could be a solution, all cluster nodes

(systems) in the IOT VMS cluster were running HP OpenVMS 7.3 or 7.3-2. All systems in the cluster were in use and thus upgrading was not an option. Version

8.2 also contains changes in various environment variables and other system parameters. Upgrading any machine that requires high availability, such as the ones used in VMS cluster, would need prior testing to determine if current startup scripts and procedures can be applied.

HP CIFS 1.1 also requires that Advanced Server / Pathworks not be running on any cluster node that would run CIFS / Samba. Given these requirements, a new

2 Alpha server will be required for testing the use of OpenVMS 8.3 and HP CIFS

1.1.

2.2 Hardware Used for Testing

In order to test HP CIFS 1.1, a Compaq DS20E AlphaServer that recently

finished being used for other purposes was chosen. The DS20E, named Troll, is

a good candidate for this testing as it is among the newer systems available. The

system has two 667 MHz 64-bit Alpha processors, 2 GB of ECC RAM, and HP

OpenVMS 8.3.

Figure 1 – Troll: Compaq DS20E The Computer Systems group raised the concern of the possibility of OpenVMS

Alpha version 8.3 having driver-related issues in the new firmware required to run

the system. These driver issues could cause an increase in network latency and

cause an overall performance decrease in the system. OpenVMS 7.3 and 8.3

were installed on two separate hard drives of equivalent speed within the system.

Booting each separately, SFTP transfers of large files were performed numerous

times and speeds were measured. The final result is that the two operating

3 systems performed network transfers of equal speed on Troll’s 100 Mbit/s copper

(EIA600) network interface card.

2.3 Installation of HP CIFS 1.1

Once the DS20E AlphaServer (Troll) was setup as a standalone server running

HP OpenVMS 8.3, HP CIFS 1.1 was to be installed. In order to install HP CIFS,

the install package was retrieved from HP’s support website. Unpacking this

package to the disk’s top-level directory, the software was installed using the

VMS PCSI install utility by issuing the following command:

TROLL $ PRODUCT INSTALL SAMBA

By not specifying a install directory (using /DESTINATION =

path>), CIFS was installed to the default directory SYS$SYSDEVICE:

[VMS$COMMON]. It is generally recommended that CIFS not be installed to the

VMS system disk. However, since Troll’s purpose is primarily for CIFS, it was

considered reasonable to use this installation method for testing. After this installation was completed, a logical was defined for CIFS management. This

was done by executing:

TROLL $ @SYS$STARTUP:SAMBA$DEFINE_ROOT

And verifying:

TROLL $ SHOW LOG SAMBA$ROOT “SAMBA$ROOT” = “TROLL $DKA0:[SAMBA.]”

To configure the logical names required for CIFS / Samba as well as the

processes required to run the CIFS server, the procedure SAMBA$ROOT:[BIN]

4 SAMBA$CONFIG.COM was run. Executing the SH PROC command shows that the required processes for Samba (SMBD, SMDB445, and SWAT) are running.

To ensure that the proper VMS symbols are defined for Samba, the following

was executed:

TROLL $ @SAMBA$ROOT:[BIN]SAMBA$DEFINE_COMMANDS.COM

To ensure that these symbols are defined after reboot on VMS 8.3, this

command procedure was added to the sylogin.com file.

Finally, to start HP CIFS, the following command must be issued:

TROLL $ @SYS$STARTUP:SAMBA$STARTUP.COM

To start the HP CIFS server when the system boots, the previous and following lines were added to the startup file SYS$STARTUP:SYSSTARTUP_VMS.COM:

@SYS$STARTUP:SAMBA$DEFINE_ROOT.COM

3 CONFIGURATION AND MANAGEMENT OF HP CIFS

3.1 Configuring HP CIFS

Once CIFS / Samba has been installed a system, all configurations required for user authentication and file access must be defined from the HP CIFS configuration file SMB.CONF located in the SAMBA$ROOT:[000000.LIB] directory. The SMB.CONF file uses a Windows .ini configuration file format.

The configuration file is structured to define the services CIFS will share as well as the parameters of the service. A basic SMB.CONF uses a [global] section to define general parameters applied throughout all services, and a [homes] section to define parameters applied towards a user’s “home directory” upon

5 share mapping. All other sections are interpreted as names of other file or print share services to be configured.

3.1.1 HP CIFS / Samba as a Domain Member Server

As part of the existing configuration, a Windows Server 2000 machine (Skute) is the Primary Domain Controller (PDC) for the IOTVMS domain. The IOTVMS domain has established a trust, trusting the existing IOTPC domain. IOTPC’s

PDC is a Windows Server 2003 cluster (Knarr and Karfe). This domain is the primary one used by Windows PC users at IOT, although some users logon directly to the IOTVMS domain as part of an enhanced security model for specific projects. Since authentication of users is done at the domain level, Samba can be configured as a domain member server on the IOTVMS domain.

In order to configure CIFS as a member server, the SMB.CONF file was changed to reflect these settings. Under the [global] section, the following parameters were added:

Security = domain Domain master = no Domain logons = no

Once the configurations were set properly, the server was added to the IOTVMS domain using:

TROLL $ NET RPC JOIN -u

This was verified by adding Troll using the Active Directory Users and

Computers management tool on Skute and adding Troll as a “pre-Windows

2000” account.

6 3.1.2 Using Winbind to Map Users, Groups, and Permissions

Once CIFS was designated as a domain member server, Winbind was chosen to

correctly map domain users to share resources in VMS. As shown in the HP

OpenVMS CIFS Version 1.1 Administrator’s Guide, the following figure shows the winbind process flow:

Figure 2 – Winbind Process Flow 1. A Windows client logs in to the domain (authentication).

2. The Windows domain controller authenticates client and returns user security

data.

3. The Windows client maps an HP CIFS share.

7 4. The HP CIFS Member Server passes the user name to Windows Domain

Controller to verify the user is a domain member.

5. The Windows Domain Controller returns the user authorization and member

SID list.

6. The smbd process passes the SID and user information to the winbind module internal to the SMBD process.

7. Winbind checks the SID and user name against ID mapping data in its mapping database. Winbind either finds the existing mappings between the

Windows SID and the OpenVMS UID/GID or creates a new map if no mapping currently exists.

8. Return the mapped UID or GID from TDB database.

9. Winbind returns UID and GID mappings to smbd.

10. The HP CIFS Server presents the mapped share to the Windows client.

11. The Windows client opens file on the HP CIFS Server share.

12. UID and GID are compared with file owner, group, and any ACE in the ACL.

13. The File open action is accepted or denied based on the result in step 12.

14. The HP CIFS Server returns the open status to the Windows client.

The following lines, defined by the HP CIFS Installation Guide, must be added to the SMB.CONF file to ensure Winbind functionality:

Idmap uid = 5000 - 10000 Idmap gid = 5000 - 10000

Once these parameters are set under the [global] section, winbind is able to map users and groups to domain and local users as shown in the figures below:

Figure 3 – Winbind User Mapping 1. A domain user is authenticated successfully from the Domain Controller or an

ACL is being added based on a user.

2. HP CIFS checks if a mapping exists for the domain user in username map file.

If there is a corresponding mapping, CIFS uses the mapped user.

3. If there is no mapping, HP CIFS checks for a corresponding host user, matching the domain user. If there is a match CIFS uses that host user.

4. If there is no corresponding host user, it obtains the UID for the domain user

SID from the winbind, if enabled.

5. With UID obtained, HP CIFS check for the host user in the format

CIFS$. If there is a user already present in the host system database, HP CIFS maps to this user.

9 6. If no host account exists, HP CIFS creates one named CIFS$<% XUID>, with

a UIC value of [%oUID,%oUID] and maps this to the domain user.

Figure 4 - Winbind Group Mapping 1. An authenticated domain user belongs to a group or a valid ACL is being added based on a group.

2. HP CIFS obtains the GID for the domain group from winbind.

3. HP CIFS checks for a resource identifier of the format CIFS$GRP<%XGID>. If

there is a match, HP CIFS maps the domain group to the matching resource

identifier.

4. If there is no corresponding Resource Identifier, HP CIFS creates it in the

format CIFS$GRP<%XGID>.

10 3.2 User, Group, and File Permission Management

3.2.1 Managing Local Users

Local VMS user accounts can be used as accounts for HP CIFS. As an example,

the account GASHR was used for user account testing on Troll. The GASHR

account was added by copying the default template, SAMBA$TMPLT, and written

through MCR AUTHORIZE:

TROLL $ MCR AUTHORIZE UAF> COPY SAMBA$TMPLT GASHR /UIC=[500,500]/add_identifier

In this setup, the local system account and the IOTVMS domain administrator

account arcticb are allowed in the configuration of admin users in the

SMB.CONF file as follows:

Admin users = system, %D\arcticb

Where ‘%D’ denotes the domain to which Troll is a member, IOTVMS, or a

domain trusted by IOTVMS (IOTPC). Domain users are allowed as well through

the parameter valid users:

Valid users = %D\%U

Where ‘%U’ denotes the current user attempting to access the Samba service.

3.2.2 Managing Groups

HP CIFS offers local group mapping functionality similar to that of the local user mapping discussed in 3.2.1. However, the method employed in testing thus far involves the creation of resource identifiers and associating them with directories.

Since traditional “groups” will be related to IOT Project access, we create project

11 identifiers as resources within VMS. Creating them as resources allows for a

quota to apply to a project directory related to the project identifier, and not the

current user. To create this resource and grant the identifier to a Samba user, the

following must be run:

TROLL $ MCR AUTHORIZE UAF> ADD /ID /ATTRIBUTES=RESOURCE PJ12345 UAF> GRANT /ID/ATTR=RESOURCE PJ12345 GASHR

These identifiers are then granted owner permissions on the project directory of

the same name (see 3.2.3).

3.2.3 Directories and File Permission Management

As discussed in section 3.2.2, the current methods used for “group” access

employs the use of resource identifiers assigned as owners of directories. This

method is useful as it does not require the creation of Samba groups. To create a

project directory on a VMS disk, the following command must be issued:

TROLL $ CREATE /DIR DISK$PROJECT:[PJ12345]

Once the directory has been created, the proper permissions must be applied.

This is done by setting the project resource identifier as owner of the directory as

shown:

TROLL $ SET FILE /OWN=PJ12345 DISK$PROJECT:[000000]PJ12345 .DIR

Once the identifier has been assigned, the proper CIFS permissions must be set.

This can be done manually or by copying another projects permissions. For

12 example, performing a DIR /SEC command in the project directory may show permissions on an existing project as below:

Figure 5 – Performing DIR /SEC on Samba Share Directory

The simplest way to set the permissions on a new project is to simply copy the existing permissions of another project directory to the new directory and edit the

Access Control List (ACL) to change all references to previous identifiers to the new one. This can be done using the following:

TROLL $ SET SEC /LIKE=(NAME=SAMBA$ROOT:[000000.PROJECTS] PJDOUG.dir) DISK$PROJECT:[000000]PJ12345.dir TROLL $ EDIT /ACL DISK$PROJECT:[000000]PJ12345.DIR

13 Once the initial permissions have been set, permissions can be managed from

both the VMS and Windows ends of the system.

Figure 6 – Setting Samba Share Permissions from Windows

This bi-directional flow of permission management should allow for the HP CIFS protocol to not incur the same permission issues as the existing Advanced

Server / Pathworks implementation.

3.3 Miscellaneous Configuration Considerations

As well as the configurations discussed in sections 3.1 and 3.2, there are other

SMB.CONF configurations considered thus far in the testing of CIFS/Samba on

Troll.

In addition to the [global] parameters mentioned, other parameter

considerations include server string (the string advertised to Windows

14 clients when browsing available shares), netbios name, workgroup (the domain that the member server is a member of), encrypt passwords (setting to encrypt plaintext password authentications), log file, show add printer wizard, load printers, printing, and username map.

The [homes] section (which specifies the settings for user “home directories”) uses the parameters comment (similar to server string), browseable (ability for users to browse through all available shares), and read only.

The [projects] section (used for root projects share directory) takes advantage of the browseable and read only parameters, as well as the path parameter to specify the location of the projects directory to CIFS.

The [dka0] section uses parameters similar to that of [projects] but is only accessible by the system account and the IOTVMS domain administrator.

A complete list of available SMB.CONF parameters is available from http://www.samba.org/. A sample SMB.CONF file used in testing of CIFS shares is included as Appendix A.

4 CONCLUSION

From the usage of the HP Common Internet File System software on Troll, it has been seen that its methods of file permission translation between VMS and

Windows NT-based systems have been successful. This system is clearly more robust and reliable than the one currently in place using Advanced Server /

Pathworks software.

15 The configurations used thus far in testing have been very effective. The system

is secure and integrates well into the existing cluster as a node-specific install.

5 RECOMMENDATIONS

HP CIFS was implemented and tested over a limited period of time. This being

the case, it is important to note that Troll is currently the only VMS system using

CIFS. Once other systems are added, other considerations will have to be made.

There are some issues which the author wishes were further investigated.

i) HP CIFS Clustering: HP CIFS has numerous clustering features that

could be beneficial in this environment. A CIFS configuration would

add such features as simultaneous file access through multiple cluster

nodes, load balancing, and failover. In order to take advantage of this,

all cluster nodes would have to run OpenVMS version 8.3, and a single

SAMBA$ROOT directory would have to exist on the SYS$COMMON disk

available to all cluster members.

ii) Authentication: The current implementation of CIFS on the Troll test

server does not keep a local copy of Windows domain SIDs, and

instead authenticates directly from the Primary Domain Controller. If a

shared Samba directory is used across multiple server nodes (or

especially if Samba is installed on each node separately), a shared

LDAP (Lightweight Directory Access Protocol) database should be set

up. Another possible consideration could be the implementation of Troll

as an HP CIFS-based Windows Backup Domain Controller. Other

16 CIFS servers could use this BDC for their authentication database and would reduce load on the IOTVMS and IOTPC domain controllers.

APPENDIX A

SMB.CONF FILE USED IN SAMBA MEMBER SERVER TESTING

A-1

####################################################### # HP CIFS (Samba) for OpenVMS CONFIGURATION # LAST UPDATED: Apr-07-2010, RGASH #######################################################

[global] valid users = %D\%U admin users = %D\arcticb, system server string = TROLL (Samba on OpenVMS) netbios name = %h workgroup = IOTVMS security = domain encrypt passwords = yes log file = /samba$root/var/log_%h.%m show add printer wizard = No load printers = no printing = OpenVMS

idmap uid = 15000-20000 idmap gid = 15000-20000 idmap backend = idmap_tdb winbind use default domain = Yes winbind cache time = 30 #username map = /samba$root/lib/username.map

[homes] comment = Home Directories valid users = %D\%U browseable = no read only = no

[dka0] browseable = no path = /dka0 admin users = %D\arcticb read only = no

[projects] browseable = yes path = /samba$root/projects/ read only = no

A-2